Node.js 22 Features You Should Be Using

Nodejs 22 стал LTS, а значит пора обновляться и смотреть, чего же там нового принесли в Nodejs.

Основные изменения:
- WebSocket клиент теперь стабильная фича, можно смело переходить на него
- fetch теперь также стабильная фича, можно смело переходить на встроенный fetch
- улучшили модель разрешений. Можно лочить использование файловой системы или env-переменных

node --experimental-permission \
     --allow-fs-read=/app/data \
     --allow-env=NODE_ENV index.js

- Стабилизировали использование require из ES-модулей. Это должно упростить жизнь на время перехода экосистемы к ES-модулям
- Встроенный тест-раннер теперь поддерживает кастомные репортеры, сбор тестового покрытия и мокирование таймеров
- Поддержка AbortController в нативных API


https://nodesource.com/blog/nodejs-22-features

#development #javascript #nodejs #releaseNotes

Отзыв на обучение в Стратоплане

Снова отзыв на обучение в стратоплане. Коротко о моем статусе обучения: курс уже закончился, а последнюю половину я смотрю в записи и отстал на 4 модуля (по сути 4 месяца). Из плюсов - вместо 15 часов обучения на модуль (3 дня по 5 часов), запись просматривается где-то за 2 часа. Из минусов: вам придется пережить еще 3 отзыва на обучение т.к. в целом материал норм и я его буду досматривать :) . Последний просмотренный модуль, на основе которого я пишу этот пост, был про бизнес-процессы.

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

Если вы все еще читаете - остановитесь на минуточку и подумайте, а как вы, ваши близкие и ваши коллеги описываете процессы? Ну например, пришел к вам стажер или джун - как вы ему опишите процесс разработки в вашей команде?

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

На обучении нам показали 3 способа описания бизнес-процессов (хотя все способы подходят для любых процессов): BPMN, IDEF0, EPC (ох уж эти любители аббревиатур).

Интересно в них то, что они концентрируются на разных аспектах процессов.
Например, IDEF0, будет близка тем, кто размышляет о процессах как о производстве чего-либо и, наверное, будет удобна многим программистам.

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

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

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

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

На примере онбординга джуна.

Если вам надо объяснить, кто за что отвечает в процессе разработки - лучше использовать что-то типа BPMN - выделить свимлейны под заказчика, разработчика, тестировщика, тимлида и объяснять процесс через их действия и ответственность.

Если вам надо объяснить, как происходит процесс сборку и деплоя приложения, то возможно подойдет IDEF0, где вы опишете основные функции и с чем они работают: сборка делает из кода приложение, раннер запускает тесты на собранном приложении - если они падают, то останавливаем процесс, создаем отчет и призывать инженеров и так далее

Если вам надо объяснить, как цепочка событий приводит к какому-то результату, то подходит EPC. Например, с помощью EPC можно описать разбор входящих обращений от пользователей или стейкхолдеров. Например, техподдержка принесла баг с прода, QA верицириует реальный ли это баг, если да - создается задача, если нет - дорабатывается база знаний техподдержки и так далее.

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



#note #stratoplan

Дайджест за 2025-10-20 - 2025-10-24


——

На этой неделе я в отпуске, поэтому постов не обещаю. Буду знакомиться с Нижним Новгородом.

——-


Bun 1.3
Вышел Bun 1.3. Основные фишки: улучшили поддержку фулстэк-разработки, встроили MySQL и Redis клиенты, улучшили работу с Cookie и роутингом, сделали улучшения для монорепо

Теперь обо всем по порядку

React Compiler v1.0
Вышел React Compiler v1.0. Его можно поставить и, по заверениям разработчиков, забыть о ручном менеджменте useMemo, useCallback, React.memo в 99% кейсах - теперь эту работу должен забрать на себя React Compiler. В остальных 1% кейсов можно заняться ручной оптимизацией для достижения лучших результатов.



Oxlint JS Plugins Preview
Oxlint представили API для плагинов на JS. При этом есть 2 версии API - частично совместимое с Eslint, что позволяет подключить eslint-правила в oxlint без доп приседаний, и oxlint API, которое позволяет делать более производительные правила.


Node.js 22 Features You Should Be Using
Nodejs 22 стал LTS, а значит пора обновляться и смотреть, чего же там нового принесли в Nodejs.


Отзыв на обучение в Стратоплане
Снова отзыв на обучение в стратоплане. Коротко о моем статусе обучения: курс уже закончился, а последнюю половину я смотрю в записи и отстал на 4 модуля (по сути 4 месяца). Из плюсов - вместо 15 часов обучения на модуль (3 дня по 5 часов), запись просматривается где-то за 2 часа. Из минусов: вам придется пережить еще 3 отзыва на обучение т.к. в целом материал норм и я его буду досматривать :) . Последний просмотренный модуль, на основе которого я пишу этот пост, был про бизнес-процессы.

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

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

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

Как AI помогает мне в разработке браузерного расширения

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

Немного контекста про пет-проект - это браузерное расширение для jira, которое делает работу в jira чуточку удобнее. Оно было создано другими людьми, а я там изредка добавляю новые фичи. Занимаюсь я этим проектом крайне мало времени и AI очень сильно упрощает разработку расширения в контексте ограниченного времени.

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

Кто пробовал вручную переводить код с JS на TS, тот знает, насколько это тяжело. То есть, ну с одной стороны - сиди да понемногу описывай поля, которые нашел. С другой, на практике не получается это делать прям продуктивно - работа идет мучительно медленно. Здесь мне на помощь пришел github copilot, который можно запустить прям в веб-морде гитхаба и дать ему задачу, а он сделает изменения и опубликует ветку. Copilot переписал весь код на ts, а я потом его ревьюил. Результат вышел более менее хорошим: были ошибки, часть из которых я заметил во время ревью, а часть пошла в прод и была исправлена после. Я не уверен, что я сам справился бы лучше. Однако уверен, что если бы это был крафтовый ручной рефакторинг - он занял бы кратно больше времени.

Вывод, который я сделал из этого кейса: AI хорошо справляется с техническими рефакторингами. В частности, хорошо переписывает код на ts.

Второй интересный кейс связан с разработкой новой фичи в расширении. Я делал фичу, которая должна отрабатывать на jira-задачах, которые подходят под условия пользователя. В jira как раз существует язык для написания запросов на поиск задач - JQL. Он не супер гибкий, но а) он простой для изучения б) его знают все, кто работает с jira. Например Team = MyTeamName and labels not in (A,B,C).

JQL идеально подходит для фичи, но есть проблема: удобных готовых решений не существует (или я их не нашел).

Писать самому такое решение - задача решаемая, но сложная. Я решил попробовать дать эту задачу cursor'у. И знаете - вышло очень хорошо! Cursor сделал трех-ступенчатое решение:
- Написал tokenizer, который разбирает поисковую строку на токены
- Написал парсер, который проходит по токенам и возвращает условие в структурированном формате или ошибку, если поисковая строка невалидна
- Написал функцию, которая проверяет, подходит ли задача под JQL-фильтр

Конечно, обошлось не без проблем. Например, при правках этого кода cursor запутывался (я, честно говоря, тоже запутывался). Чтобы сделать ошибки человекочитаемыми, пришлось самому разбираться в том, как работает токенайзер и парсер.

Флоу доработки JQL парсера был построен на test-first подходе:
- Сначала cursor сделал первую реализацию
- Затем я попросил написать его юнит-тесты на эту реализацию
- Если нужны правки - дописываю тест и прошу поправить код, чтобы тесты проходили

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

Бонусом, после написания кода, я попросил AI все задокументировать + сделать виджет для тестирования JQL-парсера, который визуально показывает, как работает условие и почему оно срабатывает или не срабатывает для определенной задачи (скрин приложу в коменты)

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

Ссылки с пруфами:
- JS => TS
- вот код jql-парсера




#note #ai #jiraHelper

Исходники веб-версии app store

Чуваки из эпла, которые разрабатывают веб версию апстора, случайно сделали сорсмапы кода открытыми на проде. И теперь исходный код апстора стал общественным достоянием - энтузиасты скачали его и залили на гитхаб. Репозиторий уже прикрыли, но вы легок можете найти другие репозитории поиском по гитхабу по строке apps.apple.com. Скорее всего уже можно посмотреть и не на гитхабе.

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

Я посмотрел краем глаза, что увидел:
- Используется svelte и scss
- Не смотря на использование svelte, встречается импеативная работа с DOM (создание элементов, навешивание классов)
- Иногда встречаются достаточно объемные комментарии к работе кода - респект людям, описывающие нюансы работы решения в комментариях
- У каждой уважающей себя команды непременно должен быть написан свой логгер. Чтобы было уж совсем по-взрослому - нужен базовый логгер и его наследник - ConsoleLogger. У эпла все серьезно - логгеры с наследованием
- Используется нативный dialog для модалок + полифилл. Также респект за использование нативного dialog

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

https://github.com/rxliuli/apps.apple.com

#development #javascript #svelte #appStore #apple

Дайджест за 2025-11-05 - 2025-11-06

Как AI помогает мне в разработке браузерного расширения
На прошлой неделе я отдыхал в Нижнем Новгороде без устройств для публикации контеннта, поэтому постов не было. Отпуск закончился - пора снова контент пилить. Давайте расскажу про пару кейсов использования AI в пет-проекте.

Исходники веб-версии app store
Чуваки из эпла, которые разрабатывают веб версию апстора, случайно сделали сорсмапы кода открытыми на проде. И теперь исходный код апстора стал общественным достоянием - энтузиасты скачали его и залили на гитхаб. Репозиторий уже прикрыли, но вы легок можете найти другие репозитории поиском по гитхабу по строке apps.apple.com. Скорее всего уже можно посмотреть и не на гитхабе.


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

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

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl

Пост в блоге Мартина Фаулера где автор пытается разобраться в новомодном в AI-тусовке термине Spec-Driven-Development, рассматривая его имплементацию разными инструментами

Spec Driven Development, это когда спека пишется перед кодом и является источником правды, а AI по спеке реализует код.

Можно выделить 3 основных варианта имплементации spec driven development:
- spec first - сначала пишется спека, затем по ней пишется код. После реализации кода спека не нужна
- spec anchored - пишется спека, затем по ней спишется код. Затем спека используется в будущих доработках фичи
- spec as source - спека - это главный файл, источник истины. Человек взаимодействует только со спекой, оставляя задачу реализации AI

Тут надо бы понять, а что вообще такое спека. Как обычно в IT далеко не все термины хорошо определены. Спека - один из этих терминов. Автор дает следующее определение: "Структурированный артефакт, или набор артефактов, описывающих поведение и функциональность на естественном языке".

Автор статьи попробовала 3 инструмента для SDD подхода: Kiro, Spec-kit (от гитхаба), Tessl (пока в бете).

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

№1: Инструменты в основном spec-fisrt, т.е. спека пишется под задачу, а после реализации кода она уже и не нужна

№2: Сам подход (и в частности инструменты) плохо работает для небольших задач.
Там, где достаточно сделать быстрый фикс с AI-агентом прямо в коде, SDD-инструменты генерируют тонны избыточной документации. Например, для решения небольшой проблемы будут описаны все критерии приемки и несколько юзер сторей.
Инструменты должны адаптировать свой флоу под сложность задач

№3: Приходиться ревьюить много markdown-документов.
А т.к. LLM переплюнет по словоблудию любого человека, то документы получаютяс большие. Ревьюить их - сложно. Ревьюить код намного проще.

№4: Появляется ложное чувство контроля из-за обилия документации, чеклистов, планов и правил. А по-факту ИИ просто игнорирует часть инструкций.

№5: SDD можно рассматривать как развитие идей MDD (Model Driven Development).
При применении MDD вы описываете модель доменной области на каком-то DSL, а затем имлементируете эту модель в коде. Подход, ожидаемо, не взлетел - никому не охота писать модели, которые проще сразу описывать в коде. Но применение LLM убирает рутину из процесса, оставляя саму суть - человек описывает систему на естественном языке, а LLM до-описывает все скучное.

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

https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html

#development #martinFowler #specificationDrivenDevelopment #ai

Применяем что-то типа Specification Driven Development на практике

В предыдущем посте написал про Spec Driven Development и упомянул, что вдохновился подходоми решил его попробовать.

Напомню: у меня есть пет-проект, который помогает мне (и не только мне) в работе и на развитие которого я выделяю очень мало времени (буквально считанные часы в месяц) - chrome extension подсвечивающий разное в jira. Фичи я в нем делаю строго с ИИ т.к. писать крафтовый код - долго. Обычно закидываю задачу в агента и иду заниматься своими делами

У меня описаны в проекте какие-то правила для курсора, поэтому задачи я описываю в пару предложений.

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

В рамках моего проекта мне надо описывать UI-элементы и их поведение, поэтому спека крутится вокруг компонентов.

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

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

По итогу применять практику мне прям понравилось.

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

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

Во вторых, просто приятное ощущение когда вместо промпта пишешь "я поправил спеку, поправь реализацию".

По итогу все получилось хорошо. Я писал спеку - ИИ писал код. Если было что-то не так - я правил спеку и писал свой волшебный промпт "я поправил спеку, поправь реализацию". Единственные вещи, которые делал сам - боролся с CSS и с обработкой событий в инпутов (в jira есть неприятная особенность - там кастомные клавиатурные хоткеи, поэтому если упустить всплытие событий, то пользователь случайно может сделать что-то не то в jira)

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

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

Какие уроки извлек:
- Сначала думай (пиши спеку), потом делай - все еще рабочая стратегия
- SDD - выглядит жизнеспособно, по крайней мере если вы делаете пет-проект chrome extension
- ИИ хорошо пишет доку по спеке+коду


Ссылка на спеку, по которой сдеплан код



#development #specificationDrivenDevelopment #ai #note #javascipt #jiraHelper

ESLint Plugin for Baseline JavaScript

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

https://baselinejs.vercel.app/

#development #javascript #eslint #baseline

Codefest 16: Call for Papers

Codefest открыл сбор заявок на доклады на 2026 год. Сбор заявок продлится до 1 марта. Если хотите выступить - отправляйте заявки. Конференция ламповая, хожу на нее в качестве и спикера и слушателя уже лет 10, почти без перерывов.

Конференция - крупнейшая в Сибири, куда приезжают куча спикеров и участников со всей России. Хотя, будем честны, по моим ощущениям основа состава конференции - ребята из Сибири.

Хорошие доклады, куча стендов компании, кайфовые афтепати - это все Codefest

С точки зрения спикера, подготовка сделана хорошо:
- Готовите тему (или несколько) и верхнеуровнево обрисовываете, что вы вообще можете рассказать по этой теме
- На предварительном созвоне программный комитет скажет, как можно усилить доклад или развернуть в другую сторону
- Если вас принимают в программу, то программный комитет поможет подготовиться: устроит прогоны, даст хорошую обратную связь

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



https://16.codefest.ru/themes#program

#note #codefest #callForPaper

Error chaining in JavaScript: cleaner debugging with Error.cause

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

Решаемая проблема
Когда в коде возникает ошибка, а вы ее заворачиваете во что-то более читаемое, то вы теряете корневой источник ошибки. Как это делается без Error.cause

try {
  JSON.parse('{ bad json }');
} catch (err) {
  throw new Error('Something went wrong: ' + err.message);
}

Здесь мы сохраняем исходную ошибку только через упоминание в error.message и не сохраняем стак-трейсы

Решение: Error.cause
Стандартизировали возможность передать исходную ошибку как причину новой ошибки, что позволяет сохранять весь контекст на любом уровне

try {
  try {
    JSON.parse('{ bad json }');
  } catch (err) {
    throw new Error('Something went wrong', { cause: err });
  }
} catch (err) {
  console.error(err.stack);
  console.error('Caused by:', err.cause.stack);
}

В выводе содержатся оба стактрейса

Error: Something went wrong
    at ...
Caused by: SyntaxError: Unexpected token b in JSON at position 2
    at JSON.parse (<anonymous>)
    at ...

Это и есть вся фича. В целом так делали и до стандартизации этого подхода, но хорошо что стандартизировали

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

Например, у вас в иерархии 3 уровня: ошибка сети => ошибка доступа к БД => ошибка сервиса

class ConnectionTimeoutError extends Error {}
class DatabaseError extends Error {}
class ServiceUnavailableError extends Error {}

try {
  try {
    try {
      throw new ConnectionTimeoutError('DB connection timed out');
    } catch (networkErr) {
      throw new DatabaseError('Failed to connect to database', { cause: networkErr });
    }
  } catch (dbErr) {
    throw new ServiceUnavailableError('Unable to save user data', { cause: dbErr });
  }
} catch (finalErr) {
  logErrorChain(finalErr);
}

Можно реализовать logErrorChain следующим образом

function logErrorChain(err, level = 0) {
  if (!err) return;
  console.error(' '.repeat(level * 2) + `${err.name}: ${err.message}`);

  if (err.cause instanceof Error) {
    logErrorChain(err.cause, level + 1);
  } else if (err.cause) {
    console.error(' '.repeat((level + 1) * 2) + String(err.cause));
  }
}

Тогда мы увидим вот такой вывод

ServiceUnavailableError: Unable to save user data
  DatabaseError: Failed to connect to database
    ConnectionTimeoutError: DB connection timed out

https://allthingssmitty.com/2025/11/10/error-chaining-in-javascript-cleaner-debugging-with-error-cause/

#development #javascript #error

Дайджест за 2025-11-17 - 2025-11-21

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl
Пост в блоге Мартина Фаулера где автор пытается разобраться в новомодном в AI-тусовке термине Spec-Driven-Development, рассматривая его имплементацию разными инструментами


Применяем что-то типа Specification Driven Development на практике
В предыдущем посте написал про Spec Driven Development и упомянул, что вдохновился подходоми решил его попробовать.


ESLint Plugin for Baseline JavaScript
Eslint Plugin для проверки использования слишком нового синтаксиса и фичей веба. Вы выбираете baseline threshold, а плагин контролирует, чтобы вы его придерживались


Codefest 16: Call for Papers
Codefest открыл сбор заявок на доклады на 2026 год. Сбор заявок продлится до 1 марта. Если хотите выступить - отправляйте заявки. Конференция ламповая, хожу на нее в качестве и спикера и слушателя уже лет 10, почти без перерывов.


Error chaining in JavaScript: cleaner debugging with Error.cause
Как-то я пропустил момент, когда в JS стандартизировали иерархию ошибок. А она уже давно доступна во всех браузерах. Статья посвящена этой фиче и по шагам рассказывает особенности и кейсы для использования.

JavaScript engines zoo

Сколько JS-движков вы можете вспомнить с ходу? Скорее всего большинство назовет 3: v8 в хроме, что-то в firefox и что-то в safari. Более прошаренные чуваки вспомнят еще штуки 3-4 специфичных. А их оказывается десятки. На сайте собрана сравнительная таблица существующих (и существовавших) JS-движок с верхнеуровневым сравнением движков друг с другом

https://ivankra.github.io/javascript-zoo/

#development #javascript #jsEngines

Valdi

Snapchat заопенсорсил свой фреймворк для кросс-платформенной разработки UI. Пока супер бета (beta-0.0.1). Код пишется на jsx, но затем компилируется в нативный код. Snapchat использует фреймворк уже 8 лет.

Пример кода

import { Component } from 'valdi_core/src/Component';

class HelloWorld extends Component {
  onRender() {
    const message = 'Hello World! 👻';
    <view backgroundColor='#FFFC00' padding={30}>
      <label color='black' value={message} />
    </view>;
  }
}

Что поддерживается:
- Комиляция в android, ios, desktop (не понял что конкретно они имеют в виду под десктопом)
- JSX + TypeScript
- Hot Reloading
- Дебаг в VSCode
- Супер оптимизированный UI на выходе (по крайней мере заявляется)

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

https://github.com/Snapchat/Valdi

#development #javascript #snapchat #framework #crossPlatform

Дайджест за 2025-11-24 - 2025-11-25

JavaScript engines zoo
Сколько JS-движков вы можете вспомнить с ходу? Скорее всего большинство назовет 3: v8 в хроме, что-то в firefox и что-то в safari. Более прошаренные чуваки вспомнят еще штуки 3-4 специфичных. А их оказывается десятки. На сайте собрана сравнительная таблица существующих (и существовавших) JS-движок с верхнеуровневым сравнением движков друг с другом


Valdi
Snapchat заопенсорсил свой фреймворк для кросс-платформенной разработки UI. Пока супер бета (beta-0.0.1). Код пишется на jsx, но затем компилируется в нативный код. Snapchat использует фреймворк уже 8 лет.


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

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

TSDiagram is an online tool that helps you draft diagrams quickly by using TypeScript

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

https://tsdiagram.com

#development #javascript #typescript #diagram

The Performance Inequality Gap, 2026

Огромнейший отчет, описывающий тренды пользования сайтами. Если коротко: размер JS-бандлов растет намного быстрее, чем мощность устройства среднего пользователя. За последние 5 лет средний размер загружаемого js вырос на треть, в то время как прочие форматы данных (кроме видео контента), выросли на скромные 5-10%.

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

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

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

https://infrequently.org/2025/11/performance-inequality-gap-2026/

#development #javascript #web #performance #research

93% Faster Next.js in (your) Kubernetes

Очень интересная статья про перформанс nodejs веб-серверов. Особенно она интересна для тех, кто поддерживает работающие nodejs приложения на проде. В статье рассказывается, как можно ускорить nextjs (и вообще любой другой nodejs-фреймворк) на 93% перейдя с pm2 или одноядерных подов в кубе на watt

Если вы хотите себе серверный рендеринг или крутить какой-то сервер на nodejs, то вам надо придумать как вы будете оркестрировать запросы. Есть 2 популярных паттерна:

1. Горизонтальное масштабирование с кубом - деплоим в куб столько подов приложения, сколько нам нужно, и выделяем каждому одно ядро
2. Делаем более жирные поды с воркерами, который оркестрирует pm2

У второго подхода проблема в том, что pm2 на коммуникациях с воркерами теряет много времени и цпу ресурса.

У первого подхода проблема в том, что k8s ничего не знает о загрузке конкретных подов и роутит запросы round-robin'ом, т.е. поочередно в разные поды закидывает запросы. Как следствие, может возникнуть ситация, что одному поду достаются простые запросы, а второй - умирает на обработке тяжелых запросов.

Хотелось бы получить нулевые издержки на коммуникацию с воркерами и при балансировке учитывать текущее состояние воркеров. Именно это позволяет сделать Watt.

Watt, как я понял, аналог pm2, но с одной особенностью - он умеет использовать фичу линукса, которая позволяет переиспользовать сокеты между несколькими процессами. Это, в свою очередь, позволяет убрать "налог" на коммуникацию между мастером и воркерами - воркеры сами подключаются к сокету (еще и могут переиспользовать кеши, если я правильно понял)

Автор приводит бенчмарк k8s 6 pods vs PM2 3x2 workers vs Watt 3x2 workers . Результаты следующие:


Single-CPU pods (6×1)
• Throughput: 972 req/s
• Success Rate: 93.7%
• Median Latency: 155 ms
• P95 Latency: 1,000 ms

PM2 (3×2 workers)
• Throughput: 910 req/s
• Success Rate: 91.9%
• Median Latency: 182 ms
• P95 Latency: 1,260 ms

Watt (3×2 workers)
• Throughput: 997 req/s
• Success Rate: 99.8%
• Median Latency: 11.6 ms
• P95 Latency: 235 ms

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

https://blog.platformatic.dev/93-faster-nextjs-in-your-kubernetes

#development #javascript #nextjs #nodejs #kubernetes #pm2 #watt

Use Nemo - Custom Directives Library

React вводит директивы use client и use server в рамках серверных компонентов, чтобы немного по-разному компилить код. Если вы когда-либо хотели быть как React и придумать свои директивы, то библиотека use-nemo для вас! Она позволяет описывать свои директивы, которые встраиваются в сборку кода в vite. Хотите сделать свою директиву use somewhat, которая будет переопределять что-то в коде - велкам.

Как это работает

Шаг 1: придумывайте директиву и описываете ее в коде

// src/components/MyComponent.tsx
"use nemo";

export function MyComponent() {
  return <div>My component</div>;
}

Шаг 2: описываете обработчик директивы и регистрируете ее

// src/directives/useMyDirective.ts
import { directiveRegistry, injectCode } from "use-nemo";
import type { DirectiveHandler } from "use-nemo";

const myDirective: DirectiveHandler = {
  name: "nemo", // This is the name used in "use nemo"
  handler({ code, id, directiveName }) {
    // Transform the code as needed
    return injectCode(code, () => {
      console.log("🐟");
    });
  },
};

directiveRegistry.register(myDirective);

Шаг 3. Подключаете плагин в vite

// vite.config.ts
import customDirectives from "use-nemo";

export default defineConfig({
  plugins: [customDirectives(), react()],
});

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

Однако, наверняка можно придумать что-то полезное. Если у вас есть какая-то интересная идея для кастомных директив - поделитесь в комментах. Интересно было бы услышать

https://github.com/Ademking/use-nemo

#development #javascript #vite

less than 100ms E-commerce: Instant loads with Speculation Rules API

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

Пока есть 2 типа предзагрузки ресурсов - prefetch и prerender.

Prefetch - это предзагрузка ресурса. Например, можно предзагрузить html, js, css или любой другой ресурс, который можно загрузить fetch'ом

Preprender - это не просто предзагрузка ресурса, но и его исполнение. Например, можно сделать prerender следующей страницы. В этом случае браузер сделает запрос страницы и начнет ее исполнять, как если бы она была открыта в соседней вкладке - загрузит все ресурсы, запустит JS, начнет делать запросы. При переходе на следующую страницу переход для пользователя будет моментальным.

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

Но с точки зрения техники конечно есть нюансы:
- Аналитика или АБ-тесты могут работать некорректно т.к. теперь нельзя считать, что если JS-исполнился, значит пользователь перешел на страницу. Кроме аналитики могут быть и другие особенности - например, мы можем ожидать что пользователь выбрал фильтры на предыдущей странице и они сохранены в localstorage или cookie, а пользователь их еще не выбрал т.к. это пререндер а не настоящий переход
- Если пользователь не перейдет на страницу, то зря потратили ресурсы при серверном рендере и на обработку запросов. А они могут стоить денег
- Пока не представляю как дебажить проблемы в случае prerender'а. Можно ли поставить брекпоинт в коде, удобно ли смотреть сетевые запросы?

Эти директивы можно устанавливать в html, а можно из JS. При грамотном использовании они могут значительно улучшить UX.

https://blog.sentry.io/less-than-100ms-e-commerce-instant-loads-with-speculation-rules-api/

#development #javascript #performance #sentry #speculationRules