[ENFER] Ne devenez JAMAIS DEV WEB ayaaaaaaaaaao sur JvArchive forum 18-25

5 juin 2022 à 12:57:35

Hé ! J'ai ce nouveau projet web à faire, mais pour être totalement honnête, je n'ai pas fait de développement web client depuis quelques années et j'ai entendu que ça avait pas mal bougé ses dernières temps. Tu es as jour sur toutes ces choses là pas vrai ?

Le terme actuel est développement Front-end, mais oui, je suis ton homme. Visualisations temps réel, musique en ligne, drônes qui font du café, demande ! Je reviens justement de JSConf et VueConf, du coup, je suis à la page sur les dernières technologies pour créer des applications webs.

Cool. J'ai besoin de créer une page pour afficher les dernières activités de mes utilisateurs, donc, j'ai juste besoin de récupérer des informations depuis une source REST et de les afficher dans un tableau filtrable que je mettrais à jour à chaque changement côté serveur. Je pensais utiliser quelque chose comme jQuery pour récupérer les données à afficher ?

Oh là, non ! Plus personne utilise jQuery maintenant. On se contente de Vanilla.js si on souhaite faire simplement du JavaScript.

Ha ? C'est quoi ça Vanilla.js ?

C'est juste du JavaScript. C'est un petit nom sympa donné aux nouvelles fonctionnalités de l'API des navigateurs pour manipuler le DOM. Et comme c'est implémenté dans les navigateurs, il n'y a plus besoin d'inclure de bibliothèque maintenant.

Du coup on a abandonné les frameworks JavaScript ? Tout est plus simple !

Non. Pas du tout. Il y en a d'autres des frameworks maintenant.

C'est ce qui me semblait. J'avais entendu parler de React ou Angular au lieu de jQuery ?

Tu devrais utiliser React oui, c'était la superstar de 2016 en concurrence avec Angular ou encore Vue, mon chouchou. React est une bibliothèque MVVM.

React est une bibliothèque MVVM ?

C'est une bibliothèque super cool faites par des gars de chez Facebook. Ça t'apporte un réel contrôle et des grandes performances sur tes applications en te permettant de gérer tes changements de vue vraiment facilement.

Ça a l'air pas mal. Je peux utiliser React pour afficher mes données alors ?

Oui, mais d'abord, tu vas devoir ajouter React et ReactDOM comme bibliothèque dans ta page web.

Attend, pourquoi deux bibliothèques ?

Et bien, il y en a une qui est la bibliothèque en elle-même, et une seconde pour manipuler le DOM, que tu vas maintenant pouvoir décrire en JSX.

JSX ? C'est quoi JSX ?

JSX c'est juste une extension de la syntaxe JavaScript qui est aussi cool que du XML. C'est une autre façon de décrire le DOM. Voit le comme du HTML++.

Qu'est-ce qui ne va pas avec le HTML ?

En 2020, personne ne code plus en HTML directement voyons.

Bien. Pourquoi pas. Si j'ajoute ces deux bibliothèques, ensuite je vais pouvoir utiliser React ?

Non, pas encore. Tu vas avoir besoin de Babel, et ensuite tu pourras utiliser React.

Une autre bibliothèque ? Qu'est-ce que c'est Babel ?

Oh, Babel est un transpileur, tout comme Traceur. Il te permet de choisir une version de JavaScript à produire en sortie sur tes sites alors que tu codes avec une autre version de JavaScript. Tu n'as pas besoin d'inclure Babel obligatoirement pour utiliser React, mais sans lui, tu vas rester bloquer avec une utilisation de JavaScript en ES5, et, soyons réaliste, en 2020, tu dois au moins coder en ES2016+ comme le reste des mecs cools.

ES5 ? ES2016+ ? Je suis un peu perdu. Qu'est-ce que c'est ES5 et ES2016+ ?

ES5 signifie ECMAScript 5. C'est l'édition que la plupart des personnes utilisent car elle est implémentée dans la plupart des navigateurs de nos jours.

ECMAScript ?

Oui, tu sais, le langage de script JavaScript s'est basé dessus en 1999 après sa création initiale en 1995. À l'époque le JavaScript était le LiveScript et tournait uniquement dans le navigateur Netscape. C'était un peu brouillon, mais maintenant heureusement c'est plus clair grâce à ses 7 éditions d'implémentation.

7 éditions. Vraiment ? Et ES5 et ES2016+ en sont donc ?

Tu parles de ES6 ? En fait, chaque édition est une version supérieur de la précédente. Donc si tu utilises ES2016+, tu utilises toutes les fonctionnalités des versions précédentes.

Ok. Et pourquoi plus la ES2016+ que la ES6 exactement ?

Et bien, tu peux utiliser ES6, mais tu ne pourras pas utiliser des fonctionnalités au top comme async ou await. Pour ça, tu as besoin de ES2016+. Sinon, tu vas te limité avec des générateurs ES6 histoire de bloquer les appels asynchrones pour un contrôle de flux plus facile.

Ok. J'ai pas tout compris. C'est un peu déroutant, mais bon. Écoute, je veux juste charger un groupe de données depuis un serveur. Pour ça j'ai juste besoin d'inclure jQuery depuis un CDN et de récupérer mes données avec des appels AJAX, pourquoi ne pas simplement faire ça ?

On est en 2020 mec, plus personne utilise jQuery maintenant, ça fini toujours en un gros tas de code spaghetti immonde. Tout le monde sait ça.

Compris. Donc mon alternative est de charger ces trois bibliothèques pour récupérer mes données et afficher cela dans un tableau HTML.

Oui, mais pour inclure ces trois bibliothèques, tu peux les empaqueter avec un gestionnaire de modules pour ne charger qu'un seul fichier.

Je vois. Et c'est quoi exactement un gestionnaire de modules ?

La définition dépend de ton environnement, mais dans le monde du web, cela signifie habituellement de supporter les modules AMD et CommonJS.

Okkayy... et les modules AMD et modules CommonJS, c'est quoi ?

Pour faire court : il y a plusieurs manières pour définir comment les bibliothèques JavaScript et les classes devraient intéragir. Tu sais, exports et require ? Tu peux écrire différents fichiers JavaScript définissant des API AMD ou CommonJS et tu peux les utiliser avec quelque chose comme Browserify pour les empaqueter ensemble.

Ok. Ça semble logique... je crois. C'est quoi Browserify ?

C'est un outil cool pour te permettre d'empaqueter ensemble des descriptions de dépendance de fichier CommonJS pour les faire tourner dans un navigateur. Ça a été créé car beaucoup de gens publiaient des dépendances dans le registre npm.

Le registre npm ?

C'est un dépôt public vraiment énorme ou les gens malins placent leurs codes dans des modules.

Comme CDN ?

Pas vraiment. C'est plutôt une base de données centralisée ou chacun peut publier son code ou le télécharger. Mais effectivement, tu peux aussi le publier sur CDN ensuite si tu veux.

Plus comme GitHub alors ?

Non, car GitHub c'est plutôt pour la collaboration, la maintenance de code, la relecture de code et le partage de code. Même si on peut s'en servir comme gestionnaire de module avec des équivalents comme jspm ?

Oh, je vois, comme Bower ?

Oui. Mais on est en 2020 maintenant, plus personne utilise Bower.

Ah, d'accord. Donc j'ai besoin de télécharger mes bibliothèques depuis npm donc ?

Oui. Donc pour le moment, si tu veux utiliser React, tu peux télécharger le module React et l'importer dans ton code. Tu peux faire ça avec toutes les bibliothèques JavaScript populaires.

Oh, comme AngularJS !

AngularJS c'est trop 2015, mais oui. Angular a pris la relève, sans le JS, c'est pas la même chose. Tu veux en savoir plus à ce propos ?

Non. C'est déjà assez avec React, j'ai déjà appris trop de chose là. Donc, si je dois utiliser React, je le récupère depuis npm, puis je le raffine avec Browserify, c'est ça ?

Oui.

Bon, ça semble quand même pas mal compliqué de prendre diverses dépendances pour les assembler ensemble.

Ça l'est. C'est pourquoi on utilise des gestionnaires de tâches comme Grunt, gulp ou Broccoli pour automatiser les transformations avec Browserify. Et tu peux même utiliser Mimosa.

Grunt ? gulp ? Broccoli ? Mimosa ? Mais de quoi on parle là ?

Des gestionnaires de tâches. Mais ils ne sont plus vraiment cool maintenant. On les utilisait en 2015, maintenant on se la joue plutôt Makefiles, et on encapsule tout ça avec webpack.

Makefiles ? C'est des trucs utilisés en C ou C++ ça ?

Ouais, mais nous aussi maintenant dans le web on aime faire compliqué et revenir aux bases. On fait ça tous les ans, et attend un peu, mais on devrait faire des assembly dans un an ou deux. Faut bien qu'on comprenne qu'on est des vrais développeurs.

Soupir. Tu mentionnais un truc nommé webpack ?

C'est un autre gestionnaire de module pour les navigateurs qui est en même temps une sorte de gestionnaire de tâches. C'est comme une meilleure version de Browserify.

Oh ! Pourquoi il est meilleur ?

Et bien, peut-être pas meilleur, mais il est plus opiniâtre sur la manière dont les dépendances doivent être attachées. webpack te permet d'utiliser différents gestionnaires de modules et pas seulement des formats CommonJS. Il supporte même des modules au format natifs ES6.

Là je suis complètement paumé avec toutes tes histoires de CommonJS et ES6.

Tout le monde l'est, mais tu ne devrais plus l'être avec SystemJS.

Encore un nom en « js »... bien, et c'est quoi SystemJS.

Ariairtoute

5 juin 2022 à 12:57:52

Et bien contrairement à Browserify et webpack (dans ses débuts), SystemJS utilise des chargeurs de modules dynamiques pour attacher des modules en plusieurs fichiers plutôt que de les empaqueter en un seul gros fichier.

Attend, je croyais qu'on voulait empaqueter tous les fichiers en un seul gros fichier justement !

Oui, mais grâce à HTTP/2, maintenant les requêtes HTTP multiples sont préférables.

Donc, on pourrait pas juste ajouter les 3 bibliothèques originales pour utiliser React ?

Pas vraiment. Je veux dire, tu pourrais inclure ses trois scripts depuis un CDN, mais tu voudrais toujours utiliser Babel ensuite.

Soupir. Et sans Babel pas d'ES6 ?

Oui, et inclure une version CDN de Babel en entier ne serait pas une bonne idée pour la production. En production, tu dois minifier ton propre jeu de fichiers personnels, tu dois minifier tes ressources, rendre plus performant ton JS (et le rendre illisible), mettre du CSS critique directement dans le HTML en amont de tes fichiers, déferrer tes scripts, etc.

C'est bon, c'est bon. Alors si je ne veux pas inclure mes bibliothèques directement depuis des CDN, qu'est ce que je voudrais faire ?

Tu voudrais les transpiler depuis TypeScript en utilisant webpack + SystemJS + Babel.

TypeScript ? Je croyais qu'on codait en JavaScript !

TypeScript est du JavaScript, ou plutôt, une surcouche de JavaScript, plus précisément de JavaScript en version ES6. Tu sais, les six versions dont nous avons parlées tout à l'heure ?

Mais je croyais que ES2016+ était déjà une surcouche de ES6 ! Pourquoi on aurait besoin de faire appel à TypeScript ?

Oh, parce qu'il nous permet d'utiliser le JavaScript comme un langage fortement typé, et réduit les erreurs à l'exécution. En 2020, tu dois ajouter différents types à ton code JavaScript.

Et TypeScript fait ça, évidemment.

Oui, mais contrairement à Flow, TypeScript est une surcouche de JavaScript qui a besoin d'être compilée.

Soupir... et Flow c'est ?

Un vérificateur de types statiques fait par des gars de Facebook. Il l'on codé en OCaml, car c'est un langage de programmation fonctionnelle fantastique !

OCaml ? Programmation fonctionnelle ?

C'est ce que les mecs cools utilisent de nos jours, mecs, tu sais, c'est 2020 ! La programmation fonctionnelle ? Les fonctions d'ordre supérieur ? Curryfication ? Fonctions pures ?

J'ai aucune idée de se dont tu parles.

Personne ne comprend au début. Écoute, tu as juste besoin de savoir que la programmation fonctionnelle est mieux que la programmation orientée objet et c'est ce qui devrait être utilisé maintenant en 2020.

Attends, j'ai appris la POO à l'école, je croyais que c'était bien ?

C'est parce que c'est ce que faisait Java avant d'être récupéré par Oracle. Je veux dire, la POO était bonne avant, et est toujours utile de nos jours, mais tout le monde a réalisé que modifier des états était pas top, donc maintenant tout le monde passe du côté des objets immuables et de la programmation fonctionnelle. Les gars utilisant Haskell en parlent depuis des années sans parler des gars de Elm. Heureusement dans le web d'aujourd'hui on a des bibliothèques comme Ramda qui permettent de la programmation fonctionnelle en JavaScript.

Est-ce que tu chies juste un tas de nom pour faire joli ? C'est quoi ça, Ranma ?

Non. Ramda. Comme Lambda. Tu sais la bibliothèque de David Chambers ?

David qui ?

David Chambers. Un mec cool. Un des contributeurs de Ramda. Tu devrais aussi t'intéresser à...

Attends, je vais t'arrêter là. Tout ça est peut-être cool, mais je pense que tout ç'est trop compliqué et inutile pour simplement faire de la récupération de données et les afficher. Je suis sûr que j'ai pas besoin de connaître ce David pour savoir créer des tableaux avec des données dynamiques. Revenons en à React. Comment je peux récupérer les données depuis le serveur avec React ?

Et bien en fait, tu ne peux pas récupérer les données avec React, tu peux juste afficher les données avec React.

T'es sérieux là ! Tout ça pour ça ? Alors on utilise quoi pour récupérer les données ?

Tu utilises Fetch pour récupérer les données du serveur. C'est le nom de l'implémentation native pour faire du XMLHttpRequests sur un serveur.

Ah, tu veux dire AJAX.

AJAX est juste l'utilisation de XMLHttpRequests. Mais oui. Fetch te permet de faire de l'AJAX en te basant sur des Promesses, que tu peux utiliser pour éviter les cascades de fonctions de rappel.

Cascades de fonctions de rappel ?

Oui. À chaque fois que tu fais une requête asynchrone au serveur, tu dois attendre la réponse, tu utilises donc une fonction dans une fonction, c'est ce qu'on appelle une fonction de rappel. Si tu as plusieurs appel, ça forme une cascade.

Ah, et les Promesses ça empêche ça ?

En effet. En manipulant tes fonctions de rappel dans des Promesses, tu peux lire ton code plus facilement et mieux le comprendre. Tu peux le simuler et le tester, avec des requêtes simultanées en attendant qu'elles soient toutes arrivées avant de continuer.

Et ça peut être fait avec Fetch ?

Oui, mais seulement si tes utilisateurs utilisent des navigateurs compatibles, sinon tu auras besoin d'un polyfill pour Fetch ou d'utiliser Request, bluebird ou axios.

Mais combien de bibliothèques je dois connaître bon sang !?

Ça, c'est l'écosystème JavaScript de npm. Il y a des milliers de bibliothèques qui font toutes la même chose. Les sources des bibliothèques sont à disposition, et nous avons les meilleures !

C'est quoi ça alors Request, bluebird et axios ?

Ce sont toutes des bibliothèques pour faire du XMLHttpRequests avec des Promesses.

Et les méthodes AJAX de jQuery ne peuvent pas retourner des Promesses aussi ?

On n'utilise plus la lettre « j » en 2020. Utilise juste Fetch, et les polyfill quand le navigateur ne l'a pas ou alors Request, bluebird et axios à la place. Ensuite gères tes Promesses avec les fonctions await et async et boom, tu as le contrôle de flux parfait.

C'est la deuxième fois que tu me parles de await mais je sais pas trop ce que c'est.

await permet de bloquer les appels asynchrones, te permettant d'avoir un meilleur contrôle sur « quand » les données vont être récupérées et en améliore la lisibilité du code. C'est génial, tu as juste besoin se t'assurer d'avoir la surcouche stage-3 avec Babel, ou d'utiliser la syntax-async-functions et le plugin transform-async-to-generator.

C'est imbitable.

Non, imbitable c'est le fait de devoir pré-compiler du code TypeScript et le transpiler avec Babel pour pouvoir utiliser des fonctionnalités qui ne sont pas encore supportées par TypeScript.

Je sais pas trop quoi dire à ce stade.

C'est très simple. Tu codes tout en TypeScript. Tous les modules sont récupérés avec Fetch et compilés en ES6. Tu les transpiles avec Babel et la surcouche stage-3, et tu charges ça avec SystemJS. Si tu n'as pas Fetch, utilise un polyfill ou utilise axios, et gère toutes tes Promesses avec await.

On a pas la même définition de « très simple ». Donc avec ce rituel je vais finalement pouvoir récupérer mes données et les afficher avec React pas vrai ?

Et ton application ne devait pas gérer les changements d'états ?

Non ça va aller, on va juste ré-afficher les données à chaque fois.

Bon d'accord. Parce que sinon j'aurais dû t'expliquer ce qu'était Flux, et ses implémentations comme dans Flummox, Alt ou Fluxible. Mais pour être honnête, tu devrais utiliser Redux.

Je crois que je m'en tape un peu de tous ses noms, je veux juste afficher des données.

Oh, si tu veux vraiment juste afficher des données, tu n'as peut être pas besoin de React pour commencer. Tu devrais plutôt utiliser un moteur de template.

Tu te fous de moi ? T'es encore sérieux là ? C'est comme ça que tu donnes des conseils ?

Je vais juste t'expliquer ce que tu pourrais utiliser.

Non arrête. Juste arrête.

Je veux dire, même si tu utilises un moteur de template, tu pourras toujours utiliser TypeScript + SystemJS + Babel si tu veux, donc tout ça n'est pas perdu.

J'ai besoin d'afficher des données sur une page. Pas d'exécuter une Fatality Sub-Zero dans Mortal Kombat. Dit moi juste quel moteur de template utilisé à partir de maintenant.

Il y en a un paquet. Attends, je vais essayer d'être plus attentif à ton parcours et d'être moins réduit qu'un simple React. Y a t-il, donc, un moteur de template avec lequel tu es plus familier ?

Et bien. Ça me parle un peu, ça, les templates, mais je n'arrive pas à me rappeler d'un nom. J'avais juste utilisé ça par curiosité.

Ariairtoute

5 juin 2022 à 12:58:33

jTemplates ? jQote ? pure ?

Ça ne me dit rien. Un autre ?

Transparency ? JsRender ? Markup.js ? Knockout ? Ce dernier permet la liaison de donnée bidirectionnelle.

Non, d'autres ?

Plates ? jQuery Templates plugin ? Handlebars ?

Ah... peut-être quelque chose comme le dernier ?

Mustache ? Underscore.js ? Je pense aussi à lodash-template mais c'est assez 2014 quand même.

Ah... peut-être pas ça finalement.

Jade ? Dust ?

Non.

dotJS ? EJS ?

Non...

Nunjucks ? ECT ?

...Non...

Hum... rien comme une syntaxe à la CoffeeScript alors. Jade ?

Non, tu l'as déjà dit Jade.

Je veux dire Pug. Je veux dire Jade. Je veux dire, Jade c'est maintenant Pug.

Soupir. Non... je me rappel de rien. Lequel tu utilises ?

J'utilise Vue en tant que moteur de template, mais aussi à la place de React en tant que MVVM ! Ça me permet de faire les deux, et c'est bien plus performant. Mais c'est plutôt tendance 2020 ça.

Et il n'y a plus moyen de rien faire sans toutes ces bibliothèques ?

Il y a aussi les chaînes de caractères ES6 permettant le templating maintenant.

Laisse moi deviner, et ça requiert ES6.

Correct.

Et en fonction du navigateur utilisé, j'ai besoin de Babel.

Correct.

Et si je ne veux pas inclure l'entièreté de la bibliothèque, j'ai besoin de les charger par module depuis npm.

Correct.

Et pour cela j'ai besoin de choses comme Browserify, ou webpack, ou d'autres alternatives comme SystemJS. M

Correct.

Et sans webpack, idéalement il faudrait utiliser un gestionnaire de tâches.

Correct.

Mais, si je souhaite utiliser de la programmation fonctionnelle et du typage fort j'ai d'abord besoin de TypeScript ou de choses comme Flow.

Correct.

Et je peux également utiliser, Fetch, les Promesses et le contrôle de flux et tout ce qui est magique.

Correct.

Et pour quelque chose de non réactif, je peux simplement utiliser des moteurs de template comme EJS ou Pug.

Correct.

Tu sais quoi. Je crois que j'en ai fini avec le web client, je crois que j'en peux plus du JavaScript.

D'ici quelques années nous coderons peut-être en Elm ou en WebAssembly.

Je pense que je vais juste repasser côté Back-end, loin du JavaScript...

Ah. Mais le JavaScript est également passé du côté Back-end avec Node.js ! C'est même de la que vient npm. Tu as des tas de modules bas niveaux comme Express ou Socket.io ou des choses plus conséquentes avec des frameworks comme NodeAtlas, Sails.js ou même des applications par dessus Node.js comme Meteor. Et pour reparler de React ou Vue, ils sont aussi utilisables côté serveur grâce à leur DOM virtuel pour faire du SSR. Essaie Nuxt.js à l'occasion.

Du JavaScript côté serveur ?

Oui, et beaucoup de développeurs Front-end qui faisaient également du Back-end ont migré sur cette technologie. C'est ce qu'on appelle maintenant les développeurs Full-stack JavaScript.

Comme toi ?

Oui.

Bon. Alors j'arrête les programmes pour ordinateurs. Je vais aller voir du côté mobile, blague.

Hola ! Tu vas mettre les pieds dans un autre domaine de complexité ! Et si c'est pour échapper au JavaScript, sache qu'avec Cordova, tu peux aussi faire des applications mobiles en JavaScript, multi-support. Tu retrouveras de nouveau React avec React Native ou encore Vue avec Weex !

Et bien, développeur JavaScript, ça doit pas être facile et très marrant tout les jours...

Ça dépend pour qui ! Pour ma part, toute cette complexité je m'en passe au quotidien grâce à Vue et NodeAtlas, et ça pourrait te réconcilier avec JavaScript !

Sérieux ? Résume ?

Oublie TypeScript, c'est pour les développeurs qui n'ont pas compris JavaScript. Pour afficher tes données finalement tu n'as besoin que de NodeAtlas : il te permet de faire ton API REST si tu n'en as pas déjà une, et te permet d'afficher tes données avec zéro configuration, en te fournissant en moteur de template EJS ou Pug. Tu peux en changer à volonté bien sûr.

C'est donc pour les trucs non réactif. Mais comment je remplace jQuery côté client ?

Et bien utilise simplement Vue pour manipuler le DOM, une seule et unique librairie, servable par CDN, plus légère que React, plus performante que React, plus simple que jQuery.

Ok. Et je change ça pour quoi si je veux des sites réactifs ?

Et bien pour les sites réactifs, ou qui ne le sont pas mais qui pourrait le devenir, dans ce cas utilise toujours Vue mais passe à la vitesse supérieur avec tout l'écosystème Vue. Tu peux même faire du SSR en couplant Vue avec NodeAtlas.

Vue aussi simple que jQuery ?

Oui. L'idée c'est d'utiliser tout ça aussi simplement que l'utilisation de jQuery, et si besoin, d'utiliser le reste. Ça ne sert à rien de monter un chantier naval pour faire une barque.

Bien d'accord. Mais pour ces histoires de production ?

NodeAtlas embarque tout ça pour toi, oublie webpack, gulp et compagnie au quotidien. Réserve les pour les très rares cas où ils seraient réellement utiles.

...