Par où commencer le JavaScript en 2018 ?

Hello les agrumes,

Je fais pas mal de JavaScript (côté client) en ce moment, or je ne sais que bricoler avec.

Quelles ressources sérieuses, en français ou en anglais, me conseilleriez-vous pour essayer d’apprendre vraiment ce langage ?

Sachant que je vais devoir faire des trucs compatibles IE11 voire IE10 (la joie d’avoir des grosses institutions comme client…), donc qu’apprendre directement quelque chose comme ES6 ne me servira pas à moins qu’il y ait une couche de compatibilité disponible quelque part.

Merci d’avance !

Hello,

Dans l’attente d’experts, je dirais que si tu démarres une application "from scratch", tu as aujourd’hui beaucoup d’outils (babel principalement, potentiellement utilisé avec webpack) qui te permettront de passer outre ces soucis de compatibilité.

Après, il faudrait que tu nous en dises un peu plus.

Si tu veux faire un front tout neuf, aujourd’hui la mode est à la "Single Page Application". Tout rendu côté client (grosso modo, t’as juste un Apache qui sert un fichier html et quelques bundles JS minifiés), la communication avec le serveur se fait à 100% par API.

Si t’es dans ce cas là, la plus grosse phase de l’apprentissage sera le framework utilisé pour écrire ta SPA (Angular, React, Vue, etc.). Beaucoup plus que le langage en lui-même.

Si tu as des pages rendues côté serveur (car tu reprends du code existant) et que tu veux juste bricoler le DOM à coups de Javascript, là je dirais que des ressources comme codeacademy peuvent aider, sinon les bibles de O’Reilly. Le plus important (selon moi) dans le langage en lui-même (sans parler de son interaction avec le DOM) c’est l’héritage par prototype qui m’a pas mal dérouté de prime abord et son corollaire "tout est fonction, même les objets". Pas très naturel quand on vient de l’OO.

Si t’as le choix, je te conseille la solution 1. D’abord parce que c’est vraiment sain cette isolation front / back. Des fois ça rend le truc un peu lourdingue et on se dit que c’était mieux avant, quand on faisait un bête rendu HTML, mais en termes de support c’est assez satisfaisant d’avoir des APIs qu’on peut tester simplement, et une équipe front qui les exploite comme il faut. Et là, j’ai tendance à favoriser React / Redux et le CQRS qui en découle. Encore une fois, t’as l’impression de prendre un bazooka pour écraser une mouche mais le fait d’avoir une UI qui n’est qu’une fonction (pure, ou presque) des données en mémoire, est ultra-satisfaisant à maintenir.

Si t’as pas le choix et que tu dois bidouiller du front qui existe déjà, franchement j’aurais tendance à introduire un truc comme React (Facebook a fait comme ça j’imagine hein, ils ont pas fait une SPA du jour au lendemain) petit à petit. Avec le serveur qui te crache du JSON dans la page directement (au lieu que tu appelles une API pour récupérer les données). C’est pas le Pérou, mais ça se fait bien.

Dans le langage en lui-même, à part aller lire des ressources qui traitent de comment écrire du code le plus fonctionnel possible en JS (sans système de type décent… c’est pas le Pérou non plus…) je vois pas trop quoi te donner comme conseil.

Si tu positionnes un peu mieux le contexte de ce que tu cherches à apprendre concrètement et sur quel type d’app, ça sera vachement plus simple de t’aiguiller je pense.

En fait, la question n’est absolument pas le framework – ça viendra peut-être, mais pas pour l’instant. À court terme ça va être de la bidouille de front déjà existant, ou de l’ajout de pages d’outils dynamiques pseudo-indépendantes mais pas assez pour pouvoir y coller des trucs comme React juste pour ça.

La question est réellement « comment apprendre JavaScript lui-même », genre proprement et depuis environ zéro. Genre : c’est quoi les bonnes pratiques, comment organiser son code de façon « javascriptique », le modèle d’objet/prototypes/whatever qui va bien, etc.

Tout ce qui vient avant de s’intéresser au framework, quoi

Il me semble que JS allongé, Eloquent JS ou encore ce site sont vraiment pas mal pour revoir js depuis zéro tout en pouvant aller assez loin. Sinon pour aller plus loin après vue.js est fait pour être progressive : tu peux l’incorporer petit à petit dans ton application et ainsi profiter de ce que ça apporte sans avoir à tout reconstruire une SPA depuis la base. Et c’est vraiment facile à apprendre, tu peux l’utiliser sans outil de build compliqué ou sans ES6 contrairement à react ou angular qui ont un coût d’entrée plus élevé.

Le tuto vue.JS de grafikart est pas mal et sinon la documentation est vraiment super agréable à lire.

Tout ce qui vient avant de s’intéresser au framework, quoi

Bah ça vient de moi certainement, mais j’ai jamais trouvé de réponse très satisfaisante à cette question du coup je passe.

D’abord "la façon d’organiser son code" si ça désigne l’organisation code par fichier par exemple, bah… C’est assez dépendant de l’environnement à mon sens. D’un ensemble de <script> qui définissent chacun un module avec namespace, jusqu’à import si t’as la chance d’avoir un bundler à portée de main, en passant par requirejs etc.

Si ça désigne le paradigme à utiliser, là encore c’est affaire de choix. Certains se sont retranchés derrière les class d’ES6 pour faire de la POO, ou même avant ça, Backbone définissait des vues en tant qu’objets. Alors qu’on peut aller loin en termes de FP en JS. C’est pas toujours très agréable ni beau, mais on peut appliquer des concepts basiques (composition, currification, etc.). Est-ce-que pour autant c’est une "bonne pratique", bah honnêtement j’en sais rien.

J’imagine (j’espère) que victor aura pas mal de matière sur le sujet.

Bon courage !

Je ne peux malheureusement pas faire nettement mieux que me joindre au Respect Robustesse de Javier.

Déjà je fais pas du tout de front-end, c’est un domaine qui me semble tellement plus complexe que le back-end…

Ensuite JS est un langage qui m’amuse beaucoup parce qu’il laisse une totale créativité à celui qui le connaît suffisamment bien, on peut le tordre for fun and profit de plus de façons que beaucoup d’autres langages populaires. Le prix c’est que bien le connaître est très difficile parce qu’il est mal conçu, et que sa souplesse est une porte ouverte au n’importe quoi. C’est aussi fun qu’aller tout seul sur une montagne au milieu du Kamchatka : t’y fais ce que tu veux, super, mais y laisser ta peau sans faire gaffe y est beaucoup plus facile qu’ailleurs.

Je crois que c’est raganwald, auteur de bons bouquins et de bons talks sur JavaScript qui disait : l’avantage de js c’est qu’on peut en faire absolument n’importe quoi, le désavantage c’est qu’on le fait.

J’ai pas non plus de bons conseils à donner pour apprendre le langage et ses patterns, je m’y suis intéressé par une voie détournée.

Du coup je te recommande de chercher quelques blog posts sur comment utiliser le debugger des devtools de Firefox et Chrome et de jouer avec les deux. Mets des breakpoints, avance étape par étape, entre vraiment dans le programme et le tooling qui te sera nécessaire. Choisis celui qui te semble le plus pratique et apprends-le bien. Pas besoin de changer de navigateur par défaut, c’est qu’un outil pour debugger.

Lis à propos des sourcemaps, de ce qu’est babel, broswerslist, fais un toy project avec ces 3 pour voir comment ça se goupille et comment utiliser ES2017 sur IE8, ES2018 sur tous les navigateurs utilisés par plus de 2% du traffic et les 3 dernières versions de Safari. Tu verras au passage les différences syntaxiques.

Le livre saint c’est MDN, la boîte à outil c’est lodash. Il y a peu de risque que tu tombes jamais dessus dans les codebases que tu rencontreras.

Ça c’est ce qui me vient en tête et je veux pas m’étaler plus. Si je savais comment apprendre ce langage à des gens j’écrirais un tuto. Pratique, ce long voyage en train, pour divaguer sur ce sujet.

Merci à tous pour vos conseils !

J’ai l’impression qu’il va falloir que je fasse avec JavaScript ce que j’ai fait avec Java : piocher un peu partout et essayer plein de trucs J’avais imaginé qu’avec autant de façons de faire possible et autant d’horreurs dans les comportements standards, les gens s’étaient plus ou moins mis d’accord sur ce qu’il fallait faire ou pas – mais j’ai l’impression que chacun a plutôt inventé sa sauce.

J’avais déjà bookmarké MDN et ajouté lodash au projet, j’en déduit que je ne suis pas totalement sur la mauvaise voie ! (Pour vous donner une idée d’où je pars, j’ai utilisé mon premier prototype custom cet après-midi…)

Ma faute, oublié de mentionner que tout projet commence par installer un linter, qui par analyse statique et un bon jeu de règles t’empêchera de faire ce que tout le monde pense qu’il faut pas faire ou d’utiliser le côté obscure du langage (par exemple with).

Prends par exemple eslint-config-airbnb-base ou un autre truc populaire. Si t’es adepte de gofmt ou rustfmt ou autre, prends les règles eslint de prettier et utilise prettier pour formatter automatiquement.

Il y a des tas de règles eslint et c’est un outil absolument indispensable. Tu peux par exemple super facilement être averti quand tu utilises une feature pas supportée par tel ensemble de versions de tels navigateurs (re-coucou browserslist) avec eslint-plugin-compat, si tu comptes ne pas transpiler. Ou si t’as oublié return devant un callback.

Tu peux carrément empêcher tout side effect si le cœur t’en dit (juste pour le pur fun(ction)) : https://github.com/purely-functional/eslint-plugin-pure/blob/master/README.md

Encore un truc que j’ai oublié de mentionner : intéressé-toi de près au modèle de concurrence de js. Commence par les callbacks, puis les promises, puis async/await, dans cet ordre.

Trop facile de faire du code qui semble bon mais qui dans un cas rare voit son callback appelé 2x. Ou un callback dans un try/catch. Ou un callback qui a des effets de bord. D’ailleurs sans passer par une bonne lecture à ce sujet tu seras embêté quand tu tomberas sur des nextTick et autres setImmediate. Comme pour presque tout modèle de concurrence, du code qui a l’air correct et qui marche dans tes conditions de test n’est pas forcément correct et sera extrêmement pénible à debugger si un seul détail est pas bon. Surtout parce que reproduire ce type de bug est très laborieux et parce que vraiment le code a l’air bon.

J’y repense parce que juste sous ton topic il y a celui-ci : https://zestedesavoir.com/forums/sujet/10314/scope-des-variables-en-javascript/

[edit] Tant que t’y es, SpaceFox, ce serait peut-être intéressant que tu collectes les lectures qui te sont utiles, qu’on puisse ensuite éventuellement préparer un petit truc expliquant comment entrer dans ce monde for the working programmer ?

J’ai eu beaucoup de mal à apprendre le Javascript. Enfin, apprendre non, mais savoir bien l’utiliser, oui. Pour certains, apprendre un langage équivaut à savoir bien l’utiliser et non pas faire quelque chose de fonctionnel.

Je l’ai appris en lisant de beaucoup d’articles, beaucoup étant très cours sur de nombreux sites web. Je suis loin de maîtriser le langage mais je progresse petit à petit. J’ai en particulier eu du mal à trouver des explications simples concernant les promises.

La chose qui m’échappe encore est la raison d’utiliser Angular, React, ou autre. Je finirai par indiquer qu’il y a TypeScript qui est de plus en plus populaire. L’ayant jamais utilisé, je ne peux pas donner mon avis.

https://ponyfoo.com/articles/es6-promises-in-depth (puis https://ponyfoo.com/articles/understanding-javascript-async-await )

(Je réagis pas sur le reste du message pour pas dérailler le sujet.)

Typescript c’est vraiment bien si jamais tu viens du monde Java (ou langage similaire), ça permet d’avoir un typage et une syntaxe assez habituelle.

Angular et autres ça fournit un framework bien fini avec des mises à jour/grandes communautés/beaucoup d’aide sur stackoverflow. Ca te permet de faire des applications single page avec énormément de fonctionnalités sans avoir à réinventer la roue et d’avoir un code lisible et maintenable.

EDIT : Arf, j’ai pas pu m’en empêcher. Désolé

Y’avait un cours pas mal sur OC? Mais entre les var et une syntaxe de POO obsolète, il commence à sacrément vieillir… Avantage, il propose de très nombreux exercices pratiques à difficulté croissante. En gros, tout sauf le chapitre sur la POO est ok, si on remplace les var par des let.

Globalement, essaie de te former à la syntaxe moderne, à la compatibilité finalement assez bonne à l’heure actuelle (pour IE faut des polyfill, mais sinon ES6 est à peu près dans les bacs).

Concernant TypeScript, j’ai honnêtement du mal à voir son intérêt, et pourtant je viens du monde Java. Un transpileur c’était bien quand personne ne gérait de fonctionnalité moderne comme les array functions, les promesses, une syntaxe plus propre de définition de classe (des copies de proto à la main c’pas le fun). Mais à part la syntaxe typée, il n’apporte plus grand chose de fou, du coup je trouve ça assez lourd. Une bonne doc et des noms de variables clairs peuvent largement suffire, avec de la rigueur.

Et pour les frameworks, ben…c’est probablement parce que tu n’as jamais projet d’envergure avec un front moderne Helmasaur. C’est bête, mais niveau:

• UI : librairie toute faite de composants normalisés pour développer plus vite

• UX : les composants permettent une expérience unifiée sans perdre l’utilisateur d’un site à un autre. Quel que soit le support, un switch, un select avec autocomplétion, un stepper, tu veux pas avoir à les coder toi-même (encore moins un select avec autocomplétion, choix multiples et chargement des données asynchrone, le genre de truc qui demande zéro ligne de dev avec une bonne lib).

• UX (encore) : point bonus, entre un site où chaque page entraine un aller-retour serveur et un chargement, et une app web où tout se comporte comme un logiciel, et éventuellement la possibilité de l’avoir en offline (merci les API modernes), ben c’est quand même plus agréable une app qu’un site classique. (+ possibilité de packaging pour avoir une appli de bureau/mobile)