JavaScript

🔧 Engine & VM JavaScript (V8 etc)

Lorsque vous serez plus à l’aise avec JavaScript il vous sera nécessaire d’étudier un minimum le fonctionnement des moteurs modernes comme V8, JS Core, SpiderMonkey etc (ce sont eux qui ont la responsabilité d’interpréter et exécuter votre code JavaScript que ce soit dans Node.js ou même dans le navigateur).

Ce n’est clairement pas un investissement à la portée d’un débutant mais plutôt d’un développeur de niveau intermédiaire ou expérimenté 📚. Pour pouvoir mieux comprendre comment votre code sera géré et optimisé il vous sera donc nécessaire d’apprendre les rouages de la machine 😈.

Parmis les articles que je vous recommande très fortement de lire:

• EN [Débutant] How JavaScript works: an overview of the engine, the runtime, and the call stack
• EN [Débutant] https://mathiasbynens.be/notes/shapes-ics
• EN [Débutant] https://mathiasbynens.be/notes/prototypes
• EN [Intermédiaire] Whats up with monomorphism

Il existe néanmoins des dizaines d’articles tous aussi passionnants que j’ai pris la peine de rassembler ici 👀: https://github.com/fraxken/VM-Resources

Quelques talks en plus pour votre plus grand bonheur:

• FR Comprendre le fonctionnement d’un moteur Javascript (Adrien MARET)
• EN JavaScript engines - how do they even?
• EN The Past, Present and Future of JavaScript Engines
• EN JavaScript Engines: The Good Parts
• EN A sneak peek into super optimized code in JS frameworks
• EN Embedding V8 in the real world by Stanimira Vlaeva
• EN Parsing JavaScript - better lazy than eager?
• EN Essentials of Interpretation

😡 La dangereuse mode des benchmarks

Je pense qu’il est important d’aborder le sujet des benchmarks pendant que nous sommes dans la section engine JS. Les développeurs adorent les utiliser comme argument pour justifier divers choix ou idéologies 😰…

Le problème c’est que la plupart du temps ces benchmarks sont complètement ratés et/ou ne sont pas représentatifs d’un workload de production 😂. Même s’ils sont concrets il va vous falloir de l’expérience pour en déduire des conclusions (et encore rien ne dit que le souci vous concerne par ailleurs).

Voici quelques articles pour vous éveiller au sujet:

• EN Dangers of cross language benchmark games
• EN The trap of the performance sweet spot
• EN Performance tuning as the art of weather forecast
• EN The Black Cat of Microbenchmarks
• EN JavaScript MicroBenchmarks (from Benedikt Meurer)
• EN Preparing and Evaluating Benchmarks (from Rafael)

Même si cela peut paraître difficile à entendre, je pense qu’une personne n’ayant pas de solide connaissance sur le fonctionnement des moteurs JavaScript n’a pas de légitimité à formuler des conclusions à partir des résultats d’un benchmark 💥.

“The hardest thing of all is to find which operation is more expensive inside the darkness of VM, especially when no operation is performed.” (Vyacheslav Egorov)

Et même les personnes ayant beaucoup d’expérience (dont notamment les contributeurs des moteurs eux-mêmes) ont toujours le doute et préfèrent prendre des pincettes pour chacune de leurs conclusions 😯. C’est vous dire la difficulté de la tâche… savoir si vous allez faire for-in, for-of ou .forEach n’a pas vraiment grand intérêt ici.

“ 👉 L’optimisation prématurée est la racine de tous les maux (ou, du moins, la plupart d’entre eux) en programmation.” (Donald Knuth)

---

⬅️ JavaScript: 🌌 Cours en ligne, talks et articles | ➡️ ⚡ ECMAscript