SolidJS 2.0 вышел в статусе Beta 15 мая 2026 года и сразу зашел с тяжелой артиллерией: async в этом релизе стал частью базовой модели фреймворка, а не надстройкой из хелперов и обходных паттернов. Для фронтенд-команд это не просто косметика в API, а смена правил игры: меньше ручной склейки вокруг Promise, но заметно больше требований к миграции и переосмыслению реактивности.
Как пишет InfoQ, команда SolidJS вообще пропустила стадию Alpha и перешла к Beta после долгой обкатки в Experimental. Автор фреймворка Райан Карниато объяснил это просто: цели, которые обычно закрывает Alpha, в этом цикле уже не выглядели достаточно самостоятельными. Самый заметный итог этой длинной подготовки — в SolidJS 2.0 вычисления теперь могут возвращать Promise напрямую, а реактивный граф сам обрабатывает приостановку и возобновление. На практике это означает, что promise можно передать, например, в createMemo без привычного слоя ручной оркестрации.
Второй крупный сдвиг касается Suspense и состояния загрузки. Механика Loading теперь отвечает только за первоначальную готовность поддерева интерфейса: показывает fallback при первом рендере, а дальше старается не дергать уже построенный UI на каждом обновлении. Для последующих переходов вводится отдельная модель ожидания через isPending(() => expr). Для разработчиков это важная поправка к старой боли Solid: раньше Suspense в некоторых сценариях мог буквально выдернуть кусок интерфейса и собрать его заново, что выглядело эффектно только в демо, но не всегда приятно в живом продукте.
Есть и изменения, которые больше оценят команды, работающие с формами, серверными мутациями и optimistic UI. В релизе появились специальные примитивы для мутаций: action() в связке с createOptimisticStore должен собрать в один поток оптимистичное обновление, запись на сервер и последующую ревалидацию данных. Отдельно вынесено и производное состояние: теперь функцию можно передавать прямо в createSignal(fn) и createStore(fn), превращая derived state в нормальную часть API, а не в набор полуручных конструкций. Параллельно SolidJS переводит обновления на батчинг через microtask, а чтение значений синхронизируется после flush(). Иными словами, планировщик становится полностью детерминированным, но разработчику придется привыкнуть к тому, что запись в сигнал больше не обязана немедленно отражаться в следующем же чтении.
Именно здесь начинается та часть релиза, где слово Beta надо читать внимательно. В SolidJS 2.0 достаточно breaking changes, чтобы миграция не превратилась в «обновил зависимость и пошел дальше». Компонент Index заменяют на ReactivatedMap, дочерние элементы For теперь получают accessor, createEffect разделен на отдельные фазы compute и apply, onMount уступает место onSettled, сеттеры store по умолчанию переходят к draft-first semantics, а система директив use: вообще убрана в пользу ref directive factories. Для команд с крупной кодовой базой это означает простой вывод: релиз обещает более цельную модель async, но платить за нее придется ревизией привычных шаблонов, особенно если проект активно использует эффекты, сложные store и кастомные директивы.
Реакция сообщества на эти изменения ожидаемо смешанная, но скучной ее не назовешь. На Reddit разработчики встретили новый async-модель заметно теплее, чем можно было ожидать от сообщества JavaScript в мае 2026 года. Один из комментаторов прямо написал, что испытывает почти облегчение от того, что async наконец стал «первоклассным гражданином» фреймворка. Другой похвалил очистку async-примитивов и напомнил, за что Solid вообще любят: fine-grained reactivity без virtual DOM. Разработчик Brenelz, который мигрировал на 2.0 и TanStack Start, и SolidStart, отметил, что новая модель async ощущается лучше, а переработка Suspense решает старую проблему с резким исчезновением интерфейса.
Но без споров не обошлось. На GitHub часть разработчиков раскритиковала разбиение createEffect на две фазы и новую логику обновления значений после flush(). Аргумент понятный: в Solid 1.x ментальная модель была интуитивнее, потому что сигнал вел себя почти как обычная переменная, а автоматическое отслеживание зависимостей внутри одного createEffect закрывало большую часть реальных сценариев. Карниато на эту критику ответил жестко и довольно честно: решения неприятные, но, по его словам, неизбежные, если цель — консистентная async-модель. Его позиция сводится к тому, что библиотека берет на себя больше сложности внутри, чтобы снаружи API оставался стройнее, а сама потребность в createEffect со временем возникала реже.
Для русскоязычной IT-аудитории из этого следует прагматичный вывод. Если команда уже смотрит на альтернативы React ради более точечной реактивности и меньшего рантайм-оверхеда, SolidJS 2.0 выглядит как заявка на более взрослую платформу, а не просто на быстрый UI-фреймворк без virtual DOM. Но если проект живет на Solid 1.x, обновление стоит рассматривать не как минорный тюнинг, а как архитектурный пересмотр подхода к async, эффектам и жизненному циклу компонентов. Главный вопрос теперь не в том, сможет ли Solid быть быстрым — это он давно умеет, — а в том, готовы ли команды принять более строгую, зато предсказуемую модель реактивности как новую цену за удобный async.