Complexification du dev frontend

Salut à tous,

Récemment j’ai voulu me remettre au goût du jour concernant le développement de web apps en Javascript. Je n’en ai pas fait depuis longtemps, à l’époque où tout le monde utilisait jQuery et où on n’entendait pas encore beaucoup parler d’AngularJS première version.

J’ai fait un peu le tour de ce qui existe maintenant comme tools et frameworks et je constate que maintenant une web app c’est compliqué à booter et c’est immédiatement une sacrée machine à gaz.

Il semble qu’il est devenu indispensable d’utiliser le système de packaging npm, de compiler son app, et d’utiliser une pléthore hétéroclite de tools simplement pour faire un Hello world. Il y a des tools pour créer une structure de projet (le projet ne fait encore rien et il y a déjà 300 fichiers), des tools pour tester, etc. Et toujours trente façons différentes de faire la même chose basique. Je me suis un peu attardé sur le framework Vue et je constate qu’il faut utiliser non pas un mais plusieurs frameworks conjointement (Vue, VueX, etc.).

C’est pas forcément une mauvaise chose en soi les frameworks, mais :

• la learning curve est beaucoup plus raide qu’avant, il faut passer beaucoup de temps avant de pouvoir démarrer un petit projet tout simple
• les frameworks et les tools semblent évoluer très vite, il semble qu’il faille tout réapprendre tous les ans, et il y en a tellement que pour bosser en équipe il faut apprendre plein de technos en doublon ; par ex quand j’ai booté un projet Vue avec vue-cli, pour pratiquement chaque truc, même les plus bateaux, j’avais le choix entre plusieurs outils (packaging, tests, templating du projet, etc) ; il y a donc un écosystème énorme à appréhender (grunt, bower, npm, yearn, webpack, angular, react, vue, vuex, etc etc), et je ne parle même pas des multiples langages qui sont apparus (typescript, sass, less, etc)
• les tools n’ont pas l’air très simples ni très stables.. je n’ai pas une seule fois utilisé npm sans voir 50 warnings dans tous les sens et je n’ai aucune idée d’à quoi ils font référence ou de si je peux faire quelque chose pour les régler
• il ne semble pas y avoir une cohérence globale dans ces tools, c’est un joyeux bordel, en tous cas de mon point de vue, et c’est pas évident de trouver une documentation orientée newbie qui fait un état des lieux général et indique quoi utiliser ; par ex il semble que vue soit généralement accompagné de vuex, mais il n’en est fait aucune mention dans la doc de vue… pour se documenter maintenant il faut lire des blogs on dirait
• les apps sont-elles performantes quand elles doivent loader tout un bouzin pareil dont 75% est inutilisé ?
• est-ce vraiment nécessaire tous ces frameworks et ces tools ? quelle en est la valeur ajoutée ?
• est-ce qu’il n’y a pas un genre d’effet de mode et de chacun réinvente la roue dans son coin dans le monde JS en ce moment ?

Bref j’ai l’impression que le dev Javascript est pas mal parti en couille en quelques années. Je suis un peu perdu dans tout ça.

Du coup j’aimerais bien l’avis et si possible un petit topo de la part de ceux d’entre vous qui ont suivi tout ce qui s’est passé et qui font du dev frontend aujourd’hui. Je n’ai plus aucune idée de par où démarrer.

Merci et bon weekend tout le monde

J’ai le même ressenti face à l’effervescence de ce secteur et au manque de stabilité. On a le choix entre investir en prenant le risque de devoir recommencer l’année prochaine ou bien on se consacre a autre chose en attendant la stabilisation.

Clairement il y a une effet de mode avec des technos qui sortent tous les jours et des fans boys pour les défendre. Le frontend c’est la jungle depuis 10 ans (toujours en fait peut être :D) mais on sent quand même que ça devient mature. Il faut juste choisir en fonction de ses besoins.

Quand on voit du vieux code front à l’arrache par rapport à du code typé, avec des tests, une vraie façon de mettre en prod, on a quand même vraiment progressé je trouve.

et du coup il faut choisir en fonction des besoin:

• Appli toute simple : on peut toujours écrire du vanilla javascript et ça marche bien, sutout avec ES6.
• Appli genre front qui lit une base de donnée : un framework PHP, Python par exemple ça va bien
• Appli avec beaucoup d’interaction dans l’UI : là du Angular/React/Vue + services back-end ça devient bien

Bref il faut se poser un peu pour choisir la bonne techno et prier un peu pour pas qu’elle disparaisse dans les 2 ans

En fait moi je travaille sur un système d’information. Donc je suis dev backend et ce que je dois exposer c’est une API publique. Le front qui va avec, utilisé par les clients, est pris en charge par une équipe UX dédiée, donc ça je ne m’en soucie pas.

Par contre je voudrais développer des UIs internes, par ex pour mon équipe de run qui doit administrer la prod. Le système d’information reste le même, je veux simplement y plugger des interfaces supplémentaires permettant des actions différentes. Donc je ne dois pas réimplémenter le backend avec un framework web gérant le front, type Django. Je dois exposer une deuxième API et développer des UIs "autonomes" l’utilisant, par autonomes je veux dire qui s’auto-gèrent pour tout ce qui est routes, templates, etc. Donc type Angular/React/Vue.

Mais mon coeur de métier c’est le backend. Je ne peux pas et je ne veux pas consacrer de temps à ces UIs. Je veux des interfaces bateau, homogènes et assez banales. Par contre je veux qu’elles soient rapides, fluides, et assez ergonomiques puisque ça doit être l’outil de travail d’autres équipes. Je veux pouvoir les compléter et les améliorer très rapidement, sans devoir installer la terre entière pour les build, sans devoir dupliquer tous mes modèles, sans trop de boilerplate mais surtout et avant tout sans trop de complexité, et que la montée en compétence pour un dev backend pour travailler dessus soit quasi immédiate.

Mais j’aimerais bien aussi d’un autre côté rester dans des technos "state of the art", histoire de pas réinventer la roue et d’être sur quelque chose que tout le monde connaît à peu près. Donc pourquoi pas un framework comme Vue, même si moi personnellement je dois passer un peu de temps à l’apprendre. Mais moi qui n’ai pas de grosses exigences en terme de frontend et qui veux juste une techno un peu KISS, ben de voir tout ce bordel auquel je comprends rien ça me refroidit un peu. Je me demande si je ferais pas mieux de faire du vanilla, quitte à ce que des nouveaux dans la team doivent se former quelques heures sur une techno maison, plutôt que d’injecter dans le projet ce genre de monstres, qui sont peut-être plus faits pour des mecs dont c’est le coeur de métier.

Mais d’un autre côté je me dis qu’avec du vanilla, sur les petits changements incrémentaux qui arriveront fréquemment une fois l’UI développée j’aurai peut-être beaucoup de perte de temps, que je vais peut-être faire un énième silo peu maintenu ou documenté qui sera legacy à peine sorti de l’oeuf, et que peut-être ces frameworks sont vraiment adaptés à mon besoin, que le plus dur c’est les premiers pas et qu’après ça tourne bien.

Je sais pas. Une idée ?

(Note : Je suis autant intéressé par des réponses à mon problème particulier que par le débat plus général sur le dev frontend, y’a pas de hors-sujet là pour moi )

Si ce que tu veux faire n’est pas très complexe et que tu veux quelque chose de simple à mettre en place, pourquoi pas de l’Elm ou du vanilla dans ce cas ?

Si c’est un prototype ou en tout cas quelque chose qui peut être refait, ça me parait une solution correcte. Si tu dois faire quelque chose plus maintenable, je dirais que ça dépend de ta boite et choisir ce que les autres maîtrisent aussi me paraît être une bonne idée.

Salut,

Je ne suis pas du tout un expert du front, pas plus que du JS en général, mais je vais apporter ma modeste contribution quand même.

Ce que tu dis dans le premier message me paraît globalement indéniable, et ça a d’ailleurs donné lieu à un phénomène que certains ont appelé « JavaScript fatigue », ce qui est assez explicite.
Néanmoins, note qu’il est par exemple tout à fait possible d’utiliser Vue en le chargeant via un CDN, ou via un simple fichier grâce à de bonnes vieilles balises script, sans faire appel à npm, yarn, webpack, etc.
L’utilisation de ces derniers est simplement recommandée et usuelle (ce qu’on pourrait considérer comme l’état de l’art a priori).
Quant à Vuex (que je ne pense pas qu’on puisse vraiment qualifier de framework), comme Redux pour React, il est encore moins obligatoire. Il vise simplement à améliorer l’organisation, la maintenabilité et l’évolutivité du code pour les applications de taille importante / SPA.

Pour ce qui est du cas exposé plus précisément, je pense que tu ne pourras pas remplir l’ensemble de tes objectifs, ils semblent trop s’opposer. D’ailleurs ton message est lui-même rempli de « mais », de « par contre », j’en déduis donc que tu le penses aussi plus ou moins.
Il reste donc à définir tes priorités parmi ce que tu as cité, et faire un choix en fonction.

Enfin, concernant les choix possibles, outre le JS à l’ancienne, jQuery et les « framework lourds » comme Vue, React, Angular, etc., il y a aussi ce que j’appellerais des « micro-framework » ou « framework légers », comme Stimulus que j’ai découvert assez récemment, qui peuvent parfois être des solutions intéressantes.
Grosso modo, l’idée est justement de garder un code léger, simple et facilement compréhensible tout en apportant un peu d’organisation et de modernisme. Ça peut être une solution hybride intéressante dans certains cas.

Je ne pense pas avoir dit de bêtises et j’en ai terminé, mais je ne suis pas sûr que ça va t’aider à y voir plus clair ou à prendre une décision.

Je ne sais pas si tu as vu cette discussion récente sur la complexité logicielle et l’inefficacité qui en résulte mais personnellement ce commentaire de @gasche m’a fait réfléchir.

Comme tu le dis, aujourd’hui le web c’est une sacrée machine à gaz. C’est plein de technologies douteuses, qui évoluent de façon un peu anarchiques parfois et ce autour de débat pas franchement intéressants. Pourquoi y contribuer ? Est-ce qu’on n’a pas mieux à faire de notre temps ?

Personnellement je m’interroge.

Tu pourrais dire la même chose du Rust ou du C++, avec les gens qui essayent de trouver des patterns intéressants avant de les intégrer au langage. La grosse différence c’est que dans le web on a tendance à vouloir faire un buzz dès qu’on crée une bibliothèque qui introduit un nouveau (ou non) concept (nodejs avec l’asynchrone, les promesses, await/async, la possibilité de séparer les parties de l’application dans des fichiers, la possibilité de rassembler en un seul fichier, etc).

Le web est un foyer de recherche de pattern, et il faut réussir à distinguer ce qui est juste du sucre syntaxique sur un hello world de ce qui apporte réellement quelque chose, mais c’est la même chose pour tous les langages, comme C#, C++, Rust, Go, C, etc.

Je suis un peu dans la même situation que l’OP : je débarque dans le monde du web et je me prends dans la figure un tas de termes et d’outils qui soudainement paraissent indispensables. J’ai le sentiment qu’il va falloir maîtriser tout ça, mais je ne sais pas par où commencer à me documenter. Il n’y a pas l’air d’avoir un point de départ dans le tas.

À mon avis, le mieux pour débuter est de sélectionner par exemple un framework et de s’y fixer, de faire des petits projets sans trop se soucier. Je vois parler de « monstres » et de « gros frameworks », mais rappelons que Vue reste quand même simple et super léger (plus léger que jQuery). J’ai moi-même commencé à découvrir Vue et j’ai été agréablement surpris de voir à quel point la mise en place, le développement et le déploiement d’un petit projet sont en réalité extrêmement simples. Vue CLI se débrouille pour gérer tout ça et il me reste plus qu’à choisir entre serve ou build. Pour le moment, je ne me soucie pas des autres outils qui y sont liés (tels que Node, Vuex, Webpacks et autres), je préfère d’abord progresser juste avec Vue.

Bonsoir,

En fait la seule véritable nouveauté de ces dernières années, c’est que tout le monde s’est mis à faire des SPA. Ca a certains avantages par rapport aux pages web classiques, mais ça ne veut pas dire que c’est forcément adapté à tous les projets. On peut s’en sortir très bien sans tout ça, en JavaScript de base, surtout avec les normes ES6, ES2015 et suivantes, qui rendent le langage bien plus complet sans forcément avoir besoin d’aller chercher beaucoup plus loin.

Le problème c’est qu’ils pense tous avoir trouvé le marteau doré et qu’ils s’en vantent; du coup le monde entier ressemble à un clou. Vu que le dit marteau est vendu par Google, Facebook ou Microsoft, tu as forcément l’impression que c’est bien et que ça résoudra tous tes soucis, ça ne peut pas en être autrement. En fait en vérité c’est ceux qui parlent le plus qui en font le moins et inversément.

Un autre souci c’est que le vanilla c’est painful, pour le développeur comme pour l’utilisateur. Quelques exemples :

• compliqué de faire une SPA parce que HTML n’a aucun mécanisme correct d’include ou de templating, il faut soit tout foutre en vrac dans un seul fichier, soit réécrire 50 fois la même chose, soit utiliser des rustines dont ça ne devrait pas être le rôle (iframes, ajax, etc), soit tout écrire dans des strings javascript (mais dans ce cas, à quoi sert HTML ? et quid de la performance ?)
• une non-SPA c’est pas terrible : entre chaque interaction un vieil écran blanc, compliqué de transmettre/partager des données entre les vues donc pas de MVC, les interactions peuvent interrompre des communications avec l’API…

Bref. Les technos web ont été conçues pour mettre en forme des documents. Pas pour développer des applications. Je trouve.

Et elles évoluent beaucoup trop lentement et mal. Par exemple j’ai vu que la balise <template> est récemment apparue en HTML. C’est bien, mais elle est inutilisable car beaucoup trop limitée (on se demande pourquoi), et ça ne résout pas le problème du "tout dans le même fichier". Finalement, mon impression est qu’elle ne sert à rien.

Autre exemple, ça fait plus de dix ans que les smartphones existent et il faut encore utiliser un framework externe type Bootstrap pour faire du responsive (certes il y a les media queries mais qui est prêt à utiliser ça ?). Et si les technos web servent à faire des UIs, pourquoi on n’a pas encore de balises <navbar>, <panel> ou <footer> qu’il suffit de mettre dans le html et de customiser la largeur et la couleur ? On doit encore se taper des armées de div, de span, de aria-machin, pour que ça ressemble à quelque chose… Sérieux !

Pour le reste je ne saurais te répondre, cependant en HTML5 il y a effectivement des balises <nav> et <footer>. Et il y a aussi des frameworks bien plus légers que Bootstrap pour faire du responsive. Je pense notamment à Bulma (mais il y en a d’autres encore plus légers).

Certes mais les browsers ne leur donnent aucune apparence particulière. Ils n’ont qu’une valeur sémantique, ce qui a du sens pour un document, mais pas pour une application.

Pour faire une navbar, insérer un <nav> ne suffit pas. Tu aurais pu mettre un <div> à la place, ça serait pareil. Pourtant, ça pourrait. On pourrait avoir des balises comme ça correspondant aux éléments courants d’une UI et une apparence par défaut qui correspond au layout courant des UIs.

Par exemple au lieu de :

<nav class="navbar navbar-expand-lg navbar-light bg-light">
  <a class="navbar-brand" href="#">Navbar</a>
  <button class="navbar-toggler" type="button" data-toggle="collapse" data-target="#navbarSupportedContent" aria-controls="navbarSupportedContent" aria-expanded="false" aria-label="Toggle navigation">
    <span class="navbar-toggler-icon"></span>
  </button>

  <div class="collapse navbar-collapse" id="navbarSupportedContent">
    <ul class="navbar-nav mr-auto">
      <li class="nav-item active">
        <a class="nav-link" href="#">Home <span class="sr-only">(current)</span></a>
      </li>
      <li class="nav-item">
        <a class="nav-link" href="#">Link</a>
      </li>
      <li class="nav-item dropdown">
        <a class="nav-link dropdown-toggle" href="#" id="navbarDropdown" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
          Dropdown
        </a>
        <div class="dropdown-menu" aria-labelledby="navbarDropdown">
          <a class="dropdown-item" href="#">Action</a>
          <a class="dropdown-item" href="#">Another action</a>
          <div class="dropdown-divider"></div>
          <a class="dropdown-item" href="#">Something else here</a>
        </div>
      </li>
      <li class="nav-item">
        <a class="nav-link disabled" href="#">Disabled</a>
      </li>
    </ul>
    <form class="form-inline my-2 my-lg-0">
      <input class="form-control mr-sm-2" type="search" placeholder="Search" aria-label="Search">
      <button class="btn btn-outline-success my-2 my-sm-0" type="submit">Search</button>
    </form>
  </div>
</nav>

On aurait un truc du genre :

<navbar>
  <brand><a href="#">Navbar</a></brand>
  <toggler>
  <item><a href="#">Home</a></item>
  <item><a href="#">Link</a></item>
  <dropdown>
    <a href="#">Dropdown</a>
    <a href="#">Action</a>
    <a href="#">Another action</a>
    <divider>
    <a href="#">Something else here</a>
  </dropdown>
  <item disabled><a href="#">Disabled/<a></item>
  <form>
    <input type="search" placeholder="Search">
    <button type="submit">Search</button>
  </form>
</navbar>

Avec le même résultat visuel.

Après faut savoir ce qu’on veut que soit HTML. Un langage pour décrire la sémantique de documents, ou un langage de description d’interfaces ? Dans les deux cas il est mauvais.

Pourtant l’idée de base est ultra puissante : un langage déclaratif, à base de balises. Rien de mieux pour décrire une interface et ses composants. Tout le monde s’est orienté vers ça (Qt avec QML, Android avec les layouts XML, etc).

Ah ok, au temps pour moi.

compliqué de faire une SPA parce que HTML n’a aucun mécanisme correct d’include ou de templating, il faut soit tout foutre en vrac dans un seul fichier, soit réécrire 50 fois la même chose, soit utiliser des rustines dont ça ne devrait pas être le rôle (iframes, ajax, etc), soit tout écrire dans des strings javascript (mais dans ce cas, à quoi sert HTML ? et quid de la performance ?)

Ca commence à venir avec <template> même si ça ne règle pas tout; mais en attendant, on peut quand même être un peu plus malin que mettre du HTML ou du CSS à la rache dans des strings.

J’ai un jeu avec une partie codée comme une SPA et à aucune place dans mon code JS il n’y a de HTML ou de CSS écrit littéralement dans des strings. ET mon code est quasi-vanilla, je me suis juste autorisé babel pour pouvoir faire du beau ES6–2015 sans sacrifier IE11.

Bref. Les technos web ont été conçues pour mettre en forme des documents. Pas pour développer des applications. Je trouve.

Là tu mets le doigt sur un point essentiel.

Le problème c’est justement qu’on ne supporte plus le bon vieux modèle requête/réponse, pourtant beaucoup plus simple, et amplement suffisant pour la plupart des usages courants. Franchement est-ce qu’on a besoin qu’un site d’information soit sous forme de SPA ? pas vraiment. Une boutique en ligne ? Bof. Un forum de discussion asynchrone ? Non plus. Facebook ? Même pas tant que ça, en-dehors de la messagerie instantanée.

Alors oui, les SPA c’est indispensable pour des jeux, des activités en temps réel comme les chat, ou des interfaces qui doivent absolument être immersives. Mais 99% du temps ça n’apporte pas grand chose, à part entres autres faire disparaître cet écran blanc qu’on ne veut plus voir. Tiens d’ailleurs, en parlant d’écran blanc, on n’aurait même plus le temps de les voir si les pages ne pesaient pas 100 Mo. Quand j’ai commencé à créer mon premier site web avec mes connaissances de collégien de l’époque, la recommandation c’était… moins de 50 Ko, images comprises évidemment. 15 ans plus tard la taille des pages a été multipliée par plus de 2000, alors que la vitesse des connexions à peine 200. Du coup le ressenti, c’est que… le web est 10 fois plus lent.

Alors pourquoi on ne fait plus que des SPA aujourd’hui ? En fait, c’est surtout parce que grosso modo d’un seul coup on peut faire à la fois un site web, une app iOS et une app Android. ON se fiche de savoir si c’est vraiment approprié, overkill ou pas. C’est moins cher; en plus c’est ce que font les GAFAM; donc c’est forcément la meilleure solution et par conséquent ça va dominer le monde. Logique.

Autre exemple, ça fait plus de dix ans que les smartphones existent et il faut encore utiliser un framework externe type Bootstrap pour faire du responsive (certes il y a les media queries mais qui est prêt à utiliser ça ?). Et si les technos web servent à faire des UIs, pourquoi on n’a pas encore de balises <navbar>, <panel> ou <footer> qu’il suffit de mettre dans le html et de customiser la largeur et la couleur ? On doit encore se taper des armées de div, de span, de aria-machin, pour que ça ressemble à quelque chose… Sérieux !

C’est la suite de ta constatation précédente en fait: le HTML n’a pas été conçu pour ça. Le <panel> pour faire du GUI en XML, ça existe, de mémoire c’est du XUL, du XAML pour C# ou du JFX de JavaFX. Mais ça n’a rien à voir avec le web.

J’ai un jeu avec une partie codée comme une SPA et à aucune place dans mon code JS il n’y a de HTML ou de CSS écrit littéralement dans des strings.

Peux-tu décrire ta façon de faire ? Ca m’intéresse beaucoup.

Le problème c’est justement qu’on ne supporte plus le bon vieux modèle requête/réponse, pourtant beaucoup plus simple, et amplement suffisant pour la plupart des usages courants.

Tiens d’ailleurs, en parlant d’écran blanc, on n’aurait même plus le temps de les voir si les pages ne pesaient pas 100 Mo.

Alors pourquoi on ne fait plus que des SPA aujourd’hui ? En fait, c’est surtout parce que grosso modo d’un seul coup on peut faire à la fois un site web, une app iOS et une app Android.

Je vois deux choses intéressantes à ça :

1. Le découplage backend/frontend

• c’est plus logique, plus MVC
• permet d’exposer ses données à l’automatisation, un soft devrait pouvoir utiliser un autre soft au même titre qu’un humain
• permet de faire évoluer le frontend indépendamment du backend, voire de refondre l’un sans toucher à l’autre ; par ex ça permet de refondre le backend en faisant de cette refonte un travail moins vaste et donc plus abordable, un choix de techno concentré sur le backend et indépendant des capacités de cette techno à servir une interface, permet de faire cette refonte sans perturber les habitudes des utilisateurs, etc.
• permet une plus grande liberté à l’utilisateur, qui obtient ainsi potentiellement la possibilité d’utiliser l’interface la plus adaptée à son besoin (gui/cli/..), et qui devient capable de customiser son interface voire de créer la sienne

2. Le Web a un peu pris le rôle que les OS sont censés jouer mais auxquels ils ne répondent que partiellement : d’une part, fournir une abstraction du matériel et de la plate-forme, et d’autre part apporter une certaine conteneurisation. Les technos Web sont les seules qui font office de standard portable pour le développement d’applications. Ce n’est pas du tout ce pour quoi elles ont été conçues, mais de facto elles sont beaucoup utilisées pour ça aujourd’hui. Et là où on a raison, c’est qu’un tel standard devrait exister.

C’est la suite de ta constatation précédente en fait: le HTML n’a pas été conçu pour ça. Le <panel> pour faire du GUI en XML, ça existe, de mémoire c’est du XUL, du XAML pour C# ou du JFX de JavaFX. Mais ça n’a rien à voir avec le web.

Le problème de ces technos c’est qu’il y en a tellement qu’elles sont méconnues, qu’elles sont potentiellement un investissement plus risqué, et surtout comme dit précédemment les technos web ont l’énorme avantage de la portabilité et de l’accessibilité immédiate au plus grand nombre, grâce à un fonctionnement standard sur toutes les plate-formes, et une livraison "just in time" via réseau, c’est-à-dire sans build, sans install, etc., toutes les plate-formes disposant d’un moteur pour les faire tourner (le browser). (Ce qui évacue en outre les questions de mise à jour, de gestion de parc, etc).

En somme l’idéal selon moi serait une technologie présentant les mêmes caractéristiques que le web de ce point de vue là, mais orienté application. Parce que je suis d’accord, ce n’est pas le rôle des technos web.

Tu utilises bien la dernière version de NPM ? Tu as eu des warnings sur quels frameworks ?

En vrac, je suis assez d’accord avec le problème soulevé ici. J’irais même plus loin : la majorité du développement web aujourd’hui, c’est juste un énorme assemblage de n’importe quoi qui tient uniquement parce qu’on ne le regarde pas trop fixement. Le moindre projet ramène immédiatement des quantités délirantes de dépendances.

Comme rien n’est compatible avec rien et qu’il y a des tonnes d’environnements d’exécution, on est vite obligés d’utiliser des outils comme Babel et Webpack, qui sont pratiques, mais à la fois ignobles à configurer et atrocement lents.

Mais pour moi les deux plus gros problèmes du développement front – plus exactement de la communauté JS parce que j’ai l’impression que ça touche Node aussi – c’est :

1. Cette idée qu’il faut foncer à marche forcée, quitte à sortir des trucs pas finis, quitte à tout casser tous les trois mois, quitte à visiblement ne pas faire la moindre forme de conception, quitte à faire un fork / réimplémenter un truc au lieu de tenter d’améliorer l’original.
2. Cette manie de tout découper en modules, micromodules, nanomodules, au point que le moindre projet tire des milliers de dépendances dont certaines sont totalement ridicules.

La plus belle illustration du point 2 est le module NPM is-even, qui permet de savoir qu’un nombre est pair. Le plus ridicule n’est pas qu’il y ait un module pour ça, non ; ni le fait qu’il ait été téléchargé près de 30 000 fois la semaine dernière. Le plus ridicule est que ce module a une dépendance ; parce que le code utile complet de ce module est :

var isOdd = require('is-odd');

module.exports = function isEven(i) {
  return !isOdd(i);
};

Oui. C’est un module qui fait un « not » sur une dépendance. Vérifiez vous-même.

À noter que le module is-odd, qui permet de savoir si un nombre est impair, est téléchargé un million deux cent mille fois par semaine (et apparemment c’est en baisse).

Sinon pour répondre à quelques points en vrac vus dans ce topic :

• Vuex est bien référencé dans la doc de Vue, et il est important de prendre en compte cet avertissement.
• J’ai systématiquement un warning NPM parce que je ne suis pas sur Mac (et qu’il y a une dépendance facultative qui n’existe que sur Mac), et j’en ai eu un autre aléatoire hier sur une sous-sous-sous dépendance dépréciée. Node et NPM à jour.

J’ai un jeu avec une partie codée comme une SPA et à aucune place dans mon code JS il n’y a de HTML ou de CSS écrit littéralement dans des strings.

Peux-tu décrire ta façon de faire ? Ca m’intéresse beaucoup.

En fait je triche un peu, le HTML que je crée en JS est sous forme d’objets. Petit extrait qui crée le haut d’une boîte de dialogue:

let closeBtn = create('button', { type: 'button', class: 'close-button'  }, msgs.Close);
let formTable = create('fieldset');
this.form = create('form', formTable);
this.dialog = create('dialog', { role: 'dialog', open: true, 'aria-modal': true, 'aria-labelledby': 'dialogTitle'  },
create('div', 
create('h1', { id: 'dialogTitle' }, this.title), 
closeBtn,  this.form));

La fonction create fait appel à createElement, createTextNode et appendChild derrière, en fonction des paramètres passés. Je trouve ça beaucoup plus pratique à manipuler que du HTML dans des strings, étant donné que je n’ai pas de système de templating poussé à la Angular. Ca, j’admets, c’est une question de goût… avec ES6 et les template string il y a moyen de faire du HTML paramétré pas trop ignoble.

Par contre pour le CSS cette fois-ci pas de « triche », le CSS inline est totalement banni. Le code JavaScript ne fait que d’ajouter et de supprimer des classes, rien d’autre. Ca par contre c’est ce que devraient faire toutes les apps un temps soi peu sérieuses, le CSS line dans le code JS ne pousse pas à isoler complètement les questions de pur design. On devrait pareillement isoler la structure, mais c’est beaucoup plus compliqué…

La plus belle illustration du point 2 est le module NPM is-even, qui permet de savoir qu’un nombre est pair. Le plus ridicule n’est pas qu’il y ait un module pour ça, non ; ni le fait qu’il ait été téléchargé près de 30 000 fois la semaine dernière. Le plus ridicule est que ce module a une dépendance ; parce que le code utile complet de ce module est :

Oui. C’est un module qui fait un « not » sur une dépendance. Vérifiez vous-même.

À noter que le module is-odd, qui permet de savoir si un nombre est impair, est téléchargé un million deux cent mille fois par semaine (et apparemment c’est en baisse).

Tout est dit avec cet exemple édifiant. Je me demande quand même si c’est de la profonde ignorance ou de la fainéantise. J’aurais bien envie de dire les deux.

Cela étant dit, je ne crois pas que ça ne touche que le développement web front-end et le JavaScript, même si c’est là que ça se ressent le plus. Il y a parfois bien de quoi se poser des questions quand on regarde toutes les dépendances qu’hibernate et spring boot ramassent au passage, et les temps monstrueux de build qu’on arrive à atteindre.