8 mois avec Javascript (ES6) et vue.js

Je rajoute en commentaire que récemment je suis tombé sur cet article et que j’avais regardé vite fait ce que récupérait vue-cli 3 à la création d’un projet (un hello world donc), à la fois en mode « prototypage rapide » et en mode « prêt pour la production ».

J’ai jamais vraiment creusé, mais c’était à la fois mieux et pire que dans cet article.

• Mieux parce que je n’ai pas vu en première approche de délires aussi terrifiants que ceux décrits dans l’article (type récupération d’encyclopédie pour afficher une définition ou image dans le code source) ;
• Pire parce que les Hello World demandent beaucoup plus de dépendances.

Ahah, je me retrouve dans tes propos à 100%, même si je ne fais pas de JS professionnellement.

Essayer de configurer un projet entre VueJs, TypeScript, Webpack et tout ça, je me souviens que j’avais galéré à mort à comprendre, surtout que tu ne verra pas deux tutoriels ou doc écrire la même chose. Puis quand ça commençait à tourner plutôt cool, Webpack 4 est sorti, et moi aussi, de mes gonds.

C’est pour ça qu’au boulot on a choisi angular/angular-cli/angular-material et qu’on discute de chaque dépendance, on vérifie le nombre de commit sur le projet, depuis quand il existe, est-ce qu’il a évolué etc. Avoir une chaine complète, cohérente et stable, coupler à du typescript en bannissant le type any, améliore grandement la santé mentale de l’équipe. Il y a encore pas mal de chose à améliorer coté outil, mais globalement on a beaucoup moins de point négatif que toi durant nos dévs.

J’ai eu a gerer un projet avec une interface web (comme architecte et toute la gestion R&D) et j’ai ete asse stupide pour aller sur le terrain de Node.js. Autant le framework lui meme etait plutot sympa, autant tout ce que tu decris etait un enorme frein pour les gens recrutes specialement pour ce projet.

Du coup, j’ai pris la decision de splitter le projet en plusieurs sous-partie: frontend en JS, backend minimal (routing REST et websocket, quelques services CRUD non-vital) et la logique applicative en Python sur un service separe. Meilleure decision de ma vie.

Pour le coup je plussois, j’ai eux à intégrer le combo vue + pug + scss avec Meteor, et là… on pleure X)

Ahah, la partie où tu parles de l’incohérence du JS me fait penser à ça : https://www.destroyallsoftware.com/talks/wat

Concernant le JS, personnellement, j’estime qu’on devrait l’utiliser le moins possible en front et pas du tout en back. Y’a sûrement des usages plus avancés légitimes, mais j’ai l’impression qu’actuellement, pour le front, beaucoup de sites abusent (certains ne chargent même pas de contenu en HTML, y’a 5 lignes de HTML et tout le reste est chargé en JS… on dirait un navigateur dans un navigateur…).

Quant au back, c’est plus une question d’expérience : les services NodeJS sont souvent problématiques, fournissent rarement un service à proprement parler, il faut bricoler avec des outils externes, etc.

Je ne parlerais pas des problèmes du langages en lui-même (incohérences, syntaxe…), car je ne saurais argumenter sur ce point.

En tout cas, ce retour d’expérience est intéressant

Le lien que tu donnes est bien un de ceux auxquels je pensais, en effet.

Quant à ceci :

C’est exactement ce qu’on obtient quand on fait une single-page application. Il y a des tas d’utilisations légitimes, en particulier dès que ton interface est très dynamique et dépend beaucoup de données très variables (l’exemple typique est un site de chat, comme Slack, Discord, Riot… ; mais les réseaux sociaux ou les interfaces gestion rentrent bien dans ce cadre aussi).

EN fait c’est particulièrement intéressant quant tu sais que lors d’une visite par un visiteur unique, le visiteur restera longtemps, aura besoin de peu de « vues » (au sens de la représentation des données) mais mais avec beaucoup de données différentes. Ça permet de transférer l’interface une fois et de la mettre à jour avec des appels à des API (voire du websocket).

Là où c’est emmerdant, c’est quand tu te retrouves avec une SPA là où les contraintes sont différentes : typiquement on trouve beaucoup de sites-vitrines dans ce genre de technologie, alors que les visiteurs restent peu et surtout que le site est complètement statique : tu obliges ton visiteur à charger beaucoup de JS et à le traiter, quand un simple HTML statique aurait très bien fait l’affaire.

Si on réfléchit au cas de ZdS, je ne vois pas l’intérêt de ce genre de technologie pour les contenus ni même pour les forums ; par contre ça pourrait être intéressant dans l’interface de rédaction.

Que le contenu change, pas de problème, mais la structure de la page ne peut-il être fait en HTML ? De plus, les parties relativement statiques (en-têtes, par exemple), peuvent être enjolivées en CSS.

Il me semble par exemple que Mastodon, qui est pourtant très dynamique, fonctionne même sans JS, le contenu n’est simplement plus mis à jour en temps réel.

Et justement, je pense que le JS ne doit servir qu’aux contenu à mettre à jour régulièrement, ou pour des fonctionnement dynamiques simples (tri par colonnes d’un tableau, notifications de nouveau messages…). Au final, sans JS, l’utilisation du site doit rester possible, simplement moins pratique.

Évidemment, il y a des cas où ce n’est pas possible. Mais je trouve qu’il y a souvent de l’abus.

Le CSS est toujours là – généralement tu écris du SCSS en réalité, qui lui aussi est compilé.

Quant au reste, quand tu crées une single-page application (ce que te permet de faire Vue.js, mais il permet aussi de faire autre chose), tu n’as plus de notion de « page HTML » telle que tu la connais avec un site statique, ni même que telle que tu génères avec un langage côté serveur. À la place tu as des composants que tu combines entre eux et que tu fais communiquer. Dès lors, avoir un HTML servi comme tel sur lequel on brancherait du CSS pour le rendre joli et du JS pour le rendre pratique, ça n’a plus de sens : chaque composant est responsable de son propre rendu.

En fait, je crois que le mot-clé est single-page application. Quand on en a besoin, on parle bien d’applications au même sens que n’importe quel logiciel installé sur ton ordinateur, pas d’un simple site de présentation statique (vitrine) ou semi-statique (tutoriels) – et évidement, sortir une SPA pour ces dernières catégories est complètement crétin.

Ensuite, les usages, les demandes utilisateur et l’ergonomie ont changé ces dernières années, l’utilisateur s’attends à faire pas mal de choses sans changer de page, il suppose par défaut que cliquer sur A va mettre à jour B sur la même page sans intervention autre de sa part.

En est donc dans des cas où JS sert à infiniment plus que « mettre à jour du contenu » ou « des fonctions dynamiques simples ».

Rajoute à ça une contrainte technique : mettre à jour le DOM est très lent, tous ces frameworks utilisent donc un DOM virtuel en sous-main, qui doit donc être géré en JS. Ça permet d’avoir des cas où utiliser une SPA est plus efficace et plus performant qu’utiliser du HTML simple, uniquement parce qu’un DOM virtuel gigantesque peut être rendu en un DOM réel réduit, là où sans JS tu devrais soit avoir un DOM énorme et lent, soit faire une ergonomie bancale.

Quant à la navigation sans JS, on est en 2018, elle n’a plus de raison logique d’exister : même les lecteurs d’écrans gèrent JS. Avant, Google était ton visiteur aveugle le plus important.
En 2018, Google est ton visiteur sur smartphone le plus important.

Ajoute à ça que faire une SPA, c’est souvent rapide, et que le surcout du « site qui marche sans JS quand même » est important pour un intérêt minuscule – parce que ça implique de faire des choses en double.

Cela dit, les SPA c’est comme toutes les technologies, il faut les utiliser là où c’est pertinent.

Merci pour le partage, y’a plein plein de retours intéressants et certains trucs qui me chiffonnent (Vue notamment :| ) mais peu importe, il me faudrait prendre beaucoup de temps pour répondre, notamment sur les systèmes de build (qui oui, sont un enfer, mais ça mérite de se demander pourquoi, et je pense que le fait que la tronche du livrable - 1 ou N bundles, SCSS ou pas - joue énormément).

Pour le coup des Promise vs. async / await, j’ai tendance à préférer les Promise, c’est plus "clair" que tu manipules un objet "partiel" et ce que tu peux faire avec. Pourtant, y’a un excellent article assez surprenant : https://v8.dev/blog/fast-async

Je prendrai le temps de répondre plus en longueur sur Vue / React (et les moteurs de template en fait), et sur webpack et ses copains (j’en frissonne de trouille déjà)

J’attends tes retours

À noter que :

notamment sur les systèmes de build (qui oui, sont un enfer, mais ça mérite de se demander pourquoi, et je pense que le fait que la tronche du livrable - 1 ou N bundles, SCSS ou pas - joue énormément).

Là-dessus, je joue complètement la carte de l’écosystème : Vue.js pousse à utiliser vue-cli, c’est donc à vue-cli de faire correctement le boulot (et c’est vue-cli que empile des couches de merde sur ce coup là). Mon but à moi c’est de faire du code métier et pas de me poser des questions existentielles sur l’impact de la tronche du livrable sur le système de build.

Allergique au web depuis des années, principalement back que front (en autodidacte) je me suis directement mis à Vue.js depuis 1 mois et je me fais mes premiers avis qui se rapprochent des tiens.

J’ai déjà développé un site pour mon service avec du combo Bootstrap + JQuery (et Flask pour le back) et c’était un réel foutoir avec JQuery. Mélanger du calcul à des updates graphiques fait que je ne m’y retrouve plus quand je dois maintenir le code. Passer sur Vue.js m’a vraiment réconcilié avec le front.

Je pense réécrire mon app du boulot en Vue.js, elle a pour fonctionnalité de manipuler pas mal de données et pour le peu de mini-projets que j’ai fait, j’ai l’impression que ce framework convient bien à ce type de pratique.

dans tous le cas : merci de ton REX !

@Nemergal,

Si tu veux aller un peu plus loin avec Vue.js tu peux peut-être essayer Nuxt.js, qui fournit une intégration et communication client-serveur pour les applications Vue.js.

Je l’ai utilisé pour un projet (FOE Tools, auto-hébergé sur GitHub) c’est vraiment pas mal.

Pour la partie style j’utilise Bulma à la place de Bootstrap, bon c’est les goûts, les couleurs mais c’est pour introduire ceci : il existe des libs qui wrappe le framework css avec Vue pour offrir des composants réactif Vue avec le style du framework, par exemple Buefy pour vue, c’est génial, pour Bootstrap je suis tombé sur bootstrap-vue.js, je n’ai pas testé mais ça doit bien faire la même chose. Je trouve, qu’en utilisant cela, on y gagne en productivité (et c’est fait pour ).

C’est très pratique ces libs de composants (qu’elles soient à utiliser directement comme vuetify ou qu’elles enveloppent un framework CSS comme bootstrap-vue). Elles ont toutes le même inconvénient : tu gagnes un max en productivité quand tu es dans les clous, et tu perds à mort dès que tu veux faire un truc qui est en dehors.

Après rien ne t’empêches de faire tes propres composants lorsqu’aucun ne répond à tes attentes

Toujours, mais le dilemme est plutôt « est-ce que je peux contourner la limitation du composant X ou bien le réécrire, mais en moins bien, moins intégré et ça va me prendre 2 semaines » ?

Re-Coucou, je note juste les points où j’ai un truc à dire, hein, ça veut dire que le reste RàS selon moi (précaution d’usage).

La programmation réactive

Note pour le lecteur : c’est plus générique que ça quand même. Si vous recevez un évènement en entrée, que vous le transformez, et produisez une sortie, on peut parler de programmation réactive. NB : Là où ça devient franchement drôle, c’est quand y’a plusieurs sources de données à fusionner, qu’il faut éventuellement protéger une sortie qui ne serait pas capable d’absorber autant de données qu’on en a en entrée et tout et tout (circuit-breaker, back-pressure, le bonheur <3 ).

Typiquement, dans le cas du front on n’est pas tout à fait dans la définition donnée par Wikipedia qui inclue un la communication par messages à la Erlang OTP. Bon y’a forcément un mécanisme de propagation d’évènements, mais je suis pas certain que ce soit du "message-passing" (asynchrones ! selon Wikipedia, là c’est clairement pas le cas dans un "flux" JS).

C’est une subtilité dans le cadre de l’article de SpaceFox, mais faut bien bien voir qu’entre Vue/React etc. et Erlang ou Akka et leurs "mailbox" ou Elixir et ses "process" j’ai pas l’impression que c’est pas tout à fait le même monde. C’est le même mot, mais "dans les mains, on n’a pas tout à fait le même truc".

En fait ce qu’il faut retenir, c’est que lorsqu’une donnée sera modifiée, toute la chaîne qui produit la vue sera ré-évalué pour (éventuellement) reproduire la vue. (ça Wikipedia le dit bien). Et en fait j’aurais pas parlé de ça, mais directement de l’approche "flux".

Data =======> fonction =======> représentation

Si une donnée change, on va ré-évaluer la fonction (l’ensemble de fonctions en fait) pour re-produire la représentation à l’écran. Comme le truc est malin, il ne va appliquer que les différences entre l’ancien et le nouvel état à l’écran.

Mais comment je fais changer la donnée alors ? C’est là je pense que les frameworks diffèrent, en envoyant des "actions". Et ça c’est sacrément cool en fait, ne serait-ce que pour tester.

Async / Await

Je m’étends pas j’en ai parlé plus haut. C’est bien mais "masquant". Encore plus dans un langage dont le compilateur ne peut pas te dire "mmh non, là t’as pas récupéré un Int, mais une Promise[Int], peut-être que t’as oublié d’écrire await ?"

Ca peut sembler trivial comme erreur, mais franchement, quand on va aller trifouiller des bases de code de 30000 lignes et qu’on saura plus vraiment quel appel est synchrone et lequel ne l’est pas… "Je mets await ou pas là ?" ça risque d’être une question qui va souvent se poser… Et puis le sucre… C’est un peu toujours le même sentiment… Quand c’est vraiment qu’un raccourci syntaxique bon… Mais là pour le mec qui n’a pas compris le code généré derrière (y’a une promise masquée ! et il est où du coup le try/catch). Franchement : Future[Either[NetworkError, JsonResult]] ça me semble plus propre, plus robuste dans le temps. Mais c’est les goûts et les couleurs.

Vue vs. React

Là encore, je cherche à convaincre personne et donne juste un avis perso. Je suis tombé sur un truc qui ressemblait à ça :

<tbody>
  <router-link tag="tr" v-for="item in basket" :to="'ItemLayout/' + item.id">
    <td>{{item.name}}</td>
    <td>{{item.description}}</td>
  </router-link>
</tbody>

Je pouvais pas trouver mieux pour expliquer pourquoi je crains un peu Vue. C’est chouette d’avoir un moteur de template, mais ça fait pondre ce genre de trucs magiques où pour bien comprendre il faut vraiment savoir comment il fonctionne en interne.

Y’a plein de remarques là-dedans mais le tag="tr" en fait c’est un espèce d’high-order-component un peu masqué et du coup dur de voir vraiment comment le code va être généré. Et après, le gros gros point noir de tous les moteurs de template : comment, quand les expressions sont évaluées ? item in basket j’ai quoi comme variables dans le scope ? Elles sortent d’où ? c’est des copies ? Et si jamais un petit malin s’amuse à en modifier une là-dedans ? C’est possible ? Encore pire pour la construction du lien. item item du coup fait référence à un truc qui est déclaré dans une autre expression. Et puis, c’est évalué comment ? Waouh, là y’a tellement de candidats à des erreurs, des typos, des prises de tête infernales que sérieux : ça m’inquiète.

Je préfère l’approche : j’ai une structure en entrée, des variables dans le scope, bref des trucs tangibles, inspectables au debugger, et je vais les transformer en balises HTML en appelant des fonctions (en gros : React + pure-components, ou Elm).

C’est vraiment dur et ça paraît moche, parce que JSX c’est perturbant. Mais honnêtement, à l’usage j’ai vraiment eu le même sentiment que t’as eu avec flux : ça rend la manipulation limpide en fait. render c’est vraiment juste une fonction : j’ai un ou des objets à gauche, une sortie propre qui est ma vue. Alors ouais, c’est pas la panacée non plus parce que t’as l’impression que ça "mélange" le JS et la vue. Mais en fait quand tu prônes l’approche reactive, c’est de toute façon ce que tu fais.

Je laisse webpack et ses copains pour plus tard, quand j’aurais (encore un peu) plus de temps.

Merci encore pour l’article cela dit, c’est un très bon ReX qui mériterait une "préz" propre sur une heure avec des slides et des bouts de code

C’est intéressant, parce que sur les deux points pratiques que tu soulèves, j’ai eu les expériences inverses à tes inquiétudes. je pars du principe que tu développes avec un IDE qui gère un minimum les spécificités de Vue.js (parce que ça existe alors pourquoi s’en priver ?) et que tu respectes les bonnes pratiques données par les projets.

async/await, ça fonctionne et surtout c’est lisible. Les promesses ont beau être une avancée de ce point de vue par rapport aux callbacks, tu te retrouves quand même assez rapidement à produire du code en écriture seule (donc difficile à relire). Il y a aussi plein de cas où le résultat est plus simple à comprendre (notamment les gestions d’erreurs) avec async/await qu’avec les promesses.

Quant aux appels qui peuvent être asynchrones ou pas, ma base de code n’est pas assez grande pour l’instant. Mais je n’ai jamais eu le problème grâce au découpage, j’ai du avoir le bug une seule fois sans que ça ne me fasse perdre du temps.

D’une manière générale j’aime bien le sucre syntaxique, et tout ce qui te permet de concentrer sur ton code et pas sur des aspects obscurs qui devraient être gérés automatiquement parce qu’il n’y a aucune valeur ajoutée à les gérer à la main. Ce qui m’importe, c’est pas ce que async/await va me générer comme code réel (ou même si ça va me générer une promesse ou pas d’ailleurs) ; ce que j’attends d’une expression du langage c’est qu’elle fasse ce qu’elle prétends sans surprise et de façon la plus lisible possible. Ça permet de diminuer la charge mentale associée à « comment marche le code » et augmente celle à « ce que fait le code », et c’est cette dernière qui est importante.

Quant à l’exemple de template que tu donnes, tu as un exemple un peu extrême, particulièrement peu lisible et douteux (la concaténation dans le to). Les questions que tu te posent dans la suite semblent légitimes au premier abord, mais sur des projets réels développés proprement tu n’as pas de soucis avec le moteur de template. Parce qu’une fois que tu connais les 2–3 règles de fonctionnement du moteur, c’est des questions qu’en réalité tu n’as pas à te poser : tu te fiches du quand et comment c’est évalué, tu sais ce que tu as dans le scope (une prop, une data, un computed, une method si tu veux une action ou que tu as un cas tordu à gérer, ou comme dans ton exemple une variable que tu as déclaré juste au-dessus). Les seuls cas pénibles et peu clairs que j’ai eu à gérer, c’est quand tu te retrouves avec des composants qui ont des « scope slot ».

En fait, quant tu arrives à écrire des trucs trop compliqués dans la partie HTML de ton composant Vue.js (dès que tu dois inspecter au debugger un élément quelconque de cette partie), c’est généralement signe que tu as mal placé ta logique, et que tu dois sortir des computed, des méthodes voire des nouveaux composants. Il ne faut pas hésiter à faire davantage de composants.

Yep, en fait coté Bootstrap j’utilise un thème très bien foutu qui est développé sur Boostrap.vue et ne demande donc pas de JQuery. J’ai entendu parler de Bulma mais pas encore creusé, peut-être un jour sur un autre projet.

Trois ans et demie après, je refais un peu de JS et… ben ça s’est pas arrangé l’écosystème