7 min de lecture
Une bibliothèque JavaScript développée par un ingénieur de Midjourney promet d’accélérer radicalement la mise en page du texte dans le navigateur. 6 800 étoiles GitHub en quelques jours, Hacker News en ébullition, des débats sur X pour savoir si CSS est arrivé à son terme. Les démonstrations donnent l’impression de magie. Mais celui qui regarde de plus près découvre une histoire faite de vestiges hérités des navigateurs, de hacks géniaux et de la question éternelle : quand une abstraction devient-elle la solution – et quand devient-elle le problème ?
L’essentiel
- Quoi : Pretext est une bibliothèque JavaScript sous licence MIT qui calcule la mise en page du texte dans le navigateur sans déclencher de reflows DOM – selon son auteur, environ 500 fois plus vite que les approches basées sur le DOM (une comparaison que ce dernier qualifie lui-même de « injuste »)
- Qui : Cheng Lou, ingénieur chez Midjourney et contributeur à React, créateur de react-motion (plus de 21 700 étoiles GitHub)
- Comment : Approche en deux phases – mesure unique via Canvas (~19 ms pour 500 textes), puis calcul purement arithmétique dans le hot path (~0,09 ms)
- Pour qui : Interfaces utilisateur hautes performances telles que les interfaces de messagerie, les outils éditoriaux ou les listes virtuelles – pas pour les sites web standards
- Mise en perspective : Approche techniquement valide, portée par un développeur sérieux, mais l’engouement viral dépasse nettement le niveau actuel de maturité du projet
Pourquoi Internet s’est emballé
Il existe des moments dans le monde du frontend où quelqu’un présente quelque chose qui, en théorie, ne devrait tout simplement pas être possible. Du texte qui s’écoule en temps réel autour de formes arbitraires. Des bulles de discussion qui s’ajustent pixel par pixel à leur contenu. Des mises en page de magazines qui réagissent à 120 images par seconde. Dans le navigateur. Sans bidouilles, sans contournements, sans faire tomber la page à genoux.
Cheng Lou l’a démontré la semaine dernière. « J’ai traversé les profondeurs de l’enfer pour vous apporter, pour les années à venir, l’un des fondements les plus importants de l’ingénierie UI », a-t-il écrit sur X. L’understatement n’est pas son fort. Mais les démonstrations tiennent leurs promesses – du moins à première vue.
Pretext est la bibliothèque en question. Plus de 6 800 étoiles GitHub en quelques jours. Sur Hacker News, le débat s’est ouvert sous le titre « L’avenir de la mise en page du texte n’est pas CSS ». La communauté React a réagi comme à la sortie d’un nouvel album de son groupe préféré.
Cela tient aussi à l’expéditeur. Cheng Lou n’est pas un inconnu dans le monde du frontend. Chez Meta, il a travaillé sur React, ReasonML et Messenger. Son projet parallèle react-motion (plus de 21 700 étoiles GitHub) est l’une des bibliothèques d’animations les plus utilisées dans l’écosystème React. Aujourd’hui, chez Midjourney, il construit l’architecture frontend : pile Bun, React vanilla, aucun framework. Cinq développeurs à plein temps pour des millions d’utilisateurs. Quand une personne de cette trempe affirme que le navigateur est cassé, on l’écoute.
Le problème de trente ans que personne n’avait remarqué
Pour comprendre pourquoi Pretext existe, il faut saisir ce que fait réellement le navigateur lorsqu’il affiche du texte. Version courte : bien trop de choses.
À chaque fois qu’il faut calculer la hauteur d’un bloc de texte ou déterminer où une ligne doit être rompue, le navigateur déclenche un reflow de mise en page. Il mesure les caractères, calcule les espacements, rompt les lignes, vérifie les règles de débordement (overflow), met à jour la disposition de tous les éléments environnants. Il s’agit de l’une des opérations les plus coûteuses dans le navigateur. Sur un site web statique, cela ne pose pas de problème. Sur des interfaces dynamiques – applications de messagerie, éditeurs, mises en page animées, listes virtuelles avec des milliers d’entrées – cela devient un goulot d’étranglement.
Le piège ? La plupart des développeurs ne remarquent jamais ce problème. Leur site fonctionne, après tout. Le texte s’affiche, les lignes sont rompues, tout va bien. Ce n’est que lorsqu’on tente de mettre en page dynamiquement des centaines de blocs de texte simultanément – une application de messagerie, un outil de tableau blanc, un éditeur de mise en page de magazine – qu’on bute contre le mur. Et ce mur est là depuis que Netscape Navigator a rendu sa première mise en page HTML en 1994.
Comment Pretext trompe le navigateur
La solution proposée par Pretext est élégante sur le plan conceptuel et exigeante sur le plan technique.
Phase 1 – prepare() : Le texte est normalisé, découpé en segments, puis mesuré via l’API Canvas du navigateur. Pas via le DOM, mais via le moteur de polices bas-niveau que le navigateur embarque déjà. Les résultats sont stockés dans un cache. Cela prend une fois environ 19 millisecondes pour 500 blocs de texte. On paie une fois, on utilise autant de fois qu’on veut.
Phase 2 – layout() : À partir de ce moment, Pretext ne fait plus que des calculs arithmétiques à partir des largeurs mémorisées. Aucun contact avec le DOM. Où la ligne se rompt-elle ? Quelle sera la hauteur du paragraphe ? Le texte tient-il dans cette boîte ? Toutes ces questions sont résolues par des calculs mathématiques, non par le moteur de mise en page du navigateur. 0,09 milliseconde pour 500 textes.
Cela permet des fonctionnalités impossibles à réaliser avec CSS seul : du texte qui s’écoule dynamiquement autour de formes arbitraires ; des conteneurs qui se rétractent précisément à la largeur minimale nécessaire pour un nombre donné de lignes (shrink-wrap) ; des mises en page de type magazine avec des largeurs de colonnes variables – le tout à 120 images par seconde.
Un détail qui fera tiquer les développeurs frontend : selon Cheng Lou, le moteur a été largement développé à l’aide de Claude Code et de Codex. Ces outils d’IA comparent leurs résultats à la ground truth fournie par le navigateur, itèrent sur les cas limites (edge cases) et optimisent l’algorithme de mise en page. Il s’agit d’un exemple fascinant d’ingénierie assistée par IA, dès lors que la tâche est clairement définie et que le signal de retour est explicite.
Les démos : effet « waouh » avec notes en bas de page
La page officielle de démonstration présente sept exemples : des mises en page accordéon aux bulles de discussion avec un espace vide minimal, en passant par une démo d’éditeur éditorial avec une mise en page multi-colonne animée, des citations en encadré (pull quotes) et un live-reflow. S’y ajoutent des démos communautaires reproduisant des mises en page de magazines et des grilles Masonry.
À première vue, les démos donnent l’impression de quelque chose qui ne devrait pas être possible dans le navigateur. Le texte s’écoule fluidement autour d’obstacles, les conteneurs s’adaptent en temps réel, les mises en page réagissent sans délai perceptible. Et puis viennent les problèmes quotidiens : zones de saisie (textareas) qui s’étirent automatiquement, centrage vertical de texte multiligne, voire même de l’ASCII Art typographique variable en tant que preuve de concept.
Et puis on clique sur la discussion Hacker News. Et les notes en bas de page commencent.
Ce que l’engouement passe sous silence
« ~500x, mais c’est une comparaison injuste. »
Cheng Lou sur son propre benchmark, X, mars 2026
Le fait que le développeur qualifie lui-même son benchmark de « injuste » mérite respect. L’accélération d’environ 500 fois dans le hot path compare un chemin de calcul mis en cache à une mesure initiale complète via getBoundingClientRect(). C’est un peu comme dire « ma voiture est 500 fois plus rapide que la vôtre », mais uniquement si l’on ne compte pas le temps de remplissage du réservoir. La mesure initiale (prepare) coûte 19 millisecondes. Pour la plupart des sites web, la différence est insignifiante, car ils ne déclenchent pas des centaines de reflows par image.
Qualité des démos au lancement : Plusieurs développeurs ont relevé que la page de démonstration elle-même présentait des problèmes de rendu. Le texte était tronqué (overflow: hidden), et selon un commentaire sur Hacker News, la page était « totalement et complètement cassée » sur mobile. Un développeur a commenté sobrement : « La bibliothèque qui veut réparer le web possède un site web défectueux. » La plupart de ces problèmes ont désormais été corrigés.
CSS pouvait déjà le faire : Certains des layouts présentés – texte autour de formes, zones d’exclusion (exclusion zones), régions – étaient prévus comme fonctionnalités CSS. CSS Exclusions et CSS Regions existent en tant que spécifications. Elles n’ont jamais été largement implémentées, car les éditeurs de navigateurs ont fixé d’autres priorités. Pretext ne résout donc pas un problème CSS, mais un problème d’engagement des navigateurs. C’est une distinction importante.
Niveau de maturité : Pretext est un projet open source précoce Open-Source-Projekt. L’auteur documente honnêtement ses limites : l’utilisation de system-ui comme police peut entraîner des mesures imprécises sur macOS. Les conteneurs très étroits provoquent des ruptures de ligne au sein des mots. Le rendu côté serveur (server-side rendering) n’est pas encore finalisé. Celui qui met Pretext en production aujourd’hui est un early adopter, avec toutes les conséquences que cela implique.
Pour qui Pretext est réellement pertinent
La bibliothèque résout un problème réel – mais spécifique. Pretext devient pertinent là où de nombreux blocs de texte doivent être mis en page dynamiquement et simultanément :
- Interfaces de messagerie : Applications de messagerie qui virtualisent des milliers de bulles de messages et doivent en calculer la hauteur à l’avance
- Outils éditoriaux : Éditeurs de mise en page pour magazines, newsletters ou présentations, qui font couler le texte en temps réel autour d’images
- Interfaces basées sur Canvas : Outils de tableau blanc comme Figma ou Miro, qui rendent le texte en dehors du DOM
- Listes virtuelles : Toute application qui affiche des centaines ou des milliers de blocs de texte et doit connaître leurs dimensions avant qu’ils n’apparaissent dans la zone visible (viewport)
Pour les entreprises DACH qui développent leurs propres produits SaaS avec des interfaces fortement axées sur le texte, il vaut la peine de suivre l’évolution de la maturité du projet. Pour un site web d’entreprise, un blog ou une page de destination, Pretext n’apporte aucun avantage mesurable. Et c’est parfaitement acceptable. Toute bibliothèque n’a pas vocation à sauver le monde. Parfois, il suffit de résoudre élégamment un problème difficile pour le bon public cible.
Une mise en perspective : entre génie et engouement
Pretext n’est ni une escroquerie ni une promesse vide. Le cœur technique – éliminer les mesures DOM du hot path de la mise en page et les remplacer par des calculs arithmétiques mis en cache – constitue une approche valide qui fait une réelle différence pour certains cas d’usage. Le fait que Cheng Lou qualifie lui-même son benchmark de « injuste » et documente clairement les limites du projet le distingue agréablement des influenceurs habituels du monde du développement, qui présentent chaque semaine un nouveau framework comme la prochaine révolution.
La vérité, comme souvent, se situe au milieu. Non, « tout site web que vous avez jamais utilisé » n’est pas défectueux. Cette affirmation virale relève du clickbait, probablement choisie délibérément. Mais le problème sous-jacent est réel : la mise en page dans les navigateurs est trop lente pour certains cas d’usage, et CSS a promis des fonctionnalités qui n’ont jamais vu le jour. Pretext comble ce vide – avec élégance, performance et des limites clairement définies.
Ce qui reste : une prouesse technique impressionnante d’un développeur qui sait exactement ce qu’il fait. Une bibliothèque qui, dans un an, sera soit un composant incontournable de la boîte à outils frontend – soit un brillant prototype qui finira poussiéreux dans la liste « Awesome JavaScript ». Les deux destins seraient pleinement mérités.
Questions fréquentes
Qu’est-ce exactement que Pretext ?
Une bibliothèque JavaScript/TypeScript sous licence MIT qui calcule la mise en page du texte dans le navigateur sans aucune opération DOM. Elle mesure le texte une fois via l’API Canvas, puis calcule les ruptures de ligne, les hauteurs et les positions purement par des méthodes mathématiques. Développée par Cheng Lou (Midjourney, ancien employé de Meta).
Pretext est-il vraiment 500 fois plus rapide que CSS ?
Dans le hot path, selon le développeur, environ 500 fois plus rapide : 0,09 ms pour 500 blocs de texte contre des mesures DOM via getBoundingClientRect(). Cheng Lou lui-même qualifie cette comparaison de « injuste », car la mesure initiale unique (~19 ms) n’y est pas incluse. Pour les sites web standards, la différence est sans incidence.
Pretext remplace-t-il CSS ?
Non. Pretext ne remplace pas le moteur de rendu du navigateur. Il utilise le moteur de polices du navigateur comme base, mais contourne le processus de mise en page DOM pour le calcul du texte. CSS reste responsable du style, des couleurs, des espacements et de tous les autres aspects de la mise en page.
Ai-je besoin de Pretext pour mon site web ?
Probablement pas. Pretext est pertinent pour les applications de messagerie, les outils éditoriaux, les interfaces basées sur Canvas et les listes virtuelles. Il n’apporte aucun avantage pour les blogs, les sites d’entreprise ou le commerce électronique. Le développeur le reconnaît lui-même.
Quel est le niveau de maturité du projet ?
Plus de 6 800 étoiles GitHub, mais le projet est toujours en développement actif. Le rendu côté serveur est absent, la page de démonstration présentait des problèmes de rendu au lancement. L’utilisation de system-ui comme police peut conduire à des mesures imprécises sur macOS. Pour un usage en production, il convient de surveiller attentivement l’évolution de la maturité.
Pretext a-t-il été développé à l’aide d’IA ?
Oui. Selon Cheng Lou, le moteur a été largement développé à l’aide de Claude Code et de Codex. Ces outils d’IA comparent leurs résultats à la ground truth fournie par le navigateur et itèrent sur les cas limites. Il s’agit d’un exemple intéressant de développement de bibliothèques assisté par IA, avec un signal de retour clairement défini.
Lectures recommandées par la rédaction
Plus d’articles du réseau MBF Media
Digital Chiefs : Numérisation du Mittelstand 2026 – Le rapport de situation honnête
SecurityToday : Copilot comme risque de sécurité
MyBusinessFuture : L’IA « Made in Germany » – 935 startups
Source de l’image : Pexels / Rashed Paykary (px:31343632)
