Интерфейсный код теперь может выполняться на серверной части?

Может ли он достичь «написал один раз, работает везде»?

Недавно Cloudflare объявила в своем официальном блоге, что официально запустила новую группу сообщества — WinterCG в партнерстве с Vercel, Shopify и отдельными основными участниками Node.js и Deno. Его полное название — Группа сообщества Runtimes, взаимодействующая с Интернетом, которая занимается интероперабельной реализацией стандартизированных веб-API в средах разработки на основе JavaScript без веб-браузера.

Так может ли JavaScript действительно «написать один раз, работать везде»?

Какую проблему они пытаются решить?

В бессерверной среде, такой как Cloudflare Workers, или среде выполнения, такой как Node.js и Deno, многие требования такие же, как и в среде веб-браузера. Например, эти API: fetch(), ReadableStream и WritableStream, URL и т. д.

Основная цель W3C и Рабочей группы по технологиям веб-гипертекстовых приложений (или WHATWG) состоит в том, чтобы обеспечить разработку и поддержку стандартизированных API-интерфейсов для среды веб-браузера. И эти небраузерные среды выполнения реализовали свои собственные специальные решения. Это заставляет разработчиков следить за ними при переключении среды.

Таким образом, недавно созданная WinterCG попытается это изменить. Они предоставляют площадку для обсуждения и отстаивания общих требований всех веб-сред, развернутых в любом месте стека.

В чем преимущества для нас, разработчиков?

Хотя Cloudflare Workers, Node.js, Deno и веб-браузеры сильно отличаются друг от друга, у них много общих функций. Например, они оба предоставляют возможность отправлять HTTP-запросы, они оба предоставляют API для генерации криптографических хэшей и т. д.

Представьте, если бы все они реализовали один и тот же общий стандарт для этого, тогда разработчику вообще не нужно было бы переписывать его при переходе в другую среду, просто чтобы он продолжал делать то же самое.

Поэтому нам, разработчикам, нужно заботиться только о том, чтобы код, который мы пишем, работал правильно, независимо от того, где он выполняется. Это означает, что код JavaScript, который обычно работает в браузере, может быть перенесен для нормального выполнения во внутреннем коде.

Что они собираются делать?

WinterCG не собирается выпускать собственный набор независимых стандартных API. Идеи для новых спецификаций, созданные в WinterCG, передаются на рассмотрение в существующие рабочие процессы в W3C и WHATWG. Если у веб-браузеров нет особой потребности и интереса к новой спецификации, WinterCG будет уполномочена продвигать свои собственные спецификации, но эти спецификации не окажут никакого влияния на установленные веб-стандарты.

Так что для нас, разработчиков, стоимость обучения будет ниже.

Каков их текущий прогресс в работе?

Вот некоторые из работ, над которыми они сейчас работают:

Минимальный общий веб-API

«Минимальный общий API-интерфейс веб-платформы — это тщательно отобранный набор стандартизированных API-интерфейсов веб-платформы, предназначенный для определения минимального набора возможностей, общих для браузерных и небраузерных сред выполнения на основе JavaScript».

Это из введения в проект спецификации. Другими словами, эти API представляют собой минимальный набор существующих веб-API, которые будут последовательно и правильно реализованы в Node.js, Deno и Cloudflare Workers.

Этот список содержит наши общие Event, URL, globalThis.self, globalThis.console, globalThis.navigator.userAgent, globalThis.setTimeout() / globalthis.clearTimeout(), globalThis .setInterval() / globalThis. clearInterval() и так далее. Более подробную информацию можно найти здесь".

Потоки веб-криптографии

API веб-криптографии в браузере не поддерживает потоковый ввод и вывод для алгоритмов симметричного шифрования. Это серьезно ограничивает производительность и масштабируемость криптографических операций. Поэтому WinterCG начала составлять новую спецификацию для Web Crypto Streams, которая будет представлена на рассмотрение W3C. Цель состоит в том, чтобы сделать потоковые криптографические операции доступными для всей сети, включая веб-браузеры, в соответствии с существующими стандартами.

Подмножество fetch() для серверов

Node.js предоставляет реализацию стандартизированного API fetch() WHATWG по адресу 18.x. Однако существуют важные различия в том, как эти небраузерные среды выполнения и веб-браузеры реализуют fetch() (например, отсутствие проверки CORS между источниками и т. д.).

Таким образом, трудно достичь консенсуса по стандартам выборки, поэтому WinterCG работает над набором стандартов выборки для этих различных требований и ограничений для этой цели. Это подмножество будет полностью совместимо со стандартом выборки для браузерных сред, а также послужит документированным руководством по правильной реализации выборки в этих небраузерных средах.

Заключение

Ключевая цель, которую пытается достичь новая Группа сообщества сред выполнения с веб-совместимостью (или WinterCG), состоит в том, чтобы максимизировать веб-совместимость. Это означает реализацию функций способом, который либо идентичен, либо, по крайней мере, максимально согласован с тем, как эти функции реализованы в веб-браузерах.

Существуют определенные различия между этими средами выполнения JavaScript, и эти различия также влияют на проектные решения для стандартизированных API. Например, отсутствует механизм перекрестного происхождения CORS и ограничения доступа к локальной файловой системе в серверной среде. Поэтому я думаю, что небольшая часть перекрывающихся функциональных требований может быть повторно использована и реализована напрямую, а эти конфликтующие места могут быть тщательно спроектированы.

Но в любом случае для нас, разработчиков, написанный нами JavaScript более переносим, а стоимость перехода на платформу ниже. Это определенно добавляет новую жизнь в JavaScript. Так что ты думаешь?