- À l’échelle mondiale, la montée en puissance des navigateurs basés sur Chromium renforce les inquiétudes sur la diversité des standards web et sur l’avenir de l’open web.
- Le moteur Servo, développé en Rust, s’est distingué grâce à la performance multithread et à la sécurité mémoire, et attire l’attention comme alternative dans le domaine des moteurs de rendu web.
- Bien que le projet soit encore à un stade précoce, des bugs de rendu existent sur la plupart des sites, mais il fonctionne correctement sur certaines pages de démonstration ou sur des sites simples comme Wikipédia.
- Le projet Servo a été lancé à l’origine par Mozilla, mais il est aujourd’hui géré par la Linux Foundation Europe, avec une structure de décision technique indépendante, centrée sur la communauté.
- En contexte de concentration des moteurs de navigateur, l’évolution continue de moteurs alternatifs comme Gecko et Servo est un signal important pour préserver la diversité de l’écosystème web.
Concentration des moteurs web et ses risques
- Au tournant des années 1990 et 2000, divers moteurs de navigateur coexistaient, notamment Trident d’Internet Explorer, Presto d’Opera, Gecko de Netscape et KHTML de Konqueror.
- Au fil du temps, KHTML s’est transformé en WebKit, tandis que Presto et Trident (ainsi que Tasman) ont été intégrés ou remplacés par Blink (le moteur de Chromium).
- Avec le fait que les navigateurs modernes majeurs (Chrome, Edge, Opera, etc.) sont presque tous basés sur Chromium/Blink, un phénomène d’alignement sur l’implémentation tend à émerger.
- Des problèmes tels que les vulnérabilités de sécurité et les limites d’évolutivité deviennent visibles : quand un seul moteur a des failles, l’ensemble de l’écosystème web en pâtit.
L’arrivée du moteur Servo
- Servo est un moteur de rendu de navigateur conçu depuis zéro en Rust.
- En s’appuyant sur les avantages de Rust, notamment le traitement multithread et la sécurité mémoire, Servo cherche à réduire de manière structurelle les faiblesses des moteurs basés sur C/C++, comme les bugs mémoire.
- L’objectif principal de Servo est de devenir un moteur de rendu web embarqué, pouvant aussi être utilisé comme alternative à Electron ou Android WebView, au-delà des navigateurs autonomes.
- La gouvernance technique, sous l’égide de la Linux Foundation Europe, est pilotée par un comité technique plutôt que par des géants technologiques.
- En tant que tout premier moteur de navigateur web totalement nouveau depuis une dizaine d’années, Servo intègre aussi l’expérience des moteurs grand public pour améliorer sa maturité.
Expérience utilisateur et état actuel de Servo
- Il est possible de tester Servo via les nightly builds officielles (pour Windows, macOS, Android et Linux).
- Les fonctionnalités de base d’un navigateur — marque-pages, extensions, synchronisation des données — ne sont pas encore prises en charge.
- Sur la majorité des sites, des bugs de rendu apparaissent, et certaines pages (dont Google Search ou quelques autres) présentent des cassures de mise en page ou des crashs.
- Des pages à structure simple comme Wikipedia ou CNN Lite fonctionnent normalement.
- Les pages de démonstration de Servo permettent une démonstration de performances graphiques ; sur des benchmarks comme Particle Physics, un résultat de 55 à 60 FPS a été observé sur un MacBook Pro récent (émulation x86).
- Dans le test Acid3, Servo obtient 83/100, un score inférieur à celui des moteurs grand public (autour de 95).
- La feuille de route inclut à moyen terme le support de standards web clés comme Shadow DOM et CSS Grid, avec une priorité donnée à l’amélioration de la compatibilité web.
Histoire de Servo et moments clés
- Servo a commencé chez Mozilla en 2012, puis Samsung a rejoint l’équipe de développement en 2013.
- L’objectif initial envisageait qu’après la stabilisation, Servo puisse remplacer le moteur Gecko ; la stratégie a évolué vers un remplacement progressif de certaines parties de Gecko par le code Servo.
- Avec la mise à jour Firefox 57 (Quantum), le moteur CSS (Quantum CSS, Stylo) a été remplacé par du code Servo, avec des améliorations marquées de performance et d’efficacité mémoire.
- Après le gros plan de restructuration de Mozilla en 2020 (incluant des développeurs Servo), Servo a été transféré sous l’égide de la Linux Foundation ; son financement a été rétabli et le développement communautaire se poursuit avec le soutien d’entreprises open source comme Igalia.
Possibilités pour l’avenir de l’écosystème navigateur
- Le fait que le Département de la justice des États-Unis ait remporté la procédure sur la position dominante de Google (Chrome, Android) a relancé les discussions sur la vente de Chrome et sur l’interdiction des accords de recherche avec des navigateurs tiers.
- Mozilla dépend fortement des revenus de la monétisation de la recherche par défaut dans Firefox (essentiels pour maintenir le développement de Gecko), et a donc exprimé son opposition à ces mesures.
- Si Mozilla perd ces revenus, il est possible qu’elle oriente Firefox vers WebKit ou Chromium/Blink afin de réduire ses coûts de développement.
- Dans ce scénario, plusieurs évolutions sont envisageables, notamment le fork de Gecko et une gestion communautaire, ou encore un déclin progressif de Gecko.
- La pérennité de Servo et de Gecko réapparaît comme un facteur clé pour préserver la diversité et l’équilibre de la plate-forme web.
Conclusion et enseignements
- Même dans un contexte de standardisation des moteurs de navigateur dominants, l’émergence d’alternatives innovantes comme Servo joue un rôle important pour préserver la diversité et la santé de l’écosystème web.
- Il est difficile de devenir un navigateur utilisable au quotidien à court terme, mais la recherche et les progrès techniques se poursuivent de manière continue.
- Beaucoup d’attentes sont placées dans l’évolution future de Servo et dans son impact potentiel sur l’industrie.
4 commentaires
On est censés télécharger et utiliser un truc qui fonctionne à peine ? D’où peut bien venir une telle arrogance ?
J'ai entendu dire que Rust avait été créé pour développer Servo... J'espère vraiment que Servo réussira bien.
Le projet Hurd me revient sans arrêt à l’esprit… c’est juste une illusion de ma part, n’est-ce pas ?
Avis sur Hacker News
Dans la feuille de route actuelle, Shadow DOM et CSS Grid sont prioritaires. Je travaille sur la prise en charge de CSS Grid, et le support de « named grid lines and areas » devrait arriver bientôt. J’espère que cela permettra à davantage de mises en page de sites web de fonctionner correctement. Je suis peut-être partial parce que c’est mon projet, mais je trouve que la manière dont Servo implémente CSS Grid est assez élégante. L’implémentation centrale est séparée dans une bibliothèque externe (Taffy, lien GitHub), et cette bibliothèque est largement utilisée dans l’écosystème UI Rust. Par exemple, elle sert dans le moteur web Blitz(lien), l’éditeur de texte Zed(lien) et le moteur de jeu Bevy(lien) pour divers rôles comme Flexbox, Block layout, etc. En s’appuyant sur l’expérience acquise avec le développement de bibliothèques modulaires comme Stylo et html5ever, Servo adopte une approche qui consiste à découper le moteur web en modules indépendants avec des API publiques. J’espère que cela abaissera à l’avenir la barrière d’entrée pour les développeurs de moteurs web et aidera grandement les nouveaux venus.
C’est la première fois que j’entends parler de Blitz. Le projet semble très intéressant et ambitieux, presque comme un véritable moteur web « caché ». Servo est largement connu depuis les débuts de Rust, mais Blitz est tout aussi impressionnant.
Je me demande si le fait d’avoir directement implémenté des fonctionnalités de moteur de navigateur web influence la façon d’écrire du HTML ou du CSS. J’aimerais aussi savoir si vous cherchez encore « css grid cheatsheet » trois fois par semaine.
Je crains qu’une approche consistant à découper les fonctionnalités en modules ne finisse au contraire par produire trop de fonctions ou de la fragmentation. Pour rivaliser avec Google, une stratégie très focalisée me semble importante, et c’est ce qui m’inquiète.
J’utilise taffy pour gérer la mise en page de mon petit calendrier e-ink en Rust, donc je trouve ce genre de nouvelles très amusant.
J’aime vraiment l’idée de séparer le moteur web en modules d’API publiques utilisables indépendamment. En regardant WebRTC à l’époque, je me demandais pourquoi faire un clone bancal de Skype devait se résumer soit à 50 lignes de JavaScript, soit à une semaine de cauchemar de build Chromium en C++. Maintenant qu’il existe aussi un crate Rust pour WebRTC, c’est rassurant de voir que les applications web ne sont pas les seules à bénéficier de ce type d’investissement.
J’ai l’impression que Mozilla va entrer au panthéon des entreprises « qui ont créé la technologie du futur puis l’ont laissée filer chez des concurrents », comme Xerox. Avec Rust et Servo, ils avaient un temps pris de l’avance sur Google dans le développement des navigateurs, et je ne comprends vraiment pas pourquoi ils n’ont pas continué.
Mozilla n’est pas Xerox. Si quelqu’un est le nouveau Xerox, ce serait plutôt Google. Google investit d’énormes moyens dans de la R&D sans plan commercial clair. L’exemple typique, ce sont les modèles Transformer — en pratique, Google a créé les LLM en premier, puis s’est quand même fait dépasser par OpenAI. Le succès de Mozilla a toujours été centré sur les navigateurs web, comme Netscape ou Firefox. Rust aussi est fondamentalement un langage créé pour les navigateurs. Le fait qu’il soit utile ailleurs n’est qu’un effet secondaire heureux.
Google est la principale source de revenus de Mozilla depuis 2006. Pour survivre, Mozilla doit surtout satisfaire Google. Cela crée évidemment des conflits potentiels, mais du point de vue de Mozilla, c’est un arrangement assez avantageux.
Je pense que Mozilla est fini. Ils ont trop dépendu de Google, et ils risquent même de perdre cela. Servo et Ladybird représentent l’avenir, et il est vraiment impressionnant de voir Ladybird progresser aussi vite avec si peu de personnes.
Si Mozilla abandonne Gecko, ce sera le moment de faire un hard fork et de quitter Mozilla. Et par abandon de Gecko, je veux dire un passage à Chromium, pas à Servo.
J’ai l’impression qu’il est difficile de faire payer les gens pour un navigateur. Ils dépensent facilement 10 euros pour une bière, mais j’ai vu beaucoup de gens contourner la licence à vie de WhatsApp à 0,99 euro.
Je ne comprends toujours pas pourquoi Mozilla a renoncé à l’avenir technique de Firefox. Mais quand on regarde Mozilla à travers les flux financiers, beaucoup de choses deviennent plus claires.
L’arrêt du service Pocket est aussi un triste exemple. J’imagine parfois une blague du 1er avril où Mozilla annoncerait l’arrêt de Firefox pour se recentrer sur son cœur de métier. C’est une plaisanterie amère, mais on dirait presque que leur véritable cœur de métier est de mettre fin avec élégance à des produits populaires.
Vu les nombreux départs et la manière de communiquer, Mozilla semblait à l’époque être une entreprise extrêmement politisée. Servo communiquait énormément et Rust avait une très bonne ambiance, donc je pense que cela a peut-être justement dérangé les niveaux supérieurs. Mozilla reste encore largement dirigé par l’ancienne garde, et j’estime que la responsabilité des erreurs de la direction est majeure.
Je crois toujours très fortement que Servo peut devenir une véritable alternative au monopole de Chrome/Chromium. Je ne comprends pas pourquoi Mozilla a abandonné cela, ni pourquoi la Linux Foundation le soutient si peu.
Si l’on regarde la stratégie de Mozilla sous l’angle d’une indépendance à long terme vis-à-vis de l’argent de Google, elle a une certaine logique. Les revenus hors Google sont passés de 80 millions de dollars en 2022 à 150 millions en 2023. Les actifs totaux augmentent aussi de 100 millions par an, pour atteindre 1 milliard de dollars en 2023. La part de l’argent de Google est descendue de 90 % en 2020 à 75 % en 2023. Mozilla n’est donc pas totalement indépendant, mais il y a une direction. Contrairement à ce qu’on entend souvent, si l’on ne regarde que les flux financiers, on peut arriver à une conclusion différente. Les gens disent qu’il aurait fallu poursuivre Servo, mais en réalité, je ne pense pas que Servo ait eu un rôle majeur dans Firefox après Quantum.
Quelqu’un demande s’il est vrai que la majeure partie des revenus de Mozilla provient de Firefox.
Il y a aussi Ladybird(site officiel) pour contester le monopole de Blink. On ne sait pas encore ce que cela donnera, mais j’attends la suite avec intérêt.
Je ne comprends pas très bien l’objectif de Ladybird. Ce n’est clairement pas juste un projet hobby, puisqu’il y a d’anciens ingénieurs et une collecte de dons. Mais j’ai du mal à imaginer comment il pourrait rivaliser avec Blink, Webkit ou Gecko sur les fonctionnalités, la sécurité et les performances. Sans grande équipe ni adoption massive, je pense qu’un simple moteur a peu d’impact. Cela vaut aussi pour Servo, mais Servo a des objectifs techniques plus convaincants. Je ne vois pas d’informations aussi claires pour Ladybird.
D’un point de vue purement technique, je vois mal l’attrait de Ladybird. C’est essentiellement écrit en C++, donc il ne semble pas se différencier de Gecko ou Blink. Servo, lui, a des différences de conception techniques claires, comme la sécurité et le parallélisme, et c’est ce qui le rend attirant.
J’espère que Ladybird réussira. On peut désormais le soutenir directement, et je trouve cela important. Contrairement à Mozilla, je suis convaincu que les dons récoltés seront entièrement consacrés au développement du navigateur.
Je me demande si Ladybird essaie de passer à Swift. Développer un moteur de navigateur en C++ ne m’enthousiasme pas, mais cela semble réaliste et orienté résultat. En Rust, cela aurait un côté plus tourné vers l’avenir, et je le reconnaîtrais volontiers. En revanche, construire un moteur dans un autre langage comme Swift ressemble plutôt à une décision politique interne à une entreprise. Je m’interroge sur le choix délibéré d’un langage dont l’écosystème de support est encore insuffisant (tweet de référence).
Le test Dogemania tourne de façon fluide à 60 FPS jusqu’à 400 images sur un MacBook Pro M4 Pro. En revanche, dans Chrome, les 60 FPS tenaient jusqu’à 1400 images, et au-delà j’ai fermé parce que je n’avais plus envie de continuer.
J’ai fait la même expérience, et l’écart entre Firefox et Chromium est décevant de taille. Dans Chromium, on restait à 100 FPS même après 1000 images, alors que dans Firefox, on passait sous les 60 FPS dès qu’on dépassait 500 images. Ce n’était peut-être pas un test parfaitement équitable (pas d’extensions dans Chromium, et c’est un navigateur que j’utilise peu), mais cela m’a quand même beaucoup appris sur les performances comparées.
Si, dans dogemania, les images restent immobiles après l’animation, je me demande si ce n’est pas justement un cas très facile à optimiser. J’ai presque l’impression que de vieux ordinateurs comme l’Amiga pourraient gérer cela indéfiniment.
Appeler Servo un moteur « nouveau », c’est un peu forcé.
Je croyais que Rust avait été créé pour le navigateur web Servo.
Concernant l’idée selon laquelle « s’il ne reste plus qu’une seule implémentation d’un standard, alors elle devient le standard », je ne vois pas bien pourquoi ce serait un problème. Si l’implémentation est open source et que la spécification est définie par un comité géré par plusieurs acteurs, cela me semble acceptable. La situation actuelle, où l’on consacre énormément de ressources à créer plusieurs moteurs, me paraît au contraire être du gâchis. Je pense qu’il serait plus efficace d’avoir un seul moteur de navigateur, comme le noyau Linux, avec seulement des distributions différentes.
Même avec les meilleures intentions, une implémentation conserve des bugs et de petites imperfections. Sans seconde implémentation indépendante, on finit par dire « tout fonctionne », et le bug lui-même devient le standard. Si les pages web commencent à dépendre de ces bugs, leur fonctionnement finit par reposer non pas sur la spécification, mais sur les défauts d’une implémentation particulière. C’est aussi ce qui a conduit à l’empilement de vieilles couches d’UI dans MS Windows et à ce cauchemar de compatibilité. Avec plusieurs implémentations indépendantes, le standard peut réellement être maintenu, évoluer et être optimisé plus facilement.
En théorie, cela va, mais en pratique, je ne pense pas qu’un monopole soit souhaitable, parce que les intérêts d’un développeur unique ne coïncident pas toujours avec ceux des utilisateurs. Le récent abandon de manifest v2 côté Blink, par exemple, a été très mal accueilli par les utilisateurs.
Plus il y a de moteurs de navigateur, moins le risque est grand qu’une faille de sécurité touche tout le monde à la fois. Même avec un langage sûr pour la mémoire, des erreurs logiques peuvent encore causer des dégâts, donc la diversité reste importante.
Vous parlez d’une stratégie « un moteur, plusieurs distributions », mais pour quelqu’un habitué aux environnements BSD ou à ZFS, sortir de l’approche dominante donne justement une impression très nette de stabilité et de finition.
Les opinions de Google, ou de gens de son entourage, influencent déjà fortement la standardisation. Si tout tourne sous Chromium, la situation empirera encore. Peut-être faudra-t-il vraiment une catastrophe pour que tout le monde reconnaisse enfin les limites d’organismes comme le W3C ou le WHATWG.
« La plupart des sites web ont quelques bugs de rendu et certains ne fonctionnent pas du tout. Les résultats Google contiennent beaucoup d’éléments qui se chevauchent, et la page d’accueil de MacRumors plante après défilement. En revanche, Wikipedia, CNN Lite, des sites personnels ou les pages texte de NPR fonctionnent parfaitement » — en voyant ce genre d’observations, je constate qu’on dit rarement que Google ou MacRumors devraient corriger leurs sites pour Servo. À la place, on conclut presque toujours que Servo doit se comporter comme Chrome/Chromium, et je trouve cela très regrettable. Sinon, (a) ce sont finalement des entreprises publicitaires qui fixent les standards, et (b) les créateurs de pages web acquièrent de mauvaises incitations. S’aligner sur des pages simples comme Wikipedia ou CNN Lite est pourtant bien plus facile. Je pense qu’un navigateur « standard » devrait viser ce qui est réellement proche du standard, pas seulement ce qui est le plus populaire. Le vrai standard, c’est ce qui fonctionne à la fois dans les navigateurs peu populaires et dans les navigateurs populaires. Au final, je soutiens que la réponse consiste à corriger les pages web, pas les navigateurs. J’expérimente encore aujourd’hui avec la bibliothèque et les outils libwww d’origine du w3c. Avec quelques ajustements, cela fonctionne toujours très bien après plus de 30 ans pour optimiser des pages web textuelles. Internet est un bien public, mais les navigateurs et les pages d’aujourd’hui sont trop orientés vers l’optimisation publicitaire et la collecte de données personnelles, ce qui est regrettable. Il faut d’abord des pages et des navigateurs réellement au service des utilisateurs du www pour que cela ait du sens. Ci-dessous se trouve un petit script pour compiler un binaire statique avec libwww.
Je trouve vraiment triste de voir Mozilla passer progressivement d’une entreprise de navigateurs compétitive à une organisation qui ressemble davantage à un groupe militant. Cela rend d’autant plus amer le fait que son produit principal se soit affaibli peu à peu.