Comments 62
Большая просьба всех любителей очередных "убийц" React, Zustand, Redux - обсуждать это в соответствующих статьях про выбор и сравнение технологий. Хотелось бы иметь здесь комментарии по статье, а не превращать их в извечный, практически всегда неконструктивный спор.
Минусаторам любителей "убийц" - отдельный привет, вам тут не рады, но к сожалению это реалии хабра. Давать минусы всем моим комментариям, карме и даже статье - видимо все на что вы способы.
Спасибо.
Иммутабельные паттерны разработки UI-приложений в последние годы стали одними из самых популярных
Я даже пошёл календарь перепроверить, не оказался ли я случайно в 2018. Иммутабельные паттерны разработки при том, что у нас уже много лет есть сигналы? `Immutable.js` в 2026? И я, конечно, догадывался, что Redux всё ещё где-то рядом с нами, но назвать его популярным?
В общем, статья вызывает большие вопросы о релевантности (и ностальгию!)
Можете скинуть количество скачиваний пакета ваших сигналов и, например, зустанда? Чтобы мы могли оценить насколько сегодня, в 2026 году, они популярнее. Ну и Redux заодно.
И что вы этим докажете? Что много легаси на редаксе работает? Ну так на jQuery 90% веба до сих пор крутится.
А вот предложение на включение в JS редакс точно не получал.
> И что вы этим докажете?
Вы просто не привыкли доказывать утверждения, а я привык. В случае с популярностью это доказывается именно так.
> Что много легаси на редаксе работает?
Так зустанд же не легаси, но вы почему то его не упоминаете. Понятно почему.
В случае с популярностью это доказывается именно так.
Вот как? Тогда самый популярный стейт-менеджер это rxjs. Ни редакс, ни ваш зустанд рядом даже чихнуть не смеют. Всё верно?
RxJS это не совсем state manager, его можно использовать в этом качестве, особенно если взглянуть на subject, но изначально он создавался для управления потоками данных.
А то что какие то сигналы (из космоса?) якобы сейчас это стандарт разработки вы так и не доказали, и не докажете потому что это чушь.
PS. И да, RxJS сейчас популярнее, не спорю.
Вы там под корягой прогаете, если про сигналы не слышали, или да?
А вообще смешно, конечно, смотреть на ваши потуги доказать, что вы правы.
Но меж тем реальность, увы, не на вашей стороне.
Preact изобрёл сигналы (ну, не то чтобы это новая технология, но именно их реализация запустила хайп)
React принял сигналы по умолчанию (в смысле, они ничего не делали, Preact изначательно реализовывал сигналы и для реакта тоже).
Ангуляр внедрил у себя сигналы, который заменяют (барабанная дробь) rxjs.
У Vue они теперь тоже есть, как Alien Signals.
Solid с сигналами работает ещё до Preact.
Svelte втащили себе сигналы.
И даже в TC39 появился пропозал на включение нативных сигналов в платформу.
Если это не популярность, то вы попросту отрицаете реальность, пытаясь основываться на ничего не значащих циферках.
@preact/signals 0.6м скачиваний против 54.5м у зустанда. Понятно что вы так триггеритесь. Ну ок, может и правда в реакте что то гениальное появилось, посмотрим:
If you need to instantiate new signals or create new side effects on signal changes inside your components, you can use the
useSignal,useComputedanduseSignalEffecthooks.
Новое апи в тч для эффектов. Круто. Сейчас все начнем переписывать.If you pass a signal directly into JSX, it will bind directly to the DOM
Text
ММ, магию, которая работает никому неизвестно как - такое джуны любят. Правда как начнутся проблемы, придется либо все переписывать, либо терпеть. Н - надежность.Using signals in render props is not recommended. In this situation, the component that reads the signal is the component that calls the render prop, which may or may not be hooked up to track signals.
Еще и на Бабель нужно полагаться, чтобы код работал, только вот незадача - он не сработает в некоторых случаях. Сразу захотелось затащить в проект.Similar issues exist with using object getters & setters. Since the it isn't easily statically analyzable that a getter or setter is backed by a signal, the Babel plugin may miss some components that use signals in this way.
Ну короче магия не всегда срабатывает, нужно поставить mode: all и все заработает. И конечно же очень оптимизированно - так разрабы написали.
Изучив данную библиотеку, прихожу к выводу, что она пригодна лишь для очень популярных в России псевдоахритекторов, не до конца разобравшимся даже с оф документацией и работой основного апи, которым только скажи что есть убертехнология, регающая все проблемы (как - неважно), и они начнут ее внедрять везде, докуда дотянутся. А как только все пойдет по звезде - ливают с проекта и оставляют горе-заказчика с этим один на один (ну либо переписывают все проекты как не так давно ВК с эффектором).
Хорошо, что есть и разрабы, которые не любят использовать всякий мусор, хоть таких и единицы.
Про Vue, Angular и тп мне глубоко все равно, нет желания разбираться что там происходит. А в ТС39 - там чего только нет, в тч есть и парочка моих, это вообще смешно приводить пример какого то непринятого командой JS пропозала. Как примут, так и поговорим.
Напоминает ситуацию с абсолютным мусором - WatermelonDB. Чего только там разрабы не обещали, и кто только ее не затащил. Закончилось у многих одинаково - под небольшой нагрузкой работает как кусок г****, помогает только полное переписывание проектов с ее удалением.
После такого комментария заставили задуматься в Вашей проф-пригодности:
Почему-то вязли не ту библиотеку для сравнения -
@preact/signalsвместо@preact/signals-core, где вообще нет никаких биндингов под Реакт, а просто имплементация паттерна.Было бы очень опрометчиво подумать, что какая-либо библиотека (те же сигналы), предлагающая иное мнение в какой-либо области будет иметь моментальную популярность. Что касается популярности Zustand - по сути идеология Redux, что и дало ему бешеную популярность.
Никто не называл сигналы "стандартом разработки", однако, на различных конференциях и митапах эта тема стала появляться, люди делятся опытом использования этой идеи - и в основном она положительная.
Пишете о собственных пропозолах - каких? Они прошли Stage 0? Они имеют активное обсуждение? Пробежавшись по основному репозиторию с предложениям - не нашёл Вас ни в Issues, ни в PR'ах, ни одного упоминания в списках пропозолов тоже.
По моему мнению, для тех. лида иметь такое однополярное (или категоричное, если хотите) мнение просто непозволительно, потому что сама сфера говорит о том, чтобы интересоваться всем вокруг, в том числе что происходит у Vue, Angular и им подобным.
Я занимаюсь мобильной разработкой, которая точно не переедет ни на Vue, ни прости господи Angular, и мне есть чем интересоваться. И пока я на ней работаю сменилось уже множество "убийц" и зустанда/редакса, и реакта.
А по части различных архитектур - насмотренности уже более чем достаточно, куда больше чем у любителей ранее перечисленных "убийц".
Никто не называл сигналы "стандартом разработки",
Именно что очень неоднозначно заявлял.
однако, на различных конференциях и митапах эта тема стала появляться
делятся опытом использования этой идеи - и в основном она положительная.
Отлично, пусть побудут бетатестерами, я не имею желания.
Или просто взять MobX и не мучаться ни с чем
Мучиться там придется еще больше на больших проектах, и при этом практически никто не будет понимать как он реально работает - фатальный недостаток.
Хелловорлды симпатичнее, да.
Уж лучше в сторону Rx или аналогов смотреть если хочется полностью мутабельный подход, вопрос только зачем.
Мучиться там придется еще больше на больших проектах
Каким боком сам факт большого проекта(это мучения по дефолту) сопоставляется с тем, что именно MobX там камень преткновения?
при этом практически никто не будет понимать как он реально работает - фатальный недостаток.
Это намек на то, что на этом проекте первоклассники работают?
const obj = {
_val: 1,
set val(v) {
console.log('value is set:', v);
console.log('notify subscribers now');
this._val = v;
},
get val() {
console.log('value vas read (subscribe now)');
return this._val;
},
}
obj.val++;
let a = obj.val;https://stackblitz.com/edit/typescript-of3ea5?file=index.ts
Уж лучше в сторону Rx или аналогов смотреть
Ну это вообще смешно, только если хочется максимально вырвиглазный wite only код, который потом нереально будет поддерживать.
Технология, оборачивающая все в прокси, на платформе, где большинство разрабов с зустандом то разобраться до конца не могут - это приговор. Умножим это еще на отсутствие хороших коробочных решений по кэшированию запросов.
Есть варианты и с Rx - сложно, но предсказуемо (не мой выбор), либо EventEmitter для простой мутабельности, либо оптимизации из статьи, решающие все реально встречающиеся проблемы на простых как топор иммутабельных сторах.
Но хотите пишите на нем, для меня это мусорная библиотека.
серьёзно ?) Rx будут больше понимать как работает, чем Mobx?)
В корне с вами не согласен, конечно все зависит от как пишется код на MobX ( если mst то да каша), а обычные классы, свойства, фукнции и в целом код приближенный к обычному JS - будет намного понятнее чем RxJS
Понимать код это не читать высокоуровневый код, обмазанный проксями, а рассказать от и до что происходит в случае, например, мерджа данных в большой список.
А про классы у меня есть отличная статья, пора их уже наконец выкинуть из JS/TS.
Понимать код это не читать высокоуровневый код, обмазанный проксями, а рассказать от и до что происходит в случае, например, мерджа данных в большой список.
В таком случае вы ошиблись в выборе ЯП, вам нужен Assembler чтобы вы напрямую процессорные инструкции писали, но и даже тут вы не будете понимать до конца что происходит, потому что вы не будете знать какие именно транзисторы и логические элементы будут под напряжением.
А про классы у меня есть отличная статья, пора их уже наконец выкинуть из JS/TS.
Классы это отличная вещь, если использовать по назначению, там где это удобно. JS/TS - мультипарадигменный язык, это не ФП или ООП и т.п. Пиши так, как удобно.
обмазанный проксями
А то, что код выполняется будучи обмазанным браузером, который обмазан тоннами кода, исполняющийся в операционной системе, которая обмазана тоже тоннами кода, который обмазан процессорными инструкциями, которые выполняются в связке с железом и т.п. Это нормально да? =)
А про классы у меня есть отличная статья, пора их уже наконец выкинуть из JS/TS
Написали бы вначале статьи это, мы бы не тратили время на прочтение, сразу бы все поняли.
А вы, стесняюсь спросить, в курсе, что все браузерное API + все встроенное в сам язык API построено на классах?
Поддержу, но я не читал статью полностью, полез в комменты, а там «выкинуть классы», уровень компетенций более чем понятен, статью можно не читать
Классы уже выкинули практически отовсюду, в том числе из React, Redux, Zustand и тп. Чтобы оценивать других нужно самому что то из себя представлять.
Ну так воспользуйтесь своим советом и прекратите писать глупости. ООП существует уже много лет и классы его неотъемлемая часть. А отсылаться к вашим авторитетам в виде, прости господи, редакс и компании, это смешно. Посмотрите на любой проект на редаксе, голом реакте, Зустанд не видел, но думаю там тоже самое, это неподдерживаемый лапша код, а если по русски говно код разбираться и управлять которым на дистанции невозможно без боли в заднице
Открою великую тайну, класс в JS это объект. А ключевое слово class в JS это лишь синтаксический сахар. Так что, если выкинуть из js классы, то это значит выкинуть и объекты. а это значит вообще похоронить js.
Нет, вполне достаточно линтером запретить ключевое слово class, что я уже очень давно и делаю на своих проектах.
const userObj = {
firstName: '',
lastName: '',
printName: () => {
console.log(userObj.firstName, userObj.lastName)
},
}
userObj.firstName = 'obj first name';
userObj.lastName = 'obj last name';
userObj.printName();
class User {
firstName = '';
lastName = '';
printName = () => {
console.log(this.firstName, this.lastName)
}
}
const user = new User();
user.firstName = 'class first name';
user.lastName = 'class last name';
user.printName();Ну в чем разница то? Почему class User такой ужасный, а практически тоже самое в виде userObj это круто? На выходе даже взаимодействие с user и с userObj абсолютно идентичное.
@markelov69 Вы уже тоже пробовали что то доказать в той статье, но конструктивно не получилось.
Тем более, что в статье именно на этом примере и показано в чем разница. Перечитайте. И да, ту статью давайте обсуждать там.
Вы говорите что-то про конструктив, я вам конструктивно скинул прямо таки код, конкретный, компактный, задал конкретный вопрос, а вы вместо того, чтобы прямо на него ответить начинаете увиливать. Это же стандартный трюк, когда знаешь что не прав и ответить нечего чтобы быть правым, то начинаются левые отмазки и уводы в сторону. Это же классика. По сути ваши отговорки уже говорят о том, что ваши нападки на классы пустые и не обоснованные.
Так что, если выкинуть из js классы, то это значит выкинуть и объекты
это подмена понятий. По такой логике, до введения классов, объектов в JS не существовало
это подмена понятий. По такой логике, до введения классов, объектов в JS не существовало
С чего это вдруг? Разве же что только по вашей логике. Наоборот, фундамент js это объекты, а классы появились сильно позже, и это не настоящие классы, это лишь синтаксических сахар, а по факту это объекты. Т.е. классы == объекты, выкинуть классы == выкинуть объекты. Вот и вся арифметика.
вот именно, что это больше арифметика словами, чем логика =)
Если классы — это синтаксический сахар над объектами, и мы выкидываем классы, то мы выкидываем не объекты с собой, а только синтаксический сахар над объектами. Что здесь не логично?
Если в языке не будет классов, я все еще могу создать объект
Вот еще пример придумал, может быть станет понятнее: если мы в JS добавляем классы, а затем передумываем и сразу же после введения выпиливаем, то нам не нужно вместе с ними выпиливать объекты, нужно только синтаксис классов убрать
const userObj = {
firstName: '',
lastName: '',
printName: () => {
console.log(userObj.firstName, userObj.lastName)
},
}
userObj.firstName = 'obj first name';
userObj.lastName = 'obj last name';
userObj.printName();
class User {
firstName = '';
lastName = '';
printName = () => {
console.log(this.firstName, this.lastName)
}
}
const user = new User();
user.firstName = 'class first name';
user.lastName = 'class last name';
user.printName();
function UserFnClass() {
this.firstName = '';
this.lastName = '';
this.printName = () => {
console.log(this.firstName, this.lastName)
}
return this;
}
const userFnClass = new UserFnClass();
userFnClass.firstName = 'fn class first name';
userFnClass.lastName = 'fn class last name';
userFnClass.printName();В чём разница? Что даёт выкидывание ключевого слова class, если по факту ничего не меняется?
До того как появилось ключевое слово class, люди все так же в JS их использовали, просто через function или объект, просто тупо потому что это очень удобно, логично и структурировано. Это так же интуитивно, как ходить вперед глядя перед собой, а не пятиться назад.
Да ну что ты! Дэн Абрамов же сказал что классы это плохо! Смерись. И не забивай, что для многих использование классов = классовые компоненты в реакте
причем тут вообще эти частности? Мы разбираем нелогичное утверждение, а не экзистенциальные вопросы про то, нужны классы или нет.
@gen1lee Ну так что, вы говорите надо выкинуть class, вот представим, выкинули, дальше что измениться то?) Вот я код написал с object/class/function эквивалентный, теперь уберем из него class, что меняется то?) Можно делать тоже самое с помощью function, в принципе как раньше и делали всегда. "Классы" раньше все было через function реализованы. Куда же ещё конструктивней? Получается не работает ваше выкидывание классов из JS. Или как обычно нечего ответить когда перед носом конкретный пример кода поставили?
В JS много исторического мусора, и много на нем построено, речь про код, который пишет разработчик.
Ты из 2016?) Срочно скупай биткоины
Голый редакс + концепции в духе mapStateToProps жирно намекают на то, что автор застрял во времени лет эдак 5 назад. RTK давно лишён этих проблем
mapStateToProps это лишь один из примеров, и он до сих пор используется во многих проектах
то что появились хуки - так они тоже затронуты в статье и проблемы там те же самые остались, и тоже упомянуты в статье.
про слайсы RTK отдельно упомянуто в секции Immer (кратко - лучше не использовать)
статья в том числе и про zustand, в котором меньше предупреждений если что то используется неправильно
Если с чем то не согласны раскройте мысль поточнее. Либо читайте внимательнее, и разберитесь в технологии получше.
Много лет использует React так словно все кругом мутабельно. Для этого пришлось использовать react не так как везде пишут (не идеально но работает). В замен - проблем с производительностью никогда небыло, использую любые данные где бы они не находилось, в props передаю что хочу не думая о всяком memo. Пока react не повернется лицом к мутабельности так и будет страдать
Похоже на борьбу с инструментом. В вашем случае лучше либо его освоить, либо сменить. Первое как минимум покончит со страданием.
PS. Реакт не запрещает использовать мутабельные сторы, если они вам так почему то нравятся.
Раз уж такая пляска, то попытки затащить иммутабельность в язык без иммутабельности, а потом героически сражаться с проблемами (не идеально, но работает) - это куда более яркий пример борьбы с инструментом :upside-down-smile:
Да позволяет. Но оптимизацию рендера построил вокруг имутабельных данных (вот только это не работает). Когда memo будет отвечать только за свой компонент, а не за всю ветку, тогда и не придется бороться.
Меня очень настораживает когда вижу что в 2026 на фронте все ещё мало того что реакт, так ещё и люди mobx никак не осилят. Комменты из серии что mobx сложный как бы намекают что видимо есть проблема с базовым js. Тут сейчас ещё придут и скажут что классы в js это что то не естественное.
Чтобы понимать, почему то, что вы перечислили это переусложнение - mobx, классы, нужно как раз иметь хорошее архитектурное мышление.
Если его не иметь, то все кажется простым и понятным.
ТС предлагает выкинуть классы из языка, можно на этом заканчивать
В моей статье нет ни одного конструктивного коммента за классы - в каком моменте они лучше, при том что это самая обсуждаемая статья по программированию за 2025 год.
Такие как вы просто не могут в конструктив, поэтому да, заканчивайте.
Так у вас набросы, а не конструктив.
В моей статье нет ни одного конструктивного коммента за классы - в каком моменте они лучше, при том что это самая обсуждаемая статья по программированию за 2025 год.
Кол-во комментариев к вашей статье про классы обусловлено исключительно абсурдностью этой статьи, а не тем, что она хорошая и имеет прямое отношение к реальности и несет какую-то пользу.
Вы если хотите обсудить ту статью, то стоит это сделать там. И учитесь это делать конструктивно - так, как написана статья, с примерами кода. Ничем не подкрепленные мнения мне абсолютно не интересны.
И да, помню вас, что конструктивно это делать у вас там не получилось. Теперь гадите минусами комментариев во всех моих статьях - ваш уровень.
А альтернативы реакту? Типа в чем проблема использовать его как вью слой в связке с mobx
Большая просьба всех любителей очередных "убийц" React, Zustand, Redux - обсуждать это в соответствующих статьях про выбор и сравнение технологий. Хотелось бы иметь здесь комментарии по статье, а не превращать их в извечный, практически всегда неконструктивный спор.
Минусаторам любителей "убийц" - отдельный привет, вам тут не рады, но к сожалению это реалии хабра. Давать минусы всем моим комментариям, карме и даже статье - видимо все на что вы способы.
Спасибо.
Обидели художника
Сначала прочитал этот дисклеймер и думал, что в комментах реально люди начали скучно шутить про замену реакта ангуляром, вьюхой и тд и уж было согласился, однако дочитав все потуги автора статьи, понял, что у нас только один архитектурно мыслящий человек, а все остальные плохие и нехорошие, ведь настоящий архитектор не смотрит на новые технологии и практики, к черту Mobx, Vue, да даже про Signals знать ему не надо)
Претензия то в чем? Что я не смотрю на Mobx? а где я такое заявлял? Смотреть и использовать это разные вещи.
Сигналы посмотрел и предметно прокомментировал, автор коммента про то, что это чуть ли не новый стандарт и нужно использовать только их сразу куда то слился с обсуждения. Как это всегда бывает. И как будет с вами.
все остальные плохие и нехорошие
Тут вы правы, я действительно считаю большинство комментаторов хабра (да и вообще тыкателей клавиатуры, тем более на JS) неконструктивными, хороших разрабов абсолютное меньшинство. Если бы был сервис споров на деньги, я бы за счет таких уже обогатился. Кстати, надо такой сделать.
Убийцы иммутабельной производительности — Zustand/Redux в связке с React