7 min de lecture

Une bibliothèque JavaScript d’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 pleine effervescence, et sur X, on débat pour savoir si CSS touche à sa fin. Les démos semblent magiques. Mais à y regarder de plus près, on découvre une histoire d’héritages encombrants des navigateurs, de hacks géniaux et de l’éternelle question : quand une abstraction est-elle la solution – et quand devient-elle le problème ?

L’essentiel en bref

• Quoi : Pretext est une bibliothèque JavaScript sous licence MIT qui calcule la mise en page du texte dans le navigateur sans reflows du DOM – selon son développeur, environ 500 fois plus vite qu’une mise en page basée 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)
• Comment : Une approche en deux phases – une mesure unique via Canvas (environ 19 ms pour 500 textes), puis de la pure arithmétique dans le chemin critique (environ 0,09 ms)
• Pour qui : Les interfaces très performantes comme les chats, les outils éditoriaux, les listes virtualisées – pas pour les sites web standard
• À retenir : Une approche techniquement valide portée par un développeur sérieux, mais le buzz viral dépasse nettement le niveau de maturité actuel

Pourquoi Internet s’est emballé

Il y a des moments, dans le monde du frontend, où quelqu’un montre quelque chose qui ne devrait normalement pas être possible. Du texte qui s’écoule en temps réel autour de formes quelconques. Des bulles de chat qui s’adaptent à leur contenu au pixel près. Des mises en page de magazine qui réagissent à 120 fps. Dans le navigateur. Sans hacks, sans contournements, sans que la page ne s’effondre sous la charge.

Cheng Lou en a fait la démonstration la semaine dernière. „J’ai traversé les profondeurs de l’enfer pour vous apporter l’un des fondements les plus importants de l’ingénierie UI pour les années à venir“, a-t-il écrit sur X. L’euphémisme n’est pas son point fort. Mais les démos tiennent la promesse de l’annonce – du moins au premier regard.

Pretext est la bibliothèque dont il est question. Plus de 6 800 étoiles GitHub en quelques jours. Sur Hacker News, le débat a eu lieu 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é.

C’est aussi lié à son auteur. Cheng Lou est loin d’être 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’animation les plus utilisées de l’écosystème React. Aujourd’hui, il contribue chez Midjourney à l’architecture frontend : stack Bun, React vanilla, pas de framework. Cinq développeurs à temps plein pour des millions d’utilisateurs. Quand cet homme dit que le navigateur est cassé, on l’écoute.

Le problème vieux de 30 ans que personne n’avait remarqué

Pour comprendre pourquoi Pretext existe, il faut comprendre ce que fait réellement le navigateur lorsqu’il affiche du texte. La version courte : beaucoup trop de choses.

Chaque fois qu’il faut calculer la hauteur d’un bloc de texte ou l’endroit où une ligne doit passer à la suivante, le navigateur déclenche un reflow de mise en page. Il mesure les lettres, calcule les espacements, coupe les lignes, vérifie les règles d’overflow, actualise la mise en page de tous les éléments autour. C’est l’une des opérations les plus coûteuses dans le navigateur. Sur un site statique, cela ne pèse pas lourd. Dans des interfaces dynamiques – applications de chat, éditeurs, mises en page animées, listes virtualisées avec des milliers d’entrées – cela devient le goulot d’étranglement.

Le plus insidieux : la plupart des développeurs ne remarquent jamais le problème. Leurs sites fonctionnent, après tout. Le texte s’affiche, les lignes se coupent, tout va bien. Ce n’est que lorsqu’on essaie de mettre en page dynamiquement des centaines de blocs de texte en même temps – une application de chat, un outil de tableau blanc, un éditeur de mise en page pour magazine – que l’on se heurte au mur. Et ce mur est là depuis que Netscape Navigator a rendu la première mise en page HTML en 1994.

Comment Pretext déjoue le navigateur

La solution de Pretext est conceptuellement élégante et techniquement complexe.

Phase 1 – prepare(): Le texte est normalisé, découpé en segments et mesuré via l’API Canvas du navigateur. Non pas via le DOM, mais via le moteur de polices bas niveau que le navigateur embarque de toute façon. Les résultats sont placés en cache. Cela prend une seule fois environ 19 millisecondes pour 500 blocs de texte. On paie une fois, on réutilise autant de fois qu’on veut.

Phase 2 – layout(): À partir de là, Pretext ne travaille plus qu’avec les valeurs de largeur mises en cache. De la pure arithmétique, aucun contact avec le DOM. Où la ligne se coupe-t-elle ? Quelle hauteur prendra le paragraphe ? Le texte tient-il dans cette boîte ? Tout est résolu par les mathématiques, pas par la mise en page du navigateur. 0,09 milliseconde pour 500 textes.

Cela rend possibles des choses tout simplement impossibles avec CSS : du texte qui épouse dynamiquement des formes arbitraires. Des conteneurs qui se resserrent exactement à la largeur la plus étroite pour un nombre donné de lignes (shrink-wrap). Des mises en page façon magazine avec des largeurs de colonnes variables – le tout à 120 images par seconde.

Un détail qui devrait faire dresser l’oreille aux développeurs frontend : selon Cheng Lou, le moteur a été développé en grande partie avec l’aide de Claude Code et de Codex. Les outils d’IA comparent leurs résultats à la ground truth du navigateur, itèrent sur les cas limites et optimisent l’algorithme de mise en page. C’est un exemple fascinant de ce à quoi ressemble l’ingénierie assistée par IA lorsque la tâche est clairement définie et que le signal de feedback est sans ambiguïté.

Les démos : effet waouh avec notes de bas de page

La page de démonstration officielle présente sept showcases : des mises en page en accordéon aux bulles de chat avec un espace vide minimal, jusqu’à une démo de moteur éditorial avec mise en page multi-colonnes animée, pull quotes et reflow en direct. S’y ajoutent des démos de la communauté qui recréent des mises en page de magazine et des grilles masonry.

À première vue, les démos donnent l’impression de montrer quelque chose qui ne devrait pas être possible dans un navigateur. Le texte s’écoule avec fluidité autour des obstacles, les conteneurs s’ajustent en temps réel, les mises en page réagissent sans latence visible. Sans oublier les problèmes du quotidien : zones de texte qui s’agrandissent automatiquement, centrage de texte sur plusieurs lignes, voire ASCII art en police variable comme preuve de concept.

Et puis on ouvre la discussion sur Hacker News. Et les notes de bas de page commencent.

Ce que le battage médiatique passe sous silence

„~500x, mais c’est une comparaison injuste.“
Cheng Lou à propos de son propre benchmark, X, mars 2026

Le fait que le développeur qualifie son propre 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 avec une première mesure complète via getBoundingClientRect(). C’est comme dire „ma voiture est 500 fois plus rapide que la tienne“ – mais seulement si l’on ne compte pas le temps passé à faire le plein. La première mesure (prepare) coûte 19 millisecondes. Pour la plupart des sites web, la différence est sans importance, car ils ne déclenchent pas une centaine de reflows par frame.

Qualité de la démo au lancement : Plusieurs développeurs ont remarqué que la page de démonstration elle-même présentait des problèmes de rendu. Le texte était coupé (overflow: hidden) et, sur les appareils mobiles, la page était, selon un commentaire sur HN, „fully and completely broken“. Un développeur a commenté sèchement : „La bibliothèque qui veut réparer le web a un site cassé.“ Depuis, la plupart des problèmes ont été corrigés.

CSS savait déjà le faire : Certains des layouts montrés – texte autour de formes, Exclusion Zones, régions – étaient prévus comme fonctionnalités CSS. CSS Exclusions et CSS Regions existent sous forme de spécifications. Elles n’ont jamais été largement implémentées parce que les éditeurs de navigateurs ont fixé d’autres priorités. Pretext ne résout donc pas un problème de CSS, mais un problème d’engagement des navigateurs. C’est une distinction importante.

Niveau de maturité : Pretext est un jeune projet open source. L’auteur documente honnêtement les limites : utiliser system-ui comme police peut entraîner des mesures imprécises sur macOS. Les conteneurs très étroits provoquent des retours à la ligne au milieu des mots. Le rendu côté serveur n’est pas encore prêt. Quiconque utilise 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 vrai problème – mais un problème spécifique. Pretext devient pertinent là où de nombreux blocs de texte doivent être mis en page dynamiquement en même temps :

• Interfaces de chat : applications de messagerie qui virtualisent des milliers de bulles de messages et doivent calculer leur hauteur à l’avance
• Outils éditoriaux : éditeurs de mise en page pour magazines, newsletters ou présentations, qui font circuler le texte autour des images en temps réel
• Interfaces basées sur Canvas : outils de tableau blanc comme Figma ou Miro, qui rendent le texte en dehors du DOM
• Listes virtualisées : toute application qui affiche des centaines ou des milliers de blocs de texte et doit connaître leurs dimensions avant leur apparition dans le viewport

Pour les entreprises de la région DACH qui développent leurs propres produits SaaS avec des interfaces riches en texte, il vaut la peine de suivre son niveau de maturité. Pour un site d’entreprise, un blog ou une landing page, Pretext n’apporte aucun avantage mesurable. Et c’est très bien ainsi. Toutes les bibliothèques n’ont pas besoin de sauver le monde. Parfois, il suffit de résoudre élégamment un problème difficile pour le bon public cible.

Mise en perspective : entre génie et emballement

Pretext n’est ni une arnaque ni une promesse creuse. Le noyau technique – éliminer les mesures DOM du hot path de layout et les remplacer par de l’arithmétique mise en cache – est une approche valable, qui fait une vraie différence dans certains cas d’usage. Le fait que Cheng Lou qualifie son propre benchmark d’„injuste“ et documente clairement les limites le distingue agréablement des habituels dev-influenceurs qui proclament chaque semaine le prochain framework comme une révolution.

Comme souvent, la vérité se situe quelque part au milieu. Non, „every website you’ve ever used“ n’est pas cassé. Le claim viral est du clickbait, probablement choisi en toute connaissance de cause. Mais le problème sous-jacent est réel : le layout des navigateurs est trop lent pour certains cas d’usage, et CSS a promis des fonctionnalités qui ne sont jamais arrivées. Pretext comble cette lacune – avec élégance, performance et des limites claires.

Ce qu’il reste : une prouesse technique impressionnante, signée par un développeur qui sait ce qu’il fait. Une bibliothèque qui, dans un an, sera soit un élément incontournable de la boîte à outils frontend – soit prendra la poussière dans la liste „Awesome JavaScript“ comme une expérience géniale. Les deux seraient un destin honorable.

Questions fréquentes

Qu’est-ce que Pretext exactement ?

Une bibliothèque JavaScript/TypeScript sous licence MIT, qui calcule la mise en page du texte dans le navigateur sans opérations DOM. Elle mesure le texte une seule fois via l’API Canvas, puis calcule les retours à la ligne, les hauteurs et les positionnements de manière purement mathématique. Développée par Cheng Lou (Midjourney, ex-Meta).

Pretext est-il vraiment 500 fois plus rapide que CSS ?

Dans le hot path, selon le développeur, environ 500x : 0,09 ms pour 500 blocs de texte contre des mesures DOM via getBoundingClientRect(). Cheng Lou lui-même qualifie la comparaison d’„injuste“, car la première mesure unique (~19 ms) n’est pas prise en compte. Pour les sites web standard, la différence est sans importance.

Pretext remplace-t-il CSS ?

Non. Pretext ne remplace pas le moteur de rendu du navigateur. Il s’appuie sur le moteur de polices du navigateur, mais contourne le processus de mise en page du 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.

En ai-je besoin pour mon site web ?

Probablement pas. Pretext est pertinent pour les applications de chat, les outils éditoriaux, les interfaces basées sur Canvas et les listes virtualisées. Pour les blogs, les sites d’entreprise ou l’e-commerce, il n’apporte aucun avantage. Le développeur lui-même le reconnaît.

Quel est le niveau de maturité du projet ?

Plus de 6 800 étoiles GitHub, mais encore en développement actif. Le rendu côté serveur manque, et la page de démonstration présentait des problèmes de rendu au lancement. L’utilisation de system-ui comme police peut entraîner des mesures imprécises sur macOS. Pour une utilisation en production, il faut surveiller le degré de maturité.

Pretext a-t-il été développé avec l’IA ?

Oui. Selon Cheng Lou, le moteur a été développé en grande partie avec Claude Code et Codex. Les outils d’IA comparent leurs résultats à la ground truth du navigateur et itèrent sur les cas limites. C’est un exemple intéressant de développement de bibliothèque assisté par l’IA, avec un signal de feedback clairement définissable.

Plus d’articles du réseau MBF Media

Digital Chiefs : Transformation numérique des PME 2026 – le rapport de situation sans fard

SecurityToday : Copilot comme risque de sécurité

MyBusinessFuture : IA made in Germany – 935 startups

Source de l’image de titre : Pexels / Rashed Paykary (px:31343632)