Il s’agit plus pour l’instant d’un exercice de communication qu’autre chose, mais l’entreprise sait justement communiquer avec efficacité. Ses billets techniques sont souvent appréciés et il y a une carte à jouer : si le public veut du technique, Cloudflare va lui en donner.
Le plus intéressant dans l’annonce n’est pas tant le résultat que le processus qui a mené à sa création. La société s’est posé de nombreuses questions, par exemple en envisageant d’abord Docusaurus : un site statique doit-il utiliser du JavaScript ? Une SPA (Single Page Application) est-elle la meilleure solution ? Y a-t-il besoin d’un framework CSS générique ?
Comme décrit par Cloudflare, ces questions ont mené à d’autres, notamment sur l’utilisation de scripts côté client : pourquoi ne pas se débarrasser de JavaScript ? Il n’y avait pas besoin de contenu dynamique et le déploiement pouvait se faire via Cloudflare Pages. L’entreprise souhaitait que les développeurs puissent cliquer sur la page et voir un code source lisible.
research.cloudflare.com est un travail en cours, dont la mission est surtout de concentrer l’ensemble des articles techniques que Cloudflare consacre à ses avancées. Après avoir cliqué sur Latest Research Updates, on y trouvera des articles sur Web3 et la vision d’un web décentralisé, la disparition progressive des CAPTCHA, la possibilité pour l’informatique quantique de casser TLS, ou encore l’arrivée d’ECH en remplacement d’ESNI.
Commentaires (2)
#1
La question de “se débarrassé” de javascript coté clients est une très bonne question (vu le nombre de problèmes que ce moteur a généré sur la sécurité).
Bien que a court terme se soit “peu probable” qu’il disparaisse.
#1.1
De ce que j’en lis, il n’est pas question de se débarrasser de JavaScript sur le client. Il est question de minimiser - dans le cadre strict d’un site statique - le nombre de scripts afin que les fichiers sources restent lisibles par un humain. Et en effet, sur un site statique, la nécessité de JS est faible (éventuellement pour du reflowing des colonnes de texte et un moteur de recherche, mais pas beaucoup plus)
De mon temps on utilisait des frames…
Quant à la sécurité, c’est rarement le moteur JS lui-même qui est fautif… L’envoi de cookies à tort et à travers, oui, mais pas le JS.