3 ポイント 投稿者 GN⁺ 2025-10-07 | 2件のコメント | WhatsAppで共有
  • Ladybirdは、web-platform-testsというWeb標準の自動テストで、Appleの90%合格しきい値を達成
  • このテストは、HTML、CSS、JavaScriptなど、ブラウザーのWeb標準互換性を総合的に測定する
  • Apple(主にSafari)ブラウザーと同水準の高いテスト合格率を記録したことで、Ladybirdの中核アルゴリズムおよびWeb標準実装が、業界上位のブラウザーに近い信頼性を確保したことを示す
  • これは、新しいオープンソースブラウザーが既存市場の強者と実質的に競争可能であることを示す重要なマイルストーン

2件のコメント

 
shakespeares 2025-10-08

Blink、WebKitと肩を並べることに期待したいです。

 
GN⁺ 2025-10-07
Hacker Newsのコメント
  • web-platform-tests に深く関わった経験から言うと、テスト通過率を指標として扱うのは慎重であるべきだと思う。これは Ladybird の成果をおとしめたいわけではなく、Ladybird の急速な進歩は本当に驚くべきものだし、web-platform-tests がこのチームの助けになっているなら、それ自体は良いことだ。新しく登場する Ladybird、Servo、Flow のようなウェブプラットフォーム実装はとても歓迎している。ただし、web-platform-tests はもともとエンジニアリングツールとして最適化されていて、客観的なメトリクスとして設計されたものではない。たとえば全テスト数のうちデコーディング関連テストの比率が高すぎる。その理由はブラウザ開発で難しいからではなく、生成しやすいからだ。また、私たちは有用なテストを自由に貢献できるように、技術的・社会的な障壁を下げようとしている。これは良い指標づくりには向かないが、良いエンジニアリングリソースには適している。Interop Project は異なるトレードオフと選択的なテスト集合によってこの問題をある程度解決しているが、現在のシステムはすでにほぼ完全なウェブブラウザエンジンを実装したところだけを対象に設計されている
    • ツイートでは、この指標が Apple が Ladybird チームに課した任意の基準であることに触れている。Ladybird の月次アップデートでは、エンコーディングテストが通過率を過度に押し上げるため、それを除外した通過テスト数も公開している
    • 選別したテストのサブセットをメトリクスにすることは不可能なのか気になる
    • それなら Apple に直接言う必要がある。こうした基準を作ったのは Apple だ
    • なぜその点をここで持ち出すのか分からない。これは Ladybird のメトリクスではなく、Apple が iOS で要求しているからだ
  • Ladybird ブラウザが近いうちに実用可能な段階に達しそうなのは本当にすごい。あと数年はかかると思っていたので、ここまで競争力を持つのがこんなに早いとは思わなかった
    • 実際に使ってはいないが、月次サマリー動画はいくつか見た。テストに通ることと、日常的に高速に使えるだけの速度を持つことはまったく別問題だ。Ladybird は今のところそこまで速くはなさそうだ。それでもチーム全体の開発面での成果はすばらしい
    • 「完成度 90% に 90% の時間がかかり、残りの 10% にもさらに 90% がかかる」という話が Ladybird にも当てはまるのか気になる。もし本当だとしても、全体としてかなり良い開発期間だと思う
    • あまり期待しすぎないほうがいいと思う。9月の開発レポートを見ると、まだ直すべき部分が非常に多い。ものすごい進歩なのは確かだが、Ladybird が完成するには今後も数年はかかりそうだ
    • 3年前は Ladybird について懐疑的だった。でも第一に常勤エンジニアが 8 人に増えたことがあり(これは予想していなかった)、第二に実際に 3 年が経った。なので今はずっと楽観的だ。もちろん Chrome と競争するにはまだまだ遠いし、既存エンジンを fork せず自前で作る価値については今でも疑問が残る
    • 以前は完全に新しいブラウザエンジンを作るには何十年もかかると思っていたが、Ladybird チームのように専念する人たちが何かを成し遂げるのを見て驚いている
  • 関連ツイートでは、Ladybird が iOS 上の代替ブラウザエンジンとして検討されるための重要なマイルストーンだと言及されている
    • だから記事タイトルに Apple が入っている文脈は理解できる
    • ただし少なくとも EU 内での話で、それ以外では Apple はどれほど良いエンジンでも許可しないだろう
  • 独立的で非企業的なプロジェクトである Ladybird がこれほど速く成長したのは本当に印象的だ
    • 「non-corpo」という表現は分かるが、実際には Ladybird の組織自体は法人だ。関連書類 を参照
    • ブラウザがどれほど多くのことをしているかを考えると、この種のプロジェクトは本当に途方もない。優れた html/css レンダラーと JS エンジンを作るだけでもすでにすごいのに、いったんエコシステムに入れば、その先の変化にもずっと追随し続けなければならない。Chrome は新しい提案に抵抗することもできるが、小さなブラウザはほぼ追いかけるだけになっている感じがする
    • Ladybird が本当に非企業的なのかは疑問だ。企業スポンサーがいくつかあったと記憶している。その点では、Firefox を持つ非営利の Gecko より優れているとは言えない気がする
    • Ladybird がこのペースを維持できるなら、2027 年末ごろには本当に有力な競争相手になると期待している。ただ個人的には、次に最も機能が多い Servo エンジンにもこれほど集中的な努力が必要だと思う。FF/Mozilla はあまり関心がなさそうなので、別個のブラウザプロジェクトがぜひ必要だ
    • テストに通ることを安全だと見なすのはまったく別の問題だ。これは適合性 (conformance) テストであって、セキュリティテストとは別の話だ。それでも非常に印象的だ
  • 最後の 10% がどれほど難しいのか気になる。一般的なソフトウェアプロジェクトなら、最後の 10% を達成するのに 90% 以上の追加労力が必要になるだろう
    • そして最後の 1% は変わり続け、完全に終わることはないだろう。90% は Apple 基準だ。しかし一般ユーザーが求める水準がどこなのか気になる
    • ブラウザは歴史的に最も大きく難しいプロジェクトだった。なぜこれが簡単になると期待できるのか分からない。もし segfault 発見に 2 万ドルの懸賞金がかかるなら、本当に完成段階なのではないかと思う
  • Ladybird を自分でビルドして実行してみた。驚いたことに、すでにかなり多くのウェブサイトが問題なく開ける。ただし YouTube はまだ動かず、Vimeo や Reddit のコメント欄ではクラッシュする。それでも非常に励みになる結果だ。ビルドには HDD 容量が約 6GB 必要だ
  • グラフに大きな跳躍が見える。どんな変更がこうした改善を生んだのか気になる
    • Twitter スレッドで実際に Andreas に誰かが尋ねていたが、CSS Typed Object Model API 仕様をマージしたことが原因だ
    • この Pull Request で CSS 関連テスト約 6400 件が追加で通るようになった。それでもグラフに見えるスパイクのすべてを説明するわけではなさそうだが、確かに貢献している。PR 詳細
    • グラフに軸がないので、本当に大きな跳躍なのか分からない。たとえば 89% から 90.2% に上がっただけかもしれない。この変化がグラフ左側に表示されていない従来の増加より特別に大きいケースとは限らない
  • Ladybird の gtk 関連開発はどうなっているのか気になる
  • Ladybird ではどの JS エンジンを使っているのか気になる
    • 独自エンジンの LibJS を使っている LibJS GitHub
    • すべてのソースコードはオリジナルだ
  • エンジニアの立場からすると、巨大企業が品質基準を決めて 3rd party ソフトウェアの API アクセスを制限している点は驚きだ。顧客の立場では、厳格な品質基準と OS レベルの API 制限によってセキュリティ検証がされるのは歓迎できる
    • 消費者の立場では、ブラウザが Apple の審査を通らなければならないため、アップデート(バグやセキュリティを含む)が遅くなる。Mac や他のプラットフォームではこんな必要はない。Apple は Safari 以外を使うブラウザをまともに機能させておらず、Mac や他の OS にはこうした環境はない。そして EU で代替エンジンを認めるふりをしていても、実際には悪意ある準拠が増えただけで、事実上代替エンジンは理論上の存在にすぎない。結果として消費者にとっても損だ
    • 消費者の立場では、OS の公式ブラウザで GitHub や Threads のようなサービスを使うことにすら問題を抱えている
    • エンジニアの立場で気になるのは、Apple のブラウザ自身がその基準を守っているのかという点だ。Safari だけが特定のバグを異常なほど頻繁に起こす。誰でもウェブページを作っていれば一度は遭遇するような一般的なバグも多い
    • 壊れたブラウザを使わないという選択ができるのか疑問だ
    • これは驚くことではなく、反競争的かつ不公正なやり方でコントロールを維持しようとしているのだと思う