Вот в чём суть: вместо того чтобы писать одно и то же несколько раз, разработчики смогли создать общую библиотеку на 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.