Ladybird franchit le seuil des 90 % d’Apple dans les web-platform-tests

• Ladybird a atteint le seuil de 90 % de réussite d’Apple dans les tests automatisés de standards du web appelés web-platform-tests
• Ces tests mesurent de façon globale la compatibilité aux standards du web des navigateurs, notamment pour HTML, CSS et JavaScript
• En enregistrant un taux de réussite élevé aux tests au niveau d’un navigateur Apple (principalement Safari), Ladybird démontre que ses algorithmes fondamentaux et son implémentation des standards du web ont acquis une fiabilité comparable à celle des navigateurs les mieux classés du secteur
• Il s’agit d’une étape importante montrant qu’un nouveau navigateur open source peut réellement rivaliser avec les acteurs historiques du marché

[shakespeares]

Espérons qu’il pourra rivaliser avec Blink et WebKit.

[GN⁺]

Commentaires Hacker News

• En tant que personne ayant été très impliquée dans les web-platform-tests, je pense qu’il faut être prudent avant d’utiliser le taux de réussite aux tests comme indicateur. Ce n’est pas pour minimiser l’accomplissement de Ladybird : ses progrès rapides sont vraiment impressionnants, et si les web-platform-tests aident cette équipe, c’est en soi une bonne chose. L’arrivée de nouvelles implémentations de plateforme web comme Ladybird, Servo ou Flow est très bienvenue. Cela dit, les web-platform-tests ont été optimisés à l’origine comme outil d’ingénierie, pas conçus comme métrique objective. Par exemple, la proportion de tests liés au décodage est excessivement élevée dans le total des tests. La raison n’est pas que c’est particulièrement difficile dans le développement navigateur, mais que ces tests sont faciles à générer. De plus, nous essayons d’abaisser les barrières techniques et sociales afin que chacun puisse contribuer librement à des tests utiles. Cela ne convient pas à la création d’un bon indicateur, mais convient bien à une bonne ressource d’ingénierie. Le projet Interop résout en partie ce problème grâce à d’autres compromis et à des sous-ensembles de tests sélectionnés, mais le système actuel est déjà conçu pour viser uniquement des projets ayant pratiquement implémenté un moteur de navigateur web complet
  • Le tweet précise que cet indicateur est un critère arbitraire imposé par Apple à l’équipe Ladybird. Dans les mises à jour mensuelles de Ladybird, ils publient aussi le nombre de tests réussis en excluant les tests d’encodage, qui gonflent excessivement le taux de réussite
  • Je me demande s’il serait impossible d’utiliser comme métrique un sous-ensemble de tests soigneusement sélectionné
  • Dans ce cas, il faut en parler directement à Apple. C’est Apple qui a fixé ce critère
  • Je ne vois pas pourquoi soulever ce point ici. Ce n’est pas une métrique propre à Ladybird, c’est une exigence d’Apple pour iOS
• C’est vraiment génial que le navigateur Ladybird soit bientôt à un stade où il pourra être utilisé concrètement. Je pensais qu’il faudrait encore quelques années, je ne m’attendais pas à ce qu’il devienne compétitif aussi vite
  • Je ne l’ai pas essayé moi-même, mais j’ai regardé quelques vidéos de résumé mensuel. Réussir des tests et être assez rapide pour un usage quotidien sont deux choses complètement différentes. Ladybird ne semble pas encore très rapide pour l’instant. Cela dit, les progrès de toute l’équipe sont remarquables
  • Je me demande si le dicton « 90 % du temps est consacré aux 90 % de finition, et les 10 % restants prennent encore 90 % du temps » s’applique aussi à Ladybird. Même si c’est vrai, je trouve que le calendrier de développement reste globalement assez bon
  • Je recommande de ne pas trop s’emballer. D’après le rapport de développement de septembre, il reste encore énormément de choses à corriger. Les progrès sont indéniablement énormes, mais il faudra probablement encore plusieurs années avant que Ladybird soit terminé
  • Il y a trois ans, j’étais sceptique à propos de Ladybird. Mais d’une part, le nombre d’ingénieurs à plein temps est passé à huit, ce que je n’avais pas prévu, et d’autre part, trois ans se sont effectivement écoulés. Je suis donc bien plus optimiste aujourd’hui. Bien sûr, il est encore très loin de pouvoir rivaliser avec Chrome, et je continue à m’interroger sur l’intérêt de créer un moteur à partir de zéro plutôt que de forker un moteur existant
  • Avant, je pensais qu’il fallait plusieurs décennies pour créer un moteur de navigateur entièrement nouveau, mais je suis impressionné de voir des gens aussi investis que l’équipe Ladybird réussir à accomplir quelque chose
• Dans un tweet lié, il est indiqué qu’il s’agit d’une étape importante pour que Ladybird soit considéré comme moteur de navigateur alternatif sur iOS
  • Je comprends donc pourquoi Apple apparaît dans le titre de l’article
  • Mais cela ne vaut qu’au sein de l’UE, au minimum ; ailleurs, Apple ne l’autorisera pas, même si le moteur est excellent
• Il est vraiment impressionnant qu’un projet indépendant et non corporatif comme Ladybird ait grandi aussi vite
  • Je comprends l’expression « non-corpo », mais en réalité l’organisation Ladybird elle-même est une entité juridique. Voir les documents associés
  • Quand on pense à tout ce qu’un navigateur doit faire, un projet de cette ampleur est vraiment colossal. Rien que construire un excellent moteur de rendu HTML/CSS et un moteur JS est déjà énorme, mais une fois entré dans l’écosystème, il faut aussi suivre en permanence les évolutions à venir. Chrome peut se permettre de résister à certaines nouvelles propositions, alors que les petits navigateurs donnent surtout l’impression de courir derrière
  • Je me demande si Ladybird est vraiment non corporatif. Il me semble me souvenir qu’il y a eu un certain soutien d’entreprises. De ce point de vue, je ne pense pas qu’on puisse dire que c’est mieux que Gecko, qui est à but non lucratif et derrière Firefox
  • Si Ladybird maintient vraiment ce rythme, j’espère qu’il deviendra un concurrent sérieux d’ici fin 2027. Mais personnellement, je pense qu’un effort aussi concentré est aussi nécessaire pour Servo, qui est selon moi le moteur ayant ensuite le plus de fonctionnalités. FF/Mozilla ne semble pas très intéressé, donc un projet de navigateur séparé est indispensable
  • Faire passer les tests en toute sécurité est un problème totalement différent. Il s’agit ici de tests de conformité, pas de tests de sécurité. Cela reste malgré tout extrêmement impressionnant
• Je me demande à quel point les 10 % restants seront difficiles. Dans un projet logiciel classique, atteindre les 10 % finaux demande généralement plus de 90 % d’effort supplémentaire
  • Et le dernier 1 % continuera sans doute à changer et ne sera jamais vraiment terminé. Les 90 % sont le critère d’Apple. Mais je me demande quel est le niveau réellement attendu par les utilisateurs ordinaires
  • Historiquement, les navigateurs ont été parmi les projets les plus vastes et les plus difficiles. Je ne vois pas pourquoi on s’attendrait à ce que cela devienne facile. Je me dis que s’il y avait une prime de 20 000 dollars pour trouver un segfault, on serait peut-être proche d’un vrai stade d’achèvement
• J’ai compilé et exécuté Ladybird moi-même. Étonnamment, un assez grand nombre de sites web s’ouvrent déjà correctement. En revanche, YouTube ne fonctionne pas encore, et il y a des crashs sur Vimeo ou dans la zone de commentaires de Reddit. Malgré cela, le résultat est très encourageant. Il faut environ 6 Go d’espace disque pour la compilation
• On voit un grand bond sur le graphique ! Je me demande quel changement a permis une telle amélioration
  • Quelqu’un a effectivement posé la question à Andreas sur le fil Twitter, et la cause serait l’intégration de la spécification CSS Typed Object Model API
  • Cette Pull Request a permis de faire passer environ 6 400 tests CSS supplémentaires. Cela n’explique probablement pas à lui seul tout le pic visible sur le graphique, mais cela a clairement aidé. Détails de la PR
  • Le graphique n’a pas d’axes, donc on ne peut pas savoir s’il s’agit vraiment d’un grand bond. Par exemple, il est peut-être passé de 89 % à 90,2 %. Ce n’est pas forcément un cas plus spectaculaire que les hausses précédentes, simplement non affichées à gauche du graphique
• Je me demande où en est le développement lié à Ladybird gtk
• Je me demande quel moteur JS Ladybird utilise
  • Ils utilisent leur propre moteur, LibJS. GitHub de LibJS
  • Tout le code source est original
• Du point de vue d’un ingénieur, il est surprenant qu’un géant définisse les critères de qualité et limite l’accès API de logiciels tiers. Du point de vue du client, il est rassurant de savoir que des critères de qualité stricts et des restrictions d’API au niveau de l’OS permettent une validation de sécurité
  • Du point de vue du consommateur, les mises à jour du navigateur — y compris pour les bugs et la sécurité — sont ralenties parce qu’il doit passer la validation d’Apple. Sur Mac ou sur d’autres plateformes, ce n’est pas nécessaire. Apple fait en sorte que les navigateurs qui ne sont pas Safari ne fonctionnent pas correctement, alors qu’on ne retrouve pas cet environnement sur Mac ou sur d’autres OS. Et même si l’entreprise prétend autoriser des moteurs alternatifs dans l’UE, en pratique il n’y a guère qu’une conformité malveillante, si bien que les moteurs alternatifs restent essentiellement théoriques. Au final, les consommateurs y perdent aussi
  • Du point de vue du consommateur, on rencontre déjà des problèmes simplement en utilisant des services comme GitHub ou Threads avec le navigateur officiel de l’OS
  • En tant qu’ingénieur, ce qui m’intéresse, c’est de savoir si le navigateur d’Apple respecte ses propres critères. Safari semble souffrir énormément plus souvent que d’autres de certains bugs. Il y a aussi beaucoup de bugs courants que presque tout le monde a déjà rencontrés en créant une page web
  • Je me demande s’il est vraiment possible de choisir de ne pas utiliser un navigateur défectueux
  • Je ne trouve pas cela surprenant : j’y vois plutôt une volonté de conserver le contrôle par des moyens anticoncurrentiels et déloyaux