Ce que l'on ressent en apprenant JavaScript en 2016

framework n'a Aucun JavaScript été créé lors de la rédaction de cet article. Ce qui suit est inspiré de l'article « It's the future » de Circle CI. Vous pouvez lire l'original ici . Cet article n'est qu'une opinion et, comme tout framework JavaScript, il ne doit pas être pris trop au sérieux. Hé, j'ai ce nouveau projet Web, mais pour être honnête, je n'ai pas beaucoup codé sur le Web depuis quelques années et j'ai entendu dire que le paysage avait un peu changé. Vous êtes le développeur Web le plus à jour ici, n'est-ce pas ? -Le terme exact est ingénieur Front End, mais oui, je suis la bonne personne. Je fais du web en 2016. Visualisations, lecteurs de musique, drones volants qui jouent au football, tout ce que vous voulez. Je reviens tout juste de JsConf et ReactConf, donc je connais les dernières technologies pour créer des applications web. Cool. Je dois créer une page qui affiche la dernière activité des utilisateurs, donc je dois juste récupérer les données du point de terminaison REST et les afficher dans une sorte de tableau filtrable, et les mettre à jour si quelque chose change sur le serveur. Je pensais peut-être utiliser jQuery pour récupérer et afficher les données ? - Oh mon Dieu non, plus personne n'utilise jQuery. Tu devrais essayer d'apprendre React, on est en 2016. Oh, d'accord. Qu'est-ce que React ? -C'est une bibliothèque super cool créée par des gars de Facebook, elle apporte vraiment du contrôle et des performances à votre application, en vous permettant de gérer très facilement tous les changements de vue. Cela semble intéressant. Puis-je utiliser React pour afficher les données du serveur ? -Oui, mais vous devez d’abord ajouter React et React DOM en tant que bibliothèque sur votre page Web. Attendez, pourquoi deux bibliothèques ? -Donc, l'une est la bibliothèque proprement dite et la seconde sert à manipuler le DOM, que vous pouvez maintenant décrire en JSX. JSX ? Qu'est-ce que JSX ? -JSX n'est qu'une extension de syntaxe JavaScript qui ressemble beaucoup à XML. C'est une autre façon de décrire le DOM, considérez-le comme un meilleur HTML. Quel est le problème avec HTML ? -Nous sommes en 2016. Personne ne code plus directement en HTML. D'accord. Quoi qu'il en soit, si j'ajoute ces deux bibliothèques, je peux alors utiliser React ? -Pas tout à fait. Vous devez ajouter Babel, et vous pourrez ensuite utiliser React. Une autre bibliothèque ? Qu'est-ce que Babel ? -Oh, Babel est un transpilateur qui vous permet de cibler des versions spécifiques de JavaScript, pendant que vous codez dans n'importe quelle version de JavaScript. Vous n'êtes PAS OBLIGÉ d'inclure Babel pour utiliser ReactJS, mais à moins de le faire, vous êtes obligé d'utiliser ES5, et soyons réalistes, nous sommes en 2016, vous devriez coder en ES2016+ comme le font les autres jeunes cools. ES5 ? ES2016+ ? Je me perds ici. Qu'est-ce que ES5 et ES2016+ ? -ES5 signifie ECMAScript 5. C'est l'édition la plus ciblée car elle est implémentée par la plupart des navigateurs de nos jours. ECMAScript? -Oui, vous savez, la norme de script JavaScript a été fondée en 1999 après sa sortie initiale en 1995, à l'époque où JavaScript s'appelait Livescript et ne fonctionnait que dans Netscape Navigator. C'était très compliqué à l'époque, mais heureusement, maintenant les choses sont très claires et nous avons environ 7 éditions de cette implémentation. 7 éditions. Pour de vrai. Et ES5 et ES2016+ le sont ? -La cinquième et la septième édition respectivement. Attends, que s'est-il passé avec le sixième ? - Tu veux dire ES6 ? Oui, je veux dire, chaque édition est un sur-ensemble de la précédente, donc si tu utilises ES2016+, tu utilises toutes les fonctionnalités des versions précédentes. D'accord. Et pourquoi utiliser ES2016+ plutôt qu'ES6 alors ? -Eh bien, vous POUVEZ utiliser ES6, mais pour utiliser des fonctionnalités intéressantes comme async et wait, vous devez utiliser ES2016+. Sinon, vous êtes coincé avec des générateurs ES6 avec des coroutines pour bloquer les appels asynchrones pour un flux de contrôle approprié. Je n'ai aucune idée de ce que tu viens de dire, et tous ces noms sont déroutants. Écoute, je charge simplement un tas de données à partir d'un serveur, j'avais l'habitude de pouvoir simplement inclure jQuery à partir d'un CDN et d'obtenir les données avec des appels AJAX, pourquoi ne puis-je pas simplement faire ça ? -Nous sommes en 2016, plus personne n'utilise jQuery, ça finit en un tas de code spaghetti. Tout le monde le sait. D'accord. Mon alternative est donc de charger trois bibliothèques pour récupérer des données et afficher un tableau HTML. -Eh bien, vous incluez ces trois bibliothèques mais vous les regroupez avec un gestionnaire de modules pour ne charger qu'un seul fichier. Je vois. Et qu'est-ce qu'un gestionnaire de modules ? -La définition dépend de l'environnement, mais sur le Web, nous entendons généralement tout ce qui prend en charge les modules AMD ou CommonJS. D'accord. Et AMD et CommonJS sont… ? - Définitions. Il existe plusieurs façons de décrire la manière dont plusieurs bibliothèques et classes JavaScript doivent interagir. Vous connaissez les exportations et les exigences ? Vous pouvez écrire plusieurs fichiers JavaScript définissant l'API AMD ou CommonJS et vous pouvez utiliser quelque chose comme Browserify pour les regrouper. OK, ça a du sens… je pense. Qu’est-ce que Browserify ? -C'est un outil qui vous permet de regrouper les dépendances décrites par CommonJS dans des fichiers pouvant être exécutés dans le navigateur. Il a été créé parce que la plupart des gens publient ces dépendances dans le registre npm. registre npm ? -C'est un très grand référentiel public où les gens intelligents mettent du code et des dépendances sous forme de modules. Vous aimez un CDN ? -Pas vraiment. Il s'agit plutôt d'une base de données centralisée dans laquelle n'importe qui peut publier et télécharger des bibliothèques, afin que vous puissiez les utiliser localement pour le développement, puis les télécharger sur un CDN si vous le souhaitez. Oh, comme Bower ! -Oui, mais nous sommes en 2016, personne n'utilise plus Bower. Oh, je vois… donc je dois télécharger les bibliothèques depuis npm alors ? -Oui. Par exemple, si vous souhaitez utiliser React, téléchargez le module React et importez-le dans votre code. Vous pouvez le faire pour presque toutes les bibliothèques JavaScript populaires. Oh, comme Angular ! -Angular, c'est tellement 2015. Mais oui. Angular serait là, aux côtés de VueJS ou RxJS et d'autres bibliothèques sympas de 2016. Vous voulez en savoir plus sur celles-ci ? Restons avec React, j'apprends déjà trop de choses maintenant. Donc, si j'ai besoin d'utiliser React, je le récupère à partir de ce npm, puis j'utilise ce truc Browserify ? -Oui. Cela semble trop compliqué de simplement récupérer un ensemble de dépendances et de les lier ensemble. -C'est vrai, c'est pourquoi vous utilisez un gestionnaire de tâches comme Grunt ou Gulp ou Broccoli pour automatiser l'exécution de Browserify. Vous pouvez même utiliser Mimosa. Grognement ? Gloussement ? Brocoli ? Mimosa ? De quoi parlons-nous maintenant ? - Les gestionnaires de tâches. Mais ils ne sont plus très cool. Nous les utilisions en 2015, puis nous utilisions Makefiles, mais maintenant nous encapsulons tout avec Webpack. Makefiles ? Je pensais que c'était surtout utilisé sur les projets C ou C++. -Oui, mais apparemment, sur le Web, nous aimons compliquer les choses et revenir ensuite aux bases. Nous le faisons environ tous les ans, attendez un peu, nous allons faire de l'assemblage sur le Web dans un an ou deux. Soupir. Vous avez mentionné quelque chose appelé Webpack ? -C'est un autre gestionnaire de modules pour le navigateur tout en étant également une sorte d'exécuteur de tâches. C'est comme une meilleure version de Browserify. Oh, ok. Pourquoi est-ce mieux ? -Eh bien, peut-être pas mieux, c'est juste plus subjectif sur la façon dont vos dépendances doivent être liées. Webpack vous permet d'utiliser différents gestionnaires de modules, et pas seulement ceux de CommonJS, comme par exemple les modules natifs pris en charge par ES6. Je suis extrêmement confus par tout ce truc CommonJS/ES6. -Tout le monde l'est, mais vous ne devriez plus vous en soucier avec SystemJS. Jésus Christ, un autre nom-js. Ok, et qu'est-ce que c'est que ce SystemJS ? -Eh bien, contrairement à Browserify et Webpack 1.x, SystemJS est un chargeur de modules dynamique qui vous permet de lier plusieurs modules dans plusieurs fichiers au lieu de les regrouper dans un seul gros fichier. Attendez, mais je pensais que nous voulions créer nos bibliothèques dans un seul gros fichier et le charger ! -Oui, mais comme HTTP/2 arrive maintenant, plusieurs requêtes HTTP sont en fait meilleures. Attendez, ne pouvons-nous pas simplement ajouter les trois bibliothèques originales pour React ? -Pas vraiment. Je veux dire, vous pourriez les ajouter en tant que scripts externes à partir d'un CDN, mais vous auriez toujours besoin d'inclure Babel. Soupir. Et c'est mauvais, non ? - Oui, vous incluriez l'intégralité du noyau Babel, et cela ne serait pas efficace pour la production. En production, vous devez effectuer une série de tâches préalables pour préparer votre projet, qui font que le rituel d'invocation de Satan ressemble à une recette d'œufs à la coque. Vous devez minimiser les ressources, les enlaidir, insérer du CSS au-dessus du pli, différer les scripts, ainsi que- Je l'ai compris, je l'ai compris. Donc si vous n'incluez pas les bibliothèques directement dans un CDN, comment le feriez-vous ? -Je le transpilerais à partir de Typescript en utilisant un combo Webpack + SystemJS + Babel. Typescript ? Je pensais que nous codions en JavaScript ! -Typescript EST JavaScript, ou plutôt, un sur-ensemble de JavaScript, plus précisément JavaScript sur la version ES6. Vous savez, cette sixième version dont nous avons parlé auparavant ? Je pensais que ES2016+ était déjà un sur-ensemble d'ES6 ! POURQUOI avons-nous besoin maintenant de cette chose appelée Typescript ? - Oh, parce que cela nous permet d'utiliser JavaScript comme un langage typé et de réduire les erreurs d'exécution. Nous sommes en 2016, vous devriez donc ajouter des types à votre code JavaScript. Et Typescript le fait évidemment. -Flow également, bien qu'il ne vérifie que la saisie alors que Typescript est un sur-ensemble de JavaScript qui doit être compilé. Soupir… et Flow l’est ? fonctionnelle - C'est un vérificateur de type statique créé par des gars de Facebook. Ils l'ont codé en OCaml, parce que la programmation est géniale. OCaml ? Programmation fonctionnelle ? - C'est ce que les jeunes cool utilisent de nos jours, tu sais, en 2016 ? Programmation fonctionnelle ? Fonctions d'ordre supérieur ? Currying ? Fonctions pures ? Je n'ai aucune idée de ce que tu viens de dire. -Personne ne le fait au début. Écoutez, vous devez juste savoir que la programmation fonctionnelle est meilleure que la programmation orientée objet et que c'est ce que nous devrions utiliser en 2016. Attends, j'ai appris la POO à l'université, je pensais que c'était bien ? - C'était Java avant qu'Oracle ne le rachète. Je veux dire, la programmation orientée objet était bonne à l'époque, et elle a toujours son utilité aujourd'hui, mais maintenant tout le monde se rend compte que modifier les états équivaut à botter des bébés, alors maintenant tout le monde se tourne vers les objets immuables et la programmation fonctionnelle. Les gars de Haskell l'appelaient depuis des années, - et ne me lancez pas sur les gars d'Elm - mais heureusement, sur le Web, nous avons maintenant des bibliothèques comme Ramda qui nous permettent d'utiliser la programmation fonctionnelle en JavaScript simple. Tu donnes juste des noms pour le plaisir ? Mais c'est quoi Ramnda ? -Non. Ramda. Comme Lambda. Vous savez, la bibliothèque de David Chambers ? David qui ? -David Chambers. Un type sympa. Il joue très bien à Coup. L'un des contributeurs de Ramda. Vous devriez également consulter Erik Meijer si vous envisagez sérieusement d'apprendre la programmation fonctionnelle. Et Erik Meijer est… ? - Un programmeur fonctionnel également. Un type génial. Il a un tas de présentations où il démolit Agile tout en portant cette chemise de couleur bizarre. Vous devriez également consulter certains des articles de Tj, Jash Kenas, Sindre Sorhus, Paul Irish, Addy Osmani- Ok. Je vais vous arrêter là. Tout cela est bien beau, mais je pense que tout cela est tellement compliqué et inutile pour simplement récupérer des données et les afficher. Je suis presque sûr que je n'ai pas besoin de connaître ces personnes ou d'apprendre toutes ces choses pour créer une table avec des données dynamiques. Revenons à React. Comment puis-je récupérer les données du serveur avec React ? -Eh bien, en fait, vous ne récupérez pas les données avec React, vous affichez simplement les données avec React. Oh, bon sang. Alors, qu'est-ce que tu utilises pour récupérer les données ? -Vous utilisez Fetch pour récupérer les données du serveur. Je suis désolé ? Vous utilisez Fetch pour récupérer les données ? Celui qui nomme ces choses a besoin d'un thésaurus. -Je sais, n'est-ce pas ? Fetch, c'est le nom de l'implémentation native pour exécuter des requêtes XMLHttpRequests sur un serveur. Oh, donc AJAX. -AJAX consiste simplement à utiliser des XMLHttpRequests. Mais bien sûr. Fetch vous permet d'utiliser AJAX en vous basant sur des promesses, que vous pouvez ensuite résoudre pour éviter l'enfer des rappels. L'enfer du rappel ? -Ouais. Chaque fois que vous effectuez une requête asynchrone sur le serveur, vous devez attendre sa réponse, ce qui vous oblige ensuite à ajouter une fonction dans une fonction, ce qu'on appelle la pyramide de rappel de l'enfer. Oh, ok. Et cette histoire de promesse résout le problème ? -En effet. En manipulant vos rappels via des promesses, vous pouvez écrire du code plus facile à comprendre, les simuler et les tester, ainsi qu'effectuer des requêtes simultanées à la fois et attendre qu'elles soient toutes chargées. Et cela peut être fait avec Fetch ? -Oui, mais seulement si votre utilisateur utilise un navigateur evergreen, sinon vous devez inclure un polyfill Fetch ou utiliser Request, Bluebird ou Axios. Combien de bibliothèques dois-je connaître, bon sang ? Combien y en a-t-il ? - C'est du JavaScript. Il doit y avoir des milliers de bibliothèques qui font toutes la même chose. Nous connaissons les bibliothèques, en fait, nous avons les meilleures bibliothèques. Nos bibliothèques sont énormes, et parfois nous y incluons des photos de Guy Fieri. Vous venez de dire Guy Fieri ? Finissons-en. Que font ces bibliothèques Bluebird, Request, Axios ? -Ce sont des bibliothèques permettant d'effectuer des XMLHttpRequests qui renvoient des promesses. La méthode AJAX de jQuery n’a-t-elle pas également commencé à renvoyer des promesses ? -Nous n'utilisons plus le mot « J » en 2016. Utilisez simplement Fetch et remplissez-le avec un polyfill lorsqu'il n'est pas dans un navigateur ou utilisez Bluebird, Request ou Axios à la place. Gérez ensuite la promesse avec wait dans une fonction asynchrone et hop, vous avez un flux de contrôle approprié. C'est la troisième fois que vous mentionnez wait mais je n'ai aucune idée de ce que c'est. -Await vous permet de bloquer un appel asynchrone, ce qui vous permet de mieux contrôler le moment où les données sont récupérées et d'augmenter globalement la lisibilité du code. C'est génial, il vous suffit de vous assurer d'ajouter le préréglage stage-3 dans Babel, ou d'utiliser les fonctions syntax-async-functions et le plugin transform-async-to-generator. C'est fou. -Non, c'est insensé de devoir précompiler le code Typescript puis de le transpiler avec Babel pour pouvoir utiliser wait. Quoi ? Ce n'est pas inclus dans Typescript ? -C'est le cas dans la prochaine version, mais à partir de la version 1.7, il ne cible que ES6, donc si vous souhaitez utiliser wait dans le navigateur, vous devez d'abord compiler votre code Typescript ciblant ES6, puis Babel cette merde pour cibler ES5. À ce stade, je ne sais pas quoi dire. -Écoutez, c'est facile. Codez tout en Typescript. Tous les modules qui utilisent Fetch les compilent pour cibler ES6, les transpilent avec Babel sur un préréglage de niveau 3 et les chargent avec SystemJS. Si vous n'avez pas Fetch, remplissez-le avec du polyfill ou utilisez Bluebird, Request ou Axios, et gérez toutes vos promesses avec wait. Nous avons des définitions très différentes de ce qui est facile. Donc, grâce à ce rituel, j'ai finalement récupéré les données et maintenant je peux les afficher avec React, n'est-ce pas ? -Votre application va-t-elle gérer les changements d’état ? Euh, je ne pense pas. J'ai juste besoin d'afficher les données. -Oh, merci mon Dieu. Sinon, j'aurais dû t'expliquer Flux et des implémentations comme Flummox, Alt, Fluxible. Même si pour être honnête, tu devrais utiliser Redux. Je vais simplement survoler ces noms. Encore une fois, j'ai juste besoin d'afficher des données. -Oh, si vous affichez simplement les données, vous n'aviez pas besoin de React au départ. Vous auriez été satisfait avec un moteur de création de modèles. Tu te moques de moi ? Tu trouves ça drôle ? C'est comme ça que tu traites tes proches ? -J'expliquais juste ce que tu pouvais utiliser. Arrête. Arrête tout simplement. -Je veux dire, même s'il s'agit simplement d'utiliser un moteur de création de modèles, j'utiliserais toujours un combo Typescript + SystemJS + Babel si j'étais vous. J'ai besoin d'afficher des données sur une page, pas d'exécuter la fatalité MK originale de Sub Zero. Dites-moi simplement quel moteur de création de modèles utiliser et je m'en chargerai à partir de là. -Il y en a beaucoup, lequel connaissez-vous ? Ugh, je ne me souviens plus du nom. C'était il y a longtemps. -jTemplates ? jQote ? PURE ? Euh, ça ne me dit rien. Encore une ? -Transparence ? JSRender ? MarkupJS ? KnockoutJS ? Celui-là avait une liaison bidirectionnelle. Un autre ? -PlatesJS ? jQuery-tmpl ? Guidon ? Certaines personnes l'utilisent encore. Peut-être. Y en a-t-il des similaires à la dernière ? - Moustache, trait de soulignement ? Je pense que maintenant même Lodash en a un pour être honnête, mais ça date un peu de 2014. Euh... peut-être qu'il était plus récent. -Jade ? DustJS ? Non. -DotJS ? EJS ? Non. - Des Nunjucks ? ECT ? Non. -Mah, personne n'aime la syntaxe Coffeescript de toute façon. Jade ? Non, tu as déjà dit Jade. -Je voulais dire Pug. Je voulais dire Jade. Je veux dire, Jade est maintenant Pug. Soupir. Non. Je ne m'en souviens plus. Lequel utiliserais-tu ? -Probablement juste des chaînes de modèles natives ES6. Laissez-moi deviner. Et cela nécessite ES6. -Correct. Ce qui, selon le navigateur que j'utilise, nécessite Babel. -Correct. Si je veux l'inclure sans ajouter toute la bibliothèque de base, je dois le charger en tant que module à partir de npm. -Correct. Ce qui nécessite Browserify, ou Wepback, ou très probablement cette autre chose appelée SystemJS. -Correct. Ce qui, à moins qu'il ne s'agisse de Webpack, devrait idéalement être géré par un exécuteur de tâches. -Correct. Mais, comme je dois utiliser la programmation fonctionnelle et les langages typés, je dois d'abord précompiler Typescript ou ajouter ce truc Flow. -Correct. Et ensuite, envoyez-le à Babel si je veux utiliser wait. -Correct. Je peux donc utiliser Fetch, les promesses, contrôler le flux et toute cette magie. -N'oubliez pas de polyfiller Fetch s'il n'est pas pris en charge, Safari ne peut toujours pas le gérer. Vous savez quoi ? Je crois que nous en avons terminé ici. En fait, je crois que j'en ai terminé. J'en ai fini avec le Web, j'en ai fini avec JavaScript. -C'est bien, dans quelques années, nous coderons tous en Elm ou WebAssembly. Je vais simplement revenir au backend. Je ne peux tout simplement pas gérer tous ces changements, versions, éditions, compilateurs et transpileurs. La communauté JavaScript est folle si elle pense que quelqu'un peut suivre ce rythme. -Je t'entends. Tu devrais alors essayer la communauté Python. Pourquoi? -Avez-vous déjà entendu parler de Python 3 ? Mise à jour : merci d'avoir signalé les fautes de frappe et les erreurs, je mettrai à jour l'article comme indiqué. Discussion sur HackerNews et Reddit .