Фреймворк развивает remote functions для чтения и изменения данных прямо из компонентов.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Разработчики SvelteKit готовят крупное обновление фреймворка и одновременно продвигают новый подход к обмену данными между браузером и сервером. В центре внимания оказались remote functions, позволяющие вызывать серверную логику практически как обычные функции прямо из компонентов, сохраняя типобезопасность и избавляя разработчика от ручного создания API-маршрутов и дополнительного кода для <code>fetch</code>. Команда Svelte считает remote functions вместе с асинхронными возможностями Svelte будущим клиент-серверного взаимодействия во фреймворке.
Команда Svelte перевела SvelteKit 3 в стадию Release Candidate 13 августа 2026 года. Стабильный выпуск должен последовать после тестирования RC, если разработчики не обнаружат проблем, требующих новых несовместимых изменений. Remote functions при этом не относятся к полностью новым возможностям третьей версии: механизм появился еще в SvelteKit 2.27 и пока остается экспериментальным. Разработчики предупреждают о возможных ошибках и изменениях API без предварительного уведомления.
Svelte появился в 2016 году благодаря разработчику Ричу Харрису, работавшему над интерактивной графикой для интернет-изданий. В отличие от React, Svelte сделал ставку на компиляцию компонентов во время сборки. Значительная часть работы фреймворка выполняется заранее, а браузер получает скомпилированный JavaScript вместо крупной универсальной среды выполнения. Позднее вокруг Svelte появился SvelteKit, добавивший маршрутизацию, серверный рендеринг, загрузку данных и другие возможности для создания полноценных веб-приложений.
Сравнения SvelteKit с Next.js часто касаются не только удобства разработки, но и объема передаваемых данных. В опубликованном в августе бенчмарке KrabArena одинаковую страницу товара реализовали на SvelteKit, Remix и Next.js. Медианный размер серверного HTML составил 3115 байт у SvelteKit, 3982 байта у Remix и 9408 байт у Next.js. В рамках конкретного теста SvelteKit сформировал примерно втрое меньший HTML-ответ, чем Next.js. Результат нельзя считать универсальным доказательством превосходства одного фреймворка над другим, поскольку размер ответа зависит от архитектуры приложения, используемых функций и условий тестирования.
Remote functions решают другую проблему. Традиционная архитектура часто заставляет разработчика отдельно создавать серверный обработчик, определять маршрут, отправлять запрос через <code>fetch</code>, сериализовать данные и следить за совпадением типов между клиентской и серверной частью. Согласно документации SvelteKit , разработчик может объявить функцию в файле <code>.remote.js</code> или <code>.remote.ts</code>, после чего импортировать функцию в компонент. На сервере код остается обычной серверной функцией и может обращаться к базе данных, переменным окружения и другим закрытым ресурсам. Для браузера SvelteKit автоматически превращает импорт в оболочку над <code>fetch</code>, обращающуюся к сгенерированной HTTP-точке.
Подход особенно полезен для страниц, где большая часть содержимого остается статической, а небольшой компонент должен получать свежие данные. Например, статическая страница может содержать динамический блок в нижней части. Классическая схема может потребовать отдельного загрузчика или переноса загрузки данных выше по дереву маршрутов. Remote function позволяет разместить запрос ближе к компоненту, которому действительно нужны данные, и обновлять результат без полной перезагрузки страницы.
Первоначальная мотивация SvelteKit как раз затрагивала ограничения <code>load</code>-функций. При использовании <code>load</code> данные страницы загружаются в отдельном файле и затем передаются компоненту через <code>data</code>. При сложной структуре приложения возникает связь между файлами, а небольшие локальные запросы приходится поднимать на уровень страницы или layout. Повторная загрузка также может затрагивать более крупный набор данных, чем требуется отдельному компоненту. Разработчики подробно разбирали подобные ограничения при обсуждении remote functions .
SvelteKit предлагает четыре основных разновидности remote functions. <code>query</code> предназначена для чтения динамических серверных данных, <code>form</code> обслуживает отправку форм, <code>command</code> выполняет операции записи вне привязки к конкретной форме, а <code>prerender</code> получает статические данные во время предварительной генерации. Аргументы функций можно проверять через библиотеки, совместимые со Standard Schema, включая Zod и Valibot.
Механизм <code>query</code> получил собственную систему дедупликации. SvelteKit сериализует аргументы запроса и использует результат в качестве ключа кэша. Несколько одинаковых вызовов в рамках одного серверного запроса не заставляют приложение выполнять одинаковую работу повторно, а на клиенте одинаковые вызовы используют один экземпляр запроса. Метод <code>refresh</code> позволяет принудительно запросить свежую версию данных с сервера.
Актуальная документация описывает и <code>query.batch</code>, рассчитанную на борьбу с проблемой N+1. Одновременные запросы в пределах одной макрозадачи объединяются, поэтому сервер может обработать набор аргументов одним обращением к источнику данных вместо множества отдельных операций.
Еще одна возможность, <code>query.live</code>, предназначена для данных, обновляющихся в реальном времени. Серверная функция может возвращать асинхронный поток значений, а клиент сохраняет соединение, пока результат используется компонентом. Несколько потребителей одной live query разделяют соединение, а после обрыва SvelteKit пытается восстановить связь с экспоненциальной задержкой. Во время серверного рендеринга SvelteKit использует первое полученное значение, после чего передает начальное состояние клиенту при гидратации.
Название remote functions отсылает к RPC, удаленному вызову процедур. Разработчик вызывает функцию из клиентского кода, хотя фактическое выполнение происходит на сервере. SvelteKit скрывает сетевой слой, сериализацию и создание HTTP-точки, но серверные функции все равно фактически становятся доступными через сеть. Команда Svelte поэтому сознательно требует размещать remote functions в отдельных <code>.remote</code>-файлах и не смешивать серверный код с обычным клиентским модулем.
Похожую задачу решает Next.js с помощью React Server Functions. Серверные функции Next.js также можно вызывать с клиента через сетевой запрос, а в контексте изменения данных используется название Server Actions. Однако документация Next.js в первую очередь описывает Server Actions как механизм изменения данных. Для чтения информации Next.js активно использует Server Components и другие механизмы загрузки.
Разница делает remote functions SvelteKit более универсальной абстракцией для непосредственной работы компонентов с сервером: <code>query</code> отвечает за чтение, <code>form</code> и <code>command</code> за изменение данных, <code>prerender</code> за заранее вычисляемую информацию, а <code>query.live</code> за потоковые обновления. Сравнивать подход напрямую с Server Actions все же нужно осторожно, поскольку Next.js предлагает отдельную архитектуру Server Components для получения данных на сервере.
Связь двух конкурирующих экосистем выглядит необычно. Создатель Svelte Рич Харрис присоединился к Vercel в 2021 году, чтобы работать над Svelte полный рабочий день. Vercel одновременно развивает Next.js и финансирует работу над Svelte, при этом Svelte сохраняет статус независимого проекта с открытым исходным кодом.
Remote functions не стали единственным заметным изменением SvelteKit 3. RC переносит конфигурацию SvelteKit в <code>vite.config.ts</code>, заменяет внутренний алиас <code>$lib</code> на стандартные subpath imports <code>#lib</code>, упрощает конфигурацию TypeScript, перерабатывает работу service worker, расширяет механизм переменных окружения и улучшает обработку ошибок. SvelteKit 3 также требует Svelte 5 и Vite 8, поэтому переход с предыдущей основной версии содержит несовместимые изменения. Для миграции команда подготовила автоматизированную команду <code>sv migrate</code>, способную выполнить часть преобразований и сформировать список оставшихся задач.
Несмотря на уверенный тон разработчиков, remote functions пока рано считать окончательной заменой <code>load</code> и form actions. Официальный анонс SvelteKit 3 оставляет механизм под экспериментальным флагом, пока команда устраняет оставшиеся проблемы. <code>load</code>-функции продолжают работать, а разработчикам производственных приложений придется учитывать возможность дальнейших изменений API. При этом направление развития SvelteKit уже обозначено достаточно четко: команда хочет сделать типобезопасные серверные функции, вызываемые непосредственно из компонентов, одним из основных способов связи браузера с сервером.
<div class="articl-text-cover" style="position:relative;width:100%;max-width:800px;margin-left:auto;margin-right:auto;aspect-ratio:1200/675;margin-bottom:2rem;overflow:hidden">
<div itemprop="articleBody">Разработчики SvelteKit готовят крупное обновление фреймворка и одновременно продвигают новый подход к обмену данными между браузером и сервером. В центре внимания оказались remote functions, позволяющие вызывать серверную логику практически как обычные функции прямо из компонентов, сохраняя типобезопасность и избавляя разработчика от ручного создания API-маршрутов и дополнительного кода для <code>fetch</code>. Команда Svelte считает remote functions вместе с асинхронными возможностями Svelte будущим клиент-серверного взаимодействия во фреймворке.
Команда Svelte перевела SvelteKit 3 в стадию Release Candidate 13 августа 2026 года. Стабильный выпуск должен последовать после тестирования RC, если разработчики не обнаружат проблем, требующих новых несовместимых изменений. Remote functions при этом не относятся к полностью новым возможностям третьей версии: механизм появился еще в SvelteKit 2.27 и пока остается экспериментальным. Разработчики предупреждают о возможных ошибках и изменениях API без предварительного уведомления.
Svelte появился в 2016 году благодаря разработчику Ричу Харрису, работавшему над интерактивной графикой для интернет-изданий. В отличие от React, Svelte сделал ставку на компиляцию компонентов во время сборки. Значительная часть работы фреймворка выполняется заранее, а браузер получает скомпилированный JavaScript вместо крупной универсальной среды выполнения. Позднее вокруг Svelte появился SvelteKit, добавивший маршрутизацию, серверный рендеринг, загрузку данных и другие возможности для создания полноценных веб-приложений.
Сравнения SvelteKit с Next.js часто касаются не только удобства разработки, но и объема передаваемых данных. В опубликованном в августе бенчмарке KrabArena одинаковую страницу товара реализовали на SvelteKit, Remix и Next.js. Медианный размер серверного HTML составил 3115 байт у SvelteKit, 3982 байта у Remix и 9408 байт у Next.js. В рамках конкретного теста SvelteKit сформировал примерно втрое меньший HTML-ответ, чем Next.js. Результат нельзя считать универсальным доказательством превосходства одного фреймворка над другим, поскольку размер ответа зависит от архитектуры приложения, используемых функций и условий тестирования.
Remote functions решают другую проблему. Традиционная архитектура часто заставляет разработчика отдельно создавать серверный обработчик, определять маршрут, отправлять запрос через <code>fetch</code>, сериализовать данные и следить за совпадением типов между клиентской и серверной частью. Согласно документации SvelteKit , разработчик может объявить функцию в файле <code>.remote.js</code> или <code>.remote.ts</code>, после чего импортировать функцию в компонент. На сервере код остается обычной серверной функцией и может обращаться к базе данных, переменным окружения и другим закрытым ресурсам. Для браузера SvelteKit автоматически превращает импорт в оболочку над <code>fetch</code>, обращающуюся к сгенерированной HTTP-точке.
Подход особенно полезен для страниц, где большая часть содержимого остается статической, а небольшой компонент должен получать свежие данные. Например, статическая страница может содержать динамический блок в нижней части. Классическая схема может потребовать отдельного загрузчика или переноса загрузки данных выше по дереву маршрутов. Remote function позволяет разместить запрос ближе к компоненту, которому действительно нужны данные, и обновлять результат без полной перезагрузки страницы.
Первоначальная мотивация SvelteKit как раз затрагивала ограничения <code>load</code>-функций. При использовании <code>load</code> данные страницы загружаются в отдельном файле и затем передаются компоненту через <code>data</code>. При сложной структуре приложения возникает связь между файлами, а небольшие локальные запросы приходится поднимать на уровень страницы или layout. Повторная загрузка также может затрагивать более крупный набор данных, чем требуется отдельному компоненту. Разработчики подробно разбирали подобные ограничения при обсуждении remote functions .
SvelteKit предлагает четыре основных разновидности remote functions. <code>query</code> предназначена для чтения динамических серверных данных, <code>form</code> обслуживает отправку форм, <code>command</code> выполняет операции записи вне привязки к конкретной форме, а <code>prerender</code> получает статические данные во время предварительной генерации. Аргументы функций можно проверять через библиотеки, совместимые со Standard Schema, включая Zod и Valibot.
Механизм <code>query</code> получил собственную систему дедупликации. SvelteKit сериализует аргументы запроса и использует результат в качестве ключа кэша. Несколько одинаковых вызовов в рамках одного серверного запроса не заставляют приложение выполнять одинаковую работу повторно, а на клиенте одинаковые вызовы используют один экземпляр запроса. Метод <code>refresh</code> позволяет принудительно запросить свежую версию данных с сервера.
Актуальная документация описывает и <code>query.batch</code>, рассчитанную на борьбу с проблемой N+1. Одновременные запросы в пределах одной макрозадачи объединяются, поэтому сервер может обработать набор аргументов одним обращением к источнику данных вместо множества отдельных операций.
Еще одна возможность, <code>query.live</code>, предназначена для данных, обновляющихся в реальном времени. Серверная функция может возвращать асинхронный поток значений, а клиент сохраняет соединение, пока результат используется компонентом. Несколько потребителей одной live query разделяют соединение, а после обрыва SvelteKit пытается восстановить связь с экспоненциальной задержкой. Во время серверного рендеринга SvelteKit использует первое полученное значение, после чего передает начальное состояние клиенту при гидратации.
Название remote functions отсылает к RPC, удаленному вызову процедур. Разработчик вызывает функцию из клиентского кода, хотя фактическое выполнение происходит на сервере. SvelteKit скрывает сетевой слой, сериализацию и создание HTTP-точки, но серверные функции все равно фактически становятся доступными через сеть. Команда Svelte поэтому сознательно требует размещать remote functions в отдельных <code>.remote</code>-файлах и не смешивать серверный код с обычным клиентским модулем.
Похожую задачу решает Next.js с помощью React Server Functions. Серверные функции Next.js также можно вызывать с клиента через сетевой запрос, а в контексте изменения данных используется название Server Actions. Однако документация Next.js в первую очередь описывает Server Actions как механизм изменения данных. Для чтения информации Next.js активно использует Server Components и другие механизмы загрузки.
Разница делает remote functions SvelteKit более универсальной абстракцией для непосредственной работы компонентов с сервером: <code>query</code> отвечает за чтение, <code>form</code> и <code>command</code> за изменение данных, <code>prerender</code> за заранее вычисляемую информацию, а <code>query.live</code> за потоковые обновления. Сравнивать подход напрямую с Server Actions все же нужно осторожно, поскольку Next.js предлагает отдельную архитектуру Server Components для получения данных на сервере.
Связь двух конкурирующих экосистем выглядит необычно. Создатель Svelte Рич Харрис присоединился к Vercel в 2021 году, чтобы работать над Svelte полный рабочий день. Vercel одновременно развивает Next.js и финансирует работу над Svelte, при этом Svelte сохраняет статус независимого проекта с открытым исходным кодом.
Remote functions не стали единственным заметным изменением SvelteKit 3. RC переносит конфигурацию SvelteKit в <code>vite.config.ts</code>, заменяет внутренний алиас <code>$lib</code> на стандартные subpath imports <code>#lib</code>, упрощает конфигурацию TypeScript, перерабатывает работу service worker, расширяет механизм переменных окружения и улучшает обработку ошибок. SvelteKit 3 также требует Svelte 5 и Vite 8, поэтому переход с предыдущей основной версии содержит несовместимые изменения. Для миграции команда подготовила автоматизированную команду <code>sv migrate</code>, способную выполнить часть преобразований и сформировать список оставшихся задач.
Несмотря на уверенный тон разработчиков, remote functions пока рано считать окончательной заменой <code>load</code> и form actions. Официальный анонс SvelteKit 3 оставляет механизм под экспериментальным флагом, пока команда устраняет оставшиеся проблемы. <code>load</code>-функции продолжают работать, а разработчикам производственных приложений придется учитывать возможность дальнейших изменений API. При этом направление развития SvelteKit уже обозначено достаточно четко: команда хочет сделать типобезопасные серверные функции, вызываемые непосредственно из компонентов, одним из основных способов связи браузера с сервером.
- Источник новости
- www.securitylab.ru