Electron: Tamanho esperado do pacote de aplicativos?

Esse é o tamanho esperado, não há como diminuir.

É realmente esperado que seja tão grande? minhas compilações de windows e linux são muito menores e, olhando para a pasta Electron Framework, há três cópias do arquivo Electon Framework, uma em cada:

ContentsFrameworksElectron Framework.framework
ContentsFrameworksElectron Framework.frameworkVersionsA
ContentsFrameworksElectron Framework.frameworkVersionsCurrent

Devem ser links simbólicos?

Quão pequenas são as compilações do Windows e do Linux?

Eu também estou pensando sobre isso. Aqui estão os tamanhos do meu aplicativo de elétrons:

osx - 117,3 MB
 linux32 - 60,3 MB
 linux64 - 55,2 MB
 win ia32 - 47,8 MB
 win x64 - 66,2 MB

Obrigado!

Existe um plano para tentar reduzir o tamanho da estrutura em versões futuras? Isso torna difícil justificar o uso do Electron para aplicativos pequenos (onde o tamanho do próprio aplicativo seria diminuído pelo tamanho do Electron).

Posso confirmar que meus pacotes de apps de elétrons são quase do mesmo tamanho que @davefedele.

Você pode compactar seu aplicativo e, se estiver usando electron-packager pode ignorar alguns módulos de nó que não são necessários quando o aplicativo está em execução, o que o torna um pouco menor. Por exemplo, tenho um aplicativo Electron compactado de 37 MB (a versão do Windows é muito maior, pois contém uma cópia do Git).

Mas o Electron sempre terá uma grande parte do Chrome nele, então não há muito o que fazer. O elétron agora tem cerca de 33 MB.

O OS X compactado tem tamanho semelhante ao de outras plataformas, o que provavelmente significa que o aplicativo que você está usando para medir os tamanhos talvez esteja interpretando mal os links simbólicos.

No meu caso, estou usando um boilerplate de elétrons que não usa electron-packager e minha pasta de aplicativo de elétrons é compactada com um script python e distribuída via aws s3. Então, meu primeiro pensamento foi que os links simbólicos não foram respeitados durante a compactação (em vez de o tamanho do arquivo ser mal interpretado).

Vou ter que dar uma olhada nisso, existe em algum lugar uma lista dos links simbólicos presentes? Tenho acesso muito limitado a um computador mac (uso um servidor CI para empacotar meu aplicativo para cada plataforma).

paul<strong i="5">@psamathe</strong>:/Applications/Slack.app% find . -type l
./Contents/Frameworks/Electron Framework.framework/Electron Framework
./Contents/Frameworks/Electron Framework.framework/Libraries
./Contents/Frameworks/Electron Framework.framework/Resources
./Contents/Frameworks/Electron Framework.framework/Versions/Current
./Contents/Frameworks/Mantle.framework/Headers
./Contents/Frameworks/Mantle.framework/Mantle
./Contents/Frameworks/Mantle.framework/Modules
./Contents/Frameworks/Mantle.framework/Resources
./Contents/Frameworks/Mantle.framework/Versions/Current
./Contents/Frameworks/ReactiveCocoa.framework/Headers
./Contents/Frameworks/ReactiveCocoa.framework/Modules
./Contents/Frameworks/ReactiveCocoa.framework/ReactiveCocoa
./Contents/Frameworks/ReactiveCocoa.framework/Resources
./Contents/Frameworks/ReactiveCocoa.framework/Versions/Current
./Contents/Frameworks/Squirrel.framework/Headers
./Contents/Frameworks/Squirrel.framework/Modules
./Contents/Frameworks/Squirrel.framework/Resources
./Contents/Frameworks/Squirrel.framework/Squirrel
./Contents/Frameworks/Squirrel.framework/Versions/Current

Eu finalmente consegui investigar isso ontem e, de fato, meu problema foi causado por links simbólicos não preservados. Portanto, o tamanho do meu aplicativo diminuiu drasticamente de ~ 110 MB para ~ 45 MB.

@carlosperate Você pode descrever como corrigiu seus links simbólicos?

Bem, é importante enfatizar que não estou usando electron-packager . Eu tinha um "script de compilação" python (o mesmo script é executado no Windows, Linux e os x) que criaria outras coisas independentemente do meu app electron, então se rodasse no Mac, ele copiaria tudo para os diretórios gerais do pacote de apps do OS X, e finalmente, compacte tudo em um único arquivo.

Então, no meu caso específico, houve dois problemas com meu script, eu estava copiando os arquivos de elétrons sem respeitar os links simbólicos (muito fácil de corrigir) e o módulo zipfile em Python também não estava respeitando os links simbólicos, o que não foi tão fácil quanto eu esperava. Se você pesquisar soluções para o problema no Google, encontrará alguns artigos com implementações estranhas que estavam mais perto da mágica do que de uma explicação real, então, depois de algum tempo tentando sem sucesso fazê-lo funcionar, acabei apenas executando um subprocesso que executa o os x zip Comando CLI com os sinalizadores necessários para respeitar os links simbólicos.

FWIW, ao criar um zip no Linux para distribuição para OS X, você terá que usar o parâmetro -y para manipular corretamente os links simbólicos:

$ zip -r -y app.zip app

O que #SLACK fez? Por que seu aplicativo é tão pequeno?
O arquivo zip tem 24,6 MB.

As versões do Windows e do Linux são mais ou menos o que eu esperava, eu me pergunto como eles têm sua versão OSX tão pequena.

A última vez que verifiquei o slack estava usando MacGap para mac side

http://electron.atom.io/#built -on-electron Slack está na lista.

Sim, os aplicativos do Slack para Windows e Linux são construídos no Electron, mas o aplicativo para Mac usa MacGap.

@joshaber , acho que você está correto. O aplicativo Slack mac tem apenas cerca de 36 MB.

Vocês sabem se a Electron tem algum plano para reduzir o tamanho final do pacote? Isso seria incrível.

Vocês sabem se a Electron tem algum plano para reduzir o tamanho final do pacote? Isso seria incrível.

Há muito que você pode tirar do Chromium, Node.js, V8, etc e ainda ter um produto funcionando. Infelizmente, como tudo é corrigido para funcionar, não é tão fácil quanto torná-lo usar versões autônomas de cada um para reduzir o tamanho. Tenho certeza de que a equipe Electron gostaria de um tamanho menor. Mas você simplesmente não pode planejar e fazer acontecer. É muito cáustico no projeto geral pensar que você pode remover até mesmo 10-20 megs de código e recursos e esperar que tudo funcione estável.

Tão verdadeiro @baconface ... Uma coisa me ajudou aqui: eu estava colocando módulos como pré-construído de elétrons, construtor de elétrons e empacotador de elétrons e todas as suas dependências na pasta "app". Cortá-los do package.json do aplicativo e construir novamente me salvou muito de tamanho. Usei a estrutura two-package.json do electron-builder.

@leonelcbraz Sinta-se à vontade para pedir emprestado ou obter ideias da minha regex para ignorar por electron-packager . Eu crio arquivos executáveis ​​no diretório bin, tenho um diretório src para arquivos de origem não minificados, uso o Grunt para compilar e tenho outras coisas que não precisava lá. Se eu trabalhar em um projeto, não preciso usar o contexto de nó, apenas defino nodeIntegration como false e ignoro todo o diretório node_modules. Isso reduziu drasticamente meu tamanho de distribuição.

(^(/bin|/src)$|[Gg]runt(.*)|node_modules/grunt-(.*)|node_modules/electron-(.*))

Além disso, não há necessidade de usar a estrutura two-package.json. O NPM oferece suporte às dependências do desenvolvedor. Você pode instalar um por meio de npm install <package name> --save-dev . Você então notará em seu package.json que tem dependencies e devDependencies com suas dependências separadas ordenadamente. Modificando o regex de ignorar para electron-packager como eu fiz acima, você pode isolá-los completamente do seu aplicativo, ainda que funcione em um ambiente node.js. normal.

Edit: É ainda mais fácil do que isso!

Isso soa bem. Obrigado por compartilhar :)

O Slack agora tem uma versão beta do Electron do cliente Mac. O antigo binário do Mac (usando MacGap) tinha 36 MB no disco. O novo binário do Mac (usando Electron) tem 175 MB. 124 MB disso é o Electron Framework.

@NelsonMinar Isso é uma merda, pessoal. Precisa fazer algo com o tamanho do aplicativo.

Concordou.

Usar @baconface ignore regex ajudou muito na redução do tamanho do aplicativo, eu também ignorei manualmente mais dos node_modules que estavam lá e meu aplicativo poderia funcionar sem problemas, o que me levou a cerca de 50 MB do tamanho total do aplicativo Mac e cerca de 60 MB para Windows.

@pierreraii Ainda bem que ajudou. Uma observação importante é que o NPM3 muda a maneira como o diretório node_module funciona . Como resultado, esse truque pode não funcionar de acordo com suas expectativas. Você pode fazer o downgrade do NPM para a versão 2 usando npm i npm<strong i="7">@2</strong> -g .

No futuro, nossa solução para nosso projeto em funcionamento será usar o NPM3, mas colocar tudo o que não queremos enviado como uma dependência de desenvolvimento. Instalamos nossas ferramentas de construção de elétrons globalmente em oposição ao nível de projeto. Em seguida, fazer uma instalação apenas dos módulos necessários com npm install --only=production . No entanto, isso não é ideal para projetos de código aberto, mas funciona para nosso escritório. É uma pena que tenhamos que ter uma configuração estranha como essa, mas é duvidoso que o NPM algum dia seja projetado com o Electron em mente, já que é apenas um pontinho no ecossistema do NPM.

sim, dizer aos desenvolvedores da web para lidar com o elétron no topo é quase impossível. só pensando em um env que pode ser ambos ... atualmente baseio meus apps de elétrons em servidores pré-implantados, já que podem antes e para todos os outros, idealmente compartilhando as mesmas dependências. se asar pudesse ser um usuário real do fs, consideraria resolvidos os problemas de tamanho e cópia, especialmente com extensões nativas

@baconface Você não precisa se preocupar com nada disso. Simplesmente instale suas dependências normalmente (prod deps em dependencies e dev dep em devDependencies ) e então durante a fase de empacotamento ( electron-packager faz isso para você) simplesmente copie sua pasta de aplicativo para um diretório temporário e execute.

npm prune --production

Isso destruirá todas as dependências de desenvolvimento, independentemente da versão do NPM, resultando no tamanho mínimo possível.

você pode obter outros 40-80 +% a mais excluídos do que apenas com --production

você pode obter outros 40-80 +% a mais excluídos do que apenas com --production

Se for esse o caso, suas dependências estão configuradas incorretamente, se você precisar excluir um módulo e prune --production não o estiver excluindo, significa que foi reconhecido como uma dependência de produção. Movê-lo para devDependencies resultará em sua exclusão.

desculpe, esqueci de dizer: se você construir uma máscara de arquivo que exclui leia-me, licença, ... e o node-gyp sozinho produz 100 dobras a mais

@xblox Eu só posso imaginar esses readmes / licenças e algo parecido com alguns kilobytes no máximo, um novo truque legal é executar yarn clean que automaticamente limpa essas coisas para você.

@MarshallOfSound Você ficaria surpreso, especialmente quando usa módulos nativos. Muito lixo por aí. A abordagem yarn clean pode ser uma boa

@MarshallOfSound fazendo sua própria máscara de arquivo valendo cada centavo, é sempre surpreendente o que está dentro de alguns pacotes. E é muito mais do que apenas alguns kilobytes, mas vou verificar o fio limpo. obrigado pelo ponteiro.

@MarshallOfSound , @paulcbetts : depois de brincar com yarn clean : ele limpa apenas cerca de 70% do que é possível com a máscara de arquivo mencionada

Se quisermos apenas escrever um aplicativo hello world sem nenhuma dependência de módulo de nó, por que o empacotador ainda distorce tudo? A solução mais moderna é usar yarn clean , não é?

Meus node_modules têm 40 MB e electron 140 MB

Usando o electron-builder e esses arquivos, eu ganho cerca de 80% no meu aplicativo de desktop

files:[
"**/*",
                "!**/.*",
                '!buildResources{,/**/*}',
                '!**/node_modules/**/{CONTRIBUTORS,License,CNAME,AUTHOR,TODO,CONTRIBUTING,COPYING,INSTALL,NEWS,PORTING,Makefile,license,LICENCE,LICENSE,htdocs,CHANGELOG,ChangeLog,changelog,README,Readme,readme,test,sample,example,demo,composer.json,tsconfig.json,jsdoc.json,tslint.json,typings.json,gulpfile,bower.json,package-lock,Gruntfile,CMakeLists,karma.conf,yarn.lock}*',
                "!**/node_modules/**/{man,benchmark,node_modules,spec,cmake,browser,vagrant,doxy*,bin,obj,obj.target,example,examples,test,tests,doc,docs,msvc,Xcode,CVS,RCS,SCCS}{,/**/*}",
                "!**/node_modules/**/*.{conf,png,pc,coffee,txt,spec.js,ts,js.flow,html,def,jst,xml,ico,in,ac,sln,dsp,dsw,cmd,vcproj,vcxproj,vcxproj.filters,pdb,exp,obj,lib,map,md,sh,gypi,gyp,h,cpp,yml,log,tlog,Makefile,mk,c,cc,rc,xcodeproj,xcconfig,d.ts,yaml,hpp}",
                "!**/node_modules/**!(dom-to-image).min.js",
                "!**/node_modules/!(serialport|xpc-connection|unix-dgram|mraa)/build{,/**/*}", //prevent duplicate .node
                "!**/node_modules/**/node-v*-x64{,/**/*}", //prevent duplicate .node
                "!**/node_modules/contextify{,/**/*}",
                "!**/node_modules/jsdom{,/**/*}",
                "!**/node_modules/babe-runtime{,/**/*}",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/xterm/dist{,/**/*}",
                "!**/node_modules/source-map/dist{,/**/*}",
                "!**/node_modules/lodash/fp{,/**/*}",
                "!**/node_modules/moment/src{,/**/*}",
                "!**/node_modules/moment/min{,/**/*}",
                // "!**/node_modules/moment/locale/!(fr.js|en.js|ja.js)",
                "!**/node_modules/async/!(dist|package.json)",
                "!**/node_modules/async/internal{,/**/*}",
                "!**/node_modules/ajv/dist{,/**/*}",
                "!**/node_modules/ajv/scripts{,/**/*}",
                "!**/node_modules/asn1/tst{,/**/*}",
                "!**/node_modules/axios/lib{,/**/*}",
                "!**/node_modules/axios/!(index.js|package.json)",
                "!**/node_modules/axios/dist/axios.min.js",
                "!**/node_modules/bluebird/js/browser{,/**/*}",
                "!**/node_modules/dom-to-image/src{,/**/*}",
                "!**/node_modules/xterm/src{,/**/*}",
                "!**/node_modules/qs/dist{,/**/*}",
                "!**/node_moduleslog4js/logs{,/**/*}",
                "!**/node_modulesi18next/!(index.js|package.json|dist)",
                "!**/node_modulesi18next/dist/!(commonjs)",
                "!**/node_modules/viewport-dimensions/dist{,/**/*}",
                "!**/node_modules/validator/!(lib|index.js|package.json|validator.js)",
                "!**/node_modules/moment-timezone/builds{,/**/*}",
                "!**/node_modules/moment-timezone/data/meta{,/**/*}",
                "!**/node_modules/moment-timezone/data/unpacked{,/**/*}",
                "!**/node_modules/node-pre-gyp/!(lib|package.json)",
                "!**/node_modules/node-pre-gyp/lib/!(util|pre-binding.js|node-pre-gyp.js)",
                "!**/node_modules/node-pre-gyp/lib/util/!(versioning.js|abi_crosswalk.json)",
                "!**/node_modules/ssh2/util{,/**/*}",
                "!**/node_modules/source-map-support/browser-source-map-support.js",
                "!**/node_modules/usb/!(package.json|src)",
                "!**/node_modules/opencv/!(package.json|lib)",
                "!**/node_modules/json-schema/!(package.json|lib)",
                "!**/node_modules/hawk/dist/{,/**/*}",
                "!**/node_modules/hawk/lib/browser.js",
]

O fato é que ele realmente depende dos módulos que você usa, o que torna sua manutenção uma dor de cabeça!

@farfromrefug tenha cuidado ao enviar seu aplicativo se você estiver usando libs de código aberto, há uma chance de que as bibliotecas que você está usando exijam que o arquivo de licença seja enviado com todos os aplicativos e você os está removendo cegamente.

@OmgImAlexis Na verdade, você está certo, devo manter os arquivos de licença. Obrigado!

Apenas um aviso. electron-packager é inteligente o suficiente para eliminar dependências listadas em devDependencies . Então, mudei a maioria dos meus pacotes para isso e empacotei os scripts que uso em um único arquivo JS usando o Grunt. Portanto, agora meu regex para ignorar se parece com este "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" . Fornece os mesmos resultados, mas é muito mais fácil e não preciso adicionar caminhos de dependência manualmente ao meu regex. Funciona até com a maneira como o Yarn armazena dependências.

Eu tinha clonado recentemente o projeto de exemplo para fins de aprendizagem em https://github.com/electron/simple-samples.git. Eu criei um aplicativo win32 x64 do monitor de atividades que está dentro da pasta clonada pelo seguinte comando:
electron-packager C: userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform = win32 --arch = x64 --ignore = "node_modules"

Gostaria de saber que o tamanho do pacote é de 132 Mb para apenas um aplicativo simples.
Existe alguma maneira de reduzir o tamanho do pacote?

Eu teria sugerido usar UPX em seu executável, que é multiplataforma, suporta muitas arquiteturas e é muito fácil de usar, mas infelizmente parece que a equipe da Electron prefere não se curvar a isso.
(Já solicitado anteriormente: https://github.com/electron/electron/issues/5506)

Caso contrário, meu teste funcionou bem compactando NW.js com UPX (~ 60% menor no tamanho final), embora eu não tenha tentado se ele ainda funciona com a versão mais recente ...
Então, se o tamanho importa, talvez você possa se concentrar no desenvolvimento com este?

Consegui aumentar meu tamanho de distribuição OSX compactado para 52 MB movendo electron e praticamente qualquer outro pacote não runtime para devDependencies em package.json , executando rm -rf node_modules e então npm install --production .

Ao empacotar o aplicativo, electron-packager reclamaria da falta de electron dependência no projeto node_modules . Você pode contornar isso fornecendo o seguinte sinalizador para electron-packager :

--electron-version=1.7.11

Substitua 1.7.11 pela versão electron-packager desejada.

@eladnava Obrigado por fornecer informações. Vou verificar os passos fornecidos por você. Quando eu converto o aplicativo para dmg, seu tamanho é 53 MB.

Não sei / não li todas as mensagens anteriores, por favor diga-me se já foi dito.

É possível separar o próprio framework Electron e apenas enviar os aplicativos?

Pelo que eu entendi, a forma como os apps do Electron são enviados é o fw incluído. Parece que o envio de um aplicativo Java com JRE incluído nele.

É possível instalar uma estrutura Electron no sistema operacional para que todos os aplicativos que podem usar essa versão o usem?

@eladnava Você percebeu que seu aplicativo não funcionará se o elétron não estiver instalado na máquina-alvo?

@ fab1an : Acho que @yasinaydin entende isso. Ele quer um tempo de execução comum do Electron que os usuários possam instalar para todos os seus aplicativos que usam o Electron. Isso já está sendo discutido no elétron / elétron # 673, atualmente sem resolução.

@ js-choi @ fab1an Não tenho certeza de como funciona, mas tenho a sensação de que o Electron vem pré-empacotado em electron-packager , dentro de Electron Framework.framework que está incluído no aplicativo empacotado.

Portanto, não há razão para agrupar também electron dentro de node_modules seu aplicativo. Além disso, não há necessidade de instalar o pacote npm electron na máquina de destino para que minha abordagem funcione.

A electrino foi capaz de fazer um aplicativo Electron de 115 MB para apenas 167 kB usando sua tecnologia. Acho que essa tecnologia deve ser integrada ao elétron, um aplicativo hello world de 100 MB não tem um tamanho normal para exibir "Hello World": +1:

@spaceywolfi Visto que Electrino não está realmente executando o motor Chrome / V8 para renderizar seu aplicativo, mas usando o motor de navegador nativo do OSX (WebKit), você não pode simplesmente pegar seu aplicativo Electron e construí-lo com Electrino, especialmente se você usar Electron APIs, visto que não estão disponíveis lá. Pelo menos ainda não.

Você pode tentar seguir o truque que mencionei para reduzir o tamanho binário básico para ~ 50 MB.

@eladnava obrigado por explicar!

@eladnava

Não tenho certeza de como funciona, mas tenho a sensação de que o Electron vem pré-empacotado no electron-packager, dentro do Electron Framework.framework que está incluído no aplicativo empacotado.

Portanto, não há razão para empacotar também elétron dentro de node_modules do seu aplicativo. abordagem ao trabalho.

Tenho electron e electron-packager no meu devDependencies . Desta forma, posso atribuir electron ./dist/js/main.js a um script em meu package.json . Portanto, executar npm run launch por exemplo, iniciará rapidamente uma instância desempacotada pronta para testar meu aplicativo Electron. Além disso, electron-packager usará a versão listada para electron portanto, sua versão empacotada é a mesma que sua versão de teste do Electron. Também deve retirar electron e electron-packager da saída automaticamente.

@baconbrad

Obrigado pela sua dica. Acabei instalando electron e electron-packager globalmente para evitar que sejam empacotados na pasta node_modules do binário final. Descobri que electron-packager não removeu essas dependências automaticamente do binário final, o que resultou em um tamanho binário de ~ 100 MB para mim. Depois de instalar esses dois pacotes globalmente, o tamanho do binário caiu para ~ 50 MB.

@eladnava Isso provavelmente aconteceu porque você os tinha como uma dependência e não como uma dependência de dev. Se você usar npm install packagename --save-dev isso o salvará na área apropriada de seu package.json . Ele aparecerá na sua pasta node_modules mas será removido assim que empacotado.

@baconbrad

Isso é realmente possível. Mas eu acho que, como as versões mais recentes de npm instalam todas as dependências de suas dependências na pasta do projeto raiz node_modules/ , elas podem ter sido agrupadas por electron-packager no binário final .

Você sabe se electron-packager é inteligente o suficiente para omitir essas devDependencies 'dependências?

@eladnava

Você sabe se o empacotador de elétrons é inteligente o suficiente para omitir essas dependências devDependencies?

Pode confirmar que omite devDependencies dependências. Mesmo se você estiver usando a versão mais recente do NPM ou Yarn.

Além disso, você deve usar um sistema de compilação como Gulp ou Grunt para agrupar dependências de front end e fazer com que elas sejam listadas em devDependencies também. Isso ocorre porque eles podem ser enviados com arquivos de origem extras ou seus devDependencies . A única vez que tenho algo em meu dependencies é porque absolutamente preciso enviá-lo. Seus scripts ainda vão querer ser executados no contexto do nó, então você precisará chamar window.module = module; module = undefined; antes de carregar seus scripts agrupados no contexto do navegador. Em seguida, certifico-me de que meu empacotador possui isso na opção de ignorar "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . A execução de todas essas etapas basicamente elimina o aumento excessivo de dependências ou a inclusão incorreta de arquivos de origem ou pastas de construção.

@baconbrad

Parabéns pelas dicas cara!

Oi, pessoal,

A fim de reduzir drasticamente o tamanho do aplicativo para todos, economizar largura de banda para todos, tornar o processo de construção mais fácil para todos, etc. a otimização / pensamento deve ser feito de forma diferente do que apenas ignorar alguns node_modules.

Que tal usar a mesma ideia que os aplicativos Java e Java têm usado com sucesso por décadas: ter uma dependência de um "JRE" (que seria um "ERE" em nosso caso).

Dessa forma, o ERE seria instalado globalmente na máquina para o primeiro aplicativo que dele necessitasse (o processo de solicitação do ERE poderia ser automatizado pelo instalador do aplicativo para cada plataforma) e, então, cada novo aplicativo estaria usando apenas este ERE existente .

O ERE precisaria de um recurso de atualização automática e compatibilidade com versões anteriores (sem bcb!) Para que isso funcione, mas tenho quase certeza de que isso é trivial.

Então, cada aplicativo Electron pesaria apenas alguns MB. Economizando tempo dos usuários. Economizando tempo e largura de banda dos desenvolvedores e complexidade de construção.

Já foi proposto antes? Se sim, que tal então? Acho que esse é o único e melhor caminho a percorrer.

@RenaudParis Já propus antes e talvez mais alguns, mas não ouvi nenhum trabalho sério até agora.

@yasinaydin Já pensei

Bem, alguma entrada da equipe de desenvolvimento, então? @zcbenz Isso deixaria tantas pessoas felizes e tornaria a Electron um grande momento à prova de futuro (porque vamos enfrentá-lo: incorporar duas estruturas dentro de cada aplicativo está limitando seriamente o uso de aplicativos menores, esse é um discurso comum que tem acontecido há anos)

O JRE não é um ótimo exemplo a seguir aqui?

@RenaudParis e @yasinaydin , há tantos motivos para uma instalação global do elétron nunca acontecer.

Em primeiro lugar, de todos os aplicativos de produção de elétrons que estão por aí, talvez haja mais de 20 versões diferentes de elétrons em uso. Qual versão você escolheria ter globalmente? Está fragmentado assim porque o electron tem um ciclo de lançamento rápido e os desenvolvedores querem acesso aos recursos mais recentes do Chrome.

Nossos aplicativos são testados apenas com uma única versão do electron e, para um download de 40 MB, por que correríamos o risco e os custos de suporte de permitir que ele rodasse em qualquer outra versão aleatória não testada?

tornar o processo de construção mais fácil para todos

Muitos aplicativos de elétrons usam módulos nativos que, na maioria dos casos, devem ser construídos em relação à versão específica do elétron em uso. Como você resolveria esse problema?

Sinta-se à vontade para criar uma versão global do elétron que os desenvolvedores possam usar, mas acho que você descobrirá que quase ninguém o usaria pelos motivos acima!

@timfish
there are so many reasons having a global install of electron will never happen.
Parece um destes: https://www.pcworld.com/article/155984/worst_tech_predictions.html

Como os binários do Node / v8 ou do elétron não são tão grandes, um ERE global pode baixar componentes ausentes para usar uma vez, se necessário. Além disso, alguma lógica de pacote pode ser implementada para esses EREs globais, como Node.js 9.x em vez de Node.js 9.0, 9.1 etc.

Não sei, mas não acho que essa seja a atitude de fazer as coisas ... "Oh, isso não pode ser feito. Oh, é impossível. Não faz nenhum sentido." Em vez disso, deveria ser "Como podemos realizar / contornar esse x?"

@timfish, são notícias tristes ... Eu pessoalmente não me importo muito com um arquivo de 40 MB, mas 120 MB (como eu ouvi) é um pouco demais para um hello world.

Em primeiro lugar, de todos os aplicativos de produção de elétrons que estão por aí, talvez haja mais de 20 versões diferentes de elétrons em uso. Qual versão você escolheria ter globalmente?

Como eu disse, a compatibilidade com versões anteriores seria necessária.

os desenvolvedores querem acesso aos recursos mais recentes do Chrome

Conseqüentemente, o aprimoramento progressivo ... certo? Em qualquer caso, mesmo o aprimoramento progressivo não é obrigatório se um aplicativo pode exigir uma versão específica do ERE, o que acionaria uma atualização do ERE global.

Como você resolveria esse problema?

Se algumas pessoas precisam de módulos compilados especificamente, eles são livres para incorporar sua própria versão customizada dos módulos (que de qualquer forma não estaria disponível dentro do ERE) e especificar uma versão mínima do ERE. Se o ERE for atualizado para uma versão mais recente, acho que há 2 soluções óbvias: ou eles atualizam seus módulos (o mesmo que as dependências no Node hoje) ou também podemos permitir várias versões globais do ERE (o mesmo que o JRE). Acho que isso não é um problema.

elétron tem um ciclo de liberação rápida

Isso é ótimo, sem dúvida aqui. Mas talvez as pessoas pudessem sobreviver com um lançamento mensal, limitando assim a quantidade de versões ERE.

Sinta-se à vontade para criar uma versão global

Sim ... Não vou fazer isso. Não tenho as habilidades, mas teria se tivesse.

Posso apenas oferecer sugestões que considero relevantes e deixar os especialistas fazerem o seu trabalho: ou eles me dizem que estou sendo um idiota com minhas sugestões (o que pode muito bem ser o caso), ou eles acham que pode levar a algo bom . Qualquer que seja :)

Ainda acho que um ERE global seria a melhor solução, mesmo que isso signifique ter vários EREs para as várias necessidades dos diferentes aplicativos lá fora. Mas, novamente, esta é apenas uma ideia que tive ao comparar com o JRE.

@RenaudParis

isso é uma notícia triste ... Eu pessoalmente não me importo muito com um arquivo de 40 MB, mas 120 MB (como eu ouvi), entretanto, é um pouco demais para um hello world.

120 MB é descompactado, se você compactar fica em torno de 40 MB. Por exemplo, o VSCode de 64 bits para a instalação do Windows EXE tem cerca de 42,8 MB.

Pessoalmente, como usuário, sempre preferiria ter um aplicativo independente sem a necessidade de gerenciar o JRE (ou ERE) global, mesmo que tenha que baixar 200 MB em vez de 10 MB.

Não é apenas 120 MB, eu criei um aplicativo da web simples que tinha cerca de 1 MB no servidor da web, mas cerca de 300 MB como um aplicativo Electron no OS X

Além disso, isso se torna mais importante quando há muitos aplicativos Electron em execução na mesma máquina.
Então será 10 vezes, 20 vezes maior.
Existem agora vários aplicativos padrão em um computador construído com Electron como Slack, VSCode etc. E existem projetos ainda maiores como NodeOS.

Node.js tem> 500k módulos. Se o Electron ficasse melhor e mais rápido e mais popular e menor, haveria muito mais aplicativos em um desktop, com GBs de arquivos Electron desnecessários.

O elétron simplesmente não é a melhor estrutura.

Eu prefiro dividir as partes desnecessárias da estrutura do Chrome, como Flash etc.

@yasinaydin

1 MB no servidor da web, mas ~ 300 MB como um aplicativo Electron no OS X

Você precisa limpar seu aplicativo antes da distribuição (dica: verifique seu node_modules). Por exemplo, o VSCode no Windows tem 228 MB após a instalação (a instalação para download tem apenas 42,8 MB).

Mas, o tamanho da instalação é apenas um problema. Outro problema é a quantidade de RAM que o aplicativo está usando e o tempo de inicialização. Na minha experiência, uma vez que o aplicativo é iniciado, a velocidade do aplicativo não é um problema.

Electron não é uma boa opção para pequenas aplicações, mas para grandes aplicações como o VSCode ele funciona.

Outro problema é a quantidade de RAM que o aplicativo está usando e o tempo de inicialização

@mvladic você não acha que precisamente são mais dois problemas que um ERE resolveria? Já sendo carregado e compartilhado entre aplicativos e todos.

Ok, talvez as pessoas não tenham 10 aplicativos Electron em execução ao mesmo tempo ... Mas talvez tenham! Fatorar dependências tanto quanto possível é importante.

Eu percebi que o Electron foi lançado primeiro como um POC, e então precisava de lançamentos muito frequentes para agradar aos desenvolvedores. Mas talvez agora que o Electron está mais maduro, algumas medidas devem ser tomadas para garantir o melhor possível {tempo de carregamento, uso de ram, tamanho do download}.

Mais uma vez, estou apenas propondo uma solução (talvez ingênua, não sei) para os problemas que os usuários do Electron parecem reclamar desde o início. Mas, no que me diz respeito, realmente não me importo com o estado atual do Electron para minhas pequenas necessidades. Electron é ótimo, estou apenas pensando em maneiras de torná-lo ainda melhor.

O elétron simplesmente não é a melhor estrutura.

@ fab1an , depende do que as pessoas precisam. Para mim, é perfeitamente adequado às minhas necessidades, porque não tenho certeza se os PWAs são maduros o suficiente. Mas, novamente, talvez para outras pessoas o Qt seja mais adequado, você está certo sobre isso.

Um runtime foi proposto e discutido antes e ainda é uma discussão aberta . Mas esta é uma daquelas coisas que é mais fácil falar do que fazer. Como você pode ver, nem todos têm sido capazes de entrar na mesma página ou descobrir como tirá-lo do papel adequadamente, onde funcionará de forma confiável na produção. Se você acha que pode contribuir para a discussão ou ajudar a começar, acho que ninguém se importaria com a ajuda extra.

Muitos desenvolvedores, incluindo eu, estão muito felizes em lançar um download de 40 MB e atualizá-lo usando atualizações delta menores. As pessoas hoje não têm problemas para baixar um programa de 40 meg. E mesmo pequenos programas por aí que têm um arquivo de alguns MB podem baixar e instalar 40 MB - 2 GB e ninguém parece ter problemas. com isso. Mesmo se uma opção de tempo de execução estivesse disponível, é provável que o usuário não a tenha e tenha que baixar mais de 40 MB para executar seu projeto de qualquer maneira.

Se esta advertência não for do seu agrado, procure outra opção, se necessário. Não quero dizer isso sem rodeios, às vezes você tem que eliminar tecnologias para cumprir a meta e as condições que deseja atender. Mas isso não torna o Electron uma tecnologia ruim nem o torna inutilizável para muitos outros. O elétron não foi feito para resolver todas as soluções. E realisticamente nunca será.

@baconbrad se o seu comentário é a tecnologia adequada para minhas necessidades (específicas).

Eu apenas disse que via muita gente reclamando do tamanho da embalagem por toda parte e eu estava apenas oferecendo uma solução (mais uma vez ingênua) para aquele problema, que me parecia ideal. Mas posso muito bem estar enganado e, de qualquer forma, isso não me impedirá de usar o Electron para minhas necessidades futuras :)

Mesmo se uma opção de tempo de execução estivesse disponível, é provável que o usuário não a tenha e tenha que baixar mais de 40 MB para executar seu projeto de qualquer maneira.

Sim, mas eu conheço muitas pessoas, mesmo aqui no centro de Paris, que têm apenas uma conexão de Internet de 5 Mbps e, para essas pessoas, economizar 40 MB (ou seja, 320 Mb) para cada aplicativo significa economizar alguns minutos cada vez que o aplicativo é atualizado (não esqueça que os 40MB serão para cada atualização, não apenas para a primeira instalação), visto que sua conexão com a internet não é utilizada.

Nem mesmo levando em consideração a economia de RAM, especialmente para notebooks. Novamente, não me sinto pessoalmente preocupado, pois tenho uma máquina relativamente boa com 32 GB de RAM, mas não estou pensando em mim aqui, mas sim nas pessoas reclamando e esperando encontrar uma solução para elas.

Por último, mas não menos importante, você pode ter uma boa conexão, e eu também (uma muito rápida, por favor! :)), e podemos ambos ter 16 ou 32 ou 64 GB de RAM, é por isso que você (você) não l Importa-se de baixar os 40 MB para cada atualização, mas e quanto aos seus usuários (já que você distribui seu aplicativo para as pessoas)?

De qualquer forma, não vou brigar por isso, só estava procurando ajudar, e como disse estou bem feliz do jeito que está, e tenho muito que fazer.

Se algumas pessoas acharem que posso ajudá-las a pensar em uma solução, ficarei feliz em ajudar, mas, caso contrário, voltarei ao trabalho :)

Saúde,

Uma coisa que vi quando movi mais dependências para devDependencies, mais tempo é necessário para criá-lo.

`` ``
✔ processo principal de construção

• construção de processo de renderização
  `` ``

Ele gastou muito mais tempo no "processo de construção de renderização", e o ícone animado parou como se tivesse travado, mas não parou. Em seguida, ele mostra 203778ms do relatório do renderizador.

Movendo devDependencies de volta às dependências, o tempo de compilação é normal novamente, mas o aplicativo é grande.

Se não estou tendo nenhum erro durante a compilação, isso significa que está tudo bem, certo?

@karimhossenbux Isso é normal para mim. Existe uma função walk em electron-packager que passa por todas as dependências para determinar se elas deveriam estar lá ou não. Com as novas dependências de estilo simples em vez das aninhadas, demorará muito mais para determinar as dependências desnecessárias. Pelo que eu sei, não há como contornar o tempo extra de compilação.

@baconbrad Obrigado! Estou usando electron-builder mas acho que funciona da mesma maneira.

Existe algum construtor de pacote de elétrons que inclui apenas sua fonte e outros downloads (necessários apenas para o sistema operacional atual em que o usuário é executado) quando o usuário executa seu aplicativo pela primeira vez? Isso facilitaria a distribuição e reduziria consideravelmente o tamanho do seu aplicativo.

Elétron, por favor, não siga a rota "ERE". Sim, eu sei que você está inchado, mas adoro como as pessoas podem baixar meu aplicativo e ele funciona muito bem sem ter que bagunçar com a instalação de deps, atualizar o ambiente de execução ou qualquer dessas bobagens de que pensei que tivéssemos nos livrado por volta de 2003 .

Bem, baixar um pacote ainda seria uma opção. Nada para reclamar
sobre aqui :)

Le ven. 25 mai 2018 à 21:03, Luke Pighetti [email protected] a
écrit:

Elétron, por favor, não siga a rota "ERE". Sim, eu sei que voce esta inchado,
mas adoro como as pessoas podem baixar meu aplicativo e ele funciona muito bem
sem ter que mexer com a instalação de dep., atualizando o tempo de execução
ambiente, ou qualquer daquelas bobagens que eu pensei que tivéssemos nos livrado de cerca de
2003

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

Estou apenas esperando os engenheiros da Microsoft melhorarem o Electron.
https://news.ycombinator.com/item?id=17229973

Estou apenas esperando os engenheiros da Microsoft melhorarem o Electron.
https://news.ycombinator.com/item?id=17229973

@zcmgyu A Microsoft

Se seu aplicativo tiver mais de 100 MB,
pode ser que seu exe inclua uma boa parte de sua pasta node_modules.
Observe que tudo declarado em package.json nas dependências é importado de volta para o executável final.
(Muito simples de verificar: basta descompilar o executável)
Portanto, lembre-se de definir apenas as libs essenciais nas dependências (electron-log, electron-updater) e adicionar todas as outras libs em devDependencies.

Seu aplicativo terá então "apenas" 50 MB ...

Meu aplicativo é pequeno - aqui está o repositório. A última versão experimental pesa cerca de 700 MB
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

Eu também estou pensando sobre isso. Aqui estão os tamanhos do meu aplicativo de elétrons:

  osx - 117.3 mb

linux32 - 60,3 MB
linux64 - 55,2 MB
win ia32 - 47,8 MB
win x64 - 66,2 MB
Obrigado!

Surpreendente! Você poderia compartilhar sobre como reduzir a aplicação de elétrons a um tamanho tão pequeno.