Temporal API на Rust: как Kiesel меняет разработку

hannadev

Temporal - это долгожданная замена устаревшему Date объекту в JavaScript. Он предоставляет правильную работу с временем, часовыми поясами и календарями без головной боли. Проблема в том, что каждый браузерный движок раньше разрабатывал это отдельно - было много дублирования и багов.

Вот в чём суть: вместо того чтобы писать одно и то же несколько раз, разработчики смогли создать общую библиотеку на Rust, которую используют сразу несколько движков. Это экономит время и делает код более надёжным.

Почему Temporal был нужен столько лет

Дата в JavaScript - это одна из самых неудачных частей языка. Объект Date был создан в спешке, как копия Java, и с тех пор считается кошмаром разработчика. Он мутирует значения, работает только с UTC внутри, и вообще не понимает временные зоны. Если вы когда-нибудь пытались правильно вывести дату в местном часовом поясе - знаете, о чём речь.

Зато Temporal вводит отдельные типы для разных ситуаций. Нужно хранить только дату без времени? Используйте PlainDate. Нужно время в конкретной зоне? ZonedDateTime вам поможет. Нужна длительность? Duration справится. Каждый тип делает одно, но делает правильно.

Вот что изменилось:

PlainDate - только дата, без времени и часового пояса
ZonedDateTime - дата и время в конкретной временной зоне
Instant - абсолютный момент времени на глобальной шкале
Duration - промежуток времени между двумя моментами
Immutability - все операции возвращают новые значения вместо изменения старых

Иммутабельность - это вообще ключевой момент. Старый Date изменял себя в процессе работы, что приводило к ошибкам. Temporal не делает ничего подобного.

Как Rust помог решить проблему дублирования

Представьте ситуацию: Chrome, Firefox, Safari и остальные браузеры решили внедрить Temporal. Без координации каждый написал бы своё решение на C++, JavaScript, своём языке - полный хаос. Результат: разные версии API, несовместимые друг с другом, горы багов.

Вместо этого сообщество разработчиков создало temporal_rs - библиотеку на Rust, которая реализует весь Temporal API согласно спецификации ECMAScript. Это похоже на создание единого стандартного решения, которое все могут использовать.

Теперь вот что происходит:

Boa (JavaScript движок на Rust) использует temporal_rs напрямую
Kiesel (JavaScript движок на Zig) подключает её через FFI
V8 (Chrome и Node.js) тоже интегрировал temporal_rs

Это первый раз, когда в V8 появился код на Rust. Раньше V8 был полностью на C++. Решение оказалось настолько удачным, что команда Chrome решила его использовать вместо разработки своей версии.

Преимущества такого подхода очевидны:

Экономия труда - не нужно писать одно и то же три раза
Меньше багов - один хорошо протестированный код вместо трёх разных реализаций
Совместимость - все браузеры используют одинаковое поведение
Быстрое развитие - новые фичи добавляются один раз для всех

Состояние Temporal в браузерах: что уже доступно

Temporal уже появился в реальных браузерах. Firefox 139 и Chrome 144 уже поддерживают этот API полностью. Safari работает над внедрением, но пока только в Technical Preview.

Однако Temporal ещё не финализирован как стандарт. Он находится на Stage 3 в процессе TC39, что значит: черновик достаточно стабилен для реализации, но может ещё измениться. Следующий шаг - Stage 4, когда его официально добавят в стандарт ECMAScript. По плану это должно произойти на встрече TC39 в марте 2026 года в Нью-Йорке в офисе Google.

Что это означает на практике:

Вы уже можете использовать Temporal в современных браузерах без полифилов
Но для production нужно учитывать, что поддержка в Safari пока неполная
Финализация в стандарте сделает API окончательным и даст полную гарантию совместимости
После Stage 4 можно будет забыть о Date и писать код только с Temporal

Тестовое покрытие поразительно: 4000+ тестов для Temporal. Для сравнения - добавление ES6 было примерно на эту же величину. Это показывает масштаб функциональности.

Почему Rust - удачный выбор для shared кода

Вы наверное удивитесь: почему именно Rust? Ответ прост - это язык, который естественно решает проблемы, которые были в JavaScript и C++.

В JavaScript нет настоящей типизации, поэтому сложно выразить строгие требования Temporal спецификации. В C++ всё дело в управлении памятью - можно написать быстро, но легко получить утечки и ошибки. Rust даёт типизацию, безопасность памяти и хорошую производительность одновременно.

Ещё один плюс - FFI (Foreign Function Interface). temporal_rs поставляется с FFI слоем, который позволяет другим языкам вызывать Rust код как обычную библиотеку. Kiesel на Zig и V8 на C++ могут подключить temporal_rs с минимальными усилиями.

Это создало интересный паттерн:

Сложная логика работает на Rust
Другие языки просто вызывают готовые функции
Все получают исправления багов одновременно
Браузеры экономят ресурсы разработки

Конформность очень высокая: Boa, Kiesel и V8 показывают более 95% совместимости с тестами. Это потому что все используют один и тот же код.

Перспективы развития и что дальше

Хотя Temporal уже в браузерах, это только начало. Когда спецификация достигнет Stage 4, начнётся массовое внедрение в реальных проектах. Сейчас большинство разработчиков ещё используют полифиллы вроде Day.js или Moment.js, но со временем этот код можно будет переписать на нативный Temporal.

Разработчики говорят о temporal_rs как об удачном примере реиспользуемых Rust библиотек в браузерных движках. Это может открыть путь для подобных проектов в будущем. Если другие части JavaScript API будут сложны для реализации, почему бы не написать их на Rust? Главное - правильно спроектировать FFI слой.

Одна из потенциальных проблем - размер пакетов. temporal_rs включает свои данные о часовых поясах и календарях, что может увеличить WASM бандл. Но это компромисс между удобством и размером - всегда можно оптимизировать потом.

Текущий момент интересный тем, что разработка JavaScript экосистемы становится более скоординированной. Когда на выходе Stage 4 и все браузеры будут с Temporal, это серьёзно упростит работу с датами для миллионов разработчиков. Старый Date останется только для обратной совместимости, но основной фокус сместится на новый API.