1

Je viens de tomber au pif sur un article de blog sur un mec qui explique pourquoi il faudrait arrêter d'utiliser Grunt, Gulp et cie. Pour info il s'agit de (cet article mais pas besoin de le lire, mon post ne porte pas directement là-dessus. Si vous ne connaissez pas Grunt et Gulp le reste de mon message risque d'être peu clair, donc je me risque à une définition minimaliste :

Grunt, Gulp et quelques dizaines d'autres outils équivalents (oui, réellement) permettent d’exécuter des tâches programmatiquement à l'aide de règles définies dans un fichier de configuration. Derrière cette définition très abstraite (qui est plus ou moins celle donnée sur leurs sites officiels, quand même) ils sont en pratique utilisés comme outils de build pour effectuer toutes les tâches de compilation/génération/traitement nécessaire entre l'écriture du code source d'un site web jusqu'à son déploiement. Comme tous ces outils tournent sous Node.js, ils sont codés en JavaScript et leurs fichiers de configuration sont tout naturellement des fichiers JSON.

Ceci étant dit revenons à l'article, ou plus précisément aux premiers commentaires. Grosso modo l'auteur de l'article présente certains défauts de ces outils et explique qu'il serait possible de s'en passer. Je trouve personnellement qu'il passe à côté de leurs défauts majeurs mais peu importe, voilà à l'heure actuelle le commentaire présenté en premier :
User 1
:You should try out this sweet tool called "make"
Je suis on-ne-peut plus d'accord, considérant que make est bien plus mature que Grunt & co, qu'il ne souffre d'aucuns de leurs bugs de jeunesse et surtout qu'il est conçu en tout premier lieu pour gérer les dépendances entre fichiers, chose qui permet d'éviter de recompiler la moitié de son projet à chaque fois qu'on touche un fichier et que ni Grunt ni aucun autre à ma connaissance n'est capable de faire correctement. Bref, le débat me semble mériter d'être ouvert, si ce n'est que les deux réponses qui suivent sont celles-ci :
User 2
:make sucks, the syntax is the most cryptic POS I've ever encoutered. One thing that these new generation of build tools do well, is to make it EASY TO UNDERSTAND what is actually happening, without using yet-another-cryptic DSL. Grunt uses JSON, gulp uses JavaScript. Make does NOT offer that, so, sorry, the rest of us have moved past generation 0 build tools.
User 3
:Make is too hard. Let's write a new build system.
Je mets de côté le ton hargneux du premier message qui le rend désagréable avant même de s'intéresser au contenu. Ces messieurs me semblent dire la même chose que je résume de cette façon : make est trop complexe à cause de sa syntaxe. Grunt & co utilisent du JSON plutôt qu'un "DSL" (sic) spécifique et sont donc beaucoup plus faciles à appréhender pour quelqu'un qui est habitué au développement web.

Il aurait été difficile de condenser davantage de choses avec lesquelles je suis en désaccord. Effectivement, Grunt utilise de fichiers de configuration en JSON. Cependant il ne s'agit que de syntaxe et le fait que ce soit du JSON, du YML ou du XML me semble importer bien peu quand on voit la complexité de ces fameux fichiers de configuration (il y a plein d'exemples dans l'article). Est-ce que cet utilisateur s'imagine vraiment qu'un développeur, sous prétexte qu'il connait JSON, va pouvoir deviner quoi écrire dans un fichier de plusieurs centaines de lignes et dans lequel la moindre propriété mal orthographiée va être récompensée par un message d'erreur obscur ? J'ai l'impression que le langage (ou le "DSL" pour faire moderne) à maitriser ici est quelque chose qui dépasse largement un simple problème de syntaxe, et que le choix de JSON est en réalité complètement anecdotique. Décrire des enchainements de tâches et de dépendances *est* quelque chose de complexe, et la syntaxe qu'on choisit d'utiliser n'y change strictement rien à mon sens. Pointer du doigt la syntaxe du fichier de configuration revient pour moi à passer complètement à côté du problème.

À la limite cet argument pourrait être acceptable s'il ne s'agissait pas du seul et unique qu'ils avancent pour mettre leurs outils en avant. Sérieusement, le seul problème avec make est que sa syntaxe n'est pas du JSON ? Au point d'en arriver à une conclusion aussi radicale que "let's write a new build system" ? Je commence à comprendre pourquoi l'écosystème front-end est aussi bordélique si des arguments aussi faibles justifient la réécriture en 30 exemplaires de choses aussi complexes qu'un outil de build. Ce qui m'inquiète encore davantage, c'est que j'aurais une confiance très modérée dans un outil écrit par quelqu'un qui décide de créer un nouveau projet juste parce que la syntaxe du précédent ne lui plait pas.

Quoiqu'il en soit, si j'extrapole cette façon de travailler, ça me semble être une explication assez plausible au bordel innommable qu'est devenu le développement web en quelques années. Je ne prétends absolument pas m'y connaître, mon seul projet web étant yAronet je n'ai qu'une vision extrêmement limitée, mais quand même : quel capharnaüm ! 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.

Bref, j'ai du mal à voir comment tout ça va pouvoir évoluer, mais ça me semble extraordinairement mal parti. Vous qui avez une expérience plus vaste dans ce domaine, qu'en pensez-vous ?
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

2

Zeph (./1) :
Quoiqu'il en soit, si j'extrapole cette façon de travailler, ça me semble être une explication assez plausible au bordel innommable qu'est devenu le développement web [...] quel capharnaüm ! 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.

La raison pour laquelle j'ai arrêté le dev web.

Quand on dit que les langages bas niveau comme l'assembleur sont trop compliqués/obscurs pour être enseigné en informatique générale (IUT, BTS...) et qu'à côté on passe 2 semaines à configurer un environnement Eclipse©®™ alors qu'en 2 minutes on peut compiler du x86 ou flasher un arduino et apprendre tout de suite des concepts fondamentaux ça me laisse sans voix.
avatar"If you see strict DRM and copy protection that threatens the preservation of history, fight it: copy the work, keep it safe, and eventually share it so it never disappears. [...] no one living 500 years from now will judge your infringing deeds harshly when they can load up an ancient program and see it for themselves."

Benj Edwards - Why History Needs Software Piracy

- - -
Achat ou échange: topic de mes recherches

3

il n'y a pas que le web hélas

ionic framework pour faire mâââgiquement des apps android/ios/whatever depuis le même code template/html. on y a trempé [un developpeur 42 nous a forcés a y tremper] un orteil, puis on a trouvé un dev qui savait causer android correctement cheeky

a propos d'android justement, j'espère ne jamais avoir à comprendre comment fonctionne gradle...

j'en déduis deux tendances

-tous les outils de build commencent par G? grin
-android a aussi une tonne de merdes "modernes"

4

Zeph > bah en Scala ils ont fait SBT.

Pour info, je ne comprends vraiment pas comment en *2010* on a seulement pu imaginer un outil de build qui :

* claque par manque de RAM lors d'un packaging (créer un fichier zip de moins de 10Mo)
* donne des infos absconses quand il y a une erreur de syntaxe dans le fichier
* met 2 minutes à se lancer sur une machine correcte mais qui a 4 ans (je ne parle pas du temps de compilation, je parle bien du simplement chargement du fichier de conf)
* demande des lignes vides comme séparateur d'instructions (bah oui, il fallait économiser les ; en fin de ligne triso)
* requiert un DSL spécifique, qui ne servira que pour ça
* pense qu'il est pertinent de retélécharger toutes les dépendances du projet à chaque chargement (=> je ne peux rien faire quand je suis déconnecté), même s'il les a téléchargées deux minutes avant

Donc si ça peut te rassurer, dis-toi qu'il n'y a pas que pour le web que c'est le bordel grin
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

5

Surtout que la solution aux limitations et aux problèmes de syntaxe de make existe déjà.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

6

./4 : ah merde, j'attendais la migration prochaine de maven à "autre chose" en me disant que ça ne pourrait être que mieux, mais tu ne me vends pas vraiment SBT là grin

En revanche la remarque reste vrai, il y a d'autres environnements dans lesquels on a essayé de réinventer de nouveaux systèmes de build inventifs. J'ai quand même le sentiment que c'est encore pire dans le développement front, peut-être à cause de la combinaison mortelle "beaucoup de développeurs" et "forte proportion de développeurs inexpérimentés" dont les deux auteurs de commentaires (cf. ./1) me semble si représentatifs. Ce qui est encore plus inquiétant c'est que ça ne semble pas aller en s'améliorant :/

./5 : *une* solution, pas *la*. Je ne discuterai pas avec toi tant que tu ne feras pas le strict minimum que je considère nécessaire pour ne pas avoir l'impression que tu utilises nos sujets uniquement pour faire de la publicité.
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

7

Je ne suis pas impliqué dans le développement voire la commercialisation de CMake. C'est juste que parmi tous les systèmes de build auxquels j'ai eu affaire (et il y en a pas mal), c'est de loin le moins pire (et si certains de mes projets utilisent autre chose, c'est parce que je ne connaissais pas CMake à l'époque où je les ai développés). Je ne vois pas trop pourquoi tu appelles ça "de la publicité".
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

8

Zeph (./6) :
./4 : ah merde, j'attendais la migration prochaine de maven à "autre chose" en me disant que ça ne pourrait être que mieux, mais tu ne me vends pas vraiment SBT là grin
SBT est bien pire que Maven. A la rigueur, je peux comprendre qu'on ait fait Grunt : ils ont simplement réinventé la roue en un peu moins bien, mais ça reste utilisable.
Avec SBT, ils ont inventé la roue carrée...

Sinon, je suis d'accord avec toi, le monde du web est plein de gens inexpérimentés (ou incompétents, au choix) qui pensent inventer quelque chose de fantastique alors que ça existe depuis 30 ans partout ailleurs (j'ai eu droit à une présentation enthousiaste d'un truc fantastique, du jamais vu ailleurs et surtout pas en JS, sur Angular JS : on peut faire .... des tests de non-régression !!!!)
avatar<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

9

(et après ça, Zeph dit que c'est moi qui trolle sur le dév web embarrassed)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

10

niveau lisibilité, préférer cmake a make c'est la peste qui se fout du choléra.

11

squalyl: tu veux vraiment voir la difference sur un projet entre cmake et make pour comprendre que l'und es deux est bien mieux ? grin

(apres il ne faut pas lire les makefile genere c'est juste imboufable)

Je deteste make pour plein de raison, et la principale c'est que des qu'on cherche a faire un truc un peu complexe ca deviens vite ingérable, il faut etre honnête. Par contre j'ai eu a faire avec pas mal d'outils sensé etre 100x mieux que make & co, comme scons, un certain nombre de machin faire pour java donc j'ai complètement oublié le nom, rake pour ruby, et d'autre dont je n'arrive meme pas as retrouver le nom qui ne sont meme pas sur wikipedia. Bref..

Aucun n'arrive a la cheville de make, si ce n'est potentiellement cmake qui n'est qu'un frontend a make, CMake m'a beaucoup aidé pour ti-nes en me simplifiant fortement la vie pour le build de ce projet, mais je continue a utiliser make. Pourquoi ? Surement un peu de masochisme, mais make est present sur 100% des unixes (meme si de temps en temps il y a quelques incompatbilité) et faire un fichier makefile pour une petite appli prends, aller, 10 lignes a tout casser (ca deviens vite chiant pour un gros projet multidossier, mais pour une arborescence simple)

Bref aucun des machin alternatifs, souvent fait pour un seul et unique language n'arrive a la cheville de make et pourtant make a vraiment plein de problemes de conception qui ne serait pas trop compliquer a changer en repartant de zero, mais aucun, aucun n'est arrivé a faire un truc aussi simple pour faire des trucs de base (oui meme cmake pour un projet tres simple peut etre un peu plus chiant)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

12

Godzil > l'intérêt majeur de cmake par rapport à make est quand même, à mon sens, de générer à peu près n'importe quoi (makefile, sln, etc).
Et je suppose que l'outil java dont tu parles est Ant ?

13

Ce qui me fait chier avec cmake (en tant qu'utilisateur) est:
* il est pas installé sur la machine, il faut donc l'installer avant d'installer l'application,
* s'il est installé, il est pas installé avec une version suffisamment récente, il faut donc le réinstaller avant d'installer l'application,
* la méthode pour installer autre part que dans /usr/local est un hack sauvage (mettre une variable globale dans le nom m'échappe tout le temps) plutôt qu'un joli "--prefix=....".
* pas de commande "--help" pour savoir quelles options existent pour la configuration.
* pas de possibilité de voir la réelle commande exécutée lors du Make (pratique pour le debug) résultat, s'il y a un problème dans la suite de build, tu ne sais pas trop ce qui ne marche pas (tu ne peux pas recopier la commande, la tester hors makefile, etc.)
* pas possible de surcharger CC ou CFLAGS lors du make et plus généralement, le Makefile généré est totalement inhackable.

Ce qui me fait chier avec make (en tant que développeur) est :
* utilisation des dates pour savoir s'il faut rebuilder. Il vaudrait mieux faire un test sur le CRC+SIZE du fichier coupler avec une base de donnée (stockant aussi les options de build) pour savoir s'il faut rebuilder,
* pas de support propre du build sur plusieurs répertoires.

14

Pen^2 oui bien sur, mais dans le cas de VisualStudio ou XCode les projet genere sont, assez moche quand même, et c'est anecdotique je pense

Et non pas ant, j'ai utilisé ant pour certain projets boulot, mais non c'en est un autre dont je n'arrive pas du tout a me rappeler le nom..

PpHd: tu oublie pour make
- Utilisation de TAB obligatoire
- Gestion des variables assez ...hum... complexe, il est tellement facile d'avoir un truc qui marche dans un coin, et tu le deplace de quelques lignes ca ne marche plus
- les differences minimes entre += ?= := etc...
- Les cibles par defauts toutes plus abscons les une que les autre $(@) $(<) $(^) $(?) $(|) $(cheeky $(+) etc....
- Les bizzareries a la ifdef / ifeq
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

15

Moches, je ne sais pas, personnellement je n'avais pas été choqué, mais je l'ai peu utilisé.
Anecdotique, je suis surpris, pour moi c'est la principale valeur ajoutée cheeky

16

Si c'est généré on s'en fout complètement que ce soit moche, non ? À moins que "moche" veuille dire quelque chose au niveau de l'affichage utilisateur une fois dans l'IDE, mais si on parle juste du code généré bah... c'est du code généré, tout l'intérêt de le générer c'était justement de ne pas avoir à l'écrire ni à le lire ?
avatarAll right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

17

pencil (c'est bien pour ça que je n'ai pas été choqué : à l'affichage, ça ressemblait à des projets dans une solution cheeky)

18

Moche dans le sens projet généré qui a première vue semble comme un projet "normal" pour l'IDE, mais des que tu as besoin de creuser un peu, tu te rends comptes que les choses sont bien plus lourd et complexes qu'avec un projet normal pour un VisualStudio/XCode.
Il y a aussi le fait que les modifications dans le projet dans l'IDE n'est pas répercuté dans les fichiers cmake, il faut donc aller changer les cmake et régénérer, donc potentiellement relancer l'IDE etc..

C'est une bonne idée au départ qui n'est pas si pratique au final. (Je precise: *pour moi*)

Ça rends aussi les réglages dans l'IDE assez complexe (genre options de compilation etc...) parce que CMake créer ses propres règles, voir comme ce n'est pas considéré comme un projet natif, certains options ne sont même pas accessible.

Alors je n'ai pas utilise cmake depuis un moment donc pas trop suivit l’évolution sur ce point, ça c'est peut être amélioré (je le souhaite) mais avec TI-NES, faire un projet VS ou Xcode ne m'a jamais convaincu, enfin si de faire directement le projet avec VS/XCode c'est plus souple au final..


Par contre un point très très pratique de cmake (vs make): la recherche automatique des headers/fichier objet d'une librairie.
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

19

En même temps à mes yeux le maître reste le cmakelists, ça me semble une très mauvaise idée d'aller voir les réglages dans l'ide. Personnellement je m'interdis de modifier manuellement un fichier fichier généré.

20

PpHd (./13) :
Ce qui me fait chier avec cmake (en tant qu'utilisateur) est:* il est pas installé sur la machine, il faut donc l'installer avant d'installer l'application,
Les temps ont changé… De nos jours, soit c'est une machine de développement, alors il y a de fortes chances que CMake soit déjà installé, soit ce n'est pas une machine de développement, alors il y a des chances que même make n'y soit pas.
* s'il est installé, il est pas installé avec une version suffisamment récente, il faut donc le réinstaller avant d'installer l'application,
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
cmake-3.3.2-1.fc22                        f22-updates           orion
Pas assez récent? wink (Bon, la version dans F21 commence à dater, mais F21 est à 1 semaine de sa fin de vie.)
* la méthode pour installer autre part que dans /usr/local est un hack sauvage (mettre une variable globale dans le nom m'échappe tout le temps) plutôt qu'un joli "--prefix=....".
-DCMAKE_INSTALL_PREFIX=, je ne vois pas en quoi c'est pire que --prefix=.
* pas de commande "--help" pour savoir quelles options existent pour la configuration.
Options globales: cmake --help-variables
Options du projet: ccmake ou cmake-gui
Ce qui me fait chier avec make (en tant que développeur) est :* utilisation des dates pour savoir s'il faut rebuilder. Il vaudrait mieux faire un test sur le CRC+SIZE du fichier coupler avec une base de donnée (stockant aussi les options de build) pour savoir s'il faut rebuilder,
Le problème des checksums est le risque de collisions.
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

21

Pen^2 (./19) :
En même temps à mes yeux le maître reste le cmakelists, ça me semble une très mauvaise idée d'aller voir les réglages dans l'ide. Personnellement je m'interdis de modifier manuellement un fichier fichier généré.
Du coup, l'EDI perd un peu son intérêt (sauf si c'est un EDI fait pour, comme KDevelop).
avatarMes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité

22

C'est un peu vrai.

23

Kevin: pencil (pour l'IDE)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

24

Kevin Kofler (./20) :
PpHd (./13) :
Ce qui me fait chier avec cmake (en tant qu'utilisateur) est:* il est pas installé sur la machine, il faut donc l'installer avant d'installer l'application,
Les temps ont changé… De nos jours, soit c'est une machine de développement, alors il y a de fortes chances que CMake soit déjà installé, soit ce n'est pas une machine de développement, alors il y a des chances que même make n'y soit pas.
Mon expérience personnelle à ce sujet est tout le contraire. J'ai très rarement eu cmake qui était installé nativement, alors que make y était tout le temps.
* s'il est installé, il est pas installé avec une version suffisamment récente, il faut donc le réinstaller avant d'installer l'application,
Pas assez récent? wink (Bon, la version dans F21 commence à dater, mais F21 est à 1 semaine de sa fin de vie.)
Sur une des machines de dev que j'ai, c'est une 2.8.12.2
* la méthode pour installer autre part que dans /usr/local est un hack sauvage (mettre une variable globale dans le nom m'échappe tout le temps) plutôt qu'un joli "--prefix=....".
-DCMAKE_INSTALL_PREFIX=, je ne vois pas en quoi c'est pire que --prefix=.
Je vois "DCMAKE_INSTALL_" en trop, pour une option qui est utilisée tout le temps (Ca marche bien. C'est juste très lourd).
* pas de commande "--help" pour savoir quelles options existent pour la configuration.
Options globales: cmake --help-variables
Options du projet: ccmake ou cmake-gui
J'ai déjà utilisé, mais je ne me souviens plus pourquoi je n'étais pas arrivé à mes fins avec.
Ce qui me fait chier avec make (en tant que développeur) est :* utilisation des dates pour savoir s'il faut rebuilder. Il vaudrait mieux faire un test sur le CRC+SIZE du fichier coupler avec une base de donnée (stockant aussi les options de build) pour savoir s'il faut rebuilder,
Le problème des checksums est le risque de collisions.
Le risque de non regénération à cause de dates incorrectes des fichiers est bien supérieur (et je l'ai eu tellement souvent). On peut aussi utiliser une autre fonction de hashage qu'un CRC si on veut.

25

SHA1024!!! love
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

26

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

27

Kevin Kofler (./20) :
Les temps ont changé… De nos jours, soit c'est une machine de développement, alors il y a de fortes chances que CMake soit déjà installé, soit ce n'est pas une machine de développement, alors il y a des chances que même make n'y soit pas.
[me ~ ]$ sudo pacman -Q |grep cmake
[me ~ ]$ sudo pacman -Q |grep make
automake 1.15-1
libpagemaker 0.0.2-1
make 4.1-1
J'ai make mais pas cmake cheeky
avatar

28

en même temps c'est un peu retro pacman

[me ~ ]$ sudo fallout -Q |grep cmake
cmake 42.53
[me ~ ]$ sudo fallout -Q |grep make
automake 1.15-1
libpagemaker 0.0.2-1
make 4.1-1

embarrassed

29

langue

(J'ai aussi yaourt, qui me permet la même chose, si t'es plus diététique que bonhomme jaune).
avatar

30

(et puis c'est Francais pour le coup)
avatarProud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.