Svelte 5 Runes і SolidJS Signals: апдэты интерфейса без павтаральнага рендароўкі

Кожны разработчык на React рано чым вынуждан адказваць, чаму компонент атрыбутаваецца чатыры разы, калі нічога візуальна не змянілася, і чаму для выправлення патрэбны memo, маса залежнасцяў і стабільны калебак. Svelte і SolidJS выйшлі з іншай практыкі: якщо фрэймворк точна ведае, якая частка статау падтрымлівае які элемент DOM, ён можа апдэйтаваць той елемент і зовсім не перзапускать компоненты. У этай статыце пояснюецца, як кожны з іх досягае гэтаго, як выглядае код у практыцы, чаму ў их модэлі разлікі з React і Angular, а таксама як выбраць, чыі з іх падходзяў для вашага наступнага проекту.

Віртуальны DOM быў засобам, а не метай

Ключовая ідея React, калі ён быў запусцаны у 2013 годзе, — это вярчыны DOM. Інтерфейс описываецца як функцыя стану. Калі стан змінюецца, React зноў вызывае ваш компонент, стварае новы дрэва ў памяці, поручае яго з паканальным і прыкладзае толькі разлікі да рэальнага DOM.

Такіяя дызайн зробіў інтерфейсы значна працэсабельнымі па супорачанню з ручной маніпуляцыяй DOM, і ён застаецца правільным модэлем. Аднак ён таксама мае своія затраты. Функцыя компонента запускаецца зноў, незалежна ад таго, чы трэба зменіць яе выход, выдзеляецца новы дрэва, і працюець процес поручання, каб выявіць, што насправды зменілася, і ў найгоршым случае все гэта рабіцца для апдэйту ўсьмоўнага <span>. Якщо вы хочаце дакладнасці пра тое, што поручае рэкансіляр і чаму, статыя па тэме «Як працюе поручання вярчыны DOM» адпаведзае на гэтыя запытанні.

Большая частка API React з тэх падзеў — memo, useMemo, useCallback, а таксама нешта часоўней — React Compiler — створаныя для таго, каб ухіліцца ад роботы, яку інакш выканала бы модэль адрасавання та разлічэння. Кампайляр автаматызуе процес мемаізацыі, таму развівачым не трэба ўжо самім пісаць такі код, але основная модэль застаецца незменнай: компоненты зноў запускаюцца, а оптымізацыя значыць перакананне іх не робіць гэтага. У стацыі на тое, што оптымізуе React Compiler і што ён залишае вам прадстаўленыя гэтыя меры.

Svelte та Solid ставяць простейшы вопыт: што, якбы залежнасць між кожным элементам стану та кожным вузлом DOM была точна вядома, і тады пад час змены стану быў перакінуты лячыць толькі той вузел?

Svelte: кампайляр, які пісае код для аднавлення за вас

Svelte — гэта прыглавная чынюючая кампайляр. Вы ствараеце компаненты ў файлах з расшырэннем .svelte, а пад час зборкі Svelte ператварае іх у звычны JavaScript, які безпосередня маніпулюе DOM. Не існуе віртуальнага DOM і няма робочыя пераканалення, а ў браузер выкладаецца толькі маленькая чынюючая.

Пачынаючы з Svelte 5, реактыўнасць выражаецца через руны — явныя прымітывы, якія распазнае кампайляр. Наведзены выкладком компанент адзначае частку стата і значэнне, якое вылучаецца з яго, а пасля відобразвае іх оба ў кнопцы:

<script>
  let count = $state(0);
  let doubled = $derived(count * 2);
</script>
<button onclick={() => count++}>
  {count} doubled is {doubled}
</button>

Это ўсё, што складаецца з компаненту. Няма функцыі-зменнікі і няма массива залежнасцей. Вы збільшаеце count як звычную зменную, і адтуды, што кампайляр вже аналізав, якія частыні маркапу чытаюць count і doubled, ён стварае код, які апдэюе саме тыя вузлы тексту. $derived перасчыляецца толькі тады, калі змянюецца ўсё, што ён чытае. Заўважкайте, што працоўнікі з адборама падзеяў у Svelte 5 — это звычныя атрыбуты, такія як onclick, якія заменяюць старэйшую синтаксіс дыректывы on:click.

Чаму команды яго любяць

• Менш коду для таго ж рэзультата. Без хуків, функцый-зменнікіў чы абгорткаў-компанентоў, компаненты Svelte зазвычай выходзяць значна корачэй, чым іх адпаведнікі ў React. Менш коду значыць менш месцаў для бягоў і шырэйшыя перагляды.

Маленькі пакеты. Паколькі большая частка роботы выканачваецца пад час компілявання, вартасць фрэймворка ў браузеры є низкай. Для сайтаў з контентам, стартовых сторанак і ўсіх тых випадкаў, дзе важліва першая загрузка, гэта є справжнім бізнес-прыямым.

Знакомыя элементы стварэння веб-сайтаў. Маркап, стылі і скрыпты знаходзяцца ў аднам файле і чытаюцца як HTML, CSS і JavaScript. Няма спецыфічных для JSX правілаў, такіх як className, што робіць файлы зрозумелымі для дизайнераў і аднароджухоў, якіе не пішуць на React.

Для цэлых прыкладнікаў SvelteKit дадае механізмы маршрутацыі, сервернай рэндарованасці і канцаўкі API, выпольваючы тую ж ролю, яку Next.js выпольвае для React, пры чым славіцца простейшай наладой.

Є адзін момент, якій варта з’ясавіць з самага пачатку: руны ўжоўваюцца як фічы кампайляра, таму яны працуюць толькі ў файлах .svelte і ў модулях, названых з суфіксамі .svelte.js або .svelte.ts. Перанесенне реакtyўной логікі ў звычны файл .js не будзе працаваць без такой назвы.

SolidJS: JSX, які запускаецца раз

Спачатку Solid можна паспамінуць з React. Ён таксама вжоўвае JSX, складае маленькія функцыі, а кантэйнер выглядае практычна таксама:

function Counter() {
  const [count, setCount] = createSignal(0);
  return (
    <button onClick={() => setCount(count() + 1)}>
      Count: {count()}
    </button>
  );
}

Разлік, який дзіўніць розробнікам React, заключаецца ў тым, што Counter запускаецца роўна адну раз. Solid пабудаваны на дробнай реактыўнасці за дапамогою сігналаў. createSignal вяртае геттер і сэттер, прычаму геттер count() — це вызов функцыі, а не простая значэнне. Калі JSX чытае count() усередине выразу, Solid фіксуе, што гэты конкретны тэкстовы вузол залежыць ад гэтага сігналу. Вызов setCount пазней апдэйтуе толькі гэты тэкстовы вузел, а не што-небудзь іншае. Функцыя компонента была лишэнь шагам падготовкі, який запоўзаў сігналы з вузламі DOM; яна больш ніколи не запускаецца, таму няма чаго перерэндараваць.

Гэтыя механізмы ўскладнююць процес павтаральнага атрыбутавання элементаў, таму Solid дасягае высокіх рэзультатаў у стандартных тестах на выконвальную спроможнасць фрэймворкаў, часта практычна дагадваючыся рэзультаты ручна напісанага JavaScript. Спрыймайце будзь-які ранг у тэстах як момантальную дыягнаміку і ацэнюйце сабой вашу робочую навантажэння, але архітектурная перадача ёсць рэальной: выкарыстоўванне апдэйтаў касаецца прыбліжна таго, што зменілася, а не розмеру дрэва компонентаў.

Чаму команды яго любяць

• Няма патрэбы ў павтаральнай обработцы. Не винікае пытання, чаму ў React што-небудзь было атрыбутавана. Функцыі useMemo, useCallback і React.memo не маюць аналага, таму што няма чога прыховваць.

Прыведжымы эфекты. Эфект выконваецца, калі змянюецца сигнал, які ён чытае, а не тады, калі компонент працюе занова і масэва завыскаў дазволяе гэта. Застарелыя замкнутасці, вядомая проблема React, практычна зніклі, таму што значэнні завжды чытаюцца свежыя через гетеры.

Паўзлівы пераход з React. JSX і складанне компонентоў пераходзяць практычна без змян, таму команде, якая працуе з React, больш за ўсё трэба забыць болючыя аспекты, а не перанавучацца з нуля.

Звычкі, якія трэба забыць

Модэль адзінаго выканання мае наследкі, які стваряюць труднасці для новачкаў. Разбіранне пропаў на пачатку компонентая зчитвае ўсі іх значэнні толькі адзін раз, што парадужае рэактыўнасць, таму пропы зазвычай адбываюцца як props.name. Раннія вяртання і тэрнары ў тэле функцыі адмацаваюцца толькі адзін раз, і самэ гэта ўважае прычыной таго, што Solid аддае компоненты керавання прабэгам, такія як Show і For. Калі гэтыя правілы стануць зрозумелымі, яны будуць адносова стабільныя, але яны ёсць галоўным джерелам багоў для разработчыкаў, якія пераходзяць з React.

Як гэта паўтарыцца з React і Angular

Глэбэйшая разніца ў філасофскіх, а не сынтаксічных аспектах.

React перапрацавіў свою основную модель, дадаў функцыі „перзапуск і прапорачынанне разніцы“, і працаваў гады над стварэнням інструментаў, якія маглі бы зменшыць вартасць адпрацоўкі гэтай моделі. Ён застаецца чырвоным выборам: яго екасістэма неперадарожная, працеваяць з якім проста, а компілятор React рэальна зменшуе неабходнасць ручнай мемоізацыі. Аднак ёсць праблема — вы працуеце в меры, якая была створаная пад абмежэнняя свайго часу.

Angular — это варыянт для крупных корпорацый з усіма неабходнымі функцыямі: ввод залежнасцей, RxJS і часткавыя правілы для практычна всіх аспектаў. Ён добра справляецца з вельмі большыми кодавымі базамі, але ў яго існуюць значныя трудносці пад час навчання і викорыстоўвання. Яго найзначнейшыя неякшнія змены — сігналы і адчуванне змян без зон — прыводзяць яго да болей тонкай реактыўнасці, якая популярная ў Solid.

Такая супрацяга ўсведамліваецца ў всій індустрыі. Angular апрацаваў механізмы сігналоў, React запрацаваў кампайляр для часу будовы, новэйшыя фреймворкі, такія як Qwik, базуюцца на дробнай реактыўнасці, а Vue, чыяе реактыўнае збераганне дадзеных завжды было блізкае да сігналоў, шукае свае сопныя стратэгіі кампайлявання. Было б пераценкай сказаць, што Svelte і Solid створылі кожную з гэтых ідэй, але яны рана і чыста паказалі, што кампайляванне і сігналы можу стаць адной з базовых частак фреймворка.

Чаму разработчыкі продовжаюць рухацца ў гэтым напрамку

Тры не такія вже й прыгожыя прычыны пояснююць большую частку інтересу:

• Менш фреймворкаў, якія трэба памяцать. Увага зосераджваецца на продукцыі, а не на семантыцы апдэйтаў фреймворка. Правільнае збераганне калебэкаў не ўважаецца значымай задачай.

Выконванасць без дадатковых настройкаў. У React чыра Angular швайнае прыладо — гэта тое, што ствараецца з вялікай адказнасцю. У Svelte чыра Solid зробіць прыладо повольным зазвычай трэба дакласті пазіроў.

Пашана да вашага часу. Меньшыя API, менш коду-шаблонаў і меньша колькасць падступных ситуацыяў. Рэзультаты апытакаванняў развіццяроў неаднакова павышалі як задоволенасць, так і інтерес да гэтых фреймворкаў, у той час як ўсё ўзростае іх загальная популярнасць на адносна малай базе.

Чы трэба вам перайсці?

Для вялікага продукту, гэта практычна не зараз. Калі ўжо існуе значны прыклад практычнаўання на React або Angular, і каманда добра ведае гэты стак, перапісваў яго ёсць аднам з найбяспечнейшых спосабоў адкладзіць роботу над проектам. Размах экасистемы таксама мае значэнне: у React є бібліятекі для практычна будзь-якіх задач, а хоць экасистемы Svelte і Solid ў розвіцеі, яны меньшы, таму заранее пераканайцеся, што элементы, ад якіх вы залежыце — такія як бібліятекі компонентав, інструменты для форм і інтеграціі з системамі аутанацыі — існуюць і ўтримваюцца.

Підход зменяецца для новых проектаў. Проект на чыстай падставе, віджет, чутлівы да выконання, або внутрэшній інструмент — гэта мяккія умовы для працы з такім падходам:

• выберыце Svelte, якщо хочаце простага шляху навучэння і сітуацыі, калі все працуе без проблем

Выберыце Solid, якщо ваша команда працуе на JSX і хочаць максымальную скорасць выконання з падтрымамі, сэроднімі React.

Заставайцеся з React або Angular, калі шырока екасистема, можлівасць працавання з спецыялістамі і ўжо наяўныя навыкі маюць большое значэнне, чым простая эфектыўнасць.

Ключовыя выводы

• Модэль render-and-diff у React є прыгадным, але робота выконваецца прыбліжна прымэрнай да глыбі дрэва компанентаў; мемоізацыя і React Compiler скарочуюць гэтую роботу без змены самай модэлі.
• Svelte 5 пераносіць реактыўнасць у компайлер за дапамогою такіх элементаў, як $state і $derived, чым ствараюцца прымусовыя апдэйты DOM і формуецца маленькі рантайм.
• Solid выконвае кожны компанент толькі адназначы і прыўязвае сігналы безпасяроджа да вузлаў DOM, чым усунуцца павтарныя апдэйты, але трэба выкладвацца на новыя практыки ў работе з пропамі і логікай керавання.
• Шырэй экасістэма спрыяе адаптаванню даўедзеных ідэй: аналіз у час складання, сігналы замест паўтаральнага атрыбутавання, і прымітывыя апдэйты замест вычыслення разніцы.
• Адпраўляйце гэтыя фреймворкі там, дзе іх прынтэгі ўжо маюць значэнне, а экасістэма падтрымае вашыя патрэбы; не перапісвайце стабільную базу кода толькі каб следаваць за трэндамі.