Node.js vs Deno vs Bun

У нас есть SSR-сервис для перегона реакт компонентов в html. Он написан на ноде.

Ради интереса решили попробовать его завести на deno и на bun: вдруг они покажут себя лучше.

В первом подходе начали с малого: просто завели текущий код на альтернативных рантаймах. Мы не заменяли пакеты ноды на пакеты его собратьев и ничего не адаптировали специально под конкретный рантайм.

Просто взяли установили текущие зависимости через deno и bun (благо оба умеют работать как с пакетами из npm, так и с пакетами ноды). Попробовали запустить.

Deno

С толчка не завелся. Кидал ошибки. Их было несколько и они последовательно всплывали после починки предыдущей. В конце концов завелся.

Bun

Сразу завелся. Но в некоторых кейсах всплывала ошибка, которую не сразу заметили. Поправили. В итоге тоже заработал.

Сравнение на проде

У нас есть несколько инстансов SSR-сервиса. Выбрали из них три для эксперимента:
- первый - остался на ноде;
- второй - на дино;
- третий - на бане.

Все три инстанса работают на одинаковом железе и нагрузка на них идёт одинаковая.

Результаты

Нода и дино оказались в нашем кейсе примерно равны по скорости ответа. Дино даже на несколько ms был быстрее.

Бан оказался в два раза медленней своих конкурентов.

Что дальше

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

P.S. если у вас есть опыт сравнения разных серверных js-рантаймов – делитесь кейсами в комментах. Будет интересно почитать.

Stop turning everything into arrays (and do less work instead)

Простая статья с основным посылом прямо в заголовке - хватит превращать все в массивы, можно делать проще и эффективнее. Если коротко - базовые цепочки типа arr.map().filter().slice().map() для большой нагрузки (или больших массивов) эффективнее заменить на итераторы items.values().filter().map().take().toArray().

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

Если у вас массив из 5000 элементов и вы сделаете arr.map(fn).map(fn2).filter(fn3).slice(0,10) то, несмотря на то, что вам нужно всего 10 элементов, движок обработает перед slice все 5000 элементов дважды в map. Т.е. в массивной цепочке операции выполняются друг за другом для всего потока данных.

Аналогичная цепочка в итераторах выглядит так items.values().map(fn1).map(fn2).filter(fn3).take(10).toArray(). Эта цепочка выполняет каждую операцию друг за другом для каждого элемента в отдельности и цепочка завершится ровно тогда, когда take(10) наберет 10 элементов после filter.

Еще в статье приводится юзкейс с загрузкой пагинированных данных через итераторы

async function* fetchPages() {
  let page = 1;
  while (true) {
    const res = await fetch(`/api/items?page=${page++}`);
    if (!res.ok) return;
    yield* await res.json();
  }
}

const firstTen = await fetchPages()
  .filter(isValid)
  .take(10)
  .toArray();

Выглядит достаточно лаконично

Когда не следует использовать итераторы:
1. Нужен доступ по индексу (arr[10])
2. Алгоритм изменяет массив
3. Мало данных - в этом случае проще будет обойтись методами массива

Достаточно простая заметка, но напоминает о возможностях итераторов в современном JS

https://allthingssmitty.com/2026/01/12/stop-turning-everything-into-arrays-and-do-less-work-instead/

#development #javascript #array #iterators

War story: the hardest bug I ever debugged

Наверняка вы сталкивались с багами, которые настолько неуловимые, что аж бесит. Только кажется, что нашёл причину, как оказывается, что это тупик. Статья как раз про такую историю с очень интересным багом.

В команде Google Docs каждую неделю происходит триаж багов и они распределяются между разработчиками. Автору статьи достался баг — иногда у пользователя в Google Docs появляется большой отступ, который мешает ему работать с документом, и это устраняется только перезагрузкой страницы.

Были обращения пользователей, но не прям массовые. Из обращений пользователей вида "баг происходит когда я делаю Х" ни одно не повторилось. Вообще не было уверенности, что этот баг вообще происходит. Но если он происходит — это точно блокер. Единственное, что известно — на баг жалуются пользователи Google Chrome.

Автор запустил дев-версию Google Docs и начал по-разному играться с UI. Ну, насколько это возможно для Google Docs — копировал, вставлял, игрался с форматированием, переносами и т. д. и т. п. В один момент он решил сделать скрипт, который создаёт 50 страниц текста и меняет жирность всего текста 100 раз. И оказалось, что баг повторяется между 10 и 40 итерациями! Постоянная смена жирности текста в итоге крашила что-то в приложении и появлялся огромный отступ.

Был найден способ воспроизвести баг, но всё ещё непонятно, где он конкретно появляется, т. к. движок рендера Google Docs был достаточно особенным — в те годы весь текст под меню позиционировался через абсолюты. Чтобы это работало быстро, большинство расчётов кешировалось. По стек-трейсу удалось понять, что кто-то записывает в кеш неправильное значение, которое затем крешит приложение.

Автор был более опытен в бекенде, поэтому позвал более опытного в UI коллегу разбираться с багом.

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

В такие моменты начинаешь проверять самые безумные теории. Было решено залогировать вывод Math.abs() — вероятность ничтожно мала, но мало ли. Но оказалось, что Math.abs() для отрицательного числа может вернуть то же самое отрицательное число. ВАУ!

Благо ребята работали в Google и просто зашли к чувакам, которые разрабатывают браузер. Там им ответили чисто по корпоративному: «Да, это баг, но технически он не наш — это вам в команду V8 движка». Оказалось, что баг уже пофикшен и выйдет в следующем релизе. Ребята оптимизировали работу Math.abs() в движке и допустили небольшую ошибку, приводящую к тому, что Math.abs() возвращал не то значение.

Достаточно интересная история с неожиданным источником проблемы. Всё-таки мы всегда доверяем встроенным в движок методам (особенно если это Math.abs(), где и ошибиться-то негде). Но вот бывает и такое.

https://www.clientserver.dev/p/war-story-the-hardest-bug-i-ever

#development #javascript #bug #googleDocs

Дайджест за 2026-01-26 - 2026-01-30

Mitigating Denial-of-Service Vulnerability from Unrecoverable Stack Space Exhaustion for React, Next.js, and APM Users
В node.js недавно исправили уязвимость в async_hooks, которая позволяла крашнуть node.js сервис. Node.js некорректно обрабатывал ошибку переполнения стека во время обработки async_hooks и просто завершал процесс, вместо кидания исключения. async_hooks достаточно популярный модуль, который используется в React Server Components, Next.js, Datadog, OpenTelemetry и других популярных проектах.

Stop turning everything into arrays (and do less work instead)
Простая статья с основным посылом прямо в заголовке - хватит превращать все в массивы, можно делать проще и эффективнее. Если коротко - базовые цепочки типа arr.map().filter().slice().map() для большой нагрузки (или больших массивов) эффективнее заменить на итераторы items.values().filter().map().take().toArray().

War story: the hardest bug I ever debugged
Наверняка вы сталкивались с багами, которые настолько неуловимые, что аж бесит. Только кажется, что нашёл причину, как оказывается, что это тупик. Статья как раз про такую историю с очень интересным багом.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

7 practical animations tips

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

Разобраны следующие примеры:
- Изменение scale на кнопке при взаимодействии
- Анимацию появления чего-либо (например тултипов) следует делать не со scale(0), а с хотя бы scale(0.9)
- Если у вас в интерфейсе есть задержка перед появлением тултипов, то для рядом расположенных элементов задержка имеет смысл только при первом появлении тултипа, а дальше тултип можно показывать сразу
- Выбирайте правильную кривую анимации. Для своих кейсов можно сделать кастомную
- Анимация появления должна быть направлена от точки, где пользователь взаимодействовал с интерфейсом (этот пример в статье заметен только с включением замедления анимации)
- Анимации должны быть быстрыми. Быстрые анимации дают ощущение быстрого продукта
- Если нужно сделать анимацию изменения состояния, а состояния разные - используйте blur.

Лучше зайти в статью и глянуть разницу анимаций своими глазами

https://emilkowal.ski/ui/7-practical-animation-tips

#development #javascript #css #animations

Yarn 6 Preview

Я уже давно не следил за развитием Yarn, а тут оказывается, они уже готовят шестую версию (пятую пока еще, правда, не выпустили). Собственно, основная большая фича Yarn 6 - это реализация пакетного менеджера на Rust

Работы по переписыванию уже ведутся какое-то время и текущая версия реализации уже работает в разы быстрее.

Кроме переписывания на Rust (и, следовательно, более быстрой работы) обещают:
- Ленивую установку пакетов - это когда вы делаете Yarn run, а Yarn сам поймет: надо ли установить какие-то пакеты или нет
- Yarn Switch - свой менеджер менеджеров пакетов. Вы в package.json указываете, какой пакетный менеджер используется в проекте, а Yarn Switch занимается установкой и запуском этого менеджера пакетов

https://yarn6.netlify.app/blog/2026-01-28-yarn-6-preview/

#development #javascript #yarn #rust

gogcli

gogcli - инструмент для терминала, позволяющий работать с сервисами Google: почта, диск, документы, календарь и другое. Очень удобно, просто и хорошо интегрируется с AI-агентами

https://gogcli.sh/

#development #google #commandLine #tool

Here's a 1 GB memory reduction for very long Claude Code sessions

Начал снова читать Твиттер, а там оказывается интересное показывают! Например, однострочный фикс утечки памяти в Claude Code, которая спасает гигабайты оперативки.


Код с утечкой памяти: () => controller.abort()
Фикс: controller.abort.bind(controller)

Создание стрелочной функции ведет к созданию замыкания на скоуп функции, в которой создается стрелочная функция, что мешает GC собрать фактически ненужную память.

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

https://x.com/jarredsumner/status/2017825694731145388

#development #javascript #performance #claudeCode #memoryLeak

The Too Early Breakpoint

Слишком ранний брэкпоинт - ситуация, когда интерфейс перестраивается в мобильную сетку слишком рано. Например, когда сайт оптимизируют для десктоп и iPhone и при открытии сайта на планшете или в половинном окне браузера показывается несуразная мобильная верстка с картинкой на весь экран.

Автор показывает на примере крупных новостных изданий как это выглядит и упоминает кейсы, для которых это реально проблема:
- Планшеты и телефоны-раскладушки (сам пользуюсь раскладушкой и периодически на сайтах действительно происходит что-то несуразное)
- Окно браузера открытое в split-screen или не на весь монитор
- Превью ссылок в разных приложениях (например в Telegram)

Решение очевидное: делать чуть больше вариантов сеток, чем две, если вы хотите чтобы ваш сайт выглядел хорошо на любом устройстве.

https://ishadeed.com/article/too-early-breakpoint/

#development #css #responsive

Дайджест за 2026-02-02 - 2026-02-13

7 practical animations tips
7 практических советов по созданию анимаций. Статья с гифками и интерактивными примерами, на которых прямо показывается, как с помощью небольших улучшений сделать анимации в интерфейсе приятнее

Yarn 6 Preview
Я уже давно не следил за развитием Yarn, а тут оказывается, они уже готовят шестую версию (пятую пока еще, правда, не выпустили). Собственно, основная большая фича Yarn 6 - это реализация пакетного менеджера на Rust

gogcli
gogcli - инструмент для терминала, позволяющий работать с сервисами Google: почта, диск, документы, календарь и другое. Очень удобно, просто и хорошо интегрируется с AI-агентами

Here's a 1 GB memory reduction for very long Claude Code sessions
Начал снова читать Твиттер, а там оказывается интересное показывают! Например, однострочный фикс утечки памяти в Claude Code, которая спасает гигабайты оперативки.

The Too Early Breakpoint
Слишком ранний брэкпоинт - ситуация, когда интерфейс перестраивается в мобильную сетку слишком рано. Например, когда сайт оптимизируют для десктоп и iPhone и при открытии сайта на планшете или в половинном окне браузера показывается несуразная мобильная верстка с картинкой на весь экран.

Немного про свой ИИ-кодинг

В прошлый раз я рассказывал, что пробую писать ТЗ вместе с ИИ-агентом, а потом смотрю как агент все это реализует. Недавно понял, что писать ТЗ мне крайне лень и решил попробовать новые подходы.

Недавно, читая посты в твиттере и чье-то интервью или заметку (по-моему Мартина Фаулера), я нашел интересную мысль: многие бест-практисы разработки, которые продвигали Мартин Фаулер, Кент Бек, Боб Мартин и другие, хорошо ложатся на ИИ-кодинг.

Многие из этих практик о том, чтобы сделать разработку итеративной, небольшими изолированными шагами и на каждом шаге иметь небольшую когнитивную нагрузку.

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

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

Я в своем пет-проекте решил попробовать часть этих практик для кодинга. Сразу оговорюсь, что я не так много развлекаюсь с ИИ-кодингом т.к. на работе я в основном занимаюсь всяким менеджментом, а пет-проектом занимаюсь в фоне.

№1 TDD
TDD, как паттерн разработки, прекрасно работает для ИИ-кодинга:
- Пиши тест, убедись что он падает
- Напиши реализацию, убедись что тест проходит
- Рефактори

TDD позволяет хотя бы минимально быть уверенным в том, что результат ИИ-кодинга вообще работает.

Что для этого нужно:
- Правило или скилл, которые скажут агенту а) как надо разрабатывать по TDD; б) запускать тесты и не завершать задачу, пока все тесты не будут зелеными
- Какие-то примеры, какие тесты считать хорошими и как вообще надо тестировать

Но, конечно, в современном фронтенде не без проблем. Однажды ИИ написал бесконечный ререндер компонента через useEffect, что привело к бесконечному запуску тестов. Когда я указал ему, что тесты бегают в бесконечном цикле и это надо исправить. Я его оставил, но через какое-то время обнаружил, что макбук начал лагать. Оказывается, ИИ решил проверять исправления следующим образом: запускать тесты в фоне и, если через 15 секунд процесс не завершился - значит не починил. Так он и запустил в фоне 6+ vitest с бесконечным циклом внутри react.

№2 BDD
BDD оказался очень удобным фреймворком для ИИ-кодинга в пет-проекте. Как это работает: я описываю юзер стори, которые надо реализовать. Затем мы с ИИ описываем их в feature-файле через gherkin (формат сценария Given-When-Then)

Таким образом я получаю файл со сценариями, которые описывают как работает приложение. Этот же файл служит источником для компонентных тестов cypress и некоторых юнит-тестов

№3 Строгое разделение ответственности
Тут много всяких паттернов: SOLID, CQS, View-Controller и так далее.

Суть в том, чтобы строго следовать бест-практисам по делению ответственности. В текущем сетапе у меня настроены такие правила хорошего дизайна:
- В *.types.ts описывается интерфейс сущности с JSDoc. Интерфейса должно быть достаточно для использования сущности потребителем, т.е. не надо сканировать всю реализацию для ее использования
- React-компоненты жестко делятся на View (не достают ничего из DI, не используют стор) и на Container. Все состояния View компонентов загоняются в storybook. Также view-компоненты удобно тестировать в cypress
- Логика приложения находится в store. API на изменение стора - это экшны. У фичи может быть несколько сторов для разных кейсов. Например в текущей фиче, которую щас делаю, 3 стора: UI конфигурации, доменная модель настроек, применение фичи на канбан-доске.

При планировании работ прошу ИИ-агента следовать этим правила и в плане описывать:
- mermaid-диаграмму с сущностями и их связями
- файловую структуру будущей фичи

Поделитесь в комментах фидбеком или тем, какие вы практики нашли полезными в ИИ-кодинге - буду учиться :)





#development #javascript #bdd #cypress #note

npmx.dev: a fast, modern browser for the npm registry.

npmx.dev - альтернатива сайту npmjs.com. Как и npmjs, позволяет искать и исследовать пакеты в npm, но также имеет несколько дополнительных фичей: поддержка темной темы, возможность провалиться в исходники пакета, показ используемой модульной системы, показ размера пакета и тд

Выглядит интересно

https://github.com/npmx-dev/npmx.dev

#development #javascript #npm

A Broken Heart - Allen Pike

Еще одна история в стиле "один из самых безумных багов, с которым я сталкивался". Allen Pike рассказывает о баге, из-за которого страница загружалась в 100 раз дольше.

В чем суть. Однажды Allen увидел, что сайт, который обычно грузится моментально, стал виснуть при загрузке. В таком случае одна из первых реакций - недовольное "опять кто-то навертел в рендере React'а". Allen послал Claude Code найти и пофиксить проблемы с рендером React'а. Claude Code нашел, пофиксил и... ничего не изменилось

Allen'у пришлось самому погружаться в традиционные инструменты для дебага. Это принесло свои плоды - было обнаружено, что Safari тратит секунды, потребляя 90+% CPU M1 MAX на перестроение лэйаута.

Далее Allen взял еще один традиционный метод поиска проблем - бинарный поиск через удаление функционала.
Метод, я надеюсь, знакомый каждому:
1. Выбираем код, в котором, как мы думаем, скрыт корень проблемы. На ранних итерациях следует выбирать большие объемы кода
2. Удаляем код.
3. Если проблема исчезла - значит проблема где-то в этой части. Восстанавливаем код, goto 1 выбирать часть кода внутри текущей
4. Если проблема не исчезла - значит проблема где-то еще. Goto 1 выбирать новый кусок кода

Метод не идеальный, но сам периодически им пользуюсь, чтобы локализовать проблему. Как правило - заменяю импорты, компоненты, функции на заглушки и смотрю на эффект. Если помогло - значит то, что я заменил, содержит проблему.

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

Claude Code успешно обнаружил проблему и она оказалась в emoji ❤️. Что, весьма неожиданно. Allen (да и я тоже) часто использует emoji в интерфейсах, потому что они узнаваемы, их легко встраивать в интерфейсы (по сути как обычный текст) и они работают везде.

В чем корень проблемы. В 2008 году Apple добавили в шрифты цвета, чтобы поддержать emoji. Сделали это весьма костыльно - буквально зашили png в шрифты. Чуть позже рабочая группа сформировала удобный стандарт для цветов в шрифтах. В приложении использовался отдельный шрифт для emoji, чтобы добиться консистентности рендеринга emoji на разных платформах. Этот шрифт опирался на гугловый формат COLRv1, который ускорял загрузку шрифта, но фолбечился до svg в некоторых браузерах. Safari оказался как раз этим "некоторым" браузером. Собственно рендер svg и приводил к дикому пересчету лэйаута.

Такой вот баг.

Какие уроки можно вынести:
- Нельзя доверять даже рендерингу шрифтов. Шок.
- Старые добрые инструменты для поиска проблем все еще работают. Не шок. Если вы все еще не прокачались до черного пояса в девтулах - никогда не поздно начать это делать.
- ИИ-агенты позволяют автоматизировать поиск проблем

https://allenpike.com/2026/a-broken-heart

#development #safari #bug #emoji #cloudCode

Дайджест за 2026-02-16 - 2026-02-20

Немного про свой ИИ-кодинг
В прошлый раз я рассказывал, что пробую писать ТЗ вместе с ИИ-агентом, а потом смотрю как агент все это реализует. Недавно понял, что писать ТЗ мне крайне лень и решил попробовать новые подходы.

npmx.dev: a fast, modern browser for the npm registry.
npmx.dev - альтернатива сайту npmjs.com. Как и npmjs, позволяет искать и исследовать пакеты в npm, но также имеет несколько дополнительных фичей: поддержка темной темы, возможность провалиться в исходники пакета, показ используемой модульной системы, показ размера пакета и тд

A Broken Heart - Allen Pike
Еще одна история в стиле "один из самых безумных багов, с которым я сталкивался". Allen Pike рассказывает о баге, из-за которого страница загружалась в 100 раз дольше.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам или друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Announcing TypeScript 6.0 Beta

Анонсировали бету TypeScript 6.0. Версия, которая должна стать переходной между текущей реализацией TS на JS и будущей реализацией на Go в 7.0. Версия 6.0 будет нести в себе изменения, упрощающие миграцию на будущую 7.0 версию, но также и некоторые полезные изменения.

Первое интересное исправление. Если у вас есть Generic-функция, которая вычисляет аргумент generic'а по переданному аргументу функции внутри, то если функция является стрелочной, то все будет работать корректно, а если это метод объекта - то будет ошибка. Шок контент. Пример ниже

declare function callIt<T>(obj: {
    produce: (x: number) => T,
    consume: (y: T) => void,
}): void;

// Works, no issues.
callIt({
    produce: (x: number) => x * 2,
    consume: y => y.toFixed(),
});

callIt({
    consume(y) { return y.toFixed(); },
    // error: 'y' is of type 'unknown'.

    produce(x: number) { return x * 2; },
});

Это связано с тем, как TS обрабатывает this у функций. Хотя ни там, ни там он не используется, во втором случае у функции есть свой this и это как-то влияет на тайп-чекер. Теперь это исправили

Завезли флаг --stableTypeOrdering для упрощения миграции до 7 версии. Этот флаг, как следует из названия, стабилизирует порядок типов в скомпилированных декларациях. Оказывается, есть кейс, когда заведение переменной, которая никак не связана с функцией, меняет порядок типов в декларации функции. Пример

Вот так компилируется, что функция возвращает 100 или 500

// Input: some-file.ts
export function foo(condition: boolean) {
    return condition ? 100 : 500;
}

// Output: some-file.d.ts - 100 | 500
export declare function foo(condition: boolean): 100 | 500;

Но если добавить перед этим переменную, то возвращаемое функцией значение начнет компилироваться как 500 или 100

// Input: some-file.ts
const x = 500;
export function foo(condition: boolean) {
    return condition ? 100 : 500;
}

// Output: some-file.d.ts - 500 | 100
export declare function foo(condition: boolean): 500 | 100;

Внимание, флаг может замедлить тайп чекинг на 25%.

Также в TypeScript 6 вошли:
- target es2025
- Поддержка Temporal
- Поддержка новых методов в Map: getOrInsert, getOrInsertComputed
- Поддержка RegExp.escape
- lib dom.iterable внесли просто в dom. Теперь достаточно подключить только dom чтобы итерироваться по document.querySelectorAll

Ломающие изменения
На основе анализа конфигов пользователей, часть опций стали дефолтными, часть требует явного указания.
- Необходимо указывать types. По дефолту теперь будет []. Для включения старого поведения можно установить ["*"]
- rootDir по дефолту теперь ..
- strict: true по дефолту
- module: "esnext" по дефолту
- target: "es2025" по дефолту. В целом политика такая, что дефолтным будет считаться текущий стабильный ES.
- noUncheckedSideEffectImports: true по дефолту
- libReplacement: false по дефолту
- target: es5 задепрекейтили. Теперь минимальный таргет - es2015 (более известный как es6)
- --moduleResolution node задепрекейтили. Те кто использовали эту опцию, должны переехать или на nodenext или на bundler
- Удалена поддержка --module amd, umd, systemjs
- baseUrl больше не поддерживается, используйте paths
- --outFile задепрекейтили, используйте бандлеры вместо TS для вывода результата в 1 файл
- Задепрекейтили старый синтаксис для модулей. Это, конечно, может выстрелить т.к. могут быть third-party type declarations, где такой синтаксис используется

// ❌
module Foo {
    export const bar = 10;
}

// ✅ 
namespace Foo {
    export const bar = 10;
}

declare module "some-module" {
    export function doSomething(): void;
}

- Также задепрекейтили ассерты импортов в пользу with

// ❌ 
import blob from "./blahb.json" asserts { type: "json" }

// ✅ 
import blob from "./blahb.json" with { type: "json" }

В общем, готовимся к переезду на 7.0. Как минимум морально. Как максимум - заменяем все устаревшее на современное.


https://devblogs.microsoft.com/typescript/announcing-typescript-6-0-beta/

#development #typescript #javascript #breaking

Building Bulletproof React Components

Один из разработчиков Vercel написал короткий гайд, как делать "пуленепробиваемые" компоненты. Суть в том, что большинство компонентов пишутся под happy path — они работают, пока не сталкиваются с реальным миром: SSR, гидрация, несколько инстансов, конкурентный рендеринг, порталы и т.д.

В статье с примерами кода разбираются 10 аспектов, которые нужно учитывать:
1. Server-Proof — не используйте localStorage или другие браузерные API напрямую в рендере, выносите в useEffect
2. Hydration-Proof — код может работать по разному на сервере и в браузере. Популярные проблемы - таймзоны, адаптив через код, темы. Учитывайте это.
3. Instance-Proof — учитывайте, что компонент может быть инстансирован несколько раз на странице. Например, используйте useId() вместо захардкоженных id
4. Concurrent-Proof — несколько компонентов (или несколько параллельных запросов к серверному рендеру) могут привести к дубликации запросов в API или БД. Добавляйте кеширование и дедубликацию запросов.
5. Composition-Proof — React.cloneElement может не сработать для серверных компонентов. Для кейсов передачи данных при композиции используйте контекст
6. Portal-Proof — вместо window используйте ref.current?.ownerDocument.defaultView для обработчиков событий, иначе они не будут работать в iframe и порталах
7. Transition-Proof — для анимаций с <ViewTransition> в React 19 оборачивайте изменения стейта в startTransition()
8. Activity-Proof — если компонент инжектит глобальные стили, используйте media="not all" чтобы отключать их когда компонент скрыт через <Activity>
9. Leak-Proof — используйте taintUniqueValue чтобы предотвратить случайную утечку токенов и секретов из серверных компонентов в клиентские компоненты. Это экспериментальная фича, которая позволяет развалить рендер с кастомной ошибкой, если клиентский код попробует достучаться до запрещенного значения
10. Future-Proof — не используйте useMemo как хранилку данных. useMemo создан для улучшения перформанса. Если вам нужно хранить данные - используйте useState.

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


https://shud.in/thoughts/build-bulletproof-react-components

#development #react #ssr #hydration #components #performance #security #quality

Components Will Kill Pages

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

Как пользователи работают с сайтами сейчас: есть пользовательский путь для закрытия какой-то потребности, есть навигация, есть формы. Сайты соревнуются друг с другом как бы сделать пользовательский путь удобнее (или наоборот, сложнее в некоторых кейсах)

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

Автор предполагает, что как класс может появиться новое направление - предоставление компонентов для ИИ-чатов. Т.е. я, как разработчик, отдаю AI схему компонентов и как они работают, а AI отдает пользователю прямо в чате интерфейс, созданный из компонентов.

Звучит интересно. Например, я работаю в сфере бронирования отелей и было бы круто, если бы мы отдавали AI удобные виджеты для просмотра вариантов отелей, а пользователь взаимодействовал с ними прямо в чате (смотрел фотки, отзывы, варианты заселения), вместо того чтобы считывать все то же самое из текстового полотна или доверяясь AI.

В таком будущем API из компонентов будет таким же важным, как и текущие сайты, реализующие пользовательские сценарии.

https://bitsandbytes.dev/posts/components-will-kill-pages

#development #frontend #ai #components

Дайджест за 2026-02-23 - 2026-02-27

Announcing TypeScript 6.0 Beta
Анонсировали бету TypeScript 6.0. Версия, которая должна стать переходной между текущей реализацией TS на JS и будущей реализацией на Go в 7.0. Версия 6.0 будет нести в себе изменения, упрощающие миграцию на будущую 7.0 версию, но также и некоторые полезные изменения.

Building Bulletproof React Components
Один из разработчиков Vercel написал короткий гайд, как делать "пуленепробиваемые" компоненты. Суть в том, что большинство компонентов пишутся под happy path — они работают, пока не сталкиваются с реальным миром: SSR, гидрация, несколько инстансов, конкурентный рендеринг, порталы и т.д.

Components Will Kill Pages
Размышления о том, как AI может поменять подход к сайтам и приложениям. Основная мысль: в мире, где пользователи всё чаще получают ответы через ChatGPT и подобные интерфейсы, традиционная навигация по страницам уходит в прошлое.

wc3ui - библиотека компонентов в стиле wc3

Битва UI-китов закончена. Наконец-то нашелся ультимативный ui-kit, предоставляющий компоненты как в warcraft III. Гонка ui-kit'ов потеряла смысл с таким игроком.

Выглядит круто. Даже захотелось внедрить в какой-то пет-проект и снова перепройти кампании wc3. Надеюсь есть в канале люди, у которых сводит олд-скулы от такого.

https://wc3ui.banteg.xyz

#development #javascript #uikit #wc3

@github-ui/storybook-addon-performance-panel

Аддон для storybook, который собирает и отображает в интерфейсе storybook метрики производительности компонентов. Новый Must-Have среди сторибучных аддонов для всех проектов. Должен помогать находить критичные проблемы рендера на ранних этапах и в изолированной среде.

https://github.com/github/storybook-addon-performance-panel

#development #javascript #storybook #performance