Electron: ¿Tamaño esperado del paquete de aplicaciones?

Ese es el tamaño esperado, no hay forma de hacerlo más pequeño.

¿Realmente se espera que sea tan grande? mis compilaciones de Windows y Linux empaquetadas son mucho más pequeñas, y mirando en la carpeta Electron Framework, hay tres copias del archivo Electon Framework, una en cada una:

ContenidoFrameworksElectron Framework.framework
ContenidoFrameworksElectron Framework.frameworkVersionsA
ContenidoFrameworksElectron Framework.frameworkVersionsCurrent

¿Se supone que son enlaces simbólicos?

¿Qué tan pequeñas son las compilaciones de Windows y Linux?

También me pregunto sobre esto. Estos son los tamaños de mi aplicación de electrones:

osx - 117,3 mb
 linux32 - 60,3 mb
 linux64 - 55,2 mb
 ganar ia32 - 47.8 mb
 ganar x64 - 66.2 mb

¡Gracias!

¿Existe un plan para intentar reducir el tamaño del marco en versiones futuras? Esto hace que sea difícil justificar el uso de Electron para aplicaciones pequeñas (donde el tamaño de la aplicación en sí sería eclipsada por el tamaño de Electron).

Puedo confirmar que mis paquetes de aplicaciones electrónicas tienen aproximadamente el mismo tamaño que @davefedele.

Puede comprimir su aplicación y si está usando electron-packager puede ignorar algunos módulos de nodo que no necesita cuando la aplicación se está ejecutando, esto la hace un poco más pequeña. Por ejemplo, tengo una aplicación Electron comprimida de 37 MB (tenga en cuenta que la versión de Windows es mucho más grande ya que contiene una copia de Git).

Pero Electron siempre tendrá una gran parte de Chrome, por lo que hay mucho que se puede hacer. El propio electrón en este momento es ~ 33 MB.

OS X comprimido tiene un tamaño similar al de otras plataformas, lo que probablemente significa que la aplicación que está utilizando para medir tamaños quizás esté malinterpretando los enlaces simbólicos.

En mi caso, estoy usando un modelo electrónico que no usa electron-packager y la carpeta de mi aplicación electrónica se comprime con un script de Python y se distribuye a través de aws s3. Así que lo primero que pensé fue que los enlaces simbólicos no se respetaron al comprimir (en lugar de malinterpretar el tamaño del archivo).

Tendré que investigarlo, ¿hay alguna lista de los enlaces simbólicos presentes? Tengo un acceso muy limitado a una computadora Mac (uso un servidor CI para empaquetar mi aplicación 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

Finalmente pude investigar esto ayer y, de hecho, mi problema se debió a que los enlaces simbólicos no se conservaban. Así que el tamaño de mi aplicación se redujo drásticamente de ~ 110 Mbs a ~ 45 Mbs.

@carlosperate ¿Puedes describir cómo

Bueno, es importante enfatizar que no estoy usando electron-packager . Tenía un "script de compilación" de Python (el mismo script se ejecuta en Windows, Linux y OS X) que compilaría otras cosas independientes de mi aplicación electrónica, luego, si se ejecutaba en Mac, copiaría todo en los directorios generales del paquete de aplicaciones de OS X, y finalmente comprima todo en un solo archivo.

Entonces, en mi caso específico, hubo dos problemas con mi script, estaba copiando los archivos electron sin respetar los enlaces simbólicos (muy fácil de arreglar), y luego el módulo zipfile en Python tampoco respetaba los enlaces simbólicos, lo cual no fue tan fácil como esperaba. Si busca soluciones al problema en Google, encontrará algunos artículos con implementaciones extrañas que estaban más cerca de la magia que de una explicación real, por lo que después de un tiempo tratando de hacer que funcionara sin éxito, terminé ejecutando un subproceso que ejecuta os x zip comando CLI con los indicadores necesarios para respetar los enlaces simbólicos.

FWIW, al crear un zip en Linux para distribuirlo a OS X, tendrá que usar el parámetro -y para manejar correctamente los enlaces simbólicos:

$ zip -r -y app.zip app

¿Qué ha hecho #SLACK? ¿Por qué su aplicación es tan pequeña?
El archivo zip es de 24,6 MB.

Las versiones de Windows y Linux son más o menos lo que esperaba, me pregunto cómo han conseguido que su versión de OSX sea tan pequeña.

La última vez que verifiqué la holgura estaba usando MacGap para el lado de mac

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

Sí, las aplicaciones de Slack para Windows y Linux se basan en Electron, pero la aplicación para Mac usa MacGap.

@joshaber Creo que tienes razón. La aplicación Slack para mac solo ocupa ~ 36 MB.

¿Saben si Electron tiene algún plan para reducir el tamaño final del paquete? Sería increíble.

¿Saben si Electron tiene algún plan para reducir el tamaño final del paquete? Sería increíble.

Hay mucho que puede sacar de Chromium, Node.js, V8, etc. y aún tener un producto que funcione. Desafortunadamente, dado que todo está parcheado para que funcione, no es tan fácil como usar versiones independientes de cada uno para reducir el tamaño. Estoy seguro de que al equipo de Electron le gustaría un tamaño más pequeño. Pero simplemente no puedes planificar y hacer que suceda. Es demasiado cáustico en el proyecto general pensar que puede eliminar incluso 10-20 megas de código y recursos y esperar que todo funcione de manera estable.

Muy cierto @baconface ... Sin embargo, una cosa me ha ayudado aquí: estaba colocando módulos como electron-prebuilder, electron-builder y electron-packager y todas sus dependencias en la carpeta "app". Cortarlos del package.json de la aplicación y compilarlos de nuevo me ahorró mucho tamaño. Usé la estructura two-package.json de electron-builder.

@leonelcbraz Siéntase libre de pedir prestadas u obtener ideas de mi expresión regular ignorar por electron-packager . Creo archivos ejecutables en el directorio bin, tengo un directorio src para archivos fuente no minificados, uso Grunt para compilar y tengo otras cosas que no necesitaba allí. Si trabajo en un proyecto, no necesito usar el contexto del nodo, simplemente configuro nodeIntegration en false e ignoro todo el directorio node_modules. Esto redujo drásticamente el tamaño de mi distribución.

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

Además, no es necesario utilizar la estructura two-package.json. NPM admite dependencias de desarrolladores. Puede instalar uno a través de npm install <package name> --save-dev . Luego notará en su package.json que tiene dependencies y devDependencies con sus dependencias claramente separadas. Modificando la expresión regular ignorar por electron-packager como hice anteriormente, puede aislarlos por completo de su aplicación y, sin embargo, funcionar en un entorno normal de node.js.

Editar: ¡ Es incluso más fácil que esto!

Eso suena bien. Gracias por compartir :)

Slack ahora tiene una versión beta de Electron del cliente Mac. El antiguo binario de Mac (usando MacGap) tenía 36 MB en el disco. El nuevo binario de Mac (usando Electron) es de 175 MB. 124 MB de eso es el marco electrónico.

@NelsonMinar Esto apesta, amigos. Necesito hacer algo con el tamaño de la aplicación.

Acordado.

Usar @baconface ignore regex ayudó mucho a reducir el tamaño de la aplicación, también

@pierreraii Me alegro de que haya ayudado. Una nota importante es que NPM3 cambia la forma en que funciona el directorio node_module . Como resultado, es posible que este truco no funcione según sus expectativas. Sin embargo, puede degradar NPM a la versión 2 usando npm i npm<strong i="7">@2</strong> -g .

En el futuro, nuestra solución para nuestro proyecto en funcionamiento es utilizar NPM3, pero poner todo lo que no queremos que se envíe como una dependencia de desarrollo. Instalamos nuestras herramientas de construcción de Electron a nivel global opuesto al nivel de proyecto. Luego, haga una instalación de solo los módulos necesarios con npm install --only=production . Sin embargo, esto no es ideal para proyectos de código abierto, pero funciona para nuestra oficina. Es lamentable que tengamos una configuración extraña como esta, pero es dudoso que NPM alguna vez se diseñe con Electron en mente, ya que es solo un problema en el ecosistema de NPM.

sí, decirle a los desarrolladores web que se ocupen de los electrones en la parte superior resulta casi imposible. solo pensando en un env que puede ser ambos ... actualmente baso mis aplicaciones electrón en servidores pre implementados, ya que pueden antes y para todos los demás, idealmente compartiendo las mismas dependencias. si asar pudiera ser un usuario real fs, entonces consideraría resueltos los problemas de tamaño y copia, especialmente con extensiones nativas

@baconface No necesitas preocuparte por nada de eso. Simplemente instale sus dependencias como de costumbre (departamentos de producción en dependencies y departamentos de desarrollo en devDependencies ) y luego, durante la fase de empaquetado ( electron-packager hace esto por usted) simplemente copie la carpeta de su aplicación a un directorio temporal y ejecutar.

npm prune --production

Eso destruirá todas las dependencias de desarrollo independientemente de su versión de NPM, lo que resultará en el tamaño mínimo posible.

puede obtener otro 40-80 +% más eliminado que solo con --producción

puede obtener otro 40-80 +% más eliminado que solo con --producción

Si ese es el caso, sus dependencias están configuradas incorrectamente, si necesita eliminar un módulo y prune --production no lo está eliminando, significa que ha sido reconocido como una dependencia de producción. Moverlo a devDependencies resultará en su eliminación.

oh, lo siento, olvidé decir: si crea una máscara de archivo que elimina el archivo léame, la licencia, ... y el nodo-gyp solo produce 100 pliegues más

@xblox Solo puedo imaginar que esos archivos Léame / licencias son como un máximo de unos pocos kilobytes, un nuevo truco genial es ejecutar yarn clean que borra automáticamente estas cosas por ti.

@MarshallOfSound Te sorprendería, especialmente cuando usas módulos nativos. Mucha basura por ahí. El enfoque yarn clean podría ser bueno

@MarshallOfSound haciendo su propia máscara de archivo que vale cada centavo, siempre es sorprendente lo que hay dentro de algunos paquetes. Y es bastante más que unos pocos kilobytes, pero revisaré el hilo limpio. gracias por la anotación.

@MarshallOfSound , @paulcbetts : después de jugar con yarn clean : limpia solo alrededor del 70% de lo que es posible con la máscara de archivo mencionada

Si solo queremos escribir una aplicación de saludo mundial sin dependencias de módulo de nodo, ¿por qué el empaquetador todavía deforma todo? La solución de vanguardia es usar yarn clean , ¿no es así?

Mis módulos de nodo son 40 MB y el electrón es 140 MB

Usando electron-builder y estos archivos globales, gano alrededor del 80% en mi aplicación de escritorio

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",
]

El caso es que realmente depende de los módulos que uses, ¡lo que hace que sea difícil de mantener!

@farfromrefug tenga cuidado al enviar su aplicación si está usando bibliotecas de código abierto, existe la posibilidad de que las bibliotecas que está usando requieran que el archivo de licencia se envíe con todas las aplicaciones y las esté eliminando ciegamente.

@OmgImAlexis En realidad, tiene razón, debería conservar los archivos de licencia. ¡Gracias!

Solo un aviso. electron-packager es lo suficientemente inteligente como para purgar las dependencias enumeradas en devDependencies . Así que moví la mayoría de mis paquetes a eso y empaqueté los scripts que uso en un solo archivo JS usando Grunt. Así que ahora mi expresión regular para ignorar se parece a esto "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" . Me da los mismos resultados, pero es mucho más fácil y no tengo que agregar manualmente rutas de dependencia a mi expresión regular. Incluso funciona con la forma en que Yarn almacena las dependencias.

Recientemente cloné el proyecto de ejemplo con fines de aprendizaje de https://github.com/electron/simple-samples.git. He creado una aplicación win32 x64 de activity-monitor que está dentro de la carpeta clonada con el siguiente comando:
electron-packager C: userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform = win32 --arch = x64 --ignore = "node_modules"

Me preguntaba que el tamaño del paquete es de 132 Mb para una aplicación simple.
¿Hay alguna forma de reducir el tamaño del paquete?

Hubiera sugerido usar UPX en su ejecutable, que es multiplataforma, admite muchas arquitecturas y es muy fácil de usar, pero desafortunadamente parece que el equipo de Electron prefiere no inclinarse ante esto.
(Ya solicitado anteriormente: https://github.com/electron/electron/issues/5506)

De lo contrario, mis pruebas funcionaron bien al comprimir NW.js con UPX (~ 60% menos en tamaño final) aunque no lo intenté si todavía funciona con la última versión ...
Entonces, si el tamaño importa, ¿tal vez podría concentrarse en desarrollar con este en su lugar?

Pude llevar el tamaño de mi distribución OSX comprimida a 52 MB moviendo electron y prácticamente cualquier otro paquete que no sea de tiempo de ejecución a devDependencies en package.json , ejecutando rm -rf node_modules y luego npm install --production .

Al empaquetar la aplicación, electron-packager se quejaría de una dependencia electron faltante en la node_modules . Puede solucionarlo proporcionando la siguiente marca a electron-packager :

--electron-version=1.7.11

Sustituya 1.7.11 por la versión electron-packager desee.

@eladnava Gracias por

No sé / no leí todos los mensajes anteriores, así que dígame si ya está dicho.

¿Es posible separar el marco de Electron y simplemente enviar las aplicaciones?

Por lo que tengo entendido, se incluye la forma en que se envían las aplicaciones de Electron es el fw. Suena como enviar una aplicación Java con JRE incluido.

¿Es posible instalar un marco Electron en el sistema operativo para que utilicen todas las aplicaciones que pueden usar esa versión?

@eladnava ¿ Te das cuenta de que tu aplicación no se ejecutará si electron no está instalado en la máquina objetivo?

@ fab1an : Creo que @yasinaydin lo entiende. Quiere un tiempo de ejecución común de Electron que los usuarios puedan instalar para todas sus aplicaciones que utilizan Electron. Esto ya se está discutiendo en electron / electron # 673, actualmente sin resolución.

@ js-choi @ fab1an No estoy del todo seguro de cómo funciona, pero tengo la sensación de que Electron viene empaquetado previamente en electron-packager , dentro del Electron Framework.framework que se incluye dentro de la aplicación empaquetada.

Por lo tanto, no hay ninguna razón para agrupar también electron dentro de los node_modules su aplicación. Además, no es necesario que el paquete npm electron se instale en la máquina de destino para que mi enfoque funcione.

electrino pudo hacer una aplicación Electron de 115 MB a solo 167 kB usando su tecnología. Creo que esta tecnología debe integrarse en electron, una aplicación Hello World de 100 MB no tiene un tamaño normal para mostrar "Hello World": +1:

@spaceywolfi Dado que Electrino no está ejecutando el motor Chrome / V8 para renderizar su aplicación, pero usando el motor de navegador web nativo de OSX (WebKit), realmente no puede simplemente tomar su aplicación Electron y construirla con Electrino, especialmente si usa Electron API, ya que no están disponibles allí. Al menos no todavía.

Puede intentar seguir el truco que mencioné para reducir el tamaño binario base a ~ 50 MB.

@eladnava ¡ gracias por explicarme!

@eladnava

No estoy del todo seguro de cómo funciona, pero tengo la sensación de que Electron viene preempaquetado en el empaquetador de electrones, dentro del marco de trabajo de Electron Framework que se incluye dentro de la aplicación empaquetada.

Por lo tanto, no hay ninguna razón para agrupar también electron dentro de los node_modules de su aplicación. enfoque al trabajo.

Tengo electron y electron-packager en mi devDependencies . De esta manera puedo asignar electron ./dist/js/main.js a un script en mi package.json . Entonces, al ejecutar npm run launch por ejemplo, se iniciará rápidamente una instancia sin empaquetar lista para probar de mi aplicación Electron. Además, electron-packager usará la versión listada para electron por lo que su versión empaquetada es la misma que su versión de prueba de Electron. También debería eliminar automáticamente electron y electron-packager de la salida.

@baconbrad

Gracias por tu sugerencia. Terminé instalando electron y electron-packager globalmente para evitar que se empaquetaran en la carpeta node_modules del binario final. Descubrí que electron-packager no eliminó estas dependencias automáticamente del binario final, lo que resultó en un tamaño binario de ~ 100 MB para mí. Después de instalar estos dos paquetes a nivel mundial, el tamaño binario se redujo a ~ 50 MB.

@eladnava Esto probablemente sucedió porque los tenías como una dependencia y no como una dependencia de desarrollo. Si usa npm install packagename --save-dev esto lo guardará en el área adecuada de su package.json . Aparecerá en su carpeta node_modules pero se eliminará una vez empaquetado.

@baconbrad

De hecho, esto es posible. Pero creo que, dado que las versiones más recientes de npm instalan todas las dependencias de sus dependencias en la carpeta del proyecto raíz node_modules/ , estas pueden haber sido empaquetadas por electron-packager en el binario final .

¿Sabes si electron-packager es lo suficientemente inteligente como para omitir esas dependencias devDependencies '?

@eladnava

¿Sabe si el empaquetador de electrones es lo suficientemente inteligente como para omitir esas dependencias de devDependencies?

Puede confirmar que omite las dependencias devDependencies . Incluso si está utilizando la última versión de NPM o Yarn.

También debe usar un sistema de compilación como Gulp o Grunt para agrupar las dependencias de front-end y hacer que también se enumeren en devDependencies . Esto se debe a que pueden enviarse con archivos fuente adicionales o sus devDependencies . La única vez que tengo algo en mi dependencies es porque absolutamente necesito enviarlo. Sus scripts aún querrán ejecutarse en el contexto del nodo, por lo que deberá llamar a window.module = module; module = undefined; antes de cargar sus scripts incluidos en el contexto del navegador. Luego me aseguro de que mi empaquetador tenga esto en la opción de ignorar "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . Hacer todos estos pasos básicamente elimina la dependencia excesiva de volumen o la inclusión por error de archivos de origen o carpetas de compilación.

@baconbrad

¡Salud por las propinas, amigo!

Hola tios,

Para reducir drásticamente el tamaño de la aplicación para todos, ahorrar ancho de banda para todos, facilitar el proceso de compilación para todos, etc., la optimización / pensamiento debe hacerse de manera diferente a simplemente ignorar algunos node_modules.

¿Qué tal usar la misma idea que las aplicaciones Java y Java han estado usando con éxito durante décadas: tener una dependencia de un "JRE" (que sería un "ERE" en nuestro caso).

De esa manera, el ERE se instalaría globalmente en la máquina para la primera aplicación que lo necesite (el proceso de requerir el ERE podría ser automatizado por el instalador de la aplicación para cada plataforma), y luego cada nueva aplicación solo usaría este ERE existente. .

El ERE necesitaría una función de actualización automática y compatibilidad con versiones anteriores (¡no bcb!) Para que esto funcione, pero estoy bastante seguro de que esto es trivial.

Entonces, cada aplicación de Electron tendría un peso de solo un par de MB. Ahorrando tiempo a los usuarios. Ahorrando tiempo y ancho de banda a los desarrolladores y complejidad de construcción.

¿Se ha propuesto antes? Si es así, ¿qué tal entonces? Creo que esta es la única y mejor manera de hacerlo.

@RenaudParis Lo propuse antes y tal vez algunos más, pero hasta ahora no he escuchado trabajos serios.

@yasinaydin Me lo imaginé, la gente debe haber pensado en eso antes.

Bueno, ¿alguna aportación del equipo de desarrollo entonces? @zcbenz Esto haría feliz a mucha gente y haría que Electron

¿No es el JRE un gran ejemplo a seguir aquí?

@RenaudParis y @yasinaydin , hay tantas razones por las que nunca sucederá una instalación global de electrones.

En primer lugar, de todas las aplicaciones de producción de electrones que existen, tal vez haya más de 20 versiones diferentes de electrones en uso. ¿Qué versión elegirías tener a nivel mundial? Está fragmentado así porque electron tiene un ciclo de lanzamiento rápido y los desarrolladores quieren acceder a las últimas funciones de Chrome.

Nuestras aplicaciones solo se prueban con una única versión de electron y, en aras de una descarga de 40 MB, ¿por qué correríamos el riesgo y los costos de soporte de permitir que se ejecute en cualquier otra versión aleatoria no probada?

hacer que el proceso de construcción sea más fácil para todos

Muchas aplicaciones de electrones utilizan módulos nativos que, en la mayoría de los casos, deben construirse con la versión específica de electrones en uso. ¿Cómo solucionarías este problema?

Siéntase libre de crear una versión global de electron que los desarrolladores puedan usar, pero creo que encontrará que casi nadie lo usaría por las razones anteriores.

@timfish
there are so many reasons having a global install of electron will never happen.
Suena como uno de estos: https://www.pcworld.com/article/155984/worst_tech_predictions.html

Dado que los binarios de Node / v8 o electron no son tan grandes, un ERE global puede descargar los componentes faltantes para usarlos una vez, si es necesario. También se puede implementar alguna lógica de paquete para estos ERE globales, como Node.js 9.x en lugar de Node.js 9.0, 9.1, etc.

No lo sé, pero no creo que esa sea la actitud para hacer las cosas ... "Oh, no se puede hacer. Oh, es imposible. No tiene ningún sentido". En su lugar, debería ser "¿Cómo podemos lograr / solucionar esta x?"

@timfish, esta es una noticia triste ... Personalmente, no me importa mucho un archivo de 40 MB, pero 120 MB (como escuché), sin embargo, es demasiado para un hola mundo.

En primer lugar, de todas las aplicaciones de producción de electrones que existen, tal vez haya más de 20 versiones diferentes de electrones en uso. ¿Qué versión elegirías tener a nivel mundial?

Como dije, se requeriría compatibilidad con versiones anteriores.

los desarrolladores quieren acceder a las últimas funciones de Chrome

Por lo tanto, mejora progresiva ... ¿verdad? En cualquier caso, incluso la mejora progresiva no es obligatoria si una aplicación puede requerir una versión específica del ERE, lo que desencadenaría una actualización del ERE global.

¿Cómo solucionarías este problema?

Si algunas personas necesitan módulos compilados específicamente, son libres de incrustar su propia versión personalizada de los módulos (que en cualquier caso no estaría disponible dentro del ERE de todos modos) y especificar una versión mínima del ERE. Si el ERE se actualiza a una versión más reciente, supongo que hay 2 soluciones obvias: o actualizan sus módulos (lo mismo que con las dependencias en Node hoy) o también podríamos permitir múltiples versiones globales del ERE (lo mismo que el JRE). Creo que esto no es un problema.

el electrón tiene un ciclo de liberación rápido

Esto es genial, sin duda aquí. Pero tal vez la gente podría sobrevivir con un lanzamiento mensual, limitando así la cantidad de versiones de ERE.

Siéntete libre de crear una versión global

Sí ... No voy a hacer eso. No tengo las habilidades, pero las tendría si las tuviera.

Simplemente puedo ofrecer sugerencias que considero relevantes y dejar que los expertos hagan su trabajo: o me dicen que estoy siendo un idiota con mis sugerencias (que bien puede ser el caso), o creen que podría conducir a algo bueno. . Lo que :)

Sigo pensando que un ERE global sería la mejor solución, incluso si eso significa tener varios ERE para las diversas necesidades de las diferentes aplicaciones que existen. Pero, de nuevo, esta es solo una idea que tuve al compararlo con el JRE.

@RenaudParis

esta es una noticia triste ... Personalmente, no me importa mucho un archivo de 40 MB, pero 120 MB (como escuché) es demasiado para un hola mundo.

120 MB no están comprimidos, si los comprimes son alrededor de 40 MB. Por ejemplo, VSCode de 64 bits para la instalación de Windows EXE es de alrededor de 42,8 MB.

Personalmente, como usuario, siempre preferiría tener una aplicación autónoma sin la necesidad de administrar JRE (o ERE) global, incluso si tengo que descargar 200 MB en lugar de 10 MB.

No es solo 120 MB, creé una aplicación web simple que era ~ 1 MB en el servidor web pero ~ 300 MB como una aplicación Electron en OS X

Además, esto se vuelve más importante cuando hay muchas aplicaciones de Electron ejecutándose en la misma máquina.
Entonces será 10 veces, 20 veces más grande.
Ahora hay varias aplicaciones estándar en una computadora construida con Electron como Slack, VSCode, etc. Y hay proyectos aún más grandes como NodeOS.

Node.js tiene> 500k módulos. Si Electron se volviera mejor, más rápido, más popular y más pequeño, habría muchas más aplicaciones en un escritorio, con GB de archivos Electron innecesarios.

Electron simplemente no es el mejor marco.

Preferiría dividir las partes innecesarias del marco de Chrome como Flash, etc.

@yasinaydin

1 MB en el servidor web pero ~ 300 MB como una aplicación de Electron en OS X

Necesita limpiar su aplicación antes de la distribución (pista: verifique su node_modules). Por ejemplo, VSCode en Windows tiene 228 MB después de la instalación (la instalación descargable es solo 42,8 MB).

Pero, el tamaño de la instalación es solo un problema. Otro problema es la cantidad de RAM que usa la aplicación y el tiempo de inicio. En mi experiencia, una vez que se inicia la aplicación, la velocidad de la aplicación no es un problema.

Electron no es una buena combinación para aplicaciones pequeñas, pero funciona para aplicaciones grandes como VSCode.

Otro problema es la cantidad de RAM que utiliza la aplicación y el tiempo de inicio.

@mvladic, ¿no crees que precisamente son dos problemas más que arreglaría un ERE? Estar ya cargado y compartido entre aplicaciones, y todo.

De acuerdo, tal vez la gente no tenga 10 aplicaciones de Electron ejecutándose al mismo tiempo ... ¡Pero tal vez sí! Es importante factorizar las dependencias tanto como sea posible.

Entiendo que Electron se lanzó por primera vez como un POC, y luego necesitó lanzamientos muy frecuentes para complacer a los desarrolladores. Pero tal vez ahora que Electron está más maduro, se deban tomar algunas medidas para garantizar el mejor {tiempo de carga, uso de RAM, tamaño de descarga} posible.

Nuevamente, solo estoy proponiendo una solución (ingenua tal vez, no lo sé) para los problemas de los que los usuarios de Electron parecen estar despotricando desde el principio. Pero en lo que a mí respecta, realmente no me importa el estado actual de Electron para mis propias pequeñas necesidades. Electron es genial, solo estoy pensando en formas de hacerlo aún mejor.

Electron simplemente no es el mejor marco.

@ fab1an , depende de lo que necesite la gente. Para mí, se adapta perfectamente a mis necesidades, porque no estoy seguro de que las PWA sean lo suficientemente maduras. Pero, de nuevo, tal vez para otras personas Qt sea más adecuado, tienes razón en eso.

Se ha propuesto y discutido un tiempo de ejecución anteriormente y todavía es una discusión abierta . Pero esta es una de esas cosas que es más fácil decirlo que hacerlo. Como puede ver, no todo el mundo ha podido ponerse en la misma página o descubrir cómo hacer que despegue correctamente donde funcionará de manera confiable en la producción. Si cree que puede contribuir a la discusión o ayudar a comenzar, no creo que a nadie le importe la ayuda adicional.

Muchos desarrolladores, incluyéndome a mí, estamos bastante contentos con realizar una descarga de 40 megas y actualizarla con actualizaciones delta más pequeñas. La gente de hoy no tiene problemas para descargar un programa de 40 megas. E incluso los programas pequeños que tienen un archivo de un par de megas pueden descargar e instalar 40 megas - 2 gigas y nadie parece tener problemas. con eso. Incluso si hubiera una opción de tiempo de ejecución disponible, es probable que un usuario no la tenga y tenga que descargar más de 40 megas para ejecutar su proyecto de todos modos.

Si esta advertencia no es su taza de té, busque otra opción si es necesario. No lo digo sin rodeos, a veces tienes que eliminar tecnologías para cumplir el objetivo y las condiciones que deseas cumplir. Pero esto no convierte a Electron en una mala tecnología ni la hace inutilizable para muchas otras. Electron no está destinado a resolver todas las soluciones. Y, de manera realista, nunca lo hará.

@baconbrad, si su comentario está dirigido a mí, no entiendo por qué, como dije explícitamente varias veces que estaba bastante feliz como está, y que Electron era precisamente la tecnología adecuada para mis necesidades (específicas).

Solo dije que vi a muchas personas quejándose en todas partes sobre el tamaño del paquete y simplemente estaba ofreciendo una solución (nuevamente ingenua) a ese problema, que me parecía ideal. Pero es muy posible que me equivoque y, en cualquier caso, no me impedirá usar Electron para mis necesidades futuras :)

Incluso si hubiera una opción de tiempo de ejecución disponible, es probable que un usuario no la tenga y tenga que descargar más de 40 megas para ejecutar su proyecto de todos modos.

Sí, pero conozco a muchas personas, incluso aquí en el centro de París, que solo tienen una conexión a Internet de 5 Mbps, y para esas personas, ahorrar 40 MB (es decir, 320 Mb) para cada aplicación significa ahorrar un par de minutos cada vez que se actualiza la aplicación (no olvide que los 40 MB serán para cada actualización, no solo para la primera instalación), dado que su conexión a Internet no se utiliza.

Ni siquiera tiene en cuenta el ahorro de RAM, especialmente para los portátiles. Una vez más, no me siento personalmente preocupado porque tengo una máquina relativamente buena con 32 GB de RAM, pero no estoy pensando en mí mismo, sino en la gente que se queja y espera encontrar una solución para ellos.

Por último, pero no menos importante, es posible que tengas una buena conexión, y yo también (¡una increíblemente rápida si lo deseas! :)), y es posible que ambos tengamos 16, 32 o 64 GB de RAM, es por eso que tú (tú mismo) no ' No le importa descargar los 40 MB para cada actualización, pero ¿qué pasa con sus usuarios (dado que distribuye su aplicación a la gente)?

De todos modos, no pelearé por esto, solo buscaba ayudar, y como dije, estoy bastante feliz como está, y tengo muchas cosas que atender.

Si algunas personas piensan que puedo ayudarlas a pensar en una solución, estaré feliz de echarles una mano, pero de lo contrario volveré al trabajo :)

Salud,

Una cosa que vi al mover más dependencias a devDependencies, más tiempo necesita para construirlo.

`` ``
✔ proceso principal de construcción

• proceso de renderizado de construcción
  `` ``

Pasó mucho más tiempo en "construir el proceso del renderizador", y el ícono animado se detiene como si fallara, pero no lo hizo. Luego muestra 203778ms del informe del renderizador.

Moviendo devDependencies nuevamente a las dependencias, el tiempo de compilación es normal nuevamente, pero la aplicación es grande.

Si no tengo ningún error durante la compilación, significa que todo está bien, ¿verdad?

@karimhossenbux Esto es normal para mí. Hay una función de paseo en electron-packager que pasa por todas las dependencias para determinar si deberían estar allí o no. Con las nuevas dependencias de estilo plano en lugar de las anidadas, llevará mucho más tiempo determinar las dependencias innecesarias. Hasta donde yo sé, no hay forma de evitar el tiempo extra de construcción.

@baconbrad ¡ Gracias! Estoy usando electron-builder pero supongo que funciona de la misma manera.

¿Existe algún creador de paquetes de electrones que incluya solo su fuente y descargue otros (solo es necesario para el sistema operativo en el que se ejecuta el usuario actual) cuando el usuario ejecuta su aplicación por primera vez? Facilitaría la distribución y debería reducir considerablemente el tamaño de la aplicación.

Electron, no sigas la ruta "ERE". Sí, sé que estás hinchado, pero me encanta cómo la gente puede descargar mi aplicación y simplemente funciona muy bien sin tener que perder el tiempo instalando departamentos, actualizando el entorno de ejecución o cualquiera de esas tonterías de las que pensé que nos habíamos deshecho alrededor de 2003. .

Bueno, descargar un paquete aún sería una opción. Nada de que quejarse
por aquí :)

Le ven. 25 de mayo de 2018 a las 21:03, Luke Pighetti [email protected] a
écrit:

Electron, no sigas la ruta "ERE". Sí, sé que estás hinchado
pero me encanta cómo la gente puede descargar mi aplicación y funciona muy bien
sin tener que perder el tiempo instalando departamentos, actualizando el tiempo de ejecución
medio ambiente, o cualquiera de esas tonterías de las que pensé que nos habíamos deshecho de
2003.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

Solo estoy esperando que los ingenieros de Microsoft mejoren Electron.
https://news.ycombinator.com/item?id=17229973

Solo estoy esperando que los ingenieros de Microsoft mejoren Electron.
https://news.ycombinator.com/item?id=17229973

@zcmgyu Microsoft ha empleado desarrolladores para trabajar en Electron durante algunos años desde que comenzaron a usarlo para VS Code. Y son algunos de los mayores contribuyentes y lo han mejorado bastante.

Si su aplicación tiene más de 100 MB,
puede ser que su exe incluya una buena parte de su carpeta node_modules.
Tenga en cuenta que todo lo declarado en package.json en las dependencias se vuelve a importar al ejecutable final.
(Muy sencillo de verificar: basta con descompilar el ejecutable)
Así que recuerde definir solo las bibliotecas esenciales en las dependencias (electron-log, electron-Updater) y agregue todas las demás bibliotecas en devDependencies.

Su aplicación tendrá "solo" 50 MB ...

Mi aplicación es pequeña, aquí está el repositorio. La última versión experimental pesa alrededor de 700 MB
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

También me pregunto sobre esto. Estos son los tamaños de mi aplicación de electrones:

  osx - 117.3 mb

linux32 - 60,3 mb
linux64 - 55,2 mb
ganar ia32 - 47.8 mb
ganar x64 - 66.2 mb
¡Gracias!

¡Increíble! ¿Podría compartir sobre cómo reducir la aplicación de electrones a un tamaño tan pequeño?