Sommaire
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 ?
Attention : 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.
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.
Ce billet est placé sous licence Creative Commons Paternité (CC BY) 4.0.
-
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… ↩
# ne pas faire de js sans pour autant s'en passer
Posté par ze0 . Évalué à 7.
Très instructif tout ça.
Et si je te disais qu'on peut faire du front en python ?
http://www.brython.info/
C'est méconnu et personnellement, du peu que j'ai testé des fois c'est un peu lent, mais ça a le mérite de fonctionner.
c'est une lib js qui traduit à la volée le python en js, et ça marche bien.
[^] # Re: ne pas faire de js sans pour autant s'en passer
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
Merci, je garde le lien sous le coude ; cela dit pour le projet professionnel, vu les outils déjà utilisés, quitte à changer de langage côté front on partirait plutôt sur quelque chose comme Kotlin (on a déjà du Java et du .NET, mais pas de Python).
La connaissance libre : https://zestedesavoir.com
# C'est... rassurant ?
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 10.
En tant que développeur back je suis frustré depuis quelques années par la crainte de passer à côté de quelque chose.
Alors j'ai essayé il y a quelques temps de monter un thème CSS en Material, et j'ai dû abandonner après en être arrivé à la même conclusion que pour JS : des forks à n'en plus finir, des docs toujours obsolètes, et toujours des nouvelles versions à venir qui devraient enfin unifier des choses et qui ne le font jamais.
Et évidemment des outils de build… en JS… qui correspondent bien à la description faite par l'auteur de ce journal.
Résultat : je suis toujours frustré, et doublement même.
[^] # Re: C'est... rassurant ?
Posté par Guillaume Denry (site web personnel) . Évalué à 10. Dernière modification le 09 novembre 2018 à 11:03.
En tant que développeur sur un "gros" projet nodejs pro depuis quelques années, je n'ai qu'une seule envie, c'est d'aller me balader dehors avec une pancarte sur laquelle serait écrit "N'utilisez surtout pas cette techno ! Fuyez, pauvres fous ! La fin est proche !".
Au début du projet, c'est fun, javascript te permet d'aller très vite, tu déclares un nom de paramètre dans ta fonction comme ça et paf, tu t'en sers direct. Tu veux un serveur web ? C'est fait en 3 lignes ! Wow et puis Express est vachement simple et sympa à utiliser !
Et puis au fil des mois, des années, tu réalises que l'extrême liberté dont tu disposes pour faire absolument tout ce que tu veux se transforme peu à peu en espèce de dette technique monstrueuse, à moins d'avoir couvert absolument toutes tes arrières avec des millions de tests auto. Tu réalises aussi que le monothread pour faire du traitement - parce qu'au bout d'un moment, ton back va forcément faire du traitement - à côté de la prise en charge des requêtes, c'est vraiment la cata absolue, alors tu regardes autour de toi, on te parle de workers, de microservices, etc, alors que ton appli ne gère juste que quelques milliers de connexions à tout casser et que tu veux juste faire un petit calcul sur tes données en même temps, et ton back en a déjà raz la gueule.
Après, tu vois des petits copains à côté qui sont partis sur une stack elixir et qui font tourner une appli qui gère des centaines de milliers de connexions et qui font simultanément le même genre de traitement que toi en même temps et qui commencent juste à se demander s'il faudrait pas modulariser l'appli, pour des raisons fonctionnelles différentes des performances.
Et là, tu pleures.
Donc non, tu ne rates pas grand chose.
[^] # Re: C'est... rassurant ?
Posté par Guillaume Denry (site web personnel) . Évalué à 6.
Je réalise que j'ai un peu compris ton commentaire de travers, tu parlais de front uniquement, sorry.
[^] # Re: C'est... rassurant ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7.
Tu as été peut-être confusionné par la dernière phrase de la conclusion qui dit :
Ton témoignage me conforte dans mon idée.
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est... rassurant ?
Posté par Guillaume Denry (site web personnel) . Évalué à 3. Dernière modification le 09 novembre 2018 à 11:21.
Non, je répondais à Nanawel, et la confusion vient de se phrase "En tant que développeur back…"
Mais j'avoue que ça me démangeait de faire le même commentaire directement en réponse à ton nourjal :)
Un cri de désespoir, sûrement…
[^] # Re: C'est... rassurant ?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 09 novembre 2018 à 11:36.
Ah OK, au temps pour moi :)
La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est... rassurant ?
Posté par Nanawel (site web personnel, Mastodon) . Évalué à 7.
J'ai pas précisé : développeur back non-JS.
Je fais du PHP pour être franc, et l'écosystème est loin d'être aussi moche (à présent).
[^] # Re: C'est... rassurant ?
Posté par folgore . Évalué à -4.
Dans le dev front, ta l’impression de devoir télécharger tout l'internet pour un simple site web spa ou app mobile. En arrière plan l'usinage a gaz de node.js, la folie des webpacks et gâteries en tout genre.
Les développeurs back qui ne veulent pas se mettre au front par toute les raisons évoques (maintenant tout deviens web, il est temps de s'aligner sur le marché!), c'est souvent dans le genre: "pas de bol, j'ai bossé avec une mauvaise stack technique". Après je comprends, c'est la jungle, la poubelle. L'astuce c'est restreindre tout ça et choisir ce qui semble populaire et maintenue.
Perso, j'arrive a travailler de manière confortable en choisissant la bon stack, on va dire même le bon starter kit ou comme on dis aussi le fameux boilerplate !
J'ai envie de faire du mobile ? j'utilise react ignite (ionic c'est bien aussi pour une appli rapide!).
Un site web (ou un mélange entre web, mobile: so pwa) ? y a ngx-rocket
Enfin bon, même si en vrai, ng cli avec typescript - scss- et/ou bootstrap / material suffit, c'est clean au moins et on sait ce qu'on fait…
L'ide: Visual Studio Code. je ne comprend même pas pourquoi j'ai lu JetBrain.
Le reste, node.js / gulp etc en arrière plan qui font leur taf.
Au pire, on supprimer node_modules si ca bug et on reinstalle tout…
Aujourd'hui ce que je préfère le plus, sont la la stack .Net Core / Web Api pour le back-end et React / Angular pour la partie front-end. En plus Microsoft est sympas, quand on crée un projet, ta déjà le kit pour te lancer proprement.
Enfin bref, je crois que c'est exagéré tout ca. Une fois que tout est en place est fonctionnel, nullement besoin de se névrosé sur les mises a jours de libs et dépendances. Dans tout les cas, on sait très bien que tous les 6 mois, y aura un fork et une nouvelle version de untel framework. On s y attardera dessus sur un nouveau projet qui contiendra un package.json surement plus a jour que celui actuel :)
[^] # Re: C'est... rassurant ?
Posté par folgore . Évalué à 1.
J’ai oublié quand même de préciser une grosse frustration : c’est quand tu veux utiliser un super composant mais au final il ne fonctionne pas soit parce que t’es en typescript, l’autre en javascript et y a pas de definition ts… ou bien soit parceque ta version de typescript ne fonctionne celui composant. Et la bonne change pour matcher la version qui va bien avec sans soucies d’interdépendances ><
[^] # Re: C'est... rassurant ?
Posté par Flavien . Évalué à 0.
un projet intéressant à suivre (React/AspNetCore/SignalR) :
DotNetify
# merci
Posté par ComputingFroggy (site web personnel) . Évalué à 2.
Merci pour ce retour très instructif.
Ça ne me motive pas trop pour faire le pas, pour passer à Vue.js maintenant … probablement plus tard.
[^] # Re: merci
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Tout dépend de quoi tu part : si tu as déjà un front que tu veux moderniser, Vue.js est un bon framework (et tu as déjà les avantages et limitations sur l'écosystème JS).
Si c'est pour changer un framework côté serveur en SPA, la question mérite effectivement une étude.
La connaissance libre : https://zestedesavoir.com
# compilation
Posté par goeb . Évalué à 5.
De quoi parle-t-on ici ? Que signifie "compilation" dans ce contexte ?
Je croyais que le javascript était interprété par le navigateur, et donc je ne comprends ni l'emploi du terme "compilation", ni la mention des I/O disque.
[^] # Re: compilation
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Si tu veux utiliser du Javascript moderne dans des navigateurs qui ne sont pas uniquement de la toute dernière génération, tu es obligé de le compiler – ou plus exactement de le transpiler – et de le fournir sous un format compatible avec les différents navigateurs.
C'est le boulot de Babel et de Webpack. En gros, le premier va transformer ton JS moderne en JS moins moderne mais compréhensible par des navigateurs qui ont plus de 6 mois ; le second va packager tout ce bordel dans des fichiers que les navigateurs vont pouvoir utiliser directement. (En réalité, c'est bien plus complexe que ça, mais tu as l'idée). Il y a aussi une phase de transformation SASS → CSS et de minification.
Donc dans un projet JS moderne, le code que tu écris n'est plus interprété directement par le navigateur. Et la phase de transformation est atrocement lente et nécessite une quantité démente d'I/O disques.
La connaissance libre : https://zestedesavoir.com
[^] # Re: compilation
Posté par François GUÉRIN (Mastodon) . Évalué à 9.
Salut,
En fait, c'est de la transpilation (transformation d'un bout de code d'un langage A vers un langage B), plus minimisation de la bande passsante utilisée pour le transport du dit bout de code. Dans mon cas, un simple uglify met 3-4 minutes… (dans un projet "de base", pas celui décrit ci-dessous)
Je suis actuellement en train de me battre avec un projet django, je souhaite moderniser ma stack (requirejs + jquery…), je me suis penché sur webpack (une horreur pour un dev "full stack"), et j'essaye d'utiliser mes forms django dans cet environnement: je passe plus de temps à faire des bouts de js cryptiques pour faire de la glue entre le monde django et le monde JS, mais je crois que je ne vais pas tarder à laisser tomber et recommencer depuis le début, en commençant par virer le dossier node_modules.
Ce mélange entre les libs utilisées en en prod et les outils de gestion de projet (?) et des plus complexe à maintenir, j'en suis à:
WTF !
[^] # Re: compilation
Posté par raspberry_cook (site web personnel) . Évalué à 2.
J'ai rencontré exactement le même problème avec Ruby on Rails. On se retrouve à faire un mélange dégueulasse en Ruby / JS …
[^] # Re: compilation
Posté par flan (site web personnel) . Évalué à 7.
[note : je ne suis pas développeur web mais le fait est que je doive développer des outils métiers avec une interface web]
Personnellement, je suis parti sur du Django avec du scss (maintenant bootstrap4, scss et django-pipeline), quasiment rien en JS et des websockets pour faire le maximum côté serveur.
Je clique sur un bouton qui doit faire apparaître une fenêtre modale ? le clic envoie un signal au serveur via le websocket, le serveur génère le HTML du popup et envoie au client le signal « afficher la fenêtre modale avec le contenu fourni ».
Côté client, j'ai quelques signaux inspirés de jQuery (ajouter/modifier/supprimer du HTML sur un sélecteur CSS, ajouter/supprimer des classes CSS, afficher une fenêtre modale, etc.) qui sont génériques et codés une bonne fois pour toute.
Toute l'intelligence est donc côté serveur, en Python, et exécutés dans des processus différents (un processus pour les interactions rapides comme ci-dessus, un ou plusieurs pour les tâches plus lourdes, etc.).
Ça me permet de faire des pages avec pas mal d'interactions dynamiques sans écrire la moindre ligne de JS (ou presque).
[^] # Re: compilation
Posté par Claude SIMON (site web personnel) . Évalué à 3.
J'ai suivi exactement la même démarche pour exactement la même raison. Je me sens moins seul du coup, parce que d'habitude j'ai du mal à faire saisir l'intérêt de cette démarche.
En ce qui me concerne, c'est sur du C++ que je suis parti, au lieu de Python. Puis je me suis «amusé» à créer des bindings pour d'autres langages, vu que le C++ s'interface avec à peu prés n'importe quel langage.
Après Java, Node.js et PHP, je viens justement de m'attaquer au binding Python.
Pour nous émanciper des géants du numérique : Zelbinium !
[^] # Re: compilation
Posté par AnthonyRabine (site web personnel) . Évalué à 8.
C'est simple, tu ne veux pas comprendre deux problématiques majeures, qui te paraissent mineures pour toi mais que la majorité des entreprises / développeurs prennent en considération :
tu mélanges tout dans le back-end. Demain tu changes de techno, t'es coincé, tout est à jeter. Et tu as un gros risque de tout faire péter à la moindre modification. Tes exemples simples sont naïfs : ils fonctionnent, mais pas lorsque l'application est gigantesque et que tu as 20 développeurs. Personne ne veut plus travailler comme cela. On veut des composants, des couches de liaisons, des interfaces agnostiques etc…
Les performances : il faut faire travailler le client, pas le serveur. L'avancée du JS et de ce genre de designs c'est génial pour des développeurs C/C++ embarqués comme moi, ça soulage le processeur et tu peux sous traiter le HTML/JS/CSS de merde à quelqu'un d'autre, et garder pour toi la noblesse et l'élégance du C embarqué.
[^] # Re: compilation
Posté par AnthonyRabine (site web personnel) . Évalué à 8.
Ok, de mon point de vue c'est une très mauvaise architecture.
Mon serveur "back-end" n'a pas une once de HTML, et il ne veut même pas savoir que c'est un site web qui demande des choses. Tout est en REST, et ça renvoie du JSON. Demain, c'est une application Android, un démon en C ou un script bash qui lancera des requêtes. Peut importe.
L'avantage des nouveaux frameworks est qu'ils intègrent un routeur côté client, c'est vraiment le truc super important : ainsi, le découpage "rendu" et "données" est parfait. J'ai développé 100% de mon appli web dans aucun backend, que du JSON fake, avec plein d'écran différents.
# TypeScript
Posté par Christie Poutrelle (site web personnel) . Évalué à 10.
Dommage que tu n'es pas essayé en TypeScript, le typage très stricte, et les "zero-cost-abstraction" (interfaces, et autres), son système de type extrêmement puissant (union types, sum types, et autres joyeusetés) et la validation à la compilation par tsc c'est juste magique. En gros, tu n'écris plus jamais une seule ligne de (Java/Ecma)Script, c'est un autre langage, qui lui pour le coup est vraiment génial.
Dans tous les cas, ça reste des technos de merde tout ce qui est autour du JS/ES, personne ne type rien, les paquets sont cassés tous les deux mois, c'est impossible de monter tes dépendances en version si tu ne l'a pas fait au moins une fois par semaine, et à chaque (nmp|yarn) add que tu fais, tu te paluches 50 dépendances de plus, 50 Mo dans ton node_modules, qui par la même occasion est une hérésie sans nom, avec des règles de résolution d'import complètement débiles.
Les gens qui sont fanatiques de cet écosystème doivent au fond avoir peur des autres langages parce que c'est "plus bas niveau" ou autres excuses, alors qu'en réalité ils sont beaucoup plus simples, régis par des règles - en fait je vais m'arrêter au mot "règles", la seule chose qu'il n'y a pas du tout dans tout l'écosystème JS, sauf quand on regarde du côté des "gros" frameworks tels qu'Angular (très bon) et React (très bon aussi).
Bref, je suis content de ne pas/plus en faire, plus jamais. Quand on a commencé par le C, C++, Java, C# et autres langages un peu sérieux et bien outillé, aller vers le JS moderne c'est une régression énorme, un retour 30 ans en arrière.
[^] # Re: TypeScript
Posté par karchnu . Évalué à 10.
Exactement. On a beau dire et répéter ad nauseam que Javascript c'est trop bien parce qu'on écrire rapidement du code, c'est aussi rapidement du code jetable, avec aucune vérification de quoi que ce soit (même pas automatique dans le compilateur). Bien sûr, ils ajoutent aussi de nouvelles terminologies hype, parce qu'ils ne connaissent tout simplement ce qui se fait en dehors de leur propre écosystème (hey les gens, la "transpilation" C'EST DE LA COMPILATION, compiler ce n'est que transformer un langage dans un autre…).
Et tout le monde crée, personne ne vérifie ce que les autres font, c'est juste affreux. Au lieu d'avoir un beau langage (sans absurdités comme évoqués dans le journal), quelques bibliothèques légères qui s'occupent d'apporter ce dont on a besoin régulièrement en web pour palier le manque d'expressivité dans le HTML+CSS, on préfère avoir des centaines de milliers de bouts de codes cassés dans un énorme dépôt. Absurde.
Je suis content de ne pas y toucher, et les quelques projets web sur lesquels je vais participer prochainement n'auront jamais une seule ligne de javascript. On préfère largement importer un interpréteur Lua/MoonScript, faire du livescript ou du Elm, mais pas une ligne de javascript. Jamais.
[^] # Re: TypeScript
Posté par kursus_hc . Évalué à 6.
Il me semble qu'une transpilation est une compilation vers un langage de même niveau, ce qui doit être le cas de javascript et typescript.
[^] # Re: TypeScript
Posté par Christie Poutrelle (site web personnel) . Évalué à 10.
Wikipedia est notre ami "Compilateur source à source": https://fr.wikipedia.org/wiki/Compilateur_source_%C3%A0_source
Un transpileur est un compilateur spécifique.
[^] # Re: TypeScript
Posté par raphj . Évalué à 2. Dernière modification le 12 novembre 2018 à 11:50.
Pas la peine d'être désagréable comme ça.
Est-ce que le terme "transpiler" a été inventé par les gens du milieu Javascript ? Non.
Est-il est mal utilisé ? Pas à ma connaissance.
Est-il ambigu ou vague ? Non.
Quel est le problème d'utiliser "transpiler" à la place de "compiler" ?
On peut ne pas aimer le terme transpiler, et considérer que c'est une forme spécifique de compilation, et préférer juste dire compilation. On peut ne pas aimer les néologismes. Mais ça n'a rien à voir avec "ils ne connaissent tout simplement ce qui se fait en dehors de leur propre écosystème". C'est hors sujet.
Il y a une différence entre ignorance et choix.
Je ne changerai pas mon avis plus ou moins neutre sur le mot "transpiler" avec des remarques en majuscules et continuerai à l'utiliser tant que personne ne me donnera un argument solide.
Commenter c'est aussi écrire. Devrait-on dire "écrire" plutôt que "commenter" ? Non, "commenter" a un sens plus précis.
Je dis ça en ayant écrit un compilateur jouet (vers assembleur) et un transpileur (vers Javascript). Il y a plein de problèmes que je n'ai pas touchés dans le second cas, notamment l'allocation de registre (mais effectivement, il y a des problèmes de renommage dans les deux cas). Il y a aussi un problème que j'ai traité dans le second cas et pas dans le premier cas : la lisibilité du code produit, et calquer le formatage du code source. Pour moi ce n'est pas complètement aberrant de vouloir appeler ces deux trucs différemment et chaque camps devrait respecter les avis de l'autre camp.
Sur le fond du problème : Javascript a clairement ses travers et son écosystème est étouffant mais ce n'est clairement pas un mauvais langage. Après, il y a des questions de goût et des expressions comme "ad nauseam" n'ont rien à faire dans un argumentaire solide.
On peut ne pas aimer et ça ne se discute peut-être pas trop, mais on peut faire du Javascript correct sans utiliser la lourdeur de l'écosystème (perso j'écris systématiquement du Javascript standard ou du TypeScript occasionnellement).
Je ne comprends pas toute cette haine pour ce langage. Il faut juste passer un peu de temps à accepter ses défauts (il y en a beaucoup - mais j'en connais dans les autres langages que j'utilise), à comprendre son fonctionnement et à apprécier ses richesses. Et des langages comme TypeScript retirent une partie des problèmes si on veut plus de garanties sur les types.
Importe ton interpréteur Lua, je ne désactiverai pas mon bloqueur de scripts pour ton projet (ça me gonfle de voir mon navigateur devoir interpréter du code pour afficher un article), ma bande passante et mon processeur ont d'autres trucs à faire et les ressources énergétiques de la planète aussi. Après on parle de bibliothèques légères, faudrait voir à être cohérent. Grrr. Désolé pour le petit coup de gueule.
[^] # Re: TypeScript
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Si tu arrives à me définir ce qu'est un "mauvais langage", on pourra peut-être discuter. Jusque là, ta définition est aussi arbitraire que de dire "Javascript est un mauvais langage".
Ce qui est certain, c'est que JavaScript est un langage qui permet plus que beaucoup d'autres d'écrire des immondices in-maintenables. Parce qu'il n'y a qu'au runtime qu'on peut vraiment dire si le programme fonctionne, et encore, en testant et re-testant. Ce langage n'offre quasiment aucune garantie de bon fonctionnement, c'est son principal problème. Il plaît beaucoup aux gens qui n'aiment pas les contraintes. C'était mon cas il y a quelques années, j'ai longtemps trouvé génial le typage dynamique. Sauf qu'au bout d'un moment, on réalise que les contraintes sur un langage ne sont pas des entraves mais au contraire, des moyens d'émancipation et des guides.
[^] # Re: TypeScript
Posté par raphj . Évalué à -4.
On peut écrire des immondices dans n'importe quel langage. Si les choses sont faites avec un peu de discipline, on peut arriver à un résultat correct.
Il suffit de ne pas faire n'importe quoi, d'utiliser un sous-ensemble correct du langage et de suivre les bonnes pratiques qu'on a choisies et de s'y tenir. Il y a des très bons linters si on veut avoir un peu de rigueur "garantie". Je ne les utilise plus actuellement mais j'en étais fan il y a quelques années et j'ai beaucoup appris grâce à eux.
Ne pas écrire du code trop intelligent, éviter les constructions bizarres, nommer ses variables correctement, et en fait appliquer les conseils qui s'appliquent à tous les langages font déjà beaucoup de bien.
Je préfère aussi avoir du typage statique mais ce n'est pas le seul aspect du langage et en l'occurrence, TypeScript offre un système de type meilleur que beaucoup de langages typés (mais il y a mieux aussi).
[^] # Re: TypeScript
Posté par flan (site web personnel) . Évalué à 10. Dernière modification le 12 novembre 2018 à 22:11.
Oui, certes, mais il y a des langages qui s'y prêtent beaucoup plus que d'autres.
[^] # Re: TypeScript
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Le relativisme absolu.
On peut écrire des immondices et du beau code en brainfuck aussi, ou avec le ruban de Turing.
[^] # Re: TypeScript
Posté par raphj . Évalué à 2. Dernière modification le 13 novembre 2018 à 10:35.
Ben voyons.
Je n'ai pas affirmé qu'on peut écrire du beau code dans n'importe quel langage.
Le ruban de Turing est un modèle pour raisonner sur la calculabilité, raisonnements qui seraient lourds à faire avec un langage de programmation quelconque. Il n'est pas question d'écrire des programmes avec dans la vie de tous les jours. Le brainfuck n'est pas pensé pour écrire du code maintenable.
Un tas d'application à succès de taille respectable qui continuent à évoluer et à fonctionner ont été écrites avec du JS, c'est qu'elles doivent être un minimum maintenables (Firefox, Thunderbird, PDF.js, Signal, Wire, Wordpress, un tas de gros sites web, …).
On peut dire la même chose de PHP (malgré ses nombreuses incohérences - Nextcloud, WordPress…), de Java (malgré ses lourdeurs), de C (malgré le nombre de pièges dans lesquels on peut tomber), de C++ (malgré sa complexité)… et bien sûr, il est possible d'écrire du code médiocre dans ces langages.
Si un code n'est pas maintenable dans n'importe lequel de ces langages, c'est que les personnes qui l'ont écrit ont mal fait leur boulot, étaient inexpérimentées dans les langages utilisés, que le processus de développement a eu des loupés ou que le langage choisi n'est pas adapté au cas d'utilisation. Après, il y a des pièges dans tous les langages. Il est nécessaire de connaître profondément la sémantique des outils qu'on utilise et d'apprendre à éviter ces pièges (vous avez déjà utilisé une liste vide comme valeur par défaut d'un paramètre de fonction en Python ?). Si vous utilisez une scie sans avoir appris à l'utiliser, vous allez peut-être couper ce que vous vouliez couper, mais vous risquez aussi de vous couper un doigt. Et si vous savez vous en servir, vous risquez quand même de vous blesser, donc la vigilance reste de la partie.
En C aussi, on peut avoir du code qui compile et qui tourne, mais qui se vautre à l'exécution à cause d'un dépassement (quand on a la chance que ça crash !).
Et puis si quelqu'un ne se sent pas capable d'écrire du code propre en $LANGAGE parce cette personne n'accroche pas avec son fonctionnement, ce n'est pas grave, il y a d'autres langages qui pourront mieux lui convenir.
[^] # Re: TypeScript
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Cette métrique est très pertinente pour juger de la qualité d'un code :
Elle l'est aussi pour juger de la qualité d'un langage. Et on dira ce qu'on voudra, mais JS a quand même un taux de WTF/minute assez hallucinant (cf les exemples que j'ai donné dans l'article).
Alors, oui, y'a des bonnes pratiques dans tous les langages. Mais je ne connais aucun autre langage (destiné à être utilisé, pas la peine de me sortir Brainfuck ou d'autres exotismes) dont les bonnes pratiques consistent à se priver de plus de la moitié des possibilités du langage.
La connaissance libre : https://zestedesavoir.com
[^] # Re: TypeScript
Posté par raphj . Évalué à 3. Dernière modification le 13 novembre 2018 à 11:16.
Ah ah, oui, cette image m'amuse beaucoup.
En C++, tu as aussi intérêt à te limiter à un sous-ensemble assez restreint du langage.
J'aime bien ton article, il est bien documenté et soulève des points valides de manière respectueuse et agréable à lire.
Il se trouve que je ne suis quasiment pas affecté par les points négatifs que tu soulèves : je n'utilise pas (beaucoup) npm ni de bibliothèques externes, ni les webworkers. Je n'ai pour l'instant pas trop adopté la syntaxe des déconstructions pour des raisons de compatibilité des navigateurs mais je vais certainement bientôt m'y mettre, et pour
nulletundefinedje me suis fait un modèle qui fonctionne pour moi (undefined= la fonction ne retourne rien de particulier,nullest explicitement renvoyé quand l'élément n'existe pas mais effectivement ce n'est pas forcément idéal).Pour ton
{ a, b } = o, ça s'explique certainement par le fait que{ a, b }est interprété comme un bloc de code qui contient une instruction pas terminée par un point virgule (ce qui est autorisé en JS, et je ne suis pas fan de ça), et cette instructiona, best composée de deux sous-instructions (qui sont des expressions…) séparées avec l'opérateur virgule. L'analyse syntaxique échoue au niveau du=parce=après un bloc de code n'a pas de sens. Les parenthèses interdisent l'analyseur de considérer les accolades comme un bloc de code. Je sais, c'est dommage. Ce n'est pas incompréhensible, mais je reconnais que c'est pénible.Pour le
===, C'est pénible et c'est la même chose en PHP : j'ai décidé de considérer que==ne devait pas être utilisé.[^] # Re: TypeScript
Posté par raphj . Évalué à 3. Dernière modification le 13 novembre 2018 à 11:45.
Il semblerait que
{a, b} = {a: 1, b: 2}sansletouvaret sans les parenthèses fonctionne avec nodejs mais que ça ne devrait pas d'après https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment#Object_destructuringEt ça ne fonctionne (effectivement) pas dans Firefox.
[^] # Re: TypeScript
Posté par barmic . Évalué à 4.
Ça reste clairement du nihilisme. Toute chose n'est pas égale par ailleurs. C'est comme si tu affirmait que le fait qu'il existe forcément une faille potentiel dans un système d'exploitation rend inintéressant le fait de tenter de faire de la sécurité.
JS est très présent car il a une position où il est un passage obligé. Ça joue énormément dans son adoption et malgré ça on voit apparaître une quantité délirante de solutions pour tenter de s'en passer (coffescript, dart, typescript, elm, asm.js,… les solution à la GWT, JSF, wt, etc). C'est un point qui me parait marquant qu'en a la quantité de développeurs qui ne voient des défauts dans ce langage (suffisamment pour préférer avoir un compilateur qui écrit en js plutôt que de l'écrire soit même).
Il est possible de maintenir du js, mais on a peu de projets qui on une durée de vie aussi grande que ce que l'on trouve ailleurs (l'un des meilleurs exemple doit être jquery qui a 12 ans).
# On t'as démasqué
Posté par G.bleu (site web personnel) . Évalué à 10.
On t'a démasqué Sam&Max !
[^] # Re: On t'as démasqué
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 6.
J'aurais tellement aimé pouvoir ne pas être d'accord avec eux sur ce coup là… cela dit, il me semble que je trouve plus de points positifs qu'eux à JS.
La connaissance libre : https://zestedesavoir.com
# vbuild : webpacker vuejs sans nodejs
Posté par manatlan (site web personnel) . Évalué à 10.
Juste un petit mot pour parler de vbuild qui permet de packager des vues, et de générer du JS … SANS NODEJS (python only)
Et tu peux même développer tes composants en python, ou en js, et ou les 2… et mixer le tout …
J'ai fait un outil de démo, pour comprendre :
https://manatlan.alwaysdata.net/vbuild/
[^] # Re: vbuild : webpacker vuejs sans nodejs
Posté par Christie Poutrelle (site web personnel) . Évalué à 2.
Pardon je t'ai moinssé sans faire exprès, j'ai fourché du clic (cependant ton lien n'a pas un certif ssl valide).
# On n'est pas limité au JS côté front
Posté par Boiethios (site web personnel) . Évalué à 4. Dernière modification le 09 novembre 2018 à 15:03.
Cette phrase donne une bonne idée de l'écosystème JS:
J'ai décidé de ne plus utiliser de JS. J'utilise uniquement des langages qui transpilent en JS: Elm, typescript, etc. On peut même utiliser des langages systèmes avec webasm, comme par exemple Yew en Rust: https://github.com/DenisKolodin/yew.
[^] # Re: On n'est pas limité au JS côté front
Posté par Yth (Mastodon) . Évalué à 7.
Mais comment tu débugges ?
Parce que les erreurs n'apparaissent que dans la console javascript de ton navigateur, et tu vas avoir une erreur ligne 1 de ton fichier javascript, que tu n'as jamais vu, et qui est minifié en une ligne.
Alors la technique, c'est quoi ?
Yth.
[^] # Re: On n'est pas limité au JS côté front
Posté par Joël Thieffry (site web personnel) . Évalué à 6.
Dans les deux cas, la nouvelle vue du code source est utilisable pour le déboggage.
[^] # Re: On n'est pas limité au JS côté front
Posté par Ontologia (site web personnel) . Évalué à 3.
Ça me fait penser qu'une "bonne" solution serait de proposer une extension "langage" au navigateur pour exécuter le source en natif, au moins durant la phase de dev.
On ne corrigerai les erreurs de "transpilation" qu'à la fin
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: On n'est pas limité au JS côté front
Posté par vv222 . Évalué à 3.
La plupart des outils liés a la compilation/transpilation d’assets pour le Web permettent de déclarer des actions différentes selon qu’on soit sur une instance de développement ou de production. On peut donc par exemple réserver la minification au serveur en production.
[^] # Re: On n'est pas limité au JS côté front
Posté par Yth (Mastodon) . Évalué à 2.
Pour la minification, c'était à moitié du troll, j'avoue, parce que oui, il suffit de développer en non minifié et de minifier en prod uniquement.
Reste la transpilation, où tu débugges dans un langage ce que tu as écris dans un autre.
Donc il y a l'option source map pour vraiment faire le lien avec le code d'origine.
Mais tu as quand même bien intérêt à connaître le javascript, et rapidement à savoir aussi comment ton code source se transpile vers le javascript.
J'ai surtout de l'expérience avec jQuery, donc pas de transpilage, pas de surcouche, direct en javascript et tu peux être à peu près sûr que si ça plante c'est de la faute de ton code et non de celui de jQuery. Ben rien que là les messages d'erreur sont parfois complètement inutilisables…
J'ai juste du mal à appréhender l'idée de rajouter des couches entre ton code et le logiciel qui va te dire où et comment ça bugge :)
Cela dit ce n'est pas pire qu'un « segmentation fault - core dumped », faut connaître les outils derrière pour interpréter ce qu'il se passe.
Pour avoir - très brièvement - fait du coffeescript, j'ai abhorré à cause de ça, et aussi du manque d'intérêt général pour la chose quand on sait déjà coder en Javascript simple : quel est l'intérêt d'un langage moins verbeux si en pratique tu dois connaître les deux, débugger dans l'un pour écrire dans l'autre, et en plus gérer les éventuels bugs du transpilage ? Le gain de temps à l'écriture du code vaut-il la perte de temps en apprentissage et débuggage ?
Clairement mon projet d'alors n'était pas en faveur du coffeescript ^ ^
Yth.
[^] # Re: On n'est pas limité au JS côté front
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Le JS écrit et le JS compilé (« transpilé ») sont exactement comme ton langage « natif » préféré et le binaire compilé : tu ne t'occupes que de ce que tu écris, sauf cas exceptionnels tu n'as pas à te soucier ni de ce qui a été compilé, ni comment ça a été fait, parce que ce fonctionnement est garanti par le compilateur.
Du coup, quand tu fais du JS moderne (ou du Typescript, ou du Coffescript pour les irréductibles qui l'utilisent encore), tu n'as besoin de connaitre que le langage source sans jamais t'intéresser ni à la compilation (qui n'ajoute pas plus de bugs qu'une compilation native) ni au produit de la compilation (qui de toutes façons est aussi illisible que n'importe quel résultat de compilation en n'importe quelle technologie : langage machine, bytecode ou autre langage).
La connaissance libre : https://zestedesavoir.com
[^] # Re: On n'est pas limité au JS côté front
Posté par Glandos . Évalué à 7.
Et les fichiers « map » sont au Javascript ce que les symboles de débogage sont aux C, C++ et autres langages compilés en langage machine.
[^] # Re: On n'est pas limité au JS côté front
Posté par Guillaume Denry (site web personnel) . Évalué à 5.
Je suis un peu hors-sujet, mais voici une conf abordant des concepts de garantie de fonctionnement par le biais de la génération de code et qui s'appuie sur Elm.
La vidéo aborde graphql dans une grosse partie (*), mais termine par typescript en montrant comment le développeur peut s'assurer que si son code typescript généré compile, alors il peut avoir de fortes garanties sur le fonctionnement de son programme. Voici le projet en question https://github.com/dillonkearns/elm-typescript-interop.
La CLI proposé par ce projet va analyser les
ports(c'est l'outil pour l'interopabilité entre le monde Elm et le monde JavaScript) déclarés dans le code Elm et généré du code Typescript qui sera utilisé par le monde JavaScript pour transmettre des données au monde Elm (et vice versa).(*) Pour ceux qui s'intéressent à graphql (et Elm mais pas obligé pour trouver la conf intéressante), c'est vraiment un truc à voir ; son système permet de générer dynamiquement tout un toolkit Elm en allant juste interroger les données d'introspection d'un serveur graphql et donc ensuite, le développeur n'a juste qu'à écrire ses requêtes en ayant une très forte garantie de fonctionnement à la compilation. C'est vraiment caviar.
# Et vue.js alors?
Posté par devnewton 🍺 (site web personnel) . Évalué à 6. Dernière modification le 09 novembre 2018 à 16:30.
Le titre parle de vue.js, mais le contenu du nourjal l'évoque à peine. C'est bien? Mieux que React ou Angular?
Pour le foutoir de webpack et autres outils de compilation, je suis totalement d'accord. J'utilise Brunch pas parce qu'il est plus performant ou plus puissant que les autres, mais parce que la configuration est compréhensible /o\
Concernant le pattern flux et Vuex, je n'ai rien compris:
Heu ok, mais dans quel pays les devs sont assez cons pour écrire une appli dont l'état est modifié de façon imprévisible? En mettant des rand() partout pour le fun?
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 9. Dernière modification le 09 novembre 2018 à 16:54.
Pour Vue.js vs React vs Angular, les trois ont l'air de se valoir, mais Vue.js semblait « plus propre », être plus agréable à utiliser, et avoir moins de casseroles d'après les moult tests que j'ai lus. Mais c'est très subjectifs (et j'aime pas le concept de JSX de React).
L'utilité et l'intérêt d'un state management pattern et d'une bibliothèque comme VueX est à peu près incompréhensible tant qu'on a pas joué avec de la programmation réactive (et de fait, je ne l'ai pas compris avant d'avoir testé et compris Vue.js).
En gros : ton framework de programmation réactive (j'ai utilisé Vue.js, mais de ce que j'en sais React et consorts fonctionnent pareil) va te permettre de découper ton application en composants. Chaque composant va par défaut gérer les données d'état et l'affichage d'un bout de l'application. C'est très pratique en terme de découpage, mais d'un point de vue « intégrité des données » ça va avoir deux inconvénients :
Donc, un outil comme VueX (ou Flux, Redux et leurs amis) te permet de corriger tout ça :
Entre autres effets de bord sympathiques, ça permet de tracer en dev toutes les modifications sur l'état de ton application, et donc de voyager dans le temps.
Voilà, j'espère que c'est plus clair comme ça ?
En réalité dans VueX, pour des raisons de langage tu ne peux pas forcer l'interdiction de modification, et les avertissements « attention cet objet a été modifié en douce hors des procédures » n'est actif qu'avec une configuration spécifique. Qui doit donc impérativement être activée en dev (sinon c'est idiot) et désactivée en prod (sinon c'est lent). ↩
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et vue.js alors?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
C'est du MVC à papa quoi :-)
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 7. Dernière modification le 09 novembre 2018 à 17:47.
Pas vraiment, parce que les responsabilités et l'utilisation sont différentes d'un framework MVC.
Notamment parce que le MVC traditionnel c'est :
Avec aucune communication entre Modèle et Vue, et un mapping à gérer plus ou moins manuellement.
Le modèle réactif avec ce type d'organisation c'est :
(Note que là les flèches ne vont que dans un seul sens, alors qu'elles sont à double sens dans le cas du MVC).
Mais je persiste, l'intérêt de la chose et la différence avec le MVC sont incompréhensibles si on ne maitrise pas déjà la programmation réactive.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et vue.js alors?
Posté par rewind (Mastodon) . Évalué à 10.
Ça, ce n'est pas MVC, c'est de l'architecture trois tiers. Dans MVC, il y a des flèches entre la vue et le modèle.
[^] # Re: Et vue.js alors?
Posté par kursus_hc . Évalué à 8.
Les cadriciels (à une époque c'était le terme obligatoire ici, c'est clairement plus ce que c'était) JS réactifs sont de type modèle-vue-vuemodèle.
Pour moi la façon la plus simple d'expliquer la différence est que ce modèle apporte un cadre solide pour construire une application autour des variables globales sans en éprouver la honte que l'on se doit de ressentir habituellement, c'est extrêmement plaisant.
[^] # Re: Et vue.js alors?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 8.
Je suis plutôt architecte et dev backend. J'ai touché un peu à React, j'ai notamment suivi une formation courte, pro. J'ai un collaborateur pur frontend qui développe en react.
Le très gros intérêt que je vois à ce type de programmation «données -> vues -> actions» (le schéma de Psychofox explicite bien le principe), c'est d'une part le workflow à sens unique et d'autre part l'immutabilité (qu'elle soit strictement imposée par le langage ou «de fait» dans la manière de programmer) - en tout cas dans react/flux.
Tu ne met pas à jour l'état de tes composants, tu les remplaces. On est loin du merdier de la programmation orientée objet et des états «WTF mais pourquoi ma propriété a telle valeur?!» dont on ne parvient pas à trouver l'origine.
Le workflow a sens unique c'est une tuerie en terme de predictabilité - on sait exactement qui fait quoi, l'immutabilité aussi, et les deux couplés c'est top.
Ça ne compense pas les inconvénients du langage JS - c'est un sujet transverse, mais les technos (et développeurs) backend ont aussi des trucs à apprendre/reprendre de l'écosystème javascript.
Au final, ce que je trouve merdeux en js, c'est l'absence de typage statique principalement car cela pourrait résoudre une bonne partie de tout le merdier de l'écosystème…
Par exemple, j'aime beaucoup python, mais en fait j'aime vraiment seulement depuis que c'est typable statiquement. Le duck typing et autres joyeusetés de type args, kwargs, c'est rapidement la plaie à comprendre et maintenir - et je ne parle pas de l'utilisation intensive des list comprehension imbriquées et conditionnelles que tout projet propose pour la plus grande joie de ses mainteneurs.
Bref chaque techno a ses casseroles, et si aucune techno n'a remplacé js jusqu'à présent, c'est probablement qu'il y a une bonne raison… D'ailleurs la tendance est même (malheureusement) d'en mettre un peu partout (au hasard : qt, gnome)… /o\
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et vue.js alors?
Posté par Albert_ . Évalué à 5. Dernière modification le 10 novembre 2018 à 17:51.
C'est super bien les listes comprehension! Bon apres tu rajoutes le mot imbriquees et la je comprend mieux le sens de la critique… Il y a de grand malade sur terre et tu peux leur donner la techno la mieux foutu du monde, ils vont arriver a te produire un truc totalement farfelus parceque c'est "fun". Le probleme c'est que cela fait des emuls…
[^] # Re: Et vue.js alors?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Je ne dis pas le contraire…
:) c'est bien ça le problème, surtout quand tu y fourres aussi des actions conditionnelles
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et vue.js alors?
Posté par Aluminium95 . Évalué à 1.
Quand tu dis « actions conditionnelles », tu veux dire qu'il y a des effets de bords durant la création de la liste ?! C'est assez imprudent je trouve…
Mais dans le cas où il n'y en a pas, je trouve que c'est beaucoup plus lisible, parce que le code dit sans équivoque ce qu'il fait : il construit une liste (imbriquée potentiellement) et il ne fait que ça. Au contraire de 5 boucles for imbriquées avec des conditionnelles dedans qui de loin n'ont pas vraiment de rapport avec la variable locale qui va servir à construire la liste. Et puis, pour les gens normaux, il est plus naturel de vouloir ajouter des effets de bords (log, état global etc.) dans des boucles que dans des listes, donc tu as de grandes chances que la construction de la liste s'accompagne d'une tripotée d'actions qui n'ont pas grand chose à voir avec la liste elle-même si tu n'utilises pas de list comprehension.
En plus, ça ressemble vraiment à la définition mathématique de compréhension d'ensembles. Du coup ça rend la spécification / description très agréable à mes yeux.
[^] # Re: Et vue.js alors?
Posté par Albert_ . Évalué à 4. Dernière modification le 13 novembre 2018 à 16:25.
quand il dit conditionel c'est:
impriquer ca c'est … sale on va dire car illisible alors que la liste comprehension c'est fait pour etre lu!
et ca c'est horrible.
[^] # Re: Et vue.js alors?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
C'est bien de ça que je parle :)
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et vue.js alors?
Posté par Aluminium95 . Évalué à 1.
J'ai voulu écrire un petit pavé, mais finalement je vais juste m'assurer que je ne suis pas en train de dire des bêtises avant : quelle serait l'alternative au même code sans compréhension de listes ?
[^] # Re: Et vue.js alors?
Posté par kantien . Évalué à 5. Dernière modification le 14 novembre 2018 à 00:40.
Au lieu d'imbriquer les compréhension de listes, n'en faire qu'une avec pour condition la conjonction des deux autres. ;-)
est équivalent à
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Et vue.js alors?
Posté par Aluminium95 . Évalué à 1. Dernière modification le 14 novembre 2018 à 00:43.
D'accord, j'ai bien fait de poser la question alors !
J'aurais séparé la liste imbriquée dans une variable séparée, mais en fonction du code, cela devient plus ou moins pertinent.
J'avais (mal) compris quelque chose de l'ordre de « sans les compréhensions de liste, ce code serait plus simple »… Ce qui me semblait quand même tiré par les cheveux.
[^] # Re: Et vue.js alors?
Posté par kantien . Évalué à 3.
On simplifie au maximum en réduisant le nombre de parcourt de listes pour construire la liste résultante. Les compréhensions de listes, c'est de la composition de
mapetfilter.c'est l'équivalent python du code haskell :
puis on utilise les lois de bases de
mapetfilter:Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: Et vue.js alors?
Posté par Aluminium95 . Évalué à 1.
Oui, mais le compilateur devrait faire la "stream fusion"/"deforestation" tout seul non ? (Python ne le fait pas, mais Haskell doit faire quelques trucs dans mon souvenir).
Enfin, j'ai l'impression que le problème était la lisibilité plutôt que l'efficacité. Toutefois, après lecture, le code "déforesté" semble plus lisible… Ce qui est bizarre en un sens.
[^] # Re: Et vue.js alors?
Posté par Papey . Évalué à 5.
Tu devrais aimer le langage elm (évoqué dans au moins un commentaire plus haut), inspiré de Haskell et compilant vers un sous-ensemble de javascript. C'est un langage front-end purement fonctionnel avec typage statique et un compilateur aux petits oignons (réputé avoir les meilleurs messages d'erreur).
Pour achever de te convaincre, sache que React s'est inspiré de Elm pour son architecture de flux.
https://elm-lang.org
[^] # Re: Et vue.js alors?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
C'est effectivement très intéressant. En creusant, je suis tombé sur une discussion Reddit je crois qui évoquait les problèmes inhérents à ELM, en particulier la pureté qui est trop forte dans certains cas… et était évoqué le langage créé par Facebook dans la lignée de React : Reasonml.
https://reasonml.github.io/
D'ailleurs il y a ReactReason : https://reasonml.github.io/reason-react/
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et vue.js alors?
Posté par barmic . Évalué à 2.
Si je ne me trompe pas c'est totalement abandonné par Vue.js C'est ce que tu vois ici avec le
state.count++. Je ne me suis pas plus intéressé que ça à ce framework, mais quand j'ai du mal à ne pas me dire qu'il y a quelque chose qu'ils n'ont pas compris dans l'archi qu'ils sont sensé implémenter…[^] # Re: Et vue.js alors?
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 11 novembre 2018 à 01:26.
Pas vraiment : ton état est immutable en dehors des méthodes prévues à cet effet… et c'est précisément l'une de ces méthodes que tu montres.
La connaissance libre : https://zestedesavoir.com
[^] # Re: Et vue.js alors?
Posté par barmic . Évalué à 2.
Alors le partiellement immuable c'est un nouveau concept ;)
Ça signifie que l'état fait de l'encapsulation, pas qu'il est immuable.
[^] # Re: Et vue.js alors?
Posté par Axone . Évalué à 2.
De ce que j'ai compris, en Python, il n'y a pas de typage dynamique. On peut mettre des indications de types dans les déclarations de fonctions, mais c'est purement cosmétique.
[^] # Re: Et vue.js alors?
Posté par flan (site web personnel) . Évalué à 3. Dernière modification le 11 novembre 2018 à 10:25.
C'est purement cosmétique, certes, mais les IDE peuvent (et certains le font) pour te prévenir dès qu'il y a un souci. En pratique, ça fonctionne plutôt bien.
[^] # Re: Et vue.js alors?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Ça permet l'autocompletion, ça documente la signature des méthodes et fonctions, et c'est vérifiable via l'utilisation de l'outil mypy.
C'est pas obligatoire, mais si on veut l'utiliser on peut et ça réduit le nombre de bugs - mypy bous aide à détecter les erreurs de design ou signatures incohérentes entre définition et utilisation.
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
[^] # Re: Et vue.js alors?
Posté par Guillaume Denry (site web personnel) . Évalué à 8. Dernière modification le 09 novembre 2018 à 17:10.
Les trucs à la redux ou vuex proposent surtout un formalisme pour encourager le développeur à épouser les concepts de flot de données unidirectionnel.
En bref, idéalement, tu as UN état centralisé pour ton application, qui va permettre de "rendre" ta vue, et ta vue va ensuite émettre des événements qui vont provoquer la modification de ton état centralisé, qui va provoquer un nouveau rendu de ta vue, etc etc.
Dans ce système, le moindre élément de la vue est affiché en fonction de données de ton état et il est souhaitable de ne pas avoir des "morceaux" d'état stockés ailleurs que dans ton état central (genre l'item courant d'une combobox, l'élément qui a le focus, etc).
C'est souvent difficile d'être pur à ce niveau là, surtout avec des frameworks javascripts, mais il y a des environnements où c'est plus facile et où l'on a pas le choix. Je pense en particulier à mon petit chouchou : Elm.
Le fait également de ne pas avoir le choix que de passer par un système de messages (on peut les appeler aussi "action" dans certains frameworks) pour modifier l'état permet de soulager la charge cognitive qu'on doit se traîner quand on essaye de comprendre un code.
# Pas compris ce qu'étais le pattern flux/Vuex
Posté par Tangi Colin . Évalué à 3.
J'ai du mal comprendre un truc,j'ai cliqué sur le lien qui amène vers https://vuex.vuejs.org/ mais j'ai pas compris ce que ça change par rapport à un modèle MVC classique.
It is a self-contained app with the following parts:
The state, which is the source of truth that drives our app;
The view, which is just a declarative mapping of the state;
The actions, which are the possible ways the state could change in reaction to user inputs from the view.
[^] # Re: Pas compris ce qu'étais le pattern flux/Vuex
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
J'espère que ce commentaire réponds à ta question ?
La connaissance libre : https://zestedesavoir.com
[^] # Re: Pas compris ce qu'étais le pattern flux/Vuex
Posté par flan (site web personnel) . Évalué à 5.
A priori, si j'ai bien compris, dans un MVC, tu affiches une vue qui va récupérer ses données dans le modèle. Quand tu cliques sur un bouton, le contrôleur est appelé pour modifier les données puis la vue.
Par contre, si tu changes tes données par un autre canal, la vue n'a a priori pas de raison d'être prévenue et donc de changer.
Au contraire, avec ce modèle, la vue est un affichage réactif des données. Si elles sont changées (par une une action comme un clic ou toute autre façon), la vue est censée être mise à jour de façon automatique (comme si tu « filmais » en permanence tes données).
[^] # Re: Pas compris ce qu'étais le pattern flux/Vuex
Posté par Guillaume Denry (site web personnel) . Évalué à 4.
Exactement. Et ça ne fonctionne que parce qu'on a derrière des outils de type virtualdom qui optimisent de ouf ce qu'il faut changer dans le (vrai) DOM en fonction de ta vue.
Bref, le virtualdom est certes regénéré à chaque changement de ton modèle de données (et encore, c'est vraiment un raccourci car on peut également optimiser cette partie), mais le "moteur" de rendu (react ou vuejs, ou Elm) est intelligent et va juste toucher ce qu'il faut sur ton DOM.
Donc, il ne faut avoir aucun scrupule quand on se dit "mais, c'est curieux que ma vue soit générée au moindre changement d'état", car ça marche plutôt bien.
# Et oui
Posté par kursus_hc . Évalué à 9.
Bravo pour le niveau de détails de l'analyse, tu n'a clairement pas chômé en huit mois ! Je travaille également à plein temps avec Vue et je suis bien d'accord sur tous les points (les excellents comme les horribles). Au final on peut dire c'est incroyablement fun à faire mais sans doute moins à maintenir, spécialement dans le temps. Personne ne sait à quoi ressemblera Javascript dans deux ans.
Mais tout le monde s'en fiche car bientôt il y aura WebAssembly qui permettra à tout le monde de faire du JS en utilisant son langage préféré, les bien meilleures perfs en plus ! L'éclatement du monopole va sérieusement forcer l'écosystème JS à se rationaliser sous peine de faire rétrograder le langage au rang d'API oubliée.
[^] # Re: Et oui
Posté par Papey . Évalué à 3.
Bof bof, de ce que j'ai compris en webassembly chaque site doit embarquer un runtime pour le langage qu'il utilise (pour gérer la mémoire, faire un ramasse-miettes ou autres) alors que pour js tout est déjà dans le moteur js du navigateur et n'a donc pas besoin d'être téléchargé à nouveau. Au final webassembly ne serait intéressant que pour les applications intensives en CPU/GPU comme du calcul scientifique ou du rendu 3D, mais pas du tout pour du web "classique".
[^] # Re: Et oui
Posté par potate . Évalué à 3.
Il est vrai que chaque langage doit intégrer son runtime. Cela dit, WebAssembly gérera plus de choses dans le futur (https://webassembly.org/docs/future-features/), notamment un ramasse-miettes et les exceptions.
Cela simplifiera le support de WebAssembly comme cible de compilation et devrait faire maigrir les runtimes.
# NodeJS
Posté par gusterhack . Évalué à 6. Dernière modification le 10 novembre 2018 à 16:15.
Moi qui comptait commencer NodeJS sa rassure pas du tout. Du coup je reste sur PHP ? Peut être en utilisant plus le côté objet de PHP.
[^] # Re: NodeJS
Posté par Ludo . Évalué à -1.
Fais du NodeJS, les points négatifs évoqués sur la communauté illustrent que le nombre de personnes est important à utiliser JavaScript.
# Alternatives
Posté par AnthonyRabine (site web personnel) . Évalué à 6.
J'ai commencé à me mettre à Vue.js dans le cadre "embarqué" (genre borne interactive écran tactile et sorte de Raspberry PI), et j'ai choisi pour simplifier les dépendances et le déploiement de ne pas utiliser NPM/Webpack et autres bidules qui font peur. On peut tout à fait s'en passer. On inclut les composants dans le index.html comme toute autre librairie JS.
Ansi, je maîtrise totalement les dépendances. Côté back-end, je fais ça en C/C++, là encore pas de NPM et compagnie, il existe de bons frameworks compatibles C++0x11 permettant d'écrire du code facilement (RegEx, fonctions anonymes etc. sont maintenant en standard, les frameworks ajoutent une dose de design REST et fournissent des utilitaires type JSON), sinon il y a toujours ce bon vieux CivetWeb en C qui est très sympa pour de l'embarqué un peu plus limité.
Au final, pour déployer :
- make pour compiler le serveur
- 2 lignes de systemd pour le mettre en démon
- et yolo on lance Chromium en mode kiosque
J'ai personnellement adoré le développement en Vue.js, c'est assez simple d'accès et bien puissant. Ne pas hésiter à faire "beaucoup" de composant et créer un bus d'événements.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.