|
1234567891011121314151617181920212223 |
- ## JavaScript
-
- > [en] The performance tradeoff isn’t about *where* the bottleneck is. It’s about *who* has to carry the burden. It’s one thing for a developer to push the burden onto a server they control. It’s another thing entirely to expect visitors to carry that load when connectivity and device performance isn’t a constant.
- >
- > Developer productivity is a great metric, but it can’t be isolated from the larger ecosystem. With Ruby, the tradeoff works because nothing is externalized, and it’s barely even a tradeoff these days. But with large front-end JavaScript frameworks, things aren’t just slow. If that JavaScript isn’t able to be loaded for a variety of reasons, sites don’t just become a little slower. ==They break entirely.==
- >
- > <cite>*[Visitors, Developers, or Machines](https://garrettdimon.com/2020/visitors-developers-or-machines/)* ([cache](/david/cache/2020/af5d5f52466dfc2f59718294faa07418/))</cite>
-
- Je ne peux pas parler de technique et de Web sans parler de JavaScript et de ce que l’on fait subir à chaque personne qui visite une page. Les compromis qui sont fait actuellement sont propres à un contexte qui donne une ascendance aux riches développeurs et développeuses qui peuvent se permettre [avec leur matériel récent](https://hankchizljaw.com/wrote/honesty-is-the-best-policy/) ([cache](/david/cache/2020/195a2ecd81fa25a7cf43248b809bf724/)) de faire des pages tout saufs *réact*ives pour le reste du monde. Ma machine [a bientôt cinq ans](/david/stream/2015/07/19/) et se trouve être limite inutilisable pour du développement web, **comment ose-t-on ?**
-
- Je trouve cela terrible, autant en terme de (non)empathie que de consommation de ressources si l’on considère les coûts de manière globale et transverse. Cela a de quoi [m’empêcher de dormir aussi](https://www.matuzo.at/blog/why-543kb-keep-me-up-at-night/) ([cache](/david/cache/2020/fc97310297178a549eab5c5f9e8a334f/)), déporter une grande partie de la complexité et du calcul du côté du navigateur s’avère être contre-productif *dans une majorité des cas*.
-
- > [en] HTTP 262 JAVASCRIPT UNNECESSARILY REQUIRED; the content is available but you’d better have a good CPU and 15 seconds of free time before the first pixel gets painted
- >
- > <cite>Taudry Hepburn [sur Twitter](https://twitter.com/tabatkins/status/1232065732034191360)</cite>
-
- On ne peut pas non plus parler de technologie sans son usage et ce n’est pas tant JavaScript que ce qui est fait avec qui m’importune. En tant que développeur, c’est mon quotidien d’apprendre à m’adapter et je sens bien que je pourrais devenir un peu moins incompétent sur le sujet *mais* c’est en tant qu’usager que je n’en peux plus. Manque de résilience, réduction des performances, tentative de prise de contrôle de mon navigateur et je n’évoque même pas tout ce qui essaye de consigner mes moindres clics.
-
- Heureusement que les navigateurs implémentent un *mode lecteur* qui rend certains sites juste… lisibles. Je ne compte plus le nombre de fois où je suis carrément obligé d’aller supprimer un nœud du <abbr title="Document Object Model">DOM</abbr> à la main (!) pour pouvoir afficher une page web. Fâcheux.
-
- ---
-
- Aujourd’hui, lorsque la [vanille](http://vanilla-js.com/) ne me suffit plus, j’utilise [StimulusJS](https://stimulusjs.org/) que je trouve être la moins mauvaise solution. On garde du <abbr title="HyperText Markup Language">HTML</abbr> propre et interprétable ce qui facilite l’amélioration progressive. C’est relativement léger compte tenu de l’aide que ça m’apporte pour structurer mon code. Et c’est suffisamment limité pour me permettre de prendre conscience de mon erreur lorsque j’essaye de mettre trop de logique dans le navigateur.
|
