👀 а вот этого я не ожидал 👀

Если что это все еще старая спека 2019 года. С тех пор она больше не обновлялась

Но вот что запланировал он с ней делать мне крайне любопытно.

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

TS СТАЛ BLAZING FAST

Пока все в экстазе носятся с ускорение TS в 10 раз, я призываю вас подумать о выборе golang. Да, авторы объяснили свой выбор и я полностью уважаю его с технической и менеджерской точки зрения (минимизация расходов, скорость перехода, уменьшение кол-ва потенциальных проблем и тд). И в целом перф круто, все дела! Но я немного попробую посмотреть негативную сторону, чтобы уравновесить настроения.

DISCLAIMER! Я полностью уважаю экспертизу специалистов из Microsoft и верю, что они делали выбор исходя из технических аспектов, как они неоднократно заявляли. Я лишь пытаюсь заглянуть на разные стороны медали и приглашаю к обсуждению

Я не просто так зачеркнул BLAZING в заголовке. Думаю все догадались о чем пойдет речь: почему не Rust. И я не хочу сейчас обсуждать что из них круче. Будем обсуждать это исключительно с точки зрения влияния на экосистему.

1. Экосистема туллинга на языках
Rust уже состоялся как основной язык для туллинга в мире JS. Я уже писал об этом в старом посте. И количество этого туллинга с момента поста только росло. А почему это важно? Так как таким образом было бы гораздо проще делать интеграции с уже кучей туллинга написанного на Rust, возможно даже появилось бы какое-то переиспользование. Относительно gonalg: битву за туллинг он проиграл во многом по причине ниже. С другой стороны если не брать экосистему туллинга, а JS/TS разработчиков. То full-stack связка с go очень даже популярна и возможно сподвигнет появлению большего количества контрибьютеров

2. Производительность в WASM.
Да, перф Go в WASM это тема отдельного обсуждения. По ссылке вы найдете еще ссылки на другие обсуждения и так можете погружаться в тему сколько хотите. Но факт есть факт - go не самый производительный в контексте WASM. А зачем нам это? Плейграунды, web-container-ы и прочие ситуации когда у нас все гоняется в браузере не супер редки. Другая сторона: вполне возможно это станет мотивацией наконец-то довести перф Go в WASM до должного уровня или Microsoft инвестирует в инструмент который сможет это реализовать лучше(например в tinygo или другую альтернативу). Потыкать WASM GO (НЕОФИЦИАЛЬНАЯ ВЕРСИЯ) можно тут [исходники] (там выводится скорость компиляции в браузере)

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

В остальном же радуемся и ждем TypeScript 7 (версия с которой Go версия станет основной).

Хочу похвалить команду Lynx(если вы как-то пропустили новость, то это "Убийцы" ReactNative/NativeScript), ведь кроме документации они еще реализовали целую спеку! Я почитал ее и написана она весьма хорошо, как минимум обильное описание каждого термина есть, а это уже много стоит. Хорошо приправлена ссылками на отдельные части, язык более чем понятный и сама спека не такая уж и длинная. Алгоритмы в нем описаны весьма интересно, через под-заголовки и описание действия в них(стейджи), прям алгоритмов как в спеке ES или HTML там нет.

Наверное это тот случай, когда спека имеет смысл и скорее объясняет чем отпугивает. Круто, что такое реализовали

PS. готовлю еще один пост про Lynx на vue-канале относительно текущих дел со Vue + Lynx

#подкаст

Разбираемся, кто, зачем и как обновляет JS.

Присоединяйтесь к обсуждению пропозалов — уже через час!

Новый выпуск «Тяжелого утра» в 11:00:
— на YouTube
— в VK Видео

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

Но сейчас у меня новость о выгрузке системного промпта у v0 (генератор приложений от Vercel). Что это такое и почему это важно?
Казалось бы многие текущие AI-инструменты это просто обертки над LLM-ками, но вся магия скрывается за тем как формируется запрос и какой системный промпт за этим стоит. Так как именно в системном промпте часто спрятано как будет мыслить AI. Поэтому же нельзя сказать что Cursor условно и Windsurf одинаковы, просто разные UI-ки, нет, там спрятано куда больше разной работы от индексирования кодовой базы, до как раз системного промпта, который как выяснилось у Windsurf крайне забавный. До этого интересности нашли у системного промпта новой сервиса с LLM Grok3

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

А удавалось ли вам вытянуть что-то интересное из AI-ки или сервиса с которым вы работаете? Пробовали ли вообще заняться своеобразным реверс-инжинирингом AI-сервиса?

Первый крупный проект на Rolldown кажется уже существует. А недавно был создан репозиторий vite-rolldown в котором уже тестируют их вместе. Значит относительно скоро мы сможем увидеть новую эпоху в мире Vite и сборщиков для веба в целом

Ссылка на оригинальный пост в X

Интересный вопрос. А есть ли у нас уже что-то подобное? Ответ смешной но есть... около-монадические промисы. Попробуем написать это на них
new Promise(Iterator.from([1,2,3,4,5,6]))
.then((x) => x.filter((num) => num % 2))
.then((x) => x.map((num) => num * 2 + 1))
.then((x) => x.drop(1))
.then((x) => zip(x, [1,2,3])) // никаких проблем
Работает? Работает. Эффект схожий с пайплайном? Схожий. А что по типизации? Все шикарно с типизацией. Тогда в чем минусы? А минусы как раз в монадичности, мы не можем просто так извлечь значение из контекста, нам нужно его вытянуть а для этого нужен await и сами понимаете как это сильно окрашивает функции. Но это не единственный минус. Также такой код сложнее оптимизировать, так как движку нужно по сути каждый такой стейдж развернуть и заинлайнить (что будет сделано очень крайне маловероятно). В то время как pipeline operator может оптимизироваться компилятором на раз, так как это по сути 1 выражение.

Это я все к чему? Да все к тому, что мы реально заждались возможности которая перевернет мир построения API и уберет потенциальные проблемы как необходимость захламления методами в объектах, уродливые вложения и имена констант которые никому не нужны. Жаль и очень жаль, что уже 3 года 0 движений по нему... хотя каждое собрание tc39 я вижу одни и те же сообщения "- а что там по пайлпайну? - а ничего, мы его в этот раз не обсуждаем"

Pipeline operator in JS.

Самая ожидаемая фича от JavaScript уже в течении многих лет, но продвижение которой по стейджам tc39 предложений уже не происходит очень давно.
Почему она так ожидаема и почему она так долго идет? Для начала разберемся с проблематикой

Вот у нас есть получение некоторых данных на основе, очень частый кейс который приходится писать в работе с данными:
const = Object.fromEntries(Object.entries(someData).filter(([,value]) => !!value).map(([key, value]) => [key, value * 2]))
Строка длинная и естественно ее можно разбить на строки, пытаться отформатировать или разбить на переменные (имена которые порой ой как больно придумывать, потому что нам они НЕ ИНТЕРЕСНЫ, нам нужен лишь результат, а не 10 промежуточных значений). Форматирование строки тоже не даст много полезных результатов, так как тут есть некоторая вложенность. Что же предлагает нам пропозал?
const = Object.entries(someData) |> %.filter(([,value]) => !!value) |> %.map(([key, value]) => [key, value * 2])) |> Object.fromEntries(%)
Строка стала чуть длиннее, зато нам теперь совершенно очевиден порядок для разбиения
const = Object.entries(someData)
|> %.filter(([,value]) => !!value)
|> %.map(([key, value]) => [key, value * 2]))
|> Object.fromEntries(%)
Теперь суть кода считается последовательно и без запоминания каких-то контекстов и это совсем базовый сценарий. Магия происходит когда мы задумываемся как мы раньше пытались сделать вот такой "поток" мысли: правильно, чейнингом. Функция возвращала объект в котором лежат методы которые вновь возвращают объект и так далее. Но мы с вами упирались в один момент: методы уже должны быть заложены в объекте. Те возьмем обработку массива
Object.entries(someData)
.filter(([,value]) => !!value)
.map(([key, value]) => [key, value * 2]))
// и вот следующего оператора нет в Array, зато он есть в Object
Object.groupBy(/*тут должен был быть наш массив*/)
Те как только нужно было использовать метод которого нет в объекте, то вся магия тут же ломалась и мы вынуждены были либо делать уродливое вложение, либо создавать сущность которая нам не интересна (единственная ее задача переложить прошлое значение как аргумент)

И вот тут приходит на помощь pipe
Object.entries(someData)
|> %.filter(([,value]) => !!value)
|> %.map(([key, value]) => [key, value * 2]))
|> Object.groupBy(%, grouper)
|> logAndReturn(%)
|> sendToClient(%)
Как мы видим в пайплайне ему не интересно чейнинг у нас или наши кастомные методы, он позволяет расширять возможности при использовании не пытаясь расширить прототипы для удобства. Особенно сильно это заметно на таких возможностях, которые подсаживают на чейнинг, как например Iterator Helpers
Iterator.from([1,2,3,4,5,6])
.filter((num) => num % 2)
.map((num) => num * 2 + 1)
.drop(1) // откидываем первое число
zip() // а вот zip в нем нет, думайте сами как сюда такую функцию вкорячить
Суть думаю ясна, что такие API очень завязаны только на встроенные возможности и юзать что-то свое с ними тем самым расширяя API не слишком и приятно. И вот такие API мог бы полностью раскрыть Pipeline Operator так как он может в 1 цепочку объединять разнородное API.

Одна из больших диллем для меня была как часто сюда писать и какой контент тут генерировать.
Первое что стоит признать: у меня очень разношерстная аудитория, тут и реактеры с гигантским стажем и вьюшники и даже те кто фронту отношения вообще не имеют и многие другие. И я очень этим ОЧЕНЬ доволен, не хочу чтобы этот канал замыкался только на Vue или фронтенде.

И тут следующий момент: Я бы не хотел отвлекать всю массу людей частыми и мало полезными новостями. Этот канал будет оставаться для новостей и крупных постов с разборами или анализами от меня. Но часто у меня бывает желание постить что-то в сиюминутном порыве или просто небольшие интересности и для этого я выделю отдельный канал Vueist. На 80%+ он будет сосредоточен только на Vue контенте или чего-то что его окружает. И количество постов там будет кратно большим чем тут.

Такое разделение позволит мне оставить этот канал как нейтральную территорию полезную или интересную для широких масс, а Vueist сделать своим уголком для мира Vue чего от меня уже ждут давно и просят.

PS. Я уже давно мечтал сделать этот шаг (канал Vueist создан еще в 2023 и просто ждал своего момента). Раньше весь мой контент это был распределено по куче сообществ в которых я состоял, теперь же оно будет централизовано в одном месте


Vueist: обучающие материалы по Vue, советы, новости и прочий шитпостинг от влюбленного во Vue 💚 всем сердцем человека

VDOM был ошибкой!

Сейчас все чаще виден тренд по уходу от VDOM на фронте во имя оптимизации.
Angular перешел на Ivy и стал редким представителем инкрементального дома
Svelte и Solid изначально отказались от VDOM в пользу генерации мутаций на основе работы сигналов.
Vue тоже активно работает над Vapor режимом в котором тоже не будет VDOM.

Но на собесах по React и не только, все еще на вопрос про VDOM, говорят что VDOM нужен для оптимизации работы с DOM, а тут выясняется, что фреймворки избавляются от VDOM по этой же причине. Так в чем же дело?

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

Но с самого начала шли разговоры, что вот это виртуальное представление отжирает память и делает лишнюю работу, почему бы не собирать изменения и просто не применять их без необходимости пробегаться по деревьям? Отличная идея, только вот сигналов которые были бы достаточно для этого развиты долгое время не было. И главное: нужен хороший КОМПИЛЯТОР. VDOM очень легко конструировать из однотипных кусочков как createElement / h. Однако если мы хотим отказаться от VDOM, то нам нужно компилировать гораздо более сложные конструкции. Те мы должны суметь распутать клубок связей и сформировать из них наиболее оптимальные пути доступа к DOM. И для небольших даже приложений количество реактивных связей между сигналами становится очень много, поэтому сигналы должны быть достаточно оптимизированы для работы с развесистыми графами.

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

Забавный момент. При разработке Vue Vapor первые версии Vapor были по производительности ниже нежели чем VDOM версии, поэтому в 2024 мы и видели несколько раундов оптимизации реактивности и как итог на Dev сборках Vapor смог обогнать даже Svelte и Solid!

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

P.S. Спасибо за 2000 подписок!

P.P.S. Отдельным пунктом можно конечно обозначить $mol в котором нет ни VDOM ни супер оптимизирующего компилятора, но там и шаблонов нет в привычном смысле, поэтому оставим его за скобками :D

Как и говорил, то я буду появляться на других стримах. Один из таких стримы от Holy.js с новостными и не только выпусками

Обсуждаем State of React и другие JS-новости — уже через час.

Новый выпуск «Тяжелого утра» в 11:00:
— на YouTube
— в VK Видео

И так, время идет, а я все жду когда мой доклад с Holy.js выложат :D
В итоге все затянулось и данный пост отложился слишком сильно. Поэтому подведу запоздалые итоге 2024 и этим вдохну жизнь в канал (да-да настолько запоздалые).

Если кратко 2024 для меня стал годом конференций. Побыл в разных ролях.
Был и спикером по началу: UfaDevConf-раза, Holy.js 2-раза, Стачка, Msk Vue.js, Omsk DevFest ну и внутренние выступления в компании
К середине года попробовал для себя уже на уровне эксперта секции(Стачка), ведущего секции(UfaDevConf)
И главным подарком под Новый Год для меня стало, что меня взяли в программный комитет Holy.js и уже весь 2025 я погружен в процесс уже организации конференций, от чего получаю большое удовольствие (прямо сейчас идет работа над 4-мя(!) мероприятиями).

Другой вектор это телеграм и сообщества. Например, достижение 2024-ого года стал администратором Vue.js сообщества. И вступил в большое количество сообществ фронтендеров, где меня сейчас легко встретить. Считаю в этом плане год успешным.

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

Что можно ожидать в 2025:
1) Оживление канала с постами, идей накопилось очень много и технических и софтовых.
2) Стримов пока можно не ждать (стримы будут после переезда в квартиру попросторнее, жду ключи на нее). Однако я переодически буду появляться как участник на чужих стримах, если меня пригласят (siberiacancode, kirjs и тд)
3) Ждать от меня новостей по моим продуктам (можно ожидать от меня в 2025 году курс по Vue.js. Да-да официальный анонс, и да, он будет полностью бесплатным и доступным для всех)
4) Новая группа бесплатного интенсива по Vue.js длиной в 2 недели как и в прошлом году (скорее всего летом)
5) Новые выступления на митапах и конференциях

Год выдался отличным, и новый, надеюсь, будет еще лучше!