Electron: Taille du lot d'applications attendue ?

C'est la taille attendue, il n'y a aucun moyen de la réduire.

Faut-il vraiment s'attendre à ce qu'il soit aussi grand? mes versions Windows et Linux fournies sont beaucoup plus petites, et en regardant dans le dossier Electron Framework, il y a trois copies du fichier Electon Framework, une sur chacune :

ContenuFrameworksElectron Framework.framework
ContenuFrameworksElectron Framework.frameworkVersionsA
ContenuFrameworksElectron Framework.frameworkVersionsCurrent

Sont-ils censés être des liens symboliques ?

Quelle est la taille des versions Windows et Linux ?

Je m'interroge aussi à ce sujet. Voici les tailles pour mon application électronique :

osx - 117,3 Mo
 linux32 - 60,3 Mo
 linux64 - 55,2 Mo
 gagner ia32 - 47,8 Mo
 gagner x64 - 66,2 Mo

Merci!

Existe-t-il un plan pour essayer de réduire la taille du framework dans les prochaines versions ? Cela rend difficile la justification de l'utilisation d'Electron pour les petites applications (où la taille de l'application elle-même serait éclipsée par la taille d'Electron).

Je peux confirmer que mes bundles d'applications électroniques sont à peu près de la même taille que @davefedele.

Vous pouvez compresser votre application et si vous utilisez electron-packager vous pouvez ignorer certains modules de nœud dont vous n'avez pas besoin lorsque l'application est en cours d'exécution, cela la rend un peu plus petite. Par exemple, j'ai une application Electron zippée de 37 Mo (Notez que la version Windows est beaucoup plus grande car elle contient une copie de Git).

Mais Electron contiendra toujours une grande partie de Chrome, il n'y a donc pas grand-chose à faire. L'électron lui-même est actuellement d'environ 33 Mo.

OS X compressé est de taille similaire à d'autres plates-formes, ce qui signifie probablement que l'application que vous utilisez pour mesurer les tailles interprète peut-être mal les liens symboliques ?

Dans mon cas, j'utilise une plaque électronique qui n'utilise pas electron-packager et mon dossier d'application électronique est compressé avec un script python et distribué via aws s3. Mon premier cependant était que les liens symboliques n'étaient pas respectés lors de la compression (plutôt que la taille du fichier étant mal interprétée).

Je vais devoir me renseigner, y a-t-il quelque part une liste des liens symboliques présents ? J'ai un accès très limité à un ordinateur mac (j'utilise un serveur CI pour emballer mon application pour chaque plate-forme).

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

J'ai finalement pu examiner cela hier, et en effet, mon problème était dû au fait que les liens symboliques n'étaient pas conservés. Ainsi, la taille de mon application a considérablement diminué, passant de ~110Mbs à ~45Mbs.

@carlosperate Pouvez-vous décrire comment vous avez corrigé vos liens symboliques ?

Eh bien, il est important de souligner que je n'utilise pas electron-packager . J'avais un "script de construction" python (le même script s'exécute sous Windows, Linux et OS x) qui construirait d'autres éléments indépendants de mon application électronique, puis, s'il s'exécutait sur mac, il copierait tout dans les répertoires généraux de l'application OS X, et enfin zip tout dans un seul fichier.

Donc, dans mon cas particulier, il y avait deux problèmes avec mon script, je copiais les fichiers électroniques sans respecter les liens symboliques (très facile à corriger), puis le module zipfile en Python ne respectait pas non plus les liens symboliques, ce qui n'a pas été aussi facile que je m'y attendais. Si vous recherchez des solutions google au problème, vous trouverez quelques articles avec des implémentations étranges qui étaient plus proches de la magie que d'une véritable explication, donc après un certain temps en essayant sans succès de le faire fonctionner, j'ai fini par exécuter un sous-processus qui exécute l'os x Commande CLI zip avec les drapeaux requis pour respecter les liens symboliques.

FWIW, lors de la création d'un zip sur Linux pour une distribution sur OS X, vous devrez utiliser le paramètre -y pour gérer correctement les liens symboliques :

$ zip -r -y app.zip app

Qu'a fait #SLACK ? Pourquoi leur application est-elle si petite ?
Le fichier d'archive zip fait 24,6 Mo.

Les versions Windows et Linux sont plus ou moins ce à quoi je m'attendais, je me demande comment leur version OSX est si petite.

La dernière fois que j'ai vérifié que Slack utilisait

http://electron.atom.io/#built -on-electron Slack est là dans la liste.

Oui, les applications Windows et Linux de Slack sont basées sur Electron, mais l'application Mac utilise MacGap.

@joshaber je pense que tu as raison. L'application Slack mac ne fait qu'environ 36 Mo.

Savez-vous si Electron a un plan pour réduire la taille finale du paquet ? Ce serait incroyable.

Savez-vous si Electron a un plan pour réduire la taille finale du paquet ? Ce serait incroyable.

Il y a peu de choses que vous pouvez retirer de Chromium, Node.js, V8, etc. tout en ayant un produit fonctionnel. Malheureusement, comme tout est corrigé pour fonctionner, ce n'est pas aussi simple que de le faire utiliser des versions autonomes de chacun pour réduire la taille. Je suis sûr que l'équipe Electron aimerait une taille plus petite. Mais vous ne pouvez tout simplement pas planifier et y arriver. Il est tout simplement trop caustique sur l'ensemble du projet pour penser que vous pouvez supprimer même 10 à 20 Mo de code et de ressources et vous attendre à ce que tout fonctionne de manière stable.

Tellement vrai @baconface... Une chose m'a cependant aidé ici: je mettais des modules comme electron-prebuilt, electron-builder et electron-packager et toutes leurs dépendances dans le dossier "app". Les couper du package.json de l'application et les reconstruire m'a fait gagner beaucoup de taille. J'ai utilisé la structure two-package.json d'electron-builder.

@leonelcbraz N'hésitez pas à emprunter ou à obtenir des idées de mon regex ignoré pour electron-packager . Je crée des fichiers exécutables dans le répertoire bin, j'ai un répertoire src pour les fichiers source non minimisés, j'utilise Grunt pour la construction et j'ai d'autres éléments dont je n'ai pas besoin. Si je travaille sur un projet, je n'ai pas besoin d'utiliser le contexte du nœud, je mets simplement nodeIntegration sur false et j'ignore tout le répertoire node_modules. Cela a considérablement réduit la taille de ma distribution.

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

De plus, il n'est pas nécessaire d'utiliser la structure two-package.json. NPM prend en charge les dépendances des développeurs. Vous pouvez en installer un via npm install <package name> --save-dev . Vous remarquerez alors dans votre package.json que vous avez un dependencies et un devDependencies avec vos dépendances bien séparées. En modifiant la regex ignorée pour electron-packager comme je l'ai fait ci-dessus, vous pouvez les isoler complètement de votre application tout en travaillant dans un environnement node.js normal.

Edit : C'est encore plus simple que ça !

Ça me semble bien. Merci pour le partage :)

Slack dispose désormais d'une version bêta Electron du client Mac. L'ancien binaire Mac (utilisant MacGap) était de 36 Mo sur le disque. Le nouveau binaire Mac (utilisant Electron) fait 175 Mo. 124 Mo de cela est le cadre Electron.

@NelsonMinar C'est nul, les gars. Besoin de faire quelque chose avec la taille de l'application.

D'accord.

L'utilisation de @baconface ignore regex a beaucoup aidé à réduire la taille de l'application, j'ai également ignoré manuellement davantage de node_modules qui étaient là et mon application pouvait fonctionner correctement sans, ce qui m'a permis d'atteindre environ 50 Mo de la taille totale de l'application Mac et environ 60 Mo pour Windows.

@pierreraii Content que cela ait aidé. Une note importante est que NPM3 modifie la façon dont le répertoire node_module fonctionne . En conséquence, cette astuce pourrait ne pas répondre à vos attentes. Vous pouvez cependant rétrograder NPM vers la version 2 en utilisant npm i npm<strong i="7">@2</strong> -g .

À l'avenir, notre solution pour notre projet au travail utilisera NPM3, mais en mettant tout ce que nous ne voulons pas expédier en tant que dépendance de développement. Nous installons nos outils de build Electron globalement opposés au niveau du projet. Ensuite, faites une installation des modules nécessaires uniquement avec npm install --only=production . Ce n'est cependant pas idéal pour les projets open source, mais cela fonctionne pour notre bureau. Il est regrettable que nous ayons une configuration étrange comme celle-ci, mais il est peu probable que le NPM soit jamais conçu avec Electron à l'esprit, car il ne s'agit que d'un problème dans l'écosystème du NPM.

oui, dire aux développeurs Web de gérer les électrons en haut s'avère presque impossible. je pense juste à un env qui peut être les deux... actuellement, je base mes applications électroniques sur des serveurs pré-déployés, car ils peuvent avant et pour tous les autres, partageant idéalement les mêmes dépendances. si asar pouvait être un vrai utilisateur fs, alors je considérerais les problèmes de taille et de copie comme résolus, en particulier avec les extensions natives

@baconface Vous n'avez pas à vous soucier de tout cela. Installez simplement vos dépendances comme d'habitude (prod deps dans dependencies et dev deps dans devDependencies ) puis pendant la phase de packaging ( electron-packager fait pour vous) copiez simplement votre dossier d'application dans un répertoire temporaire et exécutez.

npm prune --production

Cela détruira toutes les dépendances de développement, quelle que soit votre version de NPM, ce qui entraînera la taille minimale possible.

vous pouvez obtenir encore 40 à 80 % de plus de suppressions qu'avec --production

vous pouvez obtenir encore 40 à 80 % de plus de suppressions qu'avec --production

Si tel est le cas, vos dépendances sont mal configurées, si vous devez supprimer un module et que prune --production ne le supprime pas, cela signifie qu'il a été reconnu comme une dépendance de production. Le déplacer vers devDependencies entraînera sa suppression.

oh désolé, j'ai oublié de dire : si vous créez un masque de fichier qui supprime le fichier readme, la licence, ... et que node-gyp à lui seul produit 100 fois plus

@xblox Je ne peux qu'imaginer ces fichiers readmes/licences et ceux-ci étant comme des sommets de quelques kilo-octets, une nouvelle astuce intéressante consiste à exécuter yarn clean qui efface automatiquement ces éléments pour vous.

@MarshallOfSound Vous seriez surpris, surtout lorsque vous utilisez des modules natifs. Beaucoup d'ordures traînent. L'approche yarn clean pourrait être bonne

@MarshallOfSound fait votre propre masque de fichier qui vaut chaque centime, c'est toujours surprenant ce qu'il y a à l'intérieur de certains packages. Et c'est bien plus que quelques kilo-octets, mais je vais vérifier la propreté du fil. merci pour le pointeur.

@MarshallOfSound , @paulcbetts : après avoir joué avec yarn clean : il ne nettoie qu'environ 70% de ce qui est possible avec le masque de fichier mentionné

Si nous voulons juste écrire une application hello world sans aucune dépendance de module de nœud, pourquoi le packager continue-t-il de tout déformer ? La solution de pointe consiste à utiliser yarn clean , n'est-ce pas ?

Mes node_modules font 40 Mo et l'électron fait 140 Mo

En utilisant electron-builder et ce fichier glob, je gagne environ 80% sur mon application de bureau

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

Le fait est que cela dépend vraiment des modules que vous utilisez, ce qui rend la maintenance difficile !

@farfromrefug soyez prudent lors de l'expédition de votre application si vous utilisez des bibliothèques open source, il est possible que les bibliothèques que vous utilisez nécessitent que le fichier de licence soit livré avec toutes les applications et que vous les supprimiez toutes aveuglément.

@OmgImAlexis En fait, vous avez raison, je devrais conserver les fichiers de licence. Merci!

Juste un avertissement. electron-packager est suffisamment intelligent pour purger les dépendances répertoriées dans un devDependencies . J'ai donc déplacé la plupart de mes packages vers cela et regroupe les scripts que j'utilise dans un seul fichier JS à l'aide de Grunt. Alors maintenant, mon regex pour ignorer ressemble à ceci "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|build.js)" . Me donne les mêmes résultats mais est beaucoup plus facile et je n'ai pas à ajouter manuellement des chemins de dépendance à mon regex. Fonctionne même avec la façon dont Yarn stocke les dépendances.

J'avais récemment cloné l'exemple de projet à des fins d'apprentissage à partir de https://github.com/electron/simple-samples.git. J'ai créé une application win32 x64 d'activité-moniteur qui se trouve dans le dossier cloné par la commande suivante :
electron-packager C:userlearningnodeclonedAppsimple-samplesactivity-monitor cpu --platform=win32 --arch=x64 --ignore="node_modules"

Je me demandais si la taille du bundle était de 132 Mo pour une simple application.
Existe-t-il un moyen de réduire la taille du paquet ?

J'aurais suggéré d'utiliser UPX sur votre exécutable, qui est multiplateforme, prend en charge de nombreuses architectures et est extrêmement simple à utiliser, mais il semble malheureusement que l'équipe d'Electron préfère ne pas s'incliner là-dessus.
(Déjà demandé précédemment : https://github.com/electron/electron/issues/5506)

Sinon, mes tests ont bien fonctionné en compressant NW.js avec UPX (~ 60% de moins en taille finale) bien que je n'ai pas essayé si cela fonctionne toujours avec la dernière version...
Donc, si la taille compte, peut-être pourriez-vous vous concentrer sur le développement avec celui-ci à la place ?

J'ai pu obtenir ma taille de distribution OSX zippée à 52 Mo en déplaçant electron et à peu près n'importe quel autre package non exécutable vers devDependencies dans package.json , exécutant rm -rf node_modules puis npm install --production .

Lors de l'empaquetage de l'application, electron-packager se plaindrait d'une dépendance electron manquante dans le node_modules . Vous pouvez contourner ce problème en fournissant le drapeau suivant à electron-packager :

--electron-version=1.7.11

Remplacez 1.7.11 par la version electron-packager souhaitée.

@eladnava Merci d'avoir fourni des informations. Je vais vérifier les étapes fournies par vous. Lorsque je convertis l'application en dmg, sa taille est de 53 Mo.

Je ne sais pas/je n'ai pas lu tous les messages précédents, alors merci de me dire si c'est déjà dit.

Est-il possible de séparer le framework Electron lui-même et de simplement expédier les applications ?

Pour autant que je sache, la façon dont les applications Electron sont expédiées est le micrologiciel inclus. Cela ressemble à l'expédition d'une application Java avec JRE inclus.

Est-il possible d'installer un framework Electron sur le système d'exploitation afin que toutes les applications pouvant utiliser cette version l'utilisent ?

@eladnava Vous vous rendez compte que votre application ne fonctionnera pas si electron n'est pas installé sur la machine cible ?

@fab1an : Je pense que @yasinaydin comprend ça. Il veut un runtime Electron commun que les utilisateurs peuvent installer pour toutes leurs applications utilisant Electron. Ceci est déjà discuté dans electron/electron#673, actuellement sans résolution.

@js-choi @fab1an Je ne sais pas exactement comment cela fonctionne, mais j'ai le sentiment qu'Electron est pré-emballé dans electron-packager , dans le Electron Framework.framework qui est inclus dans l'application emballée.

Par conséquent, il n'y a aucune raison de regrouper également electron dans le node_modules votre application. De plus, il n'est pas nécessaire que le package npm electron soit installé sur la machine cible pour que mon approche fonctionne.

electrino a pu créer une application Electron de 115 Mo à seulement 167 Ko en utilisant leur technologie. Je pense que cette technologie doit être intégrée à l'électron, une application hello world de 100 Mo n'est tout simplement pas une taille normale pour afficher "Hello World" :+1:

@spaceywolfi Étant donné qu'Electrino n'exécute pas réellement le moteur Chrome / V8 pour rendre votre application, mais en utilisant le moteur de navigateur Web natif d'OSX (WebKit), vous ne pouvez pas vraiment simplement prendre votre application Electron et la créer avec Electrino, surtout si vous utilisez Les API Electron, car elles ne sont pas disponibles là-bas. Au moins pas encore.

Vous pouvez essayer d'utiliser l'astuce que j'ai mentionnée pour réduire la taille binaire de base à ~ 50 Mo.

@eladnava merci d'avoir expliqué !

@eladnava

Je ne sais pas exactement comment cela fonctionne, mais j'ai le sentiment qu'Electron est pré-regroupé dans un package électronique, dans le cadre Electron Framework.framework qui est inclus dans l'application emballée.

Par conséquent, il n'y a aucune raison de regrouper également des électrons dans les node_modules de votre application. approche du travail.

J'ai electron et electron-packager dans mon devDependencies . De cette façon, je peux affecter electron ./dist/js/main.js à un script dans mon package.json . Ainsi, l'exécution de npm run launch par exemple lancera rapidement une instance non emballée prête à tester de mon application Electron. De plus, electron-packager utilisera la version répertoriée pour electron afin que votre version packagée soit la même que votre version de test d'Electron. Il devrait également supprimer automatiquement electron et electron-packager de la sortie.

@baconbrad

Merci pour votre astuce. J'ai fini par installer electron et electron-packager globalement pour éviter qu'ils ne soient empaquetés dans le dossier node_modules du binaire final. J'ai trouvé que electron-packager n'éliminait pas automatiquement ces dépendances du binaire final, ce qui résultait en une taille binaire d'environ 100 Mo pour moi. Après avoir installé ces deux packages dans le monde, la taille binaire est tombée à ~ 50 Mo.

@eladnava Cela s'est probablement produit parce que vous les aviez en tant que dépendance et non en tant que dépendance de développement. Si vous utilisez npm install packagename --save-dev cela l'enregistrera dans la zone appropriée de votre package.json . Il apparaîtra dans votre dossier node_modules mais sera supprimé une fois emballé.

@baconbrad

C'est tout à fait possible. Mais je pense que puisque les nouvelles versions de npm installent toutes les dépendances de vos dépendances dans le dossier racine du projet node_modules/ , celles-ci ont peut-être été regroupées par electron-packager dans le fichier binaire final .

Savez-vous si electron-packager est assez intelligent pour omettre ces devDependencies ' dépendances ?

@eladnava

Savez-vous si electron-packager est assez intelligent pour omettre les dépendances de ces devDependencies ?

Peut confirmer qu'il omet les dépendances devDependencies . Même si vous utilisez la dernière version de NPM ou Yarn.

Vous devez également utiliser un système de construction comme Gulp ou Grunt pour regrouper les dépendances frontales et les lister également dans devDependencies . C'est parce qu'ils peuvent être livrés avec des fichiers source supplémentaires ou leur devDependencies . La seule fois où j'ai quelque chose dans mon dependencies c'est parce que je dois absolument l'expédier. Vos scripts voudront toujours s'exécuter dans le contexte du nœud, vous devrez donc appeler window.module = module; module = undefined; avant de charger vos scripts groupés dans le contexte du navigateur. Je m'assure ensuite que mon packager l'a dans l'option ignore "(^(/builds|/src)$|[Gg]runt(.*)|.gitignore|buildscript.js)" . Faire toutes ces étapes élimine fondamentalement le groupage excessif des dépendances ou l'inclusion par erreur de fichiers source ou de dossiers de construction.

@baconbrad

Bravo pour les pourboires mon pote !

Salut les gars,

Afin de réduire considérablement la taille de l'application pour tout le monde, d'économiser de la bande passante pour tout le monde, de rendre le processus de construction plus facile pour tout le monde, etc. l'optimisation/la réflexion doit être effectuée différemment que d'ignorer simplement certains node_modules.

Que diriez-vous d'utiliser la même idée que Java et les applications Java utilisent avec succès depuis des décennies : avoir une dépendance à un "JRE" (qui serait un "ERE" dans notre cas).

De cette façon, l'ERE serait installé globalement sur la machine pour la première application qui en a besoin (le processus d'exigence de l'ERE pourrait être automatisé par le programme d'installation de l'application pour chaque plate-forme), puis chaque nouvelle application n'utiliserait que cet ERE existant. .

L'ERE aurait besoin d'une fonction de mise à jour automatique et d'une compatibilité descendante (pas de bcb!) Pour que cela fonctionne, mais je suis presque sûr que c'est trivial.

Ensuite, chaque application Electron ne pèserait que quelques Mo. Gain de temps pour les utilisateurs. Gain de temps et de bande passante pour les développeurs et complexité de construction.

A-t-il déjà été proposé ? Si oui, qu'en est-il alors ? Je pense que c'est la seule et la meilleure voie à suivre.

@RenaudParis Je l'ai proposé avant et peut-être quelques autres, mais je n'ai entendu aucun travail sérieux jusqu'à présent.

@yasinaydin J'ai pensé autant, les gens ont dû y penser avant.

Eh bien, une contribution de l'équipe de développement alors ? @zcbenz Cela rendrait tant de gens heureux et rendrait Electron à l'épreuve du temps (parce que

Le JRE n'est-il pas un bon exemple à suivre ici ?

@RenaudParis et @yasinaydin , il y a tellement de raisons pour lesquelles une installation globale d'électrons n'aura jamais lieu.

Premièrement, parmi toutes les applications d'électrons de production dans la nature, il existe peut-être plus de 20 versions différentes d'électrons utilisées. Quelle version choisiriez-vous d'avoir globalement ? C'est fragmenté comme ça parce que l'électron a un cycle de publication rapide et les développeurs veulent accéder aux dernières fonctionnalités de Chrome.

Nos applications ne sont testées qu'avec une seule version d'électron et pour un téléchargement de 40 Mo, pourquoi aurions-nous le risque et les coûts de support de l'autoriser à s'exécuter sur une autre version aléatoire non testée ?

rendre le processus de construction plus facile pour tout le monde

De nombreuses applications électroniques utilisent des modules natifs qui, dans la plupart des cas, doivent être construits par rapport à la version spécifique de l'électron utilisé. Comment résoudriez-vous ce problème ?

N'hésitez pas à créer une version globale de l'électron que les développeurs peuvent utiliser, mais je pense que vous constaterez que presque personne ne l'utiliserait pour les raisons ci-dessus !

@timfish
there are so many reasons having a global install of electron will never happen.
Cela ressemble à l'un de ceux-ci : https://www.pcworld.com/article/155984/worst_tech_predictions.html

Étant donné que les binaires Node/v8 ou electron ne sont pas si gros, un ERE global peut télécharger les composants manquants pour une utilisation unique, si nécessaire. De plus, une logique de bundle peut être implémentée pour ces ERE globaux, comme Node.js 9.x au lieu de Node.js 9.0, 9.1 séparé, etc.

Je ne sais pas mais je ne pense pas que ce soit l'attitude à adopter pour faire des trucs... "Oh, ça ne peut pas être fait. Oh c'est impossible. Ça n'a aucun sens." Au lieu de cela, il devrait être "Comment pouvons-nous accomplir / contourner ce x ?"

@timfish, c'est une triste nouvelle...

Premièrement, parmi toutes les applications d'électrons de production dans la nature, il existe peut-être plus de 20 versions différentes d'électrons utilisées. Quelle version choisiriez-vous d'avoir globalement ?

Comme je l'ai dit, une compatibilité descendante serait requise.

les développeurs veulent accéder aux dernières fonctionnalités de Chrome

D'où l'amélioration progressive... N'est-ce pas ? Dans tous les cas, même l'amélioration progressive n'est pas obligatoire si une application peut nécessiter une version spécifique de l'ERE, ce qui déclencherait une mise à jour de l'ERE globale.

Comment résoudriez-vous ce problème ?

Si certaines personnes ont besoin de modules spécifiquement compilés, elles sont libres d'intégrer leur propre version personnalisée des modules (qui de toute façon ne serait de toute façon pas disponible dans l'ERE) et de spécifier une version minimale de l'ERE. Si l'ERE est mis à jour vers une version plus récente, je suppose qu'il existe 2 solutions évidentes : soit ils mettent à jour leurs modules (comme avec les dépendances dans Node aujourd'hui), soit nous pourrions également autoriser plusieurs versions globales de l'ERE (comme le JRE). Je pense que ce n'est pas un problème.

l'électron a un cycle de libération rapide

C'est génial, sans aucun doute ici. Mais peut-être que les gens pourraient survivre avec une version mensuelle, limitant ainsi le nombre de versions ERE.

N'hésitez pas à créer une version globale

Ouais... Je ne ferai pas ça. Je n'ai pas les compétences, mais je le ferais si j'en avais.

Je peux simplement proposer des suggestions que je juge pertinentes, et laisser les experts faire leur travail : soit ils me disent que je suis un idiot avec mes suggestions (ce qui peut très bien être le cas), soit ils estiment que cela pourrait conduire à quelque chose de sympa . Peu importe :)

Je pense toujours qu'un ERE global serait la meilleure solution, même si cela signifie avoir plusieurs ERE pour les différents besoins des différentes applications. Mais, encore une fois, ce n'est qu'une idée que j'ai eue en comparant avec le JRE.

@RenaudParis

c'est une triste nouvelle... Personnellement, je ne me soucie pas beaucoup d'un fichier de 40 Mo, mais 120 Mo (comme j'ai entendu), c'est cependant un peu trop pour un bonjour le monde.

120 Mo ne sont pas compressés, si vous le compressez, cela fait environ 40 Mo. Par exemple, VSCode 64 bits pour l'installation EXE de Windows est d'environ 42,8 Mo.

Personnellement, en tant qu'utilisateur, je préférerais toujours avoir une application autonome sans avoir à gérer le JRE global (ou ERE) même si je dois télécharger 200 Mo au lieu de 10 Mo.

Ce n'est pas seulement 120 Mo, j'ai créé une application Web simple qui faisait ~ 1 Mo sur le serveur Web mais ~ 300 Mo en tant qu'application Electron sur OS X

De plus, cela devient plus important lorsque de nombreuses applications Electron s'exécutent sur la même machine.
Il sera alors 10 fois, 20 fois plus gros.
Il existe maintenant plusieurs applications standard sur un ordinateur construit avec Electron comme Slack, VSCode, etc. Et il existe des projets encore plus importants comme NodeOS.

Node.js contient plus de 500 000 modules. Si Electron devenait meilleur, plus rapide, plus populaire et plus petit, il y aurait beaucoup plus d'applications sur un ordinateur de bureau, avec des Go de fichiers Electron inutiles.

Electron n'est tout simplement pas le meilleur framework.

Je préférerais envisager de séparer les parties inutiles du framework Chrome comme Flash, etc.

@yasinaydin

1 Mo sur le serveur Web mais ~ 300 Mo en tant qu'application Electron sur OS X

Vous devez nettoyer votre application avant la distribution (indice : vérifiez vos node_modules). Par exemple, VSCode sur Windows est de 228 Mo après l'installation (l'installation téléchargeable n'est que de 42,8 Mo).

Mais, la taille de l'installation n'est qu'un problème, un autre problème est la quantité de RAM utilisée et le temps de lancement. D'après mon expérience, une fois l'application lancée, la vitesse d'application n'est pas un problème.

Electron n'est pas un bon match pour les petites applications, mais pour les grandes applications comme VSCode, cela fonctionne.

Un autre problème est la quantité de RAM utilisée et le temps de lancement

@mvladic , ne pensez-vous pas que ce sont précisément deux autres problèmes qu'un ERE résoudrait ? Étant déjà chargé et partagé entre les applications, et tout.

D'accord, peut-être que les gens n'ont pas 10 applications Electron en cours d'exécution en même temps... Mais peut-être qu'ils le feront ! Factoriser les dépendances autant que possible est important.

Je comprends qu'Electron a d'abord été lancé en tant que POC, puis avait besoin de versions très fréquentes pour plaire aux développeurs. Mais peut-être que maintenant qu'Electron est plus mature, certaines mesures doivent être prises pour assurer le meilleur {temps de chargement, utilisation de la RAM, taille de téléchargement}.

Encore une fois, je propose juste une solution (naïve peut-être, je ne sais pas) aux problèmes sur lesquels les utilisateurs d'Electron semblent se plaindre depuis le début. Mais en ce qui me concerne, l'état actuel d'Electron ne me dérange vraiment pas pour mes propres petits besoins. Electron est génial, je pense juste à des moyens de le rendre encore meilleur.

Electron n'est tout simplement pas le meilleur framework.

@fab1an , dépend de ce dont les gens ont besoin. Pour moi, il est parfaitement adapté à mes besoins, car je ne suis pas sûr que les PWA soient assez matures. Mais encore une fois, peut-être que Qt conviendrait mieux à d'autres personnes, vous avez raison.

Un runtime a été proposé et discuté avant et est toujours une discussion ouverte . Mais c'est une de ces choses qui est plus facile à dire qu'à faire. Comme vous pouvez le voir, tout le monde n'a pas été en mesure d'être sur la même longueur d'onde ou de trouver comment le faire démarrer correctement, là où il fonctionnera de manière fiable en production. Si vous pensez que vous pouvez contribuer à la discussion ou aider à la démarrer, je pense que personne ne s'opposerait à l'aide supplémentaire.

Beaucoup de développeurs, dont moi-même, sont plutôt satisfaits de télécharger un téléchargement de 40 Mo et de le mettre à jour à l'aide de mises à jour delta plus petites. Les gens d'aujourd'hui n'ont aucun problème à télécharger un programme de 40 Mo. Et même les petits programmes qui font quelques mégas fichiers peuvent télécharger et installer 40 Mo - 2 Go et personne ne semble avoir de problème. avec ça. Même si une option d'exécution était disponible, il est probable qu'un utilisateur ne l'aura pas et devra télécharger plus de 40 Mo pour exécuter votre projet de toute façon.

Si cette mise en garde n'est pas votre tasse de thé, envisagez une autre option si nécessaire. Je ne veux pas dire carrément, parfois vous devez éliminer des technologies pour atteindre l'objectif et les conditions que vous souhaitez rencontrer. Mais cela ne fait pas d'Electron une mauvaise technologie ou la rend inutilisable pour beaucoup d'autres. Electron n'est pas censé résoudre toutes les solutions. Et cela ne le sera jamais de manière réaliste.

@baconbrad si votre commentaire me cible, je ne comprends pas pourquoi, car j'ai dit explicitement à plusieurs reprises que j'étais plutôt content comme ça, et qu'Electron était justement la technologie adaptée à mes besoins (spécifiques).

J'ai seulement dit que j'avais vu beaucoup de gens se plaindre partout de la taille de l'emballage et que j'offrais simplement une solution (encore naïve) à ce problème, qui me semblait idéale. Mais je peux très bien me tromper et en tout cas cela ne m'empêchera absolument pas d'utiliser Electron pour mes besoins futurs :)

Même si une option d'exécution était disponible, il est probable qu'un utilisateur ne l'aura pas et devra télécharger plus de 40 Mo pour exécuter votre projet de toute façon.

Oui mais je connais plein de gens, même ici dans le centre de Paris, qui n'ont qu'une connexion internet à 5 Mbps, et pour ces gens, économiser 40 Mo (c'est-à-dire 320 Mo) pour chaque application, c'est gagner quelques minutes à chaque mise à jour de l'application (ne oubliez que les 40 Mo seront pour chaque mise à jour, pas seulement la première installation), étant donné que leur connexion Internet n'est pas utilisée.

Cela ne prend même pas en compte les économies de RAM, en particulier pour les ordinateurs portables. Encore une fois, je ne me sens pas personnellement concerné car j'ai une machine relativement bonne avec 32 Go de RAM, mais je ne pense pas à moi ici, mais plutôt aux gens qui se plaignent et espèrent trouver une solution pour eux.

Enfin et surtout, vous pouvez avoir une bonne connexion, et moi aussi (une rapide comme l'éclair, s'il vous plaît ! :) ), et nous pouvons tous les deux avoir 16 ou 32 ou 64 Go de RAM, c'est pourquoi vous (vous-même) ne le faites pas. Cela ne vous dérange pas de télécharger les 40 Mo pour chaque mise à jour, mais qu'en est-il de vos utilisateurs (étant donné que vous distribuez votre application aux gens) ?

De toute façon, je ne me battrai pas pour ça, je cherchais seulement à aider, et comme je l'ai dit, je suis plutôt content comme ça, et j'ai plein de choses à faire.

Si certaines personnes pensent que je peux les aider à trouver une solution, je serais ravie de leur donner un coup de main, mais sinon je retournerai travailler :)

À votre santé,

Une chose que j'ai vue lors du déplacement de plus de dépendances vers devDependencies, plus il faut de temps pour le construire.

````
construire le processus principal

• processus de rendu de construction
  ````

Il a passé beaucoup plus de temps à "créer un processus de rendu", et l'icône animée s'est arrêtée comme si elle se plantait, mais ce n'est pas le cas. Ensuite, il affiche 203778 ms du rapport du moteur de rendu.

En déplaçant devDependencies vers les dépendances, le temps de génération est à nouveau normal mais l'application est grande.

Si je n'ai aucune erreur lors de la construction, cela signifie que tout va bien, n'est-ce pas ?

@karimhossenbux C'est normal pour moi. Il existe une fonction de marche dans electron-packager qui passe en revue toutes les dépendances pour déterminer si elles doivent être présentes ou non. Avec les nouvelles dépendances de style plat au lieu des dépendances imbriquées, il faudra beaucoup plus de temps pour déterminer les dépendances inutiles. Pour autant que je sache, il n'y a aucun moyen de contourner le temps de construction supplémentaire.

@baconbrad Merci ! J'utilise electron-builder mais je suppose que cela fonctionne de la même manière.

Existe-t-il un constructeur de packages électroniques qui inclut uniquement votre source et en télécharge d'autres (uniquement nécessaire pour l'utilisateur du système d'exploitation actuel) lorsque l'utilisateur exécute votre application pour la première fois ?. Cela faciliterait la distribution et devrait réduire considérablement la taille de votre application.

Electron, merci de ne pas emprunter la voie "ERE". Oui, je sais que vous êtes gonflé, mais j'aime la façon dont les gens peuvent télécharger mon application et elle fonctionne très bien sans avoir à se soucier de l'installation de deps, de la mise à jour de l'environnement d'exécution ou de toutes ces bêtises dont je pensais que nous nous sommes débarrassés vers 2003 .

Eh bien, le téléchargement d'un bundle serait toujours une option. Rien à redire
à propos d'ici :)

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

Electron, merci de ne pas emprunter la voie "ERE". Oui, je sais que tu es ballonné,
mais j'aime la façon dont les gens peuvent télécharger mon application et elle fonctionne très bien
sans avoir à se soucier de l'installation de deps, de la mise à jour du runtime
l'environnement, ou tout ce non-sens dont je pensais que nous nous sommes débarrassés environ
2003.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/electron/electron/issues/2003#issuecomment-392151709 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/AApUIBjAeVZ7T4SKo8LyW6RT65XnpiKgks5t2FWfgaJpZM4FGGer
.

J'attends juste que les ingénieurs de Microsoft améliorent Electron.
https://news.ycombinator.com/item?id=17229973

J'attends juste que les ingénieurs de Microsoft améliorent Electron.
https://news.ycombinator.com/item?id=17229973

@zcmgyu Microsoft emploie des développeurs pour travailler sur Electron depuis quelques années maintenant, depuis qu'ils ont commencé à l'utiliser pour VS Code. Et ils sont parmi les plus gros contributeurs et l'ont beaucoup amélioré.

Si votre application fait plus de 100 Mo,
il se peut que votre exe comprenne une bonne partie de votre dossier node_modules.
Notez que tout ce qui est déclaré dans package.json dans les dépendances est réimporté dans l'exécutable final.
(Très simple à vérifier : il suffit de décompiler l'exécutable)
N'oubliez donc pas de définir uniquement les bibliothèques essentielles dans les dépendances (electron-log, electron-updater) et d'ajouter toutes les autres bibliothèques dans devDependencies.

Votre application n'aura alors "que" 50 Mo...

Mon application est petite, voici le repo. La dernière version expérimentale pèse environ 700 Mo
https://github.com/DeltaStudioApp/Delta-Studio/tree/experimental

Je m'interroge aussi à ce sujet. Voici les tailles pour mon application électronique :

  osx - 117.3 mb

linux32 - 60,3 Mo
linux64 - 55,2 Mo
gagner ia32 - 47,8 Mo
gagner x64 - 66,2 Mo
Merci!

Incroyable! Pourriez-vous expliquer comment réduire l'application électronique à une si petite taille.