Antfu вновь доказывает, что DX в мире JS-туллинга можно еще развивать и развивать.
Если вы его еще не знаете, то самое время познакомиться, но для начала о его новом решении: eslint-typegen

Кратко: решает проблему с отсутствием типизации в конфигах ESlint на основе кодогенерации. Те при первом прогоне он создает .d.ts файл основываясь на переданных правилах ESlint.

Имеется 2 варианта использовать:
- кодогенератор на основе переданного конфига (основной)
- Low Level API с преобразованием к строке для последующей записи в нужное место

Работает все это чудо основываясь на JSON Schema, которая указывается у правил в ESlint. Далее прогоняется через json-schema-to-typescript и далее небольшие трансформации для приведения к нужному виду. Готово. Общий объем библиотеки менее 300 строк кода, так что можно вполне изучить его за пару часов.

Из любопытного:
- если вы пользуетесь @antfu/eslint-config, то вам можно это дело не подключать, все уже настроено из коробки
- автором идеи он называет @Shinigami92

Если вас давно раздражает, что никаких подсказок в ESlint толком нет, то вот способ это исправить

Ура! Спустя N лет документация доступна на русском. Чуть-чуть тоже прикладывал усилия в переводе и планирую продолжить. По поводу багов и очепяток писать сюда: https://github.com/vuejs-translations/docs-ru/issues

Сайт: https://ru.vuejs.org/

To close or not to close

Забавная дискуссия(на самом деле самый настоящий холливар) выдалась в одном ишьюсе в репозитории Svelte.

Кратко: Рич Харрис(создатель Svelte) только сейчас обнаружил, что

<div /> Hello

Это не

<div></div> Hello

А

<div> Hello</div>

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

Вначале разберемся с ситуацией в HTML:
HTML - не имеет понятия self-closing element. Вместо этого есть void elements: br / hr / input и тп. Так же есть допущение для внешних элементов: svg/mathml, которые реализованы на основе XML. В стандарте XML self-closing tags называются empty-element tags(элементы у которых нет контента). В остальных случаях HTML просто... игнорирует завершающий /, но с 1 исключением

<a href=login/>  

<a href="login/"> тоже самое
<a href="login" /> не верно (Svelte и этот тест провалил)

Самое забавное, что все фреймворки ведут себя по разному относительно этого вопроса:

JSX(React. Solid etc...) - поддерживает self-closing tags
Angular - только с 16-ой версии начал их поддерживать для своих компонентов, в остальном все как HTML. Кстати, там тоже была бойня, хоть и поменьше
Lit - все согласно HTML. Кстати, согласно спеке даже custom elements не могут быть самозакрывающимися. Один человек недовольный отказом, даже сделал расширение добавлющее этот функционал
Ember - официально поддерживает self-closing tags, как часть расширения HTML
Vue - тут все сложнее.
1) Если используется рантайм компиляция шаблонов из HTML, то работают правила HTML и все работает согласно спеке
2) Если происходит этап билда шаблонов, например со сборщиком, то self-closing tags доступны.
При этом в vue eslint можно четко разграничить желаемое поведение. Но и это было не всегда и сам Эван был против self-closing tags, но с появлением vue-loader все-таки поддержали данный функционал.

Как мы видим единого мнения в сообществе вообще нет. На одной чаше удобство, на другой плашка "соответствует HTML5"и куча различных трейдоффов.

А что считаете вы, как должны поступать фреймворки?

Ну вот и день Х. Чуть позже залетит сюда преза и исходники даже для тех, кого нет на холи

Так. Это заняло некоторое время (пришлось написать текстовое описания слайдов и поднастроить репу, чтобы я мог множество презентаций в ней хранить). О итогах моей поездки и Holy в целом сообщу чуть позже.

А вот пока и обещанная презентация с исходниками к ней.
А вот исходники к шуточному Vueact.

PS. Управление презентаций стрелочками, либо мышкой направить в левый нижний угол.
Там же можно включить режим спикера и увидеть текстовое описание к каждому слайду (оно достаточно сильно отличается от того что было на Holy, но в достаточной мере, чтобы поработать с материалом самостоятельно и без видеозаписи)

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

С последнего поста народу тут явно поприбавилось. Welcome!
Поэтому кратенько о себе:
Я - Чернов Денис. Работаю в Спортмастер-е на Vue-хе. Влюблен в кодинг уже 13+ лет
Увлекаюсь IT-шкой в широком смысле. Внимательно слежу за всеми колебаниями в области фронтенда.

Что можно увидеть на канале:
1) Новости которые показались мне наиболее интересными. Обязательно с разборами и кучей ссылок на источники
2) Интересные моменты из Frontend-разработки и не только
3) Отчеты и доп материал по моим докладам.

Говорю я о всех фреймворках, но особой любовью тут пользуется именно Vue.
Что впрочем и стало причиной моего последнего доклада на Vue Msk.
Это стал заключительным выступлением в моем первом "спикерском сезоне". За пол года 3 конфы и 1 митап (все доклады разные, но один модификация более старого)

Выступление было на тему подкапотной реактивности во Vue.
Итого презентация: преза, исходник (напоминаю, что управление стрелками или мышкой в нижнем левом углу)
Видео с выступления: youtube

Материал для дальнейшего изучения:
1) chibi vue - буквально лучшего руководства не найти в духе с 0 до своего мини-Vue. Позволяет хорошо прочувствовать работу под капотом
2) rfc effectscope - хорошо разбирается тема с effectScope
3) watch with @vue/reactivity - в докладе я говорю про отсутствие watch/watchEffect внутри @vue/reactivity. В статье Энтони разбирает подкапотную работу реактивности во Vue и как все-таки вернуть watch
4) reactivue - шуточный (или нет) способ объединить "лучшее" по мнению Энтони между react и vue. Как раз способ запустить @vue/reactivity внутри react.
5) vue-lit - PoC как запустить реактивность vue внутри lit-html
6) исходники @vue/reactivity, Но внутри @vue/runtime-core тоже хватает интересностей (scheduler, apiWatcher/apiComputed)

Всем привет. Тем временем Holy.js сделал подарок и выложил сразу 4 видео по 4 наиболее популярным фреймворкам

- как работает Next.js
- как человек делает свой фреймворк a la Svelte
- мой доклад по Vue Renderer-ам
- и доклад с точно такой же сутью как у меня только по Angular (только тут делают на примере консольного приложения).

Так что можете выбрать доклад по своему любимому фреймворку и посмотреть.

И вот вам список докладов, но относительно работы рендереров в разных фреймворков:

- Мой доклад по Vue Renderer-ам. Тут я упоролся и сделал рендерер из Vue в React дерево элементов.
- Angular Universal. Разбирается на примере рендера в консоль
- React Reconciler с примером рендеринга в Figma
- Solid Universal. Доклад от самого создателя Solid.js (естественно на английском)
- Конкретно по рендерерам Svelte ничего конкретного не нашел. Но вот есть такое видео, где Svelte приделывают фичу по рендеру из маркдауна в компонентах в HTML. (если у кого есть больше инфы, обязательно поделитесь)

PS. Повторно прошу прощения за ввод за заблуждение неймингом доклада про Canvas. Изначально он был в концепции, но потом я увидел решения существующие и что описывать его будет не так весело, как ресерч рендерера в React. Дополнительно напомню, что главная цель этого рендерера -- это пощупать гибкость рендереров Vue даже на таком экзотическом примере, а не реальное использование на продакшене. Для тех кому все-таки интересен в canvas: vuvas (код рендерера).

И так. спустя более чем полгода мы все-таки получили результаты от State Of JS 2023(я уже и не ждал). Все задержалось из-за того что организатор опроса выгорел и попросил помощи других людей с анализом собранных данных. Может поэтому в некоторых местах пугающие цифры по объемам данных которые "не учли". Чуть позже поймете о чем я.

Проведу небольшие итоги от себя:

1) Народ считает самой главной проблемой в JS:
1.1) Отсутствие статической типизации из коробки. Причем лидирует этот пункт с большим отрывом (33% vs 9% у второго места). Оно же лидирует в списке "фичей которых не хватает"
1.2) борьбу между CommonJS и ES Modules
1.3) Болезненность работы с датами
2.3) 84% ответов не смогли определить куда-то в конкретное место. Число зашкаливающее

2) Народ считает самой главной проблемой при работе с браузерами:
2.1) Поддержка браузерами. Достаточно спорный пункт на мой взгляд. Вспомнить что было лет 15 и даже 10 лет назад, то сейчас кроссбраузерность гораздо меньшая проблема. Возможно этот пункт стоит скорее считать как "скорость поддержки". Те, люди видят классные фичи, а потом понимают, что N лет все равно не смогут ими воспользоваться. Вот это уже действительно несколько огорчает. Процент отметивших этот пункт 32%, что тоже ЗНАЧИТЕЛЬНО выше второго места с 6%
2.2) Safari. Когда я проходил опрос этого пункта не было, но это не помешало ему забраться на второе место... Думаю этого достаточно, чтобы понять всю радость программистов от этого "инструмента".
2.3) 76% ответов не смогли определить куда-то в конкретное место. Это что-то перебор. Думаю, что потеряли большое кол-во информации

Далее переходим к самому интересному разделу: библиотеки
Тут можно написать 1 слово: Vite. Vite буквально рвет все топы. Из 6 "наград" опроса Vite взял 3. При этом еще в 1 отстав всего на 2% процента от... Vitest, который тоже замечательно показал себя заняв топ тир среди инструментов тестирования. А вот Webpack четко летит на дно по показателю удовлетворенности. 48% респондентов отметило его как "использовал его, впечатления неприятные". Я могу его назвать самым быстропадающим с точки зрения впечатлений о нем. Забавный момент, что на приложенном графике. То где сейчас находится Vite, это то где в 2017ом был Webpack. Так что, возможно, лет через 6 Vite может ждать такая же судьба.
Что касается других сборщиков, то SWC и esbuild также попали в топ тир. А вот строчки аутсайдеров занял Parcel и Webpack.

Теперь идем к тому чего я больше всего ждал: Frontend Frameworks. И тут ситуация любопытная. Разберемся с каждым фреймворком по отдельности. При этом я оставлю предупреждение:
Опросы всегда штука специфичная и может давать ошибки в зависимости от захваченных групп опрашиваемых. Обычно люди проходящие опросы более заинтересованы в разработке, чем люди их игнорирующие. При этом люди проходящие опросы тоже чаще являются early adopters(люди берущие на вооружения или пробующие что-то малопопулярное/свежевышедшее). Поэтому стараемся учитывать эту погрешность и не принимать результаты опроса близко к сердцу. Конец предупреждения.

React. Мягко говоря cдает позиции относительно опроса. При этом он не падает в популярности (а даже растет), но вот процент недовольных им очень быстро растет. (это можно увидеть на том же графике с "кометами"). И черная полоса пошла с 2019. Я это связываю с подниманием головы других решений: Vue3, Svelte/Solid. Народ буквально увидел, что можно решать проблемы иначе. Далее команда реакта начала жить своей жизнью, время от времени повергая в шок программистов своими новыми фичами, которые приходилось откатывать после волны справдливого хейта. Опрос был сделан в декабре 2023, так что в 2024 интересно увидеть динамику после выхода React 19, все большего доминирование Next и нового React Compiler-а. Но сколько не ругай реакт, а с точки зрения популярности он все еще только растет. А вот Next.js прям очень сильно скакнул вниз по "уровню счастья". Сомнительные решения и app router, думаю, приложили к этому свою руку.

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 💚 всем сердцем человека