Web Browser Engineering (2021)

 (browser.engineering)
2 points par GN⁺ 2024-10-16 | 1 commentaires | Partager sur WhatsApp
  • Web Browser Engineering est un livre qui couvre tout, du réseau à JavaScript, en construisant soi-même un navigateur web basique mais complet en quelques milliers de lignes de Python
  • Le parcours d’apprentissage va du chargement des pages à l’affichage des documents, à l’exécution d’applications puis aux fonctionnalités des navigateurs modernes, en reliant dans l’ordre HTTP, HTML, CSS, DOM, sécurité et pipeline de rendu
  • La première partie se concentre sur l’implémentation des bases d’un navigateur, comme les URL et les requêtes HTTP, la création de fenêtres et le dessin sur canvas, les retours à la ligne et l’interligne du texte
  • Les parties intermédiaires et avancées couvrent la construction de l’arbre HTML, la mise en page, l’application des styles, l’envoi de formulaires, la réaction aux événements, les cookies et la connexion, ainsi que XSS et CSRF
  • La dernière partie aborde la composition, la boucle d’événements, les animations GPU, l’arbre d’accessibilité, les iframe, l’invalidation et la précision de l’édition, offrant un large aperçu des éléments d’implémentation des navigateurs modernes

Apprendre la structure d’un navigateur en l’implémentant soi-même

  • Web Browser Engineering est conçu autour de l’implémentation directe d’un navigateur basique mais complet afin de comprendre comment fonctionnent les navigateurs web
  • Le langage d’implémentation est Python, pour un volume total de quelques milliers de lignes de code
  • Le périmètre va du réseau à JavaScript
  • Le livre papier est disponible chez Bookshop, B&N et Amazon
  • Des éditions traduites existent en coréen chez Hanbit et en japonais chez O’Reilly
  • Les mises à jour peuvent être suivies sur le blog, Mastodon et Twitter, et il existe aussi un forum de discussion GitHub

Déroulé de la table des matières

À lire aussi

1 commentaires

 
GN⁺ 2024-10-16
Commentaires sur Hacker News

  • Un bon point de ce livre, c’est qu’il traite à part des « choses qu’il n’a pas faites »
    Le layout est vraiment difficile, et même gérer uniquement des tableaux sans CSS est déjà compliqué. Dès qu’on ajoute CSS, le layout devient presque d’une complexité impossible à maîtriser
    Je me demande s’il existe quelqu’un capable de garder en tête l’intégralité de la spécification CSS et tous les comportements associés. Le trio CSS+HTML+JavaScript s’est rapproché d’un langage de description de pages (PDL) dynamique, et c’est probablement devenu l’un des logiciels les plus complexes d’aujourd’hui
    À noter aussi que le décodage vidéo est déchargé sur le matériel, donc cela consomme moins de batterie qu’avant

    • Pour implémenter un layout CSS de niveau production, il faut une quantité énorme de code, et le code source de Servo le montre bien
      Par exemple, ce fichier n’implémente que les contextes bloc/en ligne ; il y a bien un peu de boilerplate Rust, mais l’essentiel est une vraie logique qui couvre différentes parties de la spécification. Et il y a tout un dossier rempli de fichiers de ce genre : https://github.com/servo/servo/blob/main/components/layout/f...
      Cela dit, implémenter un moteur de layout reste possible. CSS n’est pas de la magie : il existe une spécification qu’on peut traduire en code avec soin. Montrer ce genre de code à ceux que l’aspect arbitraire de CSS frustre peut aider à comprendre qu’il y a aussi une logique dans l’environnement d’exécution
      Bien sûr, ce n’est pas le genre de bibliothèque dans lequel on va cliquer souvent par curiosité, mais de ce point de vue ce n’est pas si différent de React
    • Oui, le layout est difficile, surtout pour deux grandes raisons, je pense
      D’abord, la partie la plus centrale du layout, comme CSS 2, a été conçue de façon assez bancale, avec des fonctionnalités étranges qui interagissent bizarrement entre elles. Des choses comme les float, le clearance et la fusion des marges. Une partie de ce noyau était censée être réutilisable dans tous les modes de layout, mais elle s’adapte mal aux autres modes. Par exemple, l’objectif des margin et padding n’est pas très clair pour les éléments grid
      Ensuite, ce n’est pas bien modularisé comme les API JavaScript. Les API JavaScript sont souvent implémentées indépendamment, alors que les modules de layout peuvent s’imbriquer de multiples façons et donc tous s’influencer mutuellement. Les spécifications plus récentes comme grid essaient d’être plus strictes, mais il reste une difficulté fondamentale : plusieurs modes de layout doivent se partager la même ressource commune, à savoir un écran 2D réel
    • Le layout est tellement difficile que j’ai abandonné mon projet passion en Common Lisp et ncurses, et je suis devenu cette chose que j’avais juré d’éliminer : un développeur React
      Je ne peux pas être le seul à vouloir un langage de layout plus simple que CSS, mais qui maximise quand même le produit simplicité × expressivité en intégrant les leçons des vingt dernières années. Je me demande s’il existe des projets qui conçoivent sérieusement quelque chose comme ça, ou si tout le monde a simplement accepté CSS3, attend un backend LLVM, ou est juste revenu au texte brut
    • Dans React Native, les ingénieurs de Facebook ont en gros abandonné en disant : « tout ce qu’on vous donne, c’est le layout flexbox », et les gens l’ont plutôt bien accepté. Bien sûr, certains râlent sur l’absence de display grid
      https://github.com/facebook/yoga
    • Cette tour de Babel finira par s’effondrer un jour
      Le layout n’a pas besoin d’être aussi complexe. Il existe des dizaines de frameworks GUI avec des systèmes de layout plus simples, et cela suffit aux applications que les gens utilisent

  • Ça a l’air génial. J’ai commencé à créer un navigateur headless il y a environ 15 ans et je l’ai maintenu pendant quelques années
    J’utilisais SpiderMonkey comme interpréteur JavaScript et j’ai implémenté le DOM moi-même. À l’époque, il exécutait tout le JavaScript moderne, AJAX, etc. ; plus tard, j’y ai même ajouté un runtime Flash personnalisé. C’était un projet qui faisait presque tout, sauf le rendu à l’écran, donc c’était vraiment amusant
    J’ai très envie de lire ce livre

    • Je me demande quelle bibliothèque tu comptais utiliser pour le rendu à l’écran

  • Je suis content de voir que l’ingénierie des navigateurs devient enfin tendance.
    En réalité, l’écosystème est dans un état assez pauvre, défini pour l’essentiel par Google, Apple et Mozilla uniquement. J’aimerais voir un futur avec davantage de moteurs de navigateur indépendants.

    • Je ne pense pas que réécrire un moteur de rendu pour HTML soit un projet réaliste. On ne le terminera jamais. HTML est désormais, de fait, une spécification entièrement possédée par Google et Apple, et c’est bien trop complexe à implémenter à partir de zéro.
      Le domaine intéressant, ce sont les technologies d’interface/document post-HTML. Le Typst mentionné dans un autre fil ressemble à un meilleur LaTeX, et Markdown a aussi eu un gros impact. Il y a largement de quoi créer un « HTML, mais en mieux ». Cela n’a même pas besoin d’être un format de balisage. Typst et React HTML brouillent la frontière entre code et données, et Jetpack Compose montre, via les capacités DSL de Kotlin, comment créer quelque chose qui ressemble à une description d’UI alors qu’il s’agit en réalité de code.
      Bien sûr, cela suppose de distribuer un « navigateur » pour ce format, ou de trouver un moyen de l’afficher dans les navigateurs existants. Cela dit, compiler vers JavaScript/HTML/WASM reste possible. On peut aussi utiliser une boîte à outils GUI portable comme JavaFX, avec en prime l’accessibilité. On peut aussi faire les deux.
      Définir son propre langage d’UI permet d’essayer beaucoup de choses que HTML gère mal. L’exemple typique, c’est la séparation entre contenu et style. HTML a essayé sans jamais vraiment y parvenir, et XSL:T a tenté l’exercice plus sérieusement, mais c’était un étrange langage purement fonctionnel utilisant une syntaxe XML. React s’en sort plutôt bien pour transformer du JSON en boîtes, mais le protocole sous-jacent a toujours un côté bricolé, ce qui rend difficile la création d’outils vraiment utiles par-dessus.
      Une autre idée serait un format immunisé contre les XSS par conception.
    • J’aimerais bien un navigateur qui consomme moins de mémoire. À part ça, je ne pense pas que le faible nombre de moteurs soit en soi un gros problème, si l’on met de côté les spyware que sont Google Chrome avec un grand G et Mozilla Firefox avec un grand M. Ce sont des millions d’heures de travail accumulées sans duplication.
      En revanche, je veux une alternative à HTML. Si je créais un navigateur, je pense que je me concentrerais sur le remplacement de HTML, parce que je ne le supporte pas, et j’aimerais aussi remplacer JavaScript, dont le runtime est trop lourd.
      Par exemple, un navigateur qui n’exécuterait que du WASM, avec presque pas de runtime JavaScript, serait assez drôle.
    • Il faudrait peut-être carrément une nouvelle plateforme ou un nouveau protocole. L’actuel est arrivé à saturation totale en matière de complexité.
    • Je me demande si vous avez déjà regardé des moteurs de navigateur alternatifs comme Servo, Ladybird, Goanna, NetSurf, Sciter ou Flow.

  • Je suis l’un des auteurs de ce livre. Merci pour les mots gentils, et je peux répondre aux questions s’il y en a.

    • Merci d’avoir écrit un si bon livre. En tant que développeur web, ou plutôt ingénieur web comme le dit le livre, j’ai toujours voulu mieux comprendre les fondations techniques dont je dépends.
      Je suis curieux de savoir comment vous avez choisi Python comme langage d’implémentation du navigateur. J’ai l’impression que JavaScript via Node aurait offert une expérience de programmation plus directement pertinente.

  • Un billet où l’auteur explique pourquoi il a choisi Python : https://browserbook.substack.com/p/why-python
    Apparemment, une partie de Python est maintenant compilée en JavaScript et s’exécute dans le navigateur, c’est-à-dire « dans le livre lui-même ».
    https://browserbook.substack.com/p/compiling-python-to-js

    • Le fait que ce soit écrit en Python me donne justement envie de lire ce livre. Si ça avait été en Rust ou en Go, je l’aurais sans doute passé, et en C++, ce serait trop pénible à lire pour un projet suivi pour le plaisir.
      J’espère pouvoir revenir après lecture et dire des choses plus intéressantes.

  • Je trouve vraiment enthousiasmant de voir ce genre de ressource exister.
    Les navigateurs donnent l’impression d’être des boîtes noires mystérieuses et indéchiffrables, et Google a probablement intérêt à ce qu’ils soient perçus ainsi. Mais quand on voit les efforts et les résultats de projets comme Ladybird, on sent que cette muraille se fissure.
    J’aimerais m’y plonger moi-même un jour et contribuer à briser ce fossé défensif, et ce livre a l’air d’être un excellent point de départ.

    • Ce fossé ne vient pas d’un manque de moteurs autres que Chrome, mais du fait qu’il y a trop peu d’utilisateurs de moteurs non-Chrome.
      Firefox existe déjà. C’est simplement que presque personne ne l’utilise, et quand les gens tombent sur un site qui ne marche pas sous Firefox, ils ont appris à ouvrir Chrome.
      Ce serait sans doute amusant de contribuer à des moteurs comme Ladybird en espérant briser ce fossé, mais je ne suis pas sûr que cela aide réellement à le faire. J’aimerais savoir ce qui serait vraiment utile.
    • L’un des auteurs du livre, Chris, dirige l’équipe de rendu Blink chez Google.
    • Je suis l’un des deux auteurs du livre, et l’autre est responsable de Blink Rendering. J’ai aussi parlé plusieurs fois avec des gens de l’équipe Chrome, et ils ne m’ont jamais donné l’impression de vouloir garder les navigateurs mystérieux.
      Au contraire, les personnes qui travaillent sur Chrome, Firefox, Safari ou Ladybird semblent toutes extrêmement enthousiastes à l’idée de parler des navigateurs et de leur fonctionnement. Le monde du développement navigateur est plus petit qu’on ne l’imagine, et comme les ingénieurs passent souvent d’une entreprise à l’autre, il serait difficile de maintenir durablement une quelconque « conspiration ».
      En revanche, il est vrai qu’il manque de ressources pédagogiques. C’est pour cela que nous avons écrit ce livre, et il manque aussi un vocabulaire commun pour discuter des étapes clés à l’intérieur d’un navigateur, en particulier la mise en page et la rastérisation. Chris et moi voulions poser cette base avec ce livre.

  • Je cherchais un projet sympa pour me lancer, et je suis déjà en train de beaucoup apprécier ce livre. L’écriture est particulièrement captivante, ce qui est très appréciable.
    Cette BD expliquant le fonctionnement de Chrome constitue aussi une bonne ressource pour débuter : https://www.google.com/googlebooks/chrome/med_00.html

  • Je suis en train d’apprendre l’architecture interne des navigateurs, et ce livre est excellent.
    Il aide à se construire une intuition de la manière dont fonctionne un navigateur, sans avoir à plonger dans les millions de lignes de code de Chrome.

  • Je me demande s’il existe un code promotionnel pour HN
    J’ai utilisé HTMLUnit [1] avec Jython [2] de manière satisfaisante par le passé, et je m’intéresse beaucoup à un avenir où une partie du code des navigateurs pourra être générée automatiquement grâce à des techniques de génération et de vérification de code. Je respecte des outils comme Playwright/Cypress/Selenium, mais je ne les ai jamais trouvés aussi confortables à utiliser que HTMLUnit
    [1] https://htmlunit.sourceforge.io/
    [2] https://www.jython.org/

    • Le livre n’est pas encore publié, donc il n’y a pas de code promotionnel, mais l’ensemble est disponible gratuitement en ligne

  • Bonne remarque. Je recommande de scinder le chapitre 9 en deux chapitres
    La partie sur l’exécution de JavaScript avec Duktape pourrait constituer un chapitre à part entière, et l’interaction avec le DOM et les événements pourrait faire l’objet d’un chapitre séparé plus tard

    • Il serait peut-être préférable de le lire en deux fois
      Les chapitres deviennent plus longs à mesure qu’on avance et traitent de sujets plus avancés, et je recommande de suivre aussi le code au fur et à mesure de la lecture