Je viens de lire quelques tutoriels sur Webpack et c'est ouf à quel point c'est incroyablement complexe et compliqué pour n'apporter basiquement rien de plus que ce qui se faisait avant

Comment une techno aussi lourde, lente, qui soit aussi casse-couilles à configurer (faire une config Webpack valable et qu'on a pas besoin de modifier à chaque changement dans le code ça relève de l'exploit) a pu réussir à s'imposer sur le marché ?

C'est moi qui loupe un truc par rapport à la valeur ajoutée de Webpack ou quoi ?

Sans compter le côté inmaintenable et magique d'une conf webpack

Salut,

Ce qui se passe quand tu enregistres un fichier (JS par exemple) avec gulp, grunt, brunch, npm : toute la tâche associée au fichier est exécutée. Tous les fichiers JS associées sont recompilés de bout en bout : analysés, lintés, compressés, concaténés, sourcemapés, etc. Si tu utilises browserify ou livereload avec, ton navigateur est rechargé. C'est lourd, et long.

Ce qui se passe quand tu enregistres un fichier (JS par exemple) avec Webpack : La portion modifiée seulement est mise à jour par rapport à avant. Tous les fichiers ne sont pas recompilés, analysés, lintés, compressés, concaténés, sourcemapés, etc. Juste la partie qui a été modifiée. Ton navigateur n'est pas rechargée, la partie modifiée est mise à jour localement. C'est léger et rapide.

Grosso modo, c'est ça.

Oui, Webpack peut s'avérer plus complexe à mettre en place qu'une config gulp/grunt/brunch/autre (encore que tu n'as peut-être jamais vu de config gulp/grunt/brunch/autre bien lourde). Mais ce n'est pas plus complexe à maintenir, et on n'a pas besoin de la modifier à chaque changement de code — du moins, pas plus qu'avec un autre task-runner (car oui, devoir modifier la tâche en cours de projet, ça arrive).

Mais surtout, tu oublies effectivement un point : comme pour une config grunt/gulp/brunch/autre, tu la fais une fois, et tu t'en ressers ensuite pour tous tes projets. Ce n'est pénible qu'une fois, c'est réutilisable à l'infini.

Mais surtout, tu oublies effectivement un point : comme pour une config grunt/gulp/brunch/autre, tu la fais une fois, et tu t'en ressers ensuite pour tous tes projets. Ce n'est pénible qu'une fois, c'est réutilisable à l'infini.

Ca c'est faux, on avait globalement la même idée dans le monde Java avec ant (écrivez votre config XML bien chiante une seule fois et réutilisez la sur tous vos projets) sauf que c'est faux. Non seulement ça doit être mis à jour en permanence, ce qui fait qu'on perd un temps monstre à la maintenance vu que les fichiers de base sont incroyablement difficiles à comprendre.

Après Maven, puis Gradle sont arrivés, avec l'idée de "convention over configuration". Comment on peut avoir autant de retard dans le monde JS ? Me dites pas qu'un outil convention over configuration est impossible en JS, j'y croirais pas. tout le monde se dit "oui mais mon projet est différent" sauf que non, tous les projets sont les mêmes : des sources JS, du CSS, des trucs un peu custom comme du JSX, HAML, SASS, TypeScript, whatever, mais basiquement l'idée est la même : on a des sources à un endroit et on veut les bundler a un autre endroit. Comment on a pu se dire à un moment qu'un truc comme Webpack était une bonne idée plutôt qu'un outil qui imposerait une arborescence ?

Pour la partie "reload atomique" juste des fichiers modifiés ok, c'est effectivement un avantage. Mais quand on sait que Maven, et même GNU make le font depuis 15 ans et 40 ans respectivement, ça force quand même à se poser des questions. Pourquoi refaire exactement les erreurs du passé ? Autoriser d'écrire les fichiers de conf dans un general purpose language ça a toujours été une erreur, c'est aberrant de voir qu'elle est toujours faite et que les gens présentent encore ça comme un avantage

Ca c'est faux, on avait globalement la même idée dans le monde Java avec ant (écrivez votre config XML bien chiante une seule fois et réutilisez la sur tous vos projets) sauf que c'est faux

Ha merde. Heureusement que tu me le dis, ça fait bientôt trois ans qu'on réutilise une config tip top (et updatée régulièrement) à chaque nouveau projet dans ma boite (environs 2 par semaines). J'avais jamais remarqué que ça ne marchait pas, mais maintenant que tu me le dis, j'en prends pleinement conscience !

Bon, sarcasmes mis à part, je ne sais pas :

Comment on peut avoir autant de retard dans le monde JS

Et je ne sais pas non plus :

Pourquoi refaire exactement les erreurs du passé ?

Mais peut-être qu'en fait, ce qui parait être une erreur ou un problème n'en est pas vraiment ? Peut-être que les besoins du web sont très différents des besoins de Java ? Peut-être que Java est un langage foireux ?

Du reste, tu as raison : tous les projets sont basiquement foutus comme ça : un dossier sources, un dossier dist. Bien. Et alors, quel est le rapport avec webpack, exactement ? Webpack n'empêche en rien d'avoir une telle configuration. Je ne comprend pas ce qui te pose problème. Absolument rien n'empêche de faire de la "convention over configuration" avec webpack, gulp, grunt, brunch, npm…

Mais si aucun outil ne convient à ton usage, je t'encourage vivement à créer de nouveaux outils révolutionnaires dont toute la communauté du web (et toi le premier) pourra jouir.

webpack + ES6 + Angular

VueJs*

C'est la journée name-dropping de stack ?!

ES2015 + gulp & babel & browserify + React + Redux

Avec un back qui prend du GraphQL.

Le 03 juillet 2016 à 23:03:37 warpShadow a écrit :
quand tu enregistres un fichier (JS par exemple) avec Webpack : La portion modifiée seulement est mise à jour par rapport à avant. Tous les fichiers ne sont pas recompilés, analysés, lintés, compressés, concaténés, sourcemapés, etc. Juste la partie qui a été modifiée. Ton navigateur n'est pas rechargée, la partie modifiée est mise à jour localement. C'est léger et rapide.

En sachant que la majorité (voir la totalité ?) des compilateurs récents évitent de compiler des fichiers non modifiés pour accélérer le tout. Du coup c'est un gain de temps, autant l'appliquer partout.