question utilité webpack and co
Bonjour,
Je me pose plusieurs questions et j'aurais besoin de vous afin de délier le sac de nœud que j'ai dans le cerveau.
Sur chaque page je charge plusieurs scripts différents, par exemple :
Accueil -- une balise script avec une librairie
une balise avec un autre
une balise avec un petit script qui a besoins des deux librairies précédentes
Portfolio -- une balise qui charge lightbox
une balise qui traite le clique des images
.... Bref,
je voudrais uniformiser le tout , et avoir un script accueil, un script portfolio, un script contact par exemple...
Et là entre browserify, webpack, browserify+gulp etc je nage completement.
Pour chaque solution en gros j'ai pas l'impression qu'on puisse faire sortir, 3 scripts différents avec chacun leurs librairies :
Pour Browserify :
D'abord je travail sur le script de la page d'accueil, donc, accueil.js par exemple, je fait mes require de tout ce que j'ai besoin.
Puis dans la console, je fait un coup de browserify accueil.js -o accueil-sortie.js.
Puis après je dois travailler sur le script portfolio, et dans la console, taper browserify portfolio.js -o portfolio-sortie.js.
etc etc ...
Il y a pas moyen de lui dire de surveiller le dossier js entier et de recracher un dossier dist avec 3 scripts différents ?
Pareil pour webpack , ya le point d'entré, un fichier js qui a tout les require et qui recrache le fichier de sortie.
et si je dois travailler sur un autre fichier js, je dois changer le point d'entrée dans ma configuration à chaque fois que je vais travailler sur un script différents ?
Donc en gros tout ses services, sont réellement un gain de temps, que si on cherche à compiler un seul et unique script que toutes les pages vont se partager ?
Ou dans le cas d'une singlepage ?
Que me conseiller vous ?
11 réponses
Un parfait exemple est de regarder ce que font les sites à fort traffic.
Allocine : http://www.allocine.fr vs http://www.allocine.fr/article/fichearticle_gen_carticle=18663820.html
Le premier script contiens les vendors (librairies communes à tout le site, exemple Angular, jQuery,...)
<script type="text/javascript" src="https://assets.allocine.fr/js-21fce013fd59e0ff9c42b12aff967413/allocine/common.universe.js"></script>
<script type="text/javascript" src="https://assets.allocine.fr/js-107bcaf5ee1e149cc2b29febfb86cb80/allocine/newspage.universe.js" defer></script>Le deuxieme est le code spécifique :
<script type="text/javascript" src="https://assets.allocine.fr/js-21fce013fd59e0ff9c42b12aff967413/allocine/common.universe.js"></script>
<script type="text/javascript" src="https://assets.allocine.fr/js-18b79c15e5858ef10efa04f060955a0a/allocine/home.universe.js" defer></script>Google Logique differentes, ils mettent un maximum de code en inline afin de minimiser les connections serveurs, il est d'ailleurs recommandé par google que ta première ligne de flotaisons (comprendre la partie visible entre top:0px et top: 100vh) soit en inline.
amazon même logique que Google, sauf pour les CSS qui eux sont post-traité par un Plugin de leur serveurs web : exemple Google Pagespeed module : https://developers.google.com/speed/pagespeed/module/
instagram même logique que Allocine
<!-- page view-source:https://www.instagram.com/explore/tags/hucktheroofdog/ -->
<script type="text/javascript" src="/static/bundles/fr_FR_Commons.js/34479ee75422.js" crossorigin="anonymous"></script>
<script type="text/javascript" src="/static/bundles/fr_FR_FeedPage.js/56b3ce52354c.js" crossorigin="anonymous"></script>
<--- page view-source:https://www.instagram.com/#reactivated -->
<script type="text/javascript" src="/static/bundles/fr_FR_Commons.js/34479ee75422.js" crossorigin="anonymous"></script>
<script type="text/javascript" src="/static/bundles/fr_FR_FeedPage.js/56b3ce52354c.js" crossorigin="anonymous"></script>Linkedin Même logique que Allocine avec un découplage plus fin :
<script src="https://static.licdn.com/sc/h/br/5xsv3dev5dwa490k3nlyposgr" ></script>
<script src="https://static.licdn.com/sc/h/br/eoj1sxh2kgk5p8atssrqev5bd" ></script>
<script src="https://static.licdn.com/sc/h/br/cavscmitxv5wuye4btxqumc2p"></script><script src="https://static.licdn.com/sc/h/br/55gr22b3eabntxrhch26tca7h"></script>
<script src="https://static.licdn.com/sc/h/br/c5ajddy8ghplgcga8i853jx4j" ></script>Cette fois-ci en "module" au sens large, on parle ici de brique applicatif (tchat, timeline, recherche...).
grafikart Code source compilé dans des outputs uniques.
Je te confirme que les deux solutions sont viable à la fois coté Webpack et coté GulpJS. Au niveau du Watch l'un comme l'autre sont pas si gourmand que ça, tu devrais pas vraiment le sentir.
Enfin il n'y a pas de solution miracle à cette question, ton retour d'experience après un essaie à taille réel t'orientera vers l'une ou l'autre des solutions.
ben generalement on met tous dans un meme fichier, ou alors il faut charger les dependances à la volé, avec systemejs ou autres
Merci de répondre Defy, oui c'est ce que j'ai cru comprendre, donc en gros j'ai un fichier "script.js" et chaque page va charger ce script.
Mais par exemple, pour un back-end, sur la partie création je vais avoir besoin de tinymce par exemple, et je vais l'appliquer à un textarea.
Lorsque je vais être sur ma page d'accueil, je vais avoir une panoplie d'erreur, parce que par exemple il n'y a pas de textarea.
C'est pour ça que jusqu'à présent je chargeais tel ou tel script suivant la page. Mais je suppose que cette manière de fonctionner n'est pas idéal ? Et puis si je veux évoluer un peu et me mettre a la page, avec des Vue js ou autre, va falloir que je revois mes méthodes...
Bonjour,
Pour commencer je te recommande de d'abords experimenter GulpJS plutôt que Webpack qui, à mon sens, est le plus simple à comprendre et intuitif à l'utilisation. Là où webpack gère nativement le require(), il te faudra ajouter à GulpJS le browserify pour inclure tes scripts.
Enfin, l'un comme l'autre, je te conseil pas de tout merge sur un même fichier en sortie. Tu te retrouveras avec un vendor.min.js faisant 2Mo à charger sur chaque page, préfère une structure type :
scripts/app/components/slider.js
scripts/app/pages/homepage/app.js
scripts/app/pages/contact/app.js
scripts/app/pages/contact/module1/foo.js
tu fais deux dossiers pages et components :
- pages contiens le code spécifique d'une page + un app.js qui sera le point d'entré (là où tu as tout les require)
- components contiens tes propres modules génériques
- et biensûr package.json de npm qui te permettra de require des librairies comme tinymce.
Bojour yanis-git,
Merci, ça se rapproche un peu plus de ma manière de fonctionner à première vue, ça m'a l'air un peu plus logique. Oui gulp je m'en sert pour le sass. Mais pour les scripts c'est un peu plus compliqué. Donc si je comprends j'aurais par exemple un dossier avec 3 points d'entrée qui vont "requires" mes scripts génériques ainsi que les librairies qui se trouve dans un autre dossier. Jusque là c'est cool. Mais mon problème se corse pour la sortie; en production à la fin , je devrais charger un script minifié par page. Comment faire compiler ces 3 fichiers en une fois ? Parce que pour faire pointer sur 3 points d'entrées différents ok, mais pour avoir 3 sorties ?
Tout ce que j'ai fait jusqu'à présente, gulp ou webpack, je me retrouve avec un fichier "dist.js" par exemple. C'est possible avec gulp + browserify ?
u te retrouveras avec un vendor.min.js faisant 2Mo à charger sur chaque page
Je ne suis pas d'accorda avec toi pour le coup @yanis-git par exemple, actuellement je travaille sur une application web, mon script front fait plus de 5000 lignes de code et il fait juste 120ko non minifié donc pour avoir 2mo de fichier js minifié il faut y aller. C’est sur que si tu charges jquery et 3000000 plug-ins, mais c'est un peut overkill je trouve.
Super, merci yanis-git pour le lien c'est impeccable ça fonctionne.
Par contre entre toi et defy, dur de vous départager, deux méthodes différentes.
Je dois dire que celle de yanis-git me séduit un peu plus étant donné qu'elle colle à ma logique actuelle. Cependant est il possible de faire de même avec webpack par exemeple ? Peut-être bien que j'opterais pour cet outil un jour et que je devrais me résigner à passer à un seul fichier de sortie... autant prendre les devants dans ce cas.
Il y à un autre point qui me chagrine c'est que sur un gulp watch, s'il surveille tous les points d'entrés à chaque fois en terme de perf c'est pas top non ? c'est pour cela qu'au début j'étais partis sur ce système https://www.baptiste-donaux.fr/gulp-browserify-watchify/
Mais bon le problème était que je me retrouvais avec un seul fichier...
Donc peut être réussir à combiner les deux, mais la je sèche..
Je ne sais pas qu'est ce qui vaut le plus la peine résultat, me prendre la tête à faire plusieurs fichiers de sorties ou me résigner à un seul et faire gaffe à chaque fois de bien tester mon dom, genre si tel div existe alors fait ceci... etc
En tout cas merci de vous pencher sur mon soucis.
Un autre point aussi c'est que le fichier unique va être charger la première fois et avec le cache côté navigateur il ne va plus jamais en refaire la demande.
@quenti77 à raison, surtout couplé à un service worker qui va mettre en cache tous les assets et les redistribué directement depuis le navigateur c'est le top en termes d'archi, surtout si ton application ne doit pas changer toutes les 5 min de design tu gagne en performance et en rapidité de chargement.
Super merci pour ton investissement yanis-git, je pense que je vais partir sur webpack, j'ai réussi enfin à trouver le moyen d'avoir plusieurs entry et plusieur output en regardant de plus près la doc, c'était tout bête, je vais rester sur ma logique, merci pour ton aide ! merci à tous pour les conseils ! a+