Par Mathieu Luz de Zenika
- Pas de code source extérieur
- Utiliser un maximum de nouvelles normes
- Il faut que cela fonctionne sur au moins 2 navigateurs
- Pas de Webpack, pas de Typescript, pas de BabelJS
- Application démo : le jeu 2048
- Organismes de normalisation : IETF ( spécifications HTTP ), ECMA ( spécifications JS ), W3C ( gestions de la globalité des normes du web comme HTML, CSS ), WHATWG ( quand il y a des "incohérences" dans les normes de W3C )
- Utiliser les dernières syntaxes JS
- Pas de BabelJS pour du Vanilla
- Faire attention à la table des compatibilités des features
- Voir le post de Jake Archibald : "ECMAScript modules in browsers" pour voir ce qui fonctionne et ce ne fonctionne pas dans les navigateurs
- Existe mais peu utilisé, à part pour des démos
- Problèmes de performances à cause de chargements synchrones des librairies importées via "import"
- Contré par l'utilisé de HTTP2
- Un seul pipe pour un chargement de fichier, pas besoin d'instancier plus pipes = gain de temps
- Utilisation de "HTTP2 push" pour dire de pousser au client les fichiers à charger avant même qu'il ne les demande
- Utilisation de composants normalisés : les Web Components ( agrégation de 4 normalisations )
- Balise template
- Définition des contenus HTML à afficher plus tard
- Custom elements
- Définition de nouveaux éléments réutilisables, en utilisant le Shadow DOM
- Attention à la compatibilité avec Edge ( réglé avec l'intégration de Chromium ? )
- Définition de nouveaux éléments réutilisables, en utilisant le Shadow DOM
- Le Shadow DOM
- Ne cache pas l'HTML aux autres personnes via les Dev Tools mais vient scoper le CSS au sein du component
- Les HTML imports vont être virés de la normalisation en Avril 2019
- On ne peut plus intégrer des fichiers HTML au sein d'autres fichiers HTML
- Conflit technique entre Chrome ( pour ) et Mozilla ( contre ) car les fichiers JS suffisent
- Balise template
- On a un état de DOM e, on veut arriver à un état e', le virtual DOM n'a besoin que des nouvelles positions dans le DOM des éléments
- C'est un élément incontournable des frameworks récents
- Une chose récente et très complexe à implémenter soit-même
- Mais des articles existent pour en créer un avec du Vanilla ( 2ality, Medium )
- Cons
- API trop verbeuse pour une utilisation sans surcouche ( frameworks, etc ... )
- On en parle depuis longtemps mais le support officiel est encore très récent ( Février / Mars 2019 )
- Pros
- Le DOM devient votre propre framework 🎉
- Évite le store en passant par les WebWorkers et l'utilisation de threads ( bonne compatibilité )
- Écoute les événements pour gérer les états des données
- Web Assembly ( ou Wasm ) est "un format binaire capable de tourner sur une VM de navigateur"
- Wasm est prévu comme étant le résultat d'une compilation
- Une implémentation générale par les navigateurs après des années de batailles
- Il y a une liste de langages gérés par le Web Assembly
- Par choix d'amusement, le speaker a pris Rust pour s'amuser et apprendre un nouveau langage
- Pas d'utilisation du bundle Web Assembly / Rust, mais utilisation de la CLI de Rust pour bundler un Wasm
- La classe Web Assembly permet de récupérer le fichier généré pour le faire
- Pour le wrapping, besoin de taper dans les zones mémoires ( C-like ) pour allouer ou désallouer des données en mémoire
- En terme de performances, cela n'apporte pas de vraies différences entre une version compilée Wasm et Node.js
- Le code du Wasm est compilé, tout comme le code interprété par Node.js par le moteur V8 par exemple
Lien vers les sources : https://github.com/Swiip/vanilla-modern-js