Licence CC BY

8 mois avec Javascript (ES6) et vue.js

Ma vision personnelle du développement front en 2018

Dernière mise à jour :
Auteur :
Catégorie :
Temps de lecture estimé : 7 minutes

Il y a environ huit mois, mon patron m’a dit : « SpaceFox, on est en dèche de développeurs front, y’a un projet à faire là, est-ce que tu veux le faire ? ».

Comme c’était un projet à démarrer depuis rien, que je ne connaissais pas le javascript moderne1, et que je ne serais pas coincé que sur cette technologie, eh bien j’ai accepté. Alors, huit mois plus tard, qu’est-ce que je peux en dire ?

Tout ce qui suit n’est que mon avis personnel et ne prétends ni à l’exhaustivité, ni à l’objectivité !

L’environnement technique

Le but du jeu était de développer des applications en une page (single-page application) avec un framework moderne, et ça devait supporter IE11 en mode dégradé, et les navigateurs modernes en fonctionnement nominal. C’est de l’application assez classique, avec des appels à des API REST et une poignée de traitements côté client.

On s’est posés la question de TypeScript, mais ajouter un système de type à un langage qui n’en a pas, c’est pratique tant que tu maitrise ton code de bout en bout. Mais dès que tu appelles une lib externe, tu te retrouves avec des types à rallonge et/ou incompréhensibles. Vues les avancées de ES6, on s’est dit qu’on pouvait se passer de TypeScript. Y’a des jours où je me dis que c’était une bonne idée, d’autres où je pense que c’était une connerie… la vérité c’est qu’à mon avis je me serait fait chier autant mais pas sur les mêmes trucs.

Alors on a monté un projet avec :

  • ES6 (et même plus, parce qu’on utilise async/await)
  • Babel pour la compatibilité
  • Webpack pour lier tout ça
  • Vue.js comme framework avec vue-router pour le routage et vuex pour la gestion d’états type flux (et donc vue-cli 3 pour gérer une bonne partie des aspects)
  • Axios pour la communication réseau
  • Jest pour les tests unitaires
  • Gitlab CI pour l’intégration continue
  • eslint en mode paranoïaque pour les bonnes pratiques et le formatage du code (c’est fou ce qu’on peut apprendre en lisant les erreurs de lint)
  • Et un gros tas de libs

Les bons côtés

La souplesse de Javascript

Le fait que JS permette de faire un peu tout est n’importe quoi a un côté pratique : souvent, on peut aller au plus court et ça fonctionne. Par exemple, on peut faire des objets parfaitement arbitraires sans jamais déclarer leur structure nulle part, et mine de rien ça fait économiser plein de code.

Je ne vais pas m’étendre là-dessus : JS est très souple, c’est très pratique.

La programmation réactive

Y’a un article Wikipédia à ce sujet, mais pour résumer : en programmation classique (MVC), on va avoir des structures de données, on va définir des vues à partir de ces données, et programmer les moyens de mise à jour des données et comment les vues sont mises à jour à partir de ces données.

En programmation réactive, on va avoir des données réactives et construire des représentations de ces données. Mais pas besoin de programmer la mise à jour des vues à partir des données : le framework réactif garantit que les vues sont à jour.

Concrètement, ça a une courbe d’apprentissage bien raide et demande un découpage du travail très différent d’un framework réactif (définition des données, et dans le cas de Vue.js des composants). Mais une fois le concept maîtrisé, c’est excellent, surtout pour les applications qui consistent principalement en de la présentation et de l’édition de données.

Le pattern flux

Des explications ici avec des liens. Ça rajoute un peu de code par rapport à une utilisation du framework « nue », mais pour moi dès que l’application n’est plus triviale c’est tout simplement indispensable.

Pourquoi ? Parce que la combo programmation réactive + flux force un découplage tel que des évolutions qui seraient casse-pieds sur un framework « classique » deviennent complètement triviales.

Une communauté énorme et réactive

Il y a une telle communauté JS (forcément, c’est le seul langage disponible en front… et on l’utilise en back aussi maintenant) que si on a besoin d’un coup de patte ou d’une lib, c’est à peu près certain que ça existe.

async / await

Plus de callback ! Plus de promesses ! Tu écris ton code asynchrone, et il fonctionne !

Les performances en runtime

Une très bonne surprise : moi qui m’inquiétais de ça, en fait je peux faire afficher des centaines de composants, utiliser des select avec des milliers d’items (et une recherche) ou faire traiter des tableaux de dizaines de millions de cellules avec des performances correctes sans y passer spécialement du temps.

Les mauvais côtés

L’incohérence et l’aspect cryptique du langage

Là non plus je ne m’étendrai pas, il y a des sites entiers sur le sujet, mais en vrac : ===, la non-commutativité de beaucoup d’opérateurs, la gestion incompréhensible des casts automatiques, null et undefined

Plus vicieux : ES6 a ajouté énormément d’éléments très pratiques, mais vient aussi avec son lot de détails incompréhensibles. Exemple : si les variables a et b sont déjà déclarées et que j’ai un objet o = { a: 'quelque chose', b: 'autre chose' } que j’essaie de déstructurer, je ne peux pas faire { a, b } = o; mais je dois faire ({ a, b } = o);… (je vous laisse trouver la différence).

Les webworkers

J’en ai besoin parce que j’ai des traitements qui sont gourmands en CPU et que je veux garder une interface réactive (et que JS est mono-thread). Eh ben, c’est le pire système de parallélisme que je connaisse. Surtout couplé à l’absence de types explicites, qui fait que tu découvres seulement au runtime que ton worker ne fonctionne pas parce qu’il y a une fonction dans l’objet que tu essaie de lui passer.

La souplesse de Javascript

C’est bien, la souplesse. Mais dès qu’on bosse à plus de 1, ou plus d’une semaine sur un même projet, sans un linter paranoïaque, c’est un coup à se retrouver avec des techniques de code très différentes partout dans le projet. Ou du code illisible. Ou les deux.

La folie furieuse de la communauté

Sans déconner : après huit mois d’observation, ma conclusion la plus logique est que 95 % de la communauté Javascript est composée de macaques sous cocaïne. Je ne vois pas d’autres explication logique à l’état général de l’environnement.

Tout détailler serait beaucoup trop long, mais en vrac :

  • Tout change tout le temps sans te laisser le temps de te retourner (Vn+1 en bêta ? On déprécie la Vn !)
  • Conséquence : beaucoup de codes cassés, et pratiquement toutes les docs sont obsolètes (quel que soit le sujet).
  • Y’a le choix pour tout… tout existe au moins en double, sans que rien de devienne un standard de fait (et ça concerne jusqu’aux règles de formatage de code, ou aux éléments du framework de test – j’ignorais qu’on pouvait découper un framework de tests unitaires en plusieurs sous-blocs)
  • Le découpage en femtomodules jusqu’au ridicule infini. Il existe un package pour savoir si un nombre est pair qui se contente de dépendre d’un autre package pour savoir si un nombre est impair et fait un « not » dessus. La première fois qu’on me l’a dit je ne l’ai pas cru. Pire : ce package a connu 4 (quatre) versions, a été téléchargé 19 020 (dix-neuf-mille-vingt) fois la semaine passé et 7 (sept) autres packages en dépendent.
  • Les empilements de solutions absconses : ça fonctionne dans le cas nominal et t’explose à la tronche dès que tu essaies de sortir des clous. Exemple ? Les fichiers webpack sont un tel foutoir que même avec webpack-merge on ne s’y retrouve pas ? Pas grave, on va créer un troisième outil nommé webpack-chain qui va garantir que dans le cas nominal c’est plus simple, et que dans absolument tous les autres cas c’est encore moins compréhensible, parce qu’on doit écrire du code illisible pour générer un fichier de conf illisible (et t’as pas le choix, tout ça t’es imposé par un quatrième outil…)
  • Ce genre de réponse.
  • Le choix d’un format de fichier (JSON) qui ne gère pas les commentaires pour le fichier de définition des dépendances du projet. Juste ça.
  • Les chaines de « Projet A ne me plait pas alors je crée B qui fait la même chose mais en mieux mais depuis A s’est amélioré du coup A et B cohabitent et/ou mergent et du coup c’est le foutoir » (coucou npm et yarn !)

Les outils

C’est un peu une conséquence de tout ce qui précède. Même avec le meilleur IDE du monde, le langage et l’écosystème est tellement pourri jusqu’à la moelle que des tas de trucs qui devraient fonctionner ne peuvent pas fonctionner. Et donc tu perds un max de temps et d’énergie là où tu ne devrait pas. Exemples ? En vrac avec les IDE JetBrains :

  • Impossible d’avoir une autocomplétion correcte : dès que le scope de ta variable n’est plus absolument évident (et encore), l’outil te propose n’importe quoi. La refactorisation peut t’exploser à la tronche pour les mêmes raisons.
  • Impossible de trouver une dépendance à cause d’une typo ? C’est probablement pas grave, c’est sans doute un truc résolu dynamiquement, c’est donc un weak warning non signalé et presque invisible. Mais ça plantera au runtime.
  • Les versions installés des packages ne sont pas cohérentes avec celles demandées ? Pas grave, personne ne préviens tant qu’on essaie pas d’ouvrir le fichier package.json…
  • Le package.json qui ne fixe pas des versions précises, tâche déléguée au package-lock.json… qui ne les fixe pas non plus.
  • npm qui fait des modifications random dans ce dernier fichier (« et si je changeais la moitié des https en http ? »).
  • Les surprises à la MàJ de Node.
  • Les formats différents de packages JS. Le pire étant une lib qui n’est distribuée qu’en plugin jQuery.

Les performances en développement

Bordel mais que font les outils pour que la compilation soit aussi lente et nécessite autant d’entrées/sorties disque ? Le développement JS sans SSD, c’est devenu virtuellement impossible.


  1. Parce que malgré mes années de développement web, à cause des projets j’ai toujours été coincé sur du bricolage avec jQuery – au mieux – niveau dev front…



En conclusion…

J’ai découvert des tas de trucs ces huit derniers mois. J’ai appris des frameworks et des technologies très intéressantes, qui ont objectivement fait de moi un programmeur meilleur et plus complet. J’ai aussi une bien meilleure compréhension du développement web front moderne.

Je sais aussi maintenant que, de mon point de vue, on peut enfin faire des projets intéressants et s’amuser avec du JS en front (ce qui était strictement impossible avant pour moi). Vue.js, c’est un framework que j’aime bien (et y’a un an, je ne pensais pas dire ça un jour d’un framework JS).

Par contre, c’est clairement malgré Javascript et malgré 90 % de l’écosystème, qui sont des plaies purulentes qui ne mériteraient que la purification par le feu. Et ça fait que maintenant je sais que je ne toucherai pas à du JS côté serveur, même avec une pelleteuse de mine.

19 commentaires

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. :D

Édité par informaticienzero

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.

+0 -0

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.

Édité par KFC

« Kommunist Fried Chicken » | Macroeconomics: Three decades of intellectual regress

+0 -0

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. :D

informaticienzero

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

Édité par Heziode

+0 -0

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 ^^

Breizh eo ma bro, hag ihuel eo ma c’halon geti. Da viken. — L’oiseau imaginaire : ZzxŷxzZ

+1 -0

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

Quant à ceci :

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….

Breizh

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.

Breizh eo ma bro, hag ihuel eo ma c’halon geti. Da viken. — L’oiseau imaginaire : ZzxŷxzZ

+0 -0

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à)

Édité par Javier

Happiness is a warm puppy

+2 -0

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 ! :)

+0 -0

@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 :) ).

+1 -0

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.

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 :)

Édité par Javier

Happiness is a warm puppy

+1 -0

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.

@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 :) ).

Heziode

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. :)

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte