Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 22
Как-будто дипломную работу прочитал. К середине уже булькать начал. Но в целом познавательно.
Всё никак не удавалось понять, чем Временный лучше Даты. Но с этой статьёй смысл до меня дошёл. Наконец-то ещё один неизменяемый кирпичик в экосистему JS!
Бред какой-то. Ваша проблема в том, что вы не хотите менять значение, но меняете? Ну не хотите - не меняйте. Или над вами обязательно дядя с палкой стоять должен?
Это всё хорошо, конечно, но уж больно избыточный API, например, как получить utcNow
Стало: Temporal.Now.zonedDateTimeISO('UTC')
Было: new Date()
У вас какая-то квота на кол-во символов?
Вы, видимо, не очень много с датами работали. Как-то странно вы судите об избыточности API используя пример, где Temporal не нужен совсем. React/Vue/Angular тоже какие-то избыточные и непонятно зачем нужны, ведь чтобы отрисовать <div>Hello World!</div> в React надо ~10 строчек кода + килобайты зависимостей + бандлить это всё, хотя можно просто в index.html написать <div>Hello World!</div>
С простого: как получить текущее время в другой таймзоне?
Стало: Temporal.Now.zonedDateTimeISO('Asia/Tokyo')
Было: const dateInTokyo = new Date(
new Date().toLocaleString("en-US", { timeZone: "Asia/Tokyo" })
);
А как получить начало текущего дня в другой таймзоне? А потом перевести её на начало дня в третьей таймзоне? Одна-две строчки в Temporal или несколько часов отладки с Date и оно всё равно криво будет работать
Скажем так, работал много, но, к счастью, на бэкенде, и все эти часовые пояса и DST мне до свечки. UTC везде - вот мой выбор
Никаких возражений, что операции с таймзонами нужны, нет. И Date крайне убог. Но со своей колокольни вижу очень многословный API для простейшего и самого частого действия
используя пример, где Temporal не нужен совсем
Это вы скажите комитету, который уже анонсировал Date как legacy, когда Temporal устаканится
Java в названии надо как-то оправдывать
Было бы интереснее, если бы DateTime и прочее почерпнули из luxon. А то получается, что хотят, как с Intl, под одну гребёнку все завернуть, только в отличии от оного даты используются куда чаще и присутствует некая избыточность синтаксиса.
Я по старинной привычке просто храню и таскаю даты как строки в ISO формате и строго в UTC зоне. Можно сравнивать, они иммутабельны, их можно засунуть в любую библиотеку, JSON и посылать по сети. Использую Date/moment/luxon/dayjs только для операций над датами (вроде вашей add/subtract) или форматирования (Intl), да и то для таких операций всегда лежат заготовленные функции обертки, так что инлайново в коде объекты почти не встретить. Если надоело добавлять дни с помощью moment, можно в обертке заменить на dayjs, прогнать тесты и радоваться.
С TypeScript строки еще и брендированны, так что что попало без валидации не назначить. Требуется boilerplate код, чтобы все нюансы покрыть, но последний раз обновлял код года 3 назад, когда мигрировали с moment на dayjs.
Когда Temporal доберется до повсеместного распространения, вот тогда я просто окончательно избавлюсь от 3rd party библиотек, но от строковых ISO дат, наверное, никогда 😄
поправьте в статье день месяца пожалуйста.
Я понял посыл автора данной статьи, и вот что я могу сказать по этому поводу (ИМХО и только):
В вашем случае можно использовать тот же dayjs, luxon, momentjs (или любую другую библиотеку), и будет вам счастье, но в остальном - неправильное использование Date не повод для того, чтобы его "хоронить", а повод посмотреть документацию непосредственно к нему, где черным по белому написано - почему month не 1, 2 или 3 (и т.д.), а 0, 1 или 2 (и т.д.).
Лично я во всех проектах, где принимал участие и используется Date, дополнял небольшими dateUtils, в которых хранил helper функции для работы с Date и только те, что необходимы в рамках данного проекта. Без усложнений кода, его читаемости и прочего.
К тому же, не стоит забывать, что есть пользователи со старыми устройствами, где тот же Temporal работать не будет (Chrome до 144 версии, welcome, как пример), особенно устройства Digital Signage, где ES6-то не везде поддерживается и нужно через кучу polyfill пропускать код, а если и поддерживается, то обязательно найдется то, чего он не знает, так как там версии Chromium отстают от актуальных. Как пример: устройство Samsung Digitial Signage 2025 года поддерживает Chromium 120 версии и не выше... (ссылка тут, с указанием года выпуска модели и версии Chromium, что лежит внутри)
Как итог моего монолога:
Выбирайте то, что необходимо вам в рамках ваших задач и целевой аудитории, но никогда не навязывайте своё мнение другим, так как у других могут быть другие задачи и другая целевая аудитория.
А пока Temporal не имеет широкой браузерной поддержки, то пока не достоин столь пристального внимания. Лучше будет обратить на него внимание тогда, когда он будет поддерживаться всеми современными браузерами, и то, с точки зрения интереса "Что за зверь?"...
Мира, любви и жвачки вам :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Javascript: прощай, Date, здравствуй, Temporal