Bez генерирует браузерный движок по веб-спецификациям и тестам

Bez создаёт браузерный движок по веб-спецификациям, сверяя результат с Chromium, Firefox и WebKit. Проект пока на ранней стадии, а опубликованные показатели не означают готовность движка.

· 3 мин чтения · 4 комментария

Bez — проект по созданию браузерного движка из веб-спецификаций с проверкой результата тестами и сравнением с существующими браузерами. Материал о нём опубликован 1 октября 2026 года; приведённая в нём таблица покрытия отражает замер от 4 октября, но когда её добавили в материал, не указано. Для сайтов и приложений пока ничего менять не требуется: проект на ранней стадии.

Как проверяют код движка

Модель получает текст спецификации и предлагает варианты реализации правила. Кандидатов запускают внутри Bez и сравнивают расположение элементов с результатами Chromium, Firefox и WebKit. Если проверка не пройдена, цикл повторяют. Принятый вариант сохраняют как обычный код на Rust. В проверках также используют Web Platform Tests (WPT).

Три браузера нужны проекту как ориентиры поведения, а не как источники кода. Их результаты сверяют между собой, чтобы особенность одного движка не стала образцом для нового. В исследовании 235 документов совпали 699 из 705 попарных сравнений. Все шесть расхождений относились к глубоко вложенным процентным размерам; при сравнении трёх браузеров отличался Firefox.

Для WPT устойчивое большинство трёх движков найдено по 2 162 676 из 2 282 301 тестов и подтестов — 94,8%. Это доля проверок, для которых есть согласованный ориентир, а не доля тестов, пройденных Bez. Даже большинство не снимает вопрос о различиях: Gecko округляет длины до 1/60 пикселя, а Blink и WebKit — до 1/64. Из-за этого flex-элемент может перенестись только в Firefox или значение offsetWidth может отличиться на пиксель.

Сколько уже реализовано

В таблице на основе browser-compat-data 8.0.4 по замеру от 4 октября 2026 года сгенерированными отмечены 0,6% позиций, написанными вручную — 0,3%; до 93,0% работа ещё не дошла. Для HTML, JavaScript, SVG, WebAssembly, HTTP и MathML указано по 100% недостигнутых позиций. Таблица описывает покрытие карты возможностей, а не долю сайтов, которые Bez умеет открывать.

DOM, стили, деревья раскладки и фрагментов созданы вручную и проходят предусмотренные проектом проверки по браузерам. Из девяти правил раскладки CSS 2.1 восемь реализаций, предложенных моделями, приняли после такого сравнения. Для высоты блочного элемента оставили ручную версию: ни один кандидат её не превзошёл. Вместе правила проходят 227 подготовленных случаев и 11 пригодных страниц WPT для обычного потока.

Проект предусматривает полный движок и вариант под содержимое отдельного сайта или приложения. Во втором случае анализатор определяет используемые возможности, чтобы остальные не попадали в бинарный файл. Анализатор уже добавлен, но о готовой облегчённой сборке для применения материал не сообщает.

Есть ограничение и у самого метода. По оценке проекта, примерно для 55–60% относящихся к движку позиций совместимости доступны и автоматическая проверка, и пригодный для генерации текст спецификации. Примерно для 8–18% нет ни того ни другого. Открыты вопросы стоимости ручной реализации правил, размера генерируемых частей и объёма WPT, доступного без JavaScript. Срок выпуска полного движка не назван.

Что это значит для сайтов и разработчиков

Владельцам сайтов не нужно пересматривать требования к проектам или закладывать поддержку Bez. Практический урок пока в другом: совпадение поведения браузеров можно измерять, но проверка страницы только в одном из них не выявит все расхождения. Случай с округлением показывает, что различие возможно и в привычной CSS-разметке.

Для разработчиков приложений и устройств, которым нужно отображать веб-контент, сборка только с используемыми возможностями выглядит перспективным направлением. Однако анализатор содержимого — не то же самое, что небольшой движок, готовый к сопровождению. Приведённые результаты подтверждают работу отдельных правил раскладки, но не полноту поддержки веб-платформы.

Моё мнение

Мне близка проверка не только сгенерированного кода, но и самого ориентира: браузеры действительно могут расходиться. При этом 94,8% легко ошибочно прочитать как показатель готовности Bez. Таблица покрытия быстро возвращает к реальному масштабу работы.

Я бы смотрел на то, сколько правил удастся довести до работающего кода и кто будет разбирать противоречия между спецификациями, тестами и браузерами. Пока неясна стоимость сопровождения, обещание дешёвого добавления новых частей движка остаётся гипотезой.

Источники

Откуда новость. Текст — пересказ своими словами, факты — из источника, мнение — автора.

  1. Bez: Generating a browser engine from specs and tests tangled.org

Об авторе

Рауль Мартин

старший full-stack-разработчик

Проектирую и поддерживаю веб-приложения; в последние годы чаще разбираю унаследованный код, чем начинаю с чистого листа. Перед выбором технологии спрашиваю, кто будет её сопровождать.

Все публикации автора

Фронтенд 4 мин чтения

ts-rust: экспериментальный перенос компилятора TypeScript 7 на Rust

Экспериментальный ts-rust переносит компилятор, проверку типов и языковой сервер TypeScript 7 на Rust. Проект показывает ускорение в тестах, но пока требует проверки на конкретных приложениях.

Фронтенд 4 мин чтения

В $mol добавили поддержку Node.js для хранения данных и новые инструменты интерфейса

В обзоре изменений $mol и Giper Dev за август и сентябрь — поддержка Node.js в $mol_storage, новые возможности редактора и инструменты интерфейса. Рассказываем, что стоит проверить разработчикам.

Написать комментарий

Не публикуется. Пришлём ссылку, чтобы подтвердить комментарий.

Без ссылок и рекламы. Первый комментарий публикуется после проверки. Отправляя комментарий, вы соглашаетесь с политикой конфиденциальности.

  1. Рауль, как Bez решает, какие правила спецификаций и области платформы реализовывать в первую очередь, если прохождение WPT ещё не говорит о готовности движка?

    1. Рауль Мартин Автор публикации

      По описанию, приоритеты проекта не раскрыты, поэтому я бы не стал приписывать Bez конкретную стратегию отбора. WPT и сравнение с Chromium, Firefox и WebKit помогают проверять отдельные реализации, но сами по себе не отвечают, какие части платформы важнее; для этого нужны заявленные цели и ограничения проекта.

      1. Тут ещё важно, что совпадение с тремя браузерами и прохождение WPT проверяют поведение отдельных функций, но не показывают, какие сценарии Bez считает целевыми. Без заявленных целей даже красивый процент покрытия — скорее повод открыть профайлер ожиданий, чем вывод о готовности.

  2. в наших проектах расхождения с браузерами обычно всплывали на реальных страницах раньше, чем в искусственных тестах, так что сравнение с chromium, firefox и webkit полезно, но профайлер и wpt я бы всё равно открыл до выводов о готовности