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

Vue. Крайне любопытные результаты, но вполне предсказуемые. Итак, мы можем видеть что в 22-ом график у Vue был очень даже грустный. Резко скануло вниз и кол-во использований и удволетворенность. Причина же тут крайне простая: Миграция Vue2 -> Vue3 это та еще боль. Куча людей разочаровалось в фреймворке. Однако время идет и народ все-таки начал получать плюсы от всех изменений Vue3. Количество адептов значительно возросло, фреймворк окреп и готов к серьезным вызовам. Это и можно видеть на графике с скачком и по кол-ву использований и по кол-ву положительных отзывов. Жду и в новом году от него положительной динамики, так как в инфопространстве наблюдаю лишь большое кол-во положительных отзывов о нем. Но ложка дегтя есть: после обновления TS5 вначале год колбасило багами WebStorm, а в 2023 после обновление Volar до v2 и пользователей VSC. И вот тут порой звучат отзывы крайне разочаровывающие. Будет любопытно посмотреть как же это скажется.

Svelte. Ну у него все хорошо. Потихоньку набирает жирку в виде использований, слегка подрастерял в "уровне счастья", но этот показатель достаточно велик, чтобы пока на это внимания не обращать. На момент конца 2023, насколько я помню. руны только только были анонсированы, поэтому влияние предстоящего Svelte5 в опросе маловероятно. А вот в новом году очень будет любопытно посмотреть. Общее настроение от изменений Svelte5 можно описать как: неоднозначное. Что-то улучшили, что-то испортили. Запаха react от Svelte сильно возросло (возможно это связано с тем, что в прошлом году Рич Харрис, создатель Svelte, был нанят компанией Vercel, чьим главным продуктом является Next.js, aka главный способ использования React на данный момент).

Solid. Что-то выкинуло его из ответов. Ничего особо интересного по нему сказать нельзя. Слышали о нем людей побольше, "уровень састья" стал поменьше. Никаких громких апдейтов от него нет, предсказать что-то трудно. Из хоть каких-то факторов: у него вышел мета-фреймворк SolidStart, но отзывов о нем я пока не слышал. Самолет пока не взлеает и шансов что это изменится в новом году нет. Что в целом не делает этот фреймворк хуже и я все еще его могу рекомендовать как "React здорового человека".

Отдельно отмечу здесь Astro, хоть это и не Frontend-фреймворк. Народ с него просто тащится. Шикарные результаты и темпы развития. Пожелаем удачи. Крайне рекомендую с ним всем ознакомиться.

Что же касается общего впечатления по Frontend-фреймворкам то он начиная с 2018-ого показывает нисходящий тренд. Удивляться тоже нечему: народ все рвется на сервер к SSR/SSG/ISR и тп, а это резко увлечивает сложность разработке в конечном итоге. Фреймворки сильно усложняются. Народ плохо поспевает за "новомодными трендами". А главный локомотив фронтенд-фреймворков выдает очень спорные решения, что еще больше повышает градус недовольства. Ожидаю в новом году еще большего снижения этого показателя.

Кратко об инструментах тестирования: есть Jest, а есть Vitest. И у того и у того все замечательно. Для E2E все шикарно у playwright. Еще у нас есть Storybook проблема которого: отсутствие хоть каких-то конкурентов.

Отдельно отмечу, что в опросе прекрасно себя показал pnpm. Вполне заслуженно. Быстрый, простой. А что еще надо для счастья? Если ищете замену yarn/npm, то это самое оно и для монореп тоже неплохо подходит.

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

Раз уж забегался я по конфам в последнее время, то хотел бы и подсказать классную ссылку с IT-мероприятиями Networkly Google Calendar,
Тут IT-ивенты всех категорий по РФ. Если вам нужны ивенты по категориям, то тут лучше идти на главный сайт.

Для других стран скорее всего есть свои календари и будет круто если вы ими поделитесь.
Но из международных приличных пока нашел только dev.events.

Но для чего вообще эти мероприятия? У каждого будет свой ответ. Для меня это главным образом
1) Мотивация довести реализацию до конца чтобы с ней выступить
2) Способ расшарить знания на публику
3) Способ вживую пообщаться с невероятным количеством очень крутых ребят
4) Ну и конечно же: хорошо провести время

Мои субъективные советы по конфам:
1) Если у докладов есть запись, то посмотреть ее вы сможете и дома. Если есть в планах занятия поинтереснее на конфе, займитесь ими
2) Составьте маршрут посещения докладов и знакомств с людьми заранее, так проще будет перемещаться и находить время на какие-то активности
3) Очень большая часть знаний и живого общения происходит именно на afterparty в неформальной обстановке, советую приберегать на него силы

PS. уже на этой неделе и следующей проведу серию стримов по различным темам. Так что можете накидывать идей

Такс, косякнул с стримами на прошлой неделе. Виноват перед вами.

Были некоторые обстоятельства рабочие и семейные. Но план по контенту не отменяется
Сейчас и в субботу совместный стрим c siberiacancode

В воскресение (4 августа) будет стрим с перезапуском по истории фронтенда
А во вторник (7ого) будет стрим посвященный разбору V8

Всем привет.
Сегодняшний стрим по истории фронтенда перенес на завтра.

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

Итого основной контент завтра.
А сегодня общаемся, делюсь новостями и поясняю за разработку
https://www.twitch.tv/izede

Какое-то время меня не было на этом канале. И я все ждал с чем вернуться в новом году к вам. И решил начать не со своих новостей (а они будут!)

Но сейчас я к вам пришел со стримом от моего друга siberiacancode и сегодня он выступит с докладом который крайне для него важен: Дмитрий Бабин - Вам не нужен state менеджер
Обсудим когда нужны и не нужны стейт менеджеры в мире реакта, думаю будет интересно, хотя уверен, что многие будут не согласны с его видением, так что не стесняйтесь задавать ему вопросы и докапываться :D

для тех кому комфортнее на твиче: https://www.twitch.tv/siberiacancode

Приятного просмотра и ждите новостей от меня уже в скором времени!

И так, время идет, а я все жду когда мой доклад с 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) Новые выступления на митапах и конференциях

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

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

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

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

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

в чем принципиальное отличие сигналов от любой другой штуки с подпиской на изменения (например zustand, RxJS, mobx etc..)?

Отличный вопрос. Ведь все это разные способы реализовать реактивность. В чем же отличительная особенность сигналов? Для этого разберем остальные подходы

RxJS:
Основная суть в потоках данных и управлением этим потоком. Те трансформация этих данных и перераспределения между потоками. Это отлично ложится в концепции асинхронных потоков данных и событий. В противовес сигналы сосредотачиваются не на потоках данных, а на самом состоянии и отношениях между сигналами: разделение на состояния и вычисляемые состояния. RxJS это про push-based reactivity, те при отправке значения его цель уведомить всех подписчиков о новом событии и так пойдет по всем каналам, что может значительно сказываться на перфе при наивной работе с ними, так как вычисления не отсекаются по умолчанию. Сигналы же будут сосредоточены на ОБНОВЛЕНИИ состояния и оптимизации распространения обновления: если присвоить одинаковое значение или в результате вычисляемого свойства будет получен тот же результат, то распространение изменения будет пресечено. Также сигналы чаще сосредотачиваются на Pull/PushPull системах реактивности, те инициатором вычисления и обновления служат зависимости и если никто не подписан на сигнал, то и вычислен он не будет.
Итого: Push vs Pull, концентрация над потоком данный vs концентрация на связях и состояниях

Redux / Flux:
Основная задача этого подхода создать однонаправленный поток данных c прозрачными обновлениями: State -> View -> Action -> Reducer -> Actions. По сути эта модель описывает суть этого подхода. Мы здесь не видим ни зависимых состояний(как в сигналах), ни последовательных трансформаций(как в RxJS), мы тут полностью сосредоточены над контролем над обновлением состояния в 1 точке, все остальное остается за пределами. Нет тут ни подписок на отдельные части(в RTK мы имеем селекторы, но по факту они тоже подписываются на весь стор целиком, только обновление вызывают при изменении конкретной выбранной части), ни оптимизаций тому нужны ли кому-то данные эти в сторе. Здесь тоже используется Push-based реактивность: наша задача обновить состояние в Reducer-е изолировав обновление до одной точки, а остальное ему не интересно. При этом это моносторы и работа с разделением их на отдельные независимые части требует дополнительных усилий(RTK это делает за вас во многом). Сигналы же более точечно выбирают что и как им надо и каждый сигнал это и есть сам себе стор, поэтому они независимы и могут легко создаваться и уничтожаться в рантайме, что достаточно сложно для моносторов
Итого: Push vs Pull, концентрация на прозрачности обновления данных vs концентрация на связях и состояниях

Zustand:
По сути облегченные Redux или Flux, упростили API и сделали более простым для разбиения на несколько сторов вместо моностора. В остальном это тот же Flux подход со всеми его плюсами и минусами. Тоже Push-based реактивность сосредоточенная на 1 точке для обновления состояния.

MobX:
Я не так много с ним взаимодействовал, так что могу ошибаться, но MobX вполне могу назвать сигналами: я вижу что он не делает лишних вычислений, те это точно не Push-based реактивность и отсекает излишние вычисления. В нем легко создавать реактивные значения на лету (как и сигналы) и менять взаимосвязи. Также примитивы могут создаваться отдельно (зависимые значения - computed и эффекты - autorun).
Итого: тоже сигналы (по моему мнению)

Существуют и другие концепты: Effector (вечногорячие обсерваблы), $mol_wire (каналы, которые по своей сути тоже сигналы, но со своими фишками), обычные EventEmitter-ы (но они по сути глупые версии реактивных потоков из RxJS). Но их разберем как-нибудь в другой раз

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

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

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

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


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

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.

Интересный вопрос. А есть ли у нас уже что-то подобное? Ответ смешной но есть... около-монадические промисы. Попробуем написать это на них

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 я вижу одни и те же сообщения "- а что там по пайлпайну? - а ничего, мы его в этот раз не обсуждаем"

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

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

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

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

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

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

#подкаст

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

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

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

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

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

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

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 версия станет основной).

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

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

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

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