| title | Сравнение с другими библиотеками |
|---|---|
| description | Сравнение Solid с другими библиотеками. |
| sort | 1 |
Этот раздел не может избежать некоторой предвзятости, но мы думаем, что важно понять, где Solid по сравнению с другими библиотеками. Дело совсем не в производительности.
Чтобы получить более полное представление о производительности, посмотрите JS Framework Benchmark.
React оказал большое влияние на Solid. Больше, чем цель быть просто «библиотекой рендеринга», а не фреймворком. Его однонаправленный поток и явное разделение чтения и записи в его слоях хуков дали основу интерфейсам Solid. Solid имеет твердое мнение о том, как подходить к управлению данными при разработке приложений, но не стремится ограничивать их выполнение.
Однако, насколько Solid соответствует философии дизайна React, он работает принципиально иначе. React использует виртуальную модель DOM, а Solid - нет. Абстракция React - это раздел компонентов сверху вниз, где методы рендеринга вызываются повторно и различаются. Вместо этого Solid визуализирует каждый шаблон полностью один раз, строит его реактивный граф и только после этого выполняет инструкции, связанные с мелкими изменениями.
Модель обновления Solid не похожа на React или даже React + MobX. Вместо того чтобы думать о функциональных компонентах как о функции рендеринга, думайте о них как о конструкторе. Остерегайтесь деструктуризации или преждевременного доступа к ресурсам, теряющего реактивность. Примитивы Solid не имеют ограничений, таких как правила хуков, поэтому вы можете вкладывать их по своему усмотрению. Для «ключевого» поведения вам не нужны явные ключи в строках списка. Наконец, нет VDOM, поэтому императивные API VDOM, такие как React.Children и React.cloneElement, не имеют смысла. Мы рекомендуем находить различные способы решения проблем, используя их декларативно.
На Solid не особо влияет Vue с точки зрения дизайна, но они сравнимы по подходу. Оба они используют прокси в своей реактивной системе с автоматическим отслеживанием на основе чтения. Но на этом сходство заканчивается. Детализированное обнаружение зависимостей Vue просто передается в менее детализированную систему Virtual DOM и Component, тогда как Solid сохраняет свою детализацию вплоть до своих прямых обновлений DOM.
Vue ценит легкость, а Solid - прозрачность. Хотя новое направление Vue с Vue 3 больше соответствует подходу Solid. Эти библиотеки могут со временем выровняться, в зависимости от того, как они будут развиваться.
Как еще одна современная реактивная библиотека, миграция с Vue 3 должна показаться вам знакомой. Компоненты Solid очень похожи на тегирование шаблона в конце функции Vue setup. Остерегайтесь обертывания вывода состояний вычислениями, попробуйте функцию. Реактивность повсеместна. Прокси-серверы Solid намеренно доступны только для чтения. Не стучите по нему, пока не попробуете.
Svelte является пионером предварительно скомпилированного исчезающего фреймворка, который Solid также в определенной степени использует. Обе библиотеки действительно реактивны и могут создавать действительно небольшие пакеты исполняемого кода, хотя Svelte является здесь победителем для небольших демонстраций. Solid требует немного большей ясности в своих объявлениях, меньше полагаясь на неявный анализ со стороны компилятора, но это часть того, что дает Solid превосходную производительность. Solid также сохраняет больше во время выполнения, что лучше масштабируется в более крупных приложениях. Демонстрационная реализация RealWorld от Solid на 25% меньше, чем у Svelte.
Обе библиотеки призваны помочь своим разработчикам писать меньше кода, но подходят к нему совершенно по-разному. Svelte 3 фокусируется на оптимизации простоты работы с локализованными изменениями, уделяя особое внимание взаимодействию простых объектов и двусторонней привязке. Напротив, Solid фокусируется на потоке данных, сознательно используя CQRS и неизменяемый интерфейс. С функциональной композицией шаблонов, во многих случаях Solid позволяет разработчикам писать даже меньше кода, чем Svelte, хотя синтаксис шаблонов Svelte определенно короче.
Опыт разработчиков достаточно отличается, так что, хотя некоторые вещи аналогичны, это совсем другой опыт. Компоненты в Solid дешевы, поэтому не бойтесь иметь их больше.
Solid обязан своим существованием Knockout. Мотивом для этого проекта была модернизация модели для детального обнаружения зависимостей. Knockout был выпущен в 2010 году и поддерживает Microsoft Explorer обратно в IE6, в то время как большая часть Solid не поддерживает IE вообще.
Привязки Knockout - это просто строки в HTML, которые просматриваются во время выполнения. Они зависят от контекста клонирования ($ parent и т. Д.). В то время как Solid использует JSX или тегированные шаблонные литералы для создания шаблонов, выбирая JavaScript API.
Самая большая разница может заключаться в подходе Solid к пакетной обработке изменений, который обеспечивает синхронность, тогда как в Knockout есть deferUpdates, который использует отложенную очередь микрозадач.
Если вы привыкли к Knockout, примитивы Solid могут показаться вам странными. Разделение чтения и записи сделано намеренно и не только для того, чтобы усложнить жизнь. Постарайтесь принять ментальную модель состояние/действие/поток. Хотя библиотеки и выглядят похожими, продвигают они разные передовые практики.
Эти библиотеки невероятно похожи и оказали некоторое влияние на Solid. В основном этот скомпилированный код Solid использует очень похожий метод для первоначального рендеринга DOM. Клонирование элементов шаблона и использование заполнителей комментариев - это то, что объединяет Solid и эти библиотеки.
Самая большая разница заключается в том, что, хотя эти библиотеки не используют виртуальную модель DOM, они обрабатывают рендеринг одинаково, сверху вниз, требуя разбиения компонентов для поддержания разумности. В отличие от этого Solid использует свой мелкозернистый реактивный график только для обновления того, что было изменено, и при этом использует эту технику только для первоначального рендеринга. Этот подход использует преимущества начальной скорости, доступной только для нативной DOM, а также обеспечивает наиболее эффективный подход к обновлениям.
Эти библиотеки довольно минимальны, и их легко построить поверх. Однако имейте в виду, что - это не просто HTMLElement (массив или функция). Постарайтесь сохранить свои вещи в шаблоне JSX. Подъем работает по большей части, но лучше всего мысленно думать об этом как о библиотеке рендеринга, а не о фабрике HTMLElement.
Эта библиотека оказала наибольшее влияние на реактивный дизайн Solid. Solid использовал S.js в течение нескольких лет, пока набор функций не разместил их на разных путях. S.js - одна из самых эффективных реактивных библиотек на сегодняшний день. Он моделирует все с синхронными временными шагами, как цифровая схема, и обеспечивает согласованность без необходимости выполнять многие из более сложных механизмов, имеющихся в таких библиотеках, как MobX. Реакционная способность Solid - это своего рода гибрид между S и MobX. Это дает ему большую производительность, чем у большинства реактивных библиотек (Knockout, MobX, Vue), сохраняя при этом простоту ментальной модели для разработчика. В конечном счете, S.js по-прежнему является более производительной реактивной библиотекой, хотя разница едва заметна во всех, кроме самых изнурительных синтетических тестов.
RxJS - это реактивная библиотека. Хотя Solid имеет аналогичное представление о наблюдаемых данных, он использует совершенно иное применение паттерна наблюдателя. В то время как сигналы похожи на простую версию Observable (только следующую), шаблон автоматического обнаружения зависимостей заменяет около сотни операторов RxJS. Solid мог бы использовать этот подход, и действительно, более ранние версии библиотеки включали аналогичные операторы, но в большинстве случаев проще написать собственную логику преобразования в вычислениях. Там, где Observable являются холодным запуском, одноадресной рассылкой и принудительной рассылкой, многие проблемы на клиенте поддаются горячему запуску и многоадресной рассылке, что является поведением Solid по умолчанию.
Angular и несколько других популярных библиотек заметно отсутствуют в этом сравнении. Отсутствие опыта работы с ними не позволяет проводить адекватные сравнения. Как правило, Solid не имеет ничего общего с более крупными фреймворками, и их намного сложнее сравнивать.