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 effervescence, des débats sur X pour savoir si CSS a fait son temps. Les démonstrations semblent magiques. Mais en y regardant de plus près, on découvre une histoire faite de vestiges hérités des navigateurs, de hacks ingénieux 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 rapide que les approches basées sur le DOM (une comparaison qu’il qualifie lui-même d’« 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 haute performance comme les messageries, les outils d’édition ou les listes virtuelles – pas pour les sites web classiques
- Mise en perspective : Approche techniquement solide, portée par un développeur crédible, mais l’engouement viral dépasse largement le niveau de maturité actuel du projet
Pourquoi Internet s’est enflammé
Il arrive des moments dans l’univers du frontend où quelqu’un présente quelque chose qui, en théorie, ne devrait tout simplement pas exister. Du texte qui s’écoule en temps réel autour de formes arbitraires. Des bulles de discussion qui s’ajustent au pixel près à leur contenu. Des mises en page de magazines qui réagissent à 120 images par seconde. Dans le navigateur. Sans bidouilles, sans contournements, sans faire s’effondrer la page.
Cheng Lou a fait cette démonstration 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’autodérision n’est pas son fort. Mais ses 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 à son auteur. 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 pointure pareille affirme que le navigateur est cassé, on tend l’oreille.
Le problème de trente ans que personne n’avait repéré
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 doit calculer la hauteur d’un bloc de texte ou déterminer où une ligne doit être coupée, le navigateur déclenche un reflow de mise en page. Il mesure les caractères, calcule les espacements, coupe 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 coupées, 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 se heurte au mur. Et ce mur est là depuis que Netscape Navigator a rendu sa première mise en page HTML en 1994.
Comment Pretext dupe 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 coupe-t-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 sourciller 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 : l’effet « waouh » avec des notes en bas de page
La page officielle de démonstration présente sept exemples : des mises en page en 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-colonnes 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 avec fluidité autour des obstacles, les conteneurs s’adaptent en temps réel, les mises en page réagissent sans latence perceptible. Puis viennent les défis du quotidien : des zones de saisie (textareas) qui s’étirent automatiquement, le centrage vertical de texte multiligne, voire même de l’ASCII Art typographique variable en guise de preuve de concept.
Et puis on clique sur la discussion Hacker News. Et les notes de bas de page commencent.
Ce que l’engouement ne dit pas
« ~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 d’« injuste » mérite le 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 négligeable, car ils ne déclenchent pas des centaines de reflows par image.
Qualité des démos au lancement : Plusieurs développeurs ont souligné 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 a un site web défectueux. » La plupart de ces problèmes ont depuis é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. Une nuance importante.
Niveau de maturité : Pretext est un projet open source en phase 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 césures au milieu des mots. Le rendu côté serveur (server-side rendering) n’est pas encore finalisé. Celui qui déploie Pretext en production aujourd’hui est un early adopter, avec tout ce que cela implique.
Pour qui Pretext est réellement pertinent
La bibliothèque résout un problème concret – mais bien spécifique. Pretext devient pertinent là où de nombreux blocs de texte doivent être mis en page de manière dynamique et simultanée :
- Interfaces de messagerie : Applications de messagerie virtualisant des milliers de bulles de messages et devant 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 des 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 affichant des centaines ou des milliers de blocs de texte et devant connaître leurs dimensions avant qu’ils n’apparaissent dans la zone visible (viewport)
Pour les entreprises DACH développant leurs propres produits SaaS avec des interfaces fortement axées sur le texte, il est intéressant de suivre l’évolution de la maturité du projet. Pour un site web d’entreprise, un blog ou une landing page, Pretext n’apporte aucun avantage mesurable. Et c’est tout à fait normal. Une bibliothèque n’a pas vocation à révolutionner le monde. Parfois, il suffit de résoudre élégamment un problème complexe pour le bon public cible.
Un regard nuancé : entre génie et effet de mode
Pretext n’est ni une arnaque ni une promesse en l’air. Son cœur technique – éliminer les mesures DOM du hot path de la mise en page pour les remplacer par des calculs arithmétiques mis en cache – constitue une approche valable qui fait une réelle différence pour certains cas d’usage. Le fait que Cheng Lou qualifie lui-même son benchmark d’« injuste » et documente clairement les limites du projet le distingue agréablement des influenceurs habituels du développement, qui présentent chaque semaine un nouveau framework comme la prochaine grande révolution.
La vérité, comme souvent, se situe entre les deux. Non, « tous les sites web que vous avez jamais utilisés » ne sont pas défectueux. Cette affirmation virale relève du clickbait, probablement choisie à dessein. Mais le problème sous-jacent est bien 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 cette lacune – avec élégance, performance et des limites clairement définies.
Ce qui en reste : une prouesse technique impressionnante, signée par un développeur qui sait exactement ce qu’il fait. Une bibliothèque qui, dans un an, sera soit un incontournable de la boîte à outils frontend – soit un brillant prototype voué à prendre la poussière 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)
