А ТС подрос! Вычисления на типах можно делать еще сложнее 🙂

Когда я последний раз тестировал трамплины, еле-еле считало “300+1”.

Сейчас попробовал на node: v20.5.1, TypeScript: v5.2.2, подумав справляется с “1000+1”.

Да и сама величина рекурсии подросла. Раньше на 30 сваливалось, а сейчас 90 может съесть.

999 сейчас лимит на глубину рекурсивного типа :)

То что я пытался объяснить в этом видео прекрасно расписали в этой статье: https://signia.tldraw.dev/docs/incremental
(спасибо за ссылку @HeWhoSoughtFire)

Логичным вопросом после https://news.1rj.ru/str/xavescor_code/14 будет: а зачем вообще это делать, если всё работает? Нода прекрасно держит обратную совместимость, npm репозиторий иммутабельный. Весь код будет работать в будущем спокойно.

Оно-то так. Но увы, перестанет работать программист. Сейчас поясню:
- Пример первый. egov.kz Электронное правительство Республики Казахстан. Angular@1. Это сверхактивно развивающийся проект, аудитория которого больше 5М пользователей. Но первый ангуляр приводит к тому, что внутреннюю кодовую базу попросту больно поддерживать. Нет ни библиотек, ни программистов на рынке, ни развития тулинга. Я общаюсь с ребятами оттуда и они чуток на стену от боли лезут.
- Пример второй. nextjs.org. Основной фреймворк для реакта. Это активно развивающийся проект с двумя неприятными нюансами. Первый - они спокойно ломают обратную совместимость в патчах(не минорах и тем более не мажорах). Но это фигня, кмк, так как с этим жить можно. Ну, почитаешь issues и найдёшь решение. Страшно другое. На сайте есть документация ТОЛЬКО для последней версии. Отстал на пару мажорных версий? Ну, удачи тебе. Будет весело.
- Пример третий. nestjs.com По сравнению с next - тут чуть получше, есть версионирование доки. Но есть 1 нюанс: перейдите по ссылке на migration guide https://github.com/nestjs/nest/releases/tag/v9.0.0. И тут начнётся веселуха, потому что вы попадёте на migration guide с v9 на v10, а не v8->v9. Справедливости ради, он всё же существует. Но они сломали ссылки.

Все эти 3 примера - это проекты с огроменным финансированием, которые не умеют в примитивные вещи. А если у гигантов не получается соблюдать базовый DX, то что говорить о мелюзге? Там вообще всё плохо будет. По этой причине лучше пытаться держать актуальным проект сейчас, а не пытаться через 5-10 лет обновить это устаревшее поделие. Возможно, его будет проще переписать с нуля.

Релиз новой среды установки+выполнения+тестирования JavaScript!

https://www.youtube.com/watch?v=BsnCpESUEqM

Хайлайты:

- hello world запускается за 4мс
- отлично работает с cjs и mjs
- бесшовный импорт раст файлов
- пишит / читает диск в несколько раз быстрее ноды
- может держать 4x больше RPC чем нода
- 6x больше WS messages чем нода
- большая встроенная стандартная библиотека для фенси DX
- совместимость с большинством node апи, можете попробовать запустить на нем next/nuxt/nest и т.п.
- установка зависимостей в десятки и сотни раз быстрее всех аналогов
- встроенные методы для тестов слизанные с jest
- тесты запускаются и десятки и сотни раз быстрее vitest / jest

Добавлю от себя. Сам JS в Bun работает быстрее чем в Node по моим скромным замерам. Ну SSR по их тестам сильно быстрее. Чекайте https://bun.sh/

Вот вам самый краткий пример что бы продемонстрировать каким местом Bun повернут к разработчику и как заботиться о его DX. Он реактовские компоненты в консоль выводит в виде JSX!
https://bun.sh/guides/ecosystem/react

Сегодня в 15:00 по мск будем сравнивать @tanstack/react-query и @reatom/async.

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

Ссылки на стримы: https://news.1rj.ru/str/siberiacancode/651 (запись будет)

Напомню, этот стрим ляжет в основу моего доклада на холи: https://holyjs.ru/talks/eec3a942bf6846b5ab1b9c68b2b69f8a

Как вам такие стримы, нужно ещё? Пишите в комментарии.

Запись.

Почему Bun быстрее Node.js?

Уважаемый Мирипируни интересуется, почему я ничего не пишу про Bun. Ответ простой — я его ещё не попробовал. Зато на днях мнением поделился не менее уважаемый Маттео Коллина: My thoughts on Bun Давайте дам TL;DR

Несмотря на то, что Джарред Самнер и команда Bun делают потрясающие вещи, Маттео расстроен их заявлениями о совместимости с Node.js, которые не являются правдой в данный момент и приводят к наплыву пользователей в репозитории мейнтейнеров node.js-проектов с жалобами на неработоспособность в Bun.

Несколько причин, почему Bun так хорош такой быстрый:

- У Node.js маленькая команда и мало денег. В этих условиях они больше направлены на улучшение API и закрытие дырок в безопасности. Работы по увеличению производительности не приносят денег, более того, облачные провайдеры (главные источники дохода) не заинтерисованы в том, чтобы производительность росла, так как это означает уменьшение их доходов.

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

- Разработка Node.js более открытая, что позволяет услышать голоса всех, но в то же время замедляет процесс принятия решений

- Bun сейчас не совместим с Pino и Fastify. Команда Bun активно работает над добавлением отсутствующих API и выправлением поведения

- bun install быстрый, но его скорость во многом обеспечена поведением --prefer-offline по-умолчанию. Разница с pnpm --prefer-offline уже совсем не драматическая. Однако то, как добились этой небольшой разницы заслуживает уважения и повторения

Чем же ответит Node.js?

Несколько лет Node.js слишком мало инвестировали в перформанс (да, Маттео, мы заметили :). В прошлом году была собрана команда скорости и теперь это стратегическая инициатива (спасибо, bun!). Node.js будет двигаться вперёд без ломающих изменений. Что уже сделано — можно почитать тут.

Если вы хотите сделать Node.js быстрее, то приходите с пул-реквестами либо помогайте финансово.

Весь тви бурлит bun’ом и уже начали появляться мемчики.

Вот список интересностей которые я нарыл за последние пару дней:

- некоторый сырой код может выполнятся на bun до двух раз быстрее, скорее всего потому что он использует JSC, а нода V8

- установка зависимостей через bun на маке быстрее pnpm за счет использования нативного clonefile, который может быть быстрее симлинков, но НЕ экономит место на диске

- в самом медленном случае установки зависимостей bun совсем немного быстрее, а остальные случаи в абсолютных цифрах и так быстрые почти всегда

- у кого-то тесты на bun выполняются в 12 раз быстрее (60 -> 5 сек), просто подменой скрипта запуска

- bun.lockb нечитабелен

- история еще одной неудачной попытки миграции на bun

- пока что дебажить bun можно только через их вебсайт

- bun не следует спеке в резолвинге микротасок

Куча сил ушло на этот апдейт. Оно же должно быть интегрировано с кешами, логированием и остатальной экосистемой. Должно не ломать, а расширять существующее апи. Ну, вроде, получилось :)

Потыкать тут.

Накидайте, пожалуйста, примеров асинхронных фетчингов, каких-то сложных флоу на других либах - будет интересно переписать и посравнивать.

Да!
https://habr.com/ru/articles/761326/

Касательно последних веб-стандартов.

Мне больше всего CSS не нравится именно из-за отсутствия миксинов. Переиспользовать код через классы не удобно! Я сейчас говорю о продуктовой разработке, а не чистом html, который мы очень редко пишем

1) Чистые классы практически никогда не используются, есть css-modules, из-за которых у нас добавляется лишний импорт (компонентные стили и общие стили, типа center)

2) НЕ СЕМАНТИЧНО, я считаю, описывать именованные стили и их применение в HTML, который должен отвечать за контент. Центрируется или нет элемент должно быть описано в самом CSS, а в HTML эта информация - лишний мусор, там должен быть только индетефикатор элемента, а не набор классов - шорткатов стилей.

3) Продолжая предыдущий пункт, css проще и понятнее, когда неймспейсинг проще. Объявил класс и описывай в нем все что нужно. А бегать в html, запоминать какие классы на элементе, искать их потом в css файле - лишняя ментальная нагрузка.

Разве это не очевидно?)

JSON-viewer’ы

Совсем забыл рассказать как можно смотреть JSON в репле реатома. Самый продвинутый и крутой инспектор - discoveryjs, пример: https://news.1rj.ru/str/reatom_ru_news/222

Были сложности с тем что бы его настроить, но спасибо @rdvornov, со всем помог. Этот инспектор красиво и эффективно отображает древовидные данные и может показывать некоторую аналитику по ним! В репле реатома он открывается при клике на 🔭

Но для лучшего перфа, по умолчанию все логи рисуются в простом и легком @observablehq/inspector (3.95 kB gzip) - тоже рекомендую. Бтв, он не загружает все данные сразу в DOM, только при раскрытии. Но с темной темой у него все плохо (буду рад ПРу в репл реатома).

Подключение, вся логика и стили описаны тут: https://github.com/artalar/reatom/blob/v3/docs/src/components/Repl.astro