Comments 16
Solid хоть и пионер по части сигналов, но мне больше зашел Alpine.js с adonis и edge
Мне была важна возможность перехода на React/Preact+MobX если не хватит экосистемы, поэтому детали реактивности были не важны - главное, чтобы была возможность делать реактивные инстансы классов по аналогии с MobX. Что под капотом - геттеры-сеттеры, прокси или сигналы не так важно, если они дают достаточный перфоманс и не налагают серьезных ограничений.
Конечно, есть фреймворки, предлагающие менее 5.78 kb на старте, но не с jsx синтаксисом и без возможности практически безболезненно переключаться на другие фреймворки.
Смешно сравнивать размеры бандлов, когда главная страничка сайта написанного на нексте делает 50 запросов для подгрузки чанков, да и вообще загружается 10 мб всяких картинок.
Splid хорош тем, что он делает то, что написано в коде, без всяких ререндеров и обмазок в виде мемоизации, которую легко поломать грязными руками. Просто работает так, как написан код.
Зачем вам контроллируемые инпуты? Это реактовское понятия, как раз связанное с ререндерами, чтобы не словить рассинхрон стейта. В солиде такой пробоемы в принципе нет.
Некст вне контекста статьи, как и мегабайты картинок. Контролируемые инпуты нужны для фильтрации того, что вводит пользователь. Попробуйте на нативном инпуте нативно обработать oninput, onchange, onpaste, onkeypress, onkeydown c учетом мобильных браузеров и всех версий операционки и разрешить скажем ввод "a-b". Это очень нетривиальная задача, если у вас в наличии десятки устройств.
Добавьте обработку маски и позицию каретки для удобного редактирования.
Да, есть немало библиотек, в том числе для Solid, которые решают эту проблему. Но если в приложении пара инпутов и не хочется раздувать размер бандла, то в контролируемых инпутах Реакта все решается намного проще, чем в неконтролируемых Солида.
Для Реакта я мог использовать простые regexp для запрета ввода некорректных символов, теперь же приходится все делать через сторонние библиотеки. Не то, чтобы это вызывало серьезные неудобства, но отсутствие привычного функционала портит впечатление от фреймворка.
Ох, если вы бы помогли "имерить" также размер и производительность приложения на Fusor, я был бы вам очень вам признателен. Уверен, что результаты были бы не худшими, а может и лучшими. Все руки не доходят до этого.
Спасибо за статью и за то, что про перф что-то пишите, очень важная тема!
Меня смущает, что Painting так отличается. Если у вас одинаковое число элементов и одинаковые стили, то он должен +- быть равным, и Rendering тоже.
Я погонял локально ваш проект, и у меня всегда при перемещении по Page1 - Page 2 метрика Paiting на всех сборках близка к 5мс, а Rendering 15мс. Различий между фреймворками не заметил.
Плюс хочу добавить, что для меня супер сборка это Preact+Signals. Там перф ререндеров получается такой же, как с SolidJS. Если на них писать без использования useState/Callback/Memo, то можно вообще все приложение без ререндеров сделать (т.к. Preact если в div получает сигнал, то он не вызывает ререндер, а просто меняет атрибут элемента по изменению сигнала, по сути как в solid). Плюс совместимость с библиотеками React есть.
Да, меня тоже смущает, что Painting отличается на 50%. Думаю, тут дело в ререндерах и отсутствии оптимизации для Реакта (если бы выносил больше компонентов и они точечно обновлялись - то меньше бы было), об этом написал в статье.
Page1 - Page 2 не реактивные, а прод-приложение, из которого приводил метрики - реактивные, там есть изменения в структуре разметки, динамические элементы, показы по условию, изменения стилей и т.п. Делать что-то сложное в Реактосолиде я не стал - просто сгенерировал статику через AI и убрал 80% архитектуры прод-приложения. Можно самостоятельно для интереса сделать что-то более сложное - думаю, различия в перфомансе будут более явными.
Preact+Signals, к сожалению, совсем не поддерживает реактивные классы и завязывается на написание логики внутри компонента - этот подход не адаптировать под ViewModel и MobX. Перфоманс, уверен, будет лучше, но и ограничения явные - сильная привязка к Preact и невозможность быстрого переключения на React/Solid. Для меня же Solid был новым опытом, и оставить себе "путь отступления" было крайне важным на старте - хотя после написания проекта это оказалось избыточным, экосистемы и возможностей Solid хватило с лихвой.
Preact+Signals, к сожалению, совсем не поддерживает реактивные классы
Классовые компоненты да, там с костылями только. Я и команда не пишем новый код на классовых компонентах, а в старом коде можно хелпер создать, который будет подписываться на сигнал и делать forceUpdate. Но это велосипед, поэтому ваша правда.
и завязывается на написание логики внутри компонента - этот подход не адаптировать под ViewModel и MobX.
Я делал ViewModel (правда там нет автоматической реактивности, нужно помечать поля). Реактивность работает за пределами preact, сигналы можно как угодно формировать, не обязательно в компонентах. А если такой сигнал уже подцепится в рендере компонента, то компонент автоматически становится observer компонентом.
т.е. в компонентах создаются сигналы через useSignal, а за пределами (в сторах) уже через signal.
Да, нет магии с makeAutoObservable, но на мой взгляд это только плюс, makeAutoObservable это код с кучей оверхеда.
Другой вопрос, что сигналы это примитивы, поэтому observable.deep там невозможен из коробки (но есть открытые решения).
сильная привязка к Preact
С React тоже отлично работает. А в SolidJS свои сигналы, которые очень похожи на преактовские.
В любом случае, в новых проектах проще SolidJS использовать. Preact+Signals хорош там, где уже есть react/preact приложение, или это проект на большую команду разработчиков, куда проще искать react разработчиков чем solidjs (да, при найме это оказывается важно, хотя обе технологии простые, но люди хотят строчку в резюме "работал с реактом").
С React тоже отлично работает
У Реакта другая система реактивности - изменения Preact signals не будут вызывать ререндер компонента, а если с адаптером - то все равно не будет точечных апдейтов без ручной оптимизации. То есть на мой взгляд привязка к Preact будет достаточно сильная.
Для осуществления глубокой реактивности (не только примитивов), как вы правильно заметили, тоже будет необходима дополнительная библиотека, и по размеру код думаю приблизится к Preact+MobX, учитывая все нюансы.
Не спорю, что если использовать только 1 фреймворк, то можно оптимизировать код, однако мне было интересно именно side-to-side сравнение, поэтому взял MobX для связки с Preact.
Хз как React вообще еще жив в 2025-ом. Когда рядом есть Vue, ушедший на несколько лет вперед...
Solid.js как альтернатива (P)React+MobX на практике