en même temps il n'y à pas de réel intérêt à utiliser ici de tels outils,
le job majeur surtout niveau frontend est simplement une concaténation et minification de multiple .js puis une éventuelle compression gz de la sortie,
il y aura maximum une vingtaine de fichiers, c'est instant, pas besoin d'une gestion des dépendances non modifiées,

et surtout, pourquoi utiliser un outil appelant uglifyjs quant un jolie .sh pourra l'appeler directement ? la même si nous devons utiliser sass pour générer les css ..
après bien sur il peut y avoir des cas spéciaux, genre concaténer des images pour les utiliser comme sprites css ou passer des images en data-url, mais la aussi il y aura des outils dédiés à cette tache, ou au pire 10 lignes de code dans notre langage préféré pourrons gérer la chose ..

le taf à faire, -à mes yeux-, est véritablement minime pour passer du dev à la prod, je ne vois pas l’intérêt d'aller utiliser et apprendre un outil auquel moi et mon projet devront s'adapter
c'est plus je trouve la méthode de "compilation" qui doit s'adapter au projet, sauf si bien sur on adhère complètement à la philosophie d'un outil

> Pour répondre au moindre besoin le plus trivial il existe 3843 bibliothèques toutes plus buggées les unes que les autres, chacune embarquant son lot de 937 dépendances incompatibles.
je ne suis pas d'accord, du moins pas pour le front-end, les lib existantes fonctionnent presque toutes seulement sur des "piliers" (jquery, underscorejs, ..) il est rare qu'elles demandent plus, et la tendance va même vers un retour au vanilla au fur et à mesure que les !== entre navigateurs se gomment,
la multitude de projets est une chance, non un frein, il est certain que du temps doit être dédié à choisir une lib, puis ensuite la tester en profondeur ou non, mais une demo est généralement directement accessible et on juge rapidement si on l'élague du choix initial ou non,

le vrai bordel selon moi est plutôt choisir une lib coté serveur, pas de démo directement visible, une multitude de choix encore plus grande,
on dirait qu'avoir une réputation sur npm est awesome, je ne compte plus les packages de deux lignes wrappant simplement un appel à un outil externe (donc on se base sans vraiment le savoir sur le choix d'un autre dev), avec oui 12000 dépendances, bon npm gère assez bien les dépendances, mais ça deviens très vite un bordel immense pour le déploiement, même si le package.json simplifie le tout il est assez courant qu'un module ne veuille pas se compiler à cause d'une version trop récente des outils ou autre..

le web est actuellement en mode "partisan du moindre effort", on trouvera forcément un outil pour tout, même si s'en passer aurait voulus dire deux simples lignes et 30 secondes sur une doc, utiliser plutôt un truc déjà fait, ultra hype, est mieux, même si l'on va passer x jours à apprendre et s'adapter à l'outil, puis ensuite devoir composer durant des semaines avec ses bugs faiblesses et autres

mais bon, grunt et autres sont tout de même mineurs, le dev web actuel n'est plus un art mais majoritairement du légo, une base déjà faite, un design déjà tout fait, des plugins déjà tout fait, aucune optimisations, on installe pour tester et on laisse, 42 balises script dans la page, les appels bdd se cumulent, et pouf ... deux secondes à générer la page, deux secondes pour qu'elle s'initialise, 30 fichiers en dépendances, et une majorité si ce n'est la totalité du contenu non lisible sans js youhou

c'est peut être le vrai problème, ce désir "d'éradiquer" le classique, d'éclater la base des dev en une multitude de framework kifaittout avec chacun une philosophie propre qui fait bien souvent l'abstraction de la vrai base technique