Смотрим на тренды и те технологии веб разработки, которые будут развиваться в ближайшие годы.
Хотя, по моему личному мнению, ландшафт разработки веб-сайтов замедлился на несколько лет (2016-2021), в прошлом году он начал приобретать больше популярности (см. также [State of JS] (https://2022.stateofjs.com/), часть изображений для этой статьи были взяты там). В этой статье я хочу отметить новые тенденции в разработке веб-сайтов, которые я видел, и которые, безусловно, будут продолжать вызывать интерес среди веб-разработчиков, и которые меня волнуют в следующем году. Давайте прямо перейдем к ним.
Веб фреймворки (META)
Одностраничные приложения (SPAs) и соответствующие им фреймворки (например, React.js, Vue.js, Svelte.js) прошли через более или менее циклы популярности и уже несколько лет находятся на рынке. Однако с ростом мета-фреймворков поверх этих решений мы можем наблюдать явный тренд перехода приложений от клиентской отрисовки (CSR) к серверной отрисовке (SSR). SSR в настоящее время присутствует практически во всех JavaScript-фреймворках.
Самый популярный мета-фреймворк под названием Next.js построен на базе React.js. Ядро разработчик React, Эндрю Кларк, пойдя так далеко, назвал его «реальным релизом React 18» в 2022 году, потому что он включает в себя все батареи (например, Suspense, streaming SSR), которые команда React предоставляет в качестве основных конструкторов на более низком уровне библиотеки. Как Vercel (компания за кулисами Next.js), так и команда ядра React.js тесно сотрудничают для предоставления отличного опыта разработчика.
Хотя многие разработчики с беспокойством отслеживают близкие отношения между Next.js и React.js, существуют альтернативы React.js, такие как Remix (недавно приобретенный Shopify), которые принимают другой подход к превращению React.js в мета-фреймворк (например, использование веб-стандартов в качестве первоклассных граждан), но есть и общие функции (например, вложенное маршрутизирование) между обоими фреймворками из-за их конкуренции.
Несмотря на то, что Next.js уже установил себя как претендент в современном пространстве SSR и превратил многих фронтенд-разработчиков естественным образом в полноценных профессионалов по разработке полноценных приложений, другие фреймворки также должны быть в вашем понимании: SvelteKit (построенный на Svelte.js) с недавним выпуском 1.0, поддерживаемым Vercel, и SolidStart (построенный на Solid.js) с улучшенным DX по сравнению с React.js.
Веб приложения и паттерны рендеринга
В течение последнего десятилетия (2010-2020) доминировали одностраничные приложения (SPA) с их клиентским рендерингом (CSR), начиная с Knockout.js и Ember.js и заканчивая Angular.js, React.js и Vue.js, в последние годы возросло интерес к серверному рендерингу (SSR) с мета-фреймворками. Со стороны кажется, что цикл закрывается снова, потому что до этого (2005-2010) мы долгое время использовали SSR с простым JavaScript (например, jQuery, MooTools, Dojo.js) в многостраничных приложениях (MPAs). Однако, в отличие от того времени, когда для SSR использовался Java (например, JSP) или позднее Ruby on Rails, сейчас мы полагаемся на JavaScript. На протяжении нескольких лет Next.js был главным двигателем этого тренда, однако другие мета-фреймворки, такие как SvelteKit, набирают обороты.
SSR долгое время конкурирует со статическим генератором сайтов (SSG) за идеальную производительность (см. Next.js против Gatsby.js), несмотря на то, что оба шаблона служат совершенно разным целям. В то время как последний шаблон используется для статического контента (например, веб-сайтов, таких как блог или сайты документации), первый используется для динамического контента (например, веб-приложений). Если SEO актуален, то и SSR, и SSG могут иметь смысл. Однако при требовании высоко динамичного контента или пользовательского контента с аутентификацией разработчики не могут выбрать SSG (один раз собрано перед деплоем, поэтому статическое) и должны решить между SSR (построение по требованию для каждого запроса с индивидуальными данными на сервере) или CSR (получение по требованию индивидуальных данных на клиенте) в эти дни.
CSR, SSR и SSG не являются самыми последними тенденциями для техник рендеринга, хотя и начали тренд по оптимизации производительности несколько лет назад. Более тонкие техники рендеринга, такие как инкрементальный статический регенератор (ISR) и Streaming SSR, появились в последнее время. Первый продвигает SSG, поскольку позволяет статически перестраивать веб-сайт на основе отдельных страниц (например, перестраивать страницу X каждые 60 секунд), а не перестраивать весь веб-сайт. Даже дальше, инкрементальный статический регенератор по требованию, также называемый перевалидацией по требованию, может использоваться для запуска перестроек через приложение, поддерживающее API (например, при обновлении данных CMS).
Streaming SSR с другой стороны оптимизирует однопоточный ботленд серверного рендеринга. В то время как обычный SSR должен ждать на сервере данных, чтобы отправить отрендеренное содержимое клиенту одним пакетом, Streaming SSR позволяет разработчикам делить приложение на части, которые могут быть последовательно и параллельно отправлены с сервера на клиент.
За последние годы паттерны рендеринга были довольно прямолинейными с SSG и SSR в SPAs / MPAs. Однако в последнее время все больше трендуют более тонкие версии. Но не только ISR и SSR streaming становятся более актуальными, но и частичная гидрация (например, React Server Components), которая позволяет гидрировать только некоторые из ваших компонентов на клиенте, прогрессивная гидрация, которая дает более тонкий контроль над порядком гидрации, архитектуры островов (например, [Astro] (https://astro.build/)) для изолированных приложений или компонентов в MPA и использование возобновляемости вместо гидрации (например, [Qwik] (https://qwik.builder.io/)) становятся действительными подходами в настоящее время.
Serverless тоже в тренде
Техники рендеринга, такие как SSR и SSG, сильно связаны с тенденцией безсерверного вычисления на краю, потому что обе они ориентированы на производительность с целью обеспечения бесперебойного пользовательского опыта в браузере. В конечном итоге желание предоставить пользователям быстрее сайты и веб-приложения пробудило интерес к безсерверному вычислению на краю.
Но давайте начнем с начала: безсерверное вычисление, также известное как безсерверные функции, безсерверные вычисления (например, AWS Lambda) или облачные функции (например, Google / Firebase Cloud Functions) является большой тенденцией в облачных вычислениях уже несколько лет. Хотя безсерверное вычисление все еще означает имение запущенного (удаленного) сервера, разработчику не нужно управлять сервером и связанными с ним задачами (например, масштабирование инфраструктуры по требованию). Вместо этого нужно развернуть одну функцию в качестве безсерверной функции, которую заботится облачный поставщик.
Безсерверные функции открыли другую преимущество, потому что вместо развертывания вашего сервера приложений в одном (или нескольких) дата-центрах может быть десятки их по всему миру. Поэтому в идеальном мире безсерверные функции должны быть запущены как можно ближе к их пользователям, потому что это означало бы наименьший клиент-серверный раундтрип и, следовательно, улучшенный пользовательский опыт. Развертывание безсерверных функций как можно ближе к пользователю привело к терминам вычисления на краю и функции на краю.
Многие облачные поставщики (например, Cloudflare с Cloudflare Workers, Vercel со своей сетью Edge, Deno с Deno Deploy) соревнуются в этой области, где каждый оптимизирует лучший опыт времени до интерактивного (TTI) для своих конечных пользователей. Функции на краю не только обслуживают контент SSG / SSR быстрее (потому что провод до конечного пользователя короче), но могут также кэшировать свои результаты ближе к пользователю.
Но не только производительность имеет значение, несмотря на то, что это главный двигатель, другие преимущества, такие как уменьшение расходов, также приходят с вычислениями на краю. Например, часто не все данные, отправленные между клиентом и сервером (здесь функция на краю), должны быть вычислены основным дата-центром. В IoT есть много нерелевантных данных (например, видеозаписи без изменений на кадр), отправленных в основной дата-центр, которые просто могли бы быть отфильтрованы на краю. В конце концов, функции на краю только начало …
Ренессанс баз данных
С появлением серверных технологий (на краю), базы данных также претерпевают ренессанс. С помощью функции без сервера разработчики быстро столкнулись с проблемой открытия слишком многих подключений к базе данных, поскольку нет одного сервера, который будет держать одно подключение, а много функций без сервера с одно к одному подключением к базе данных. Пул подключений является решением для этой проблемы, но либо нужно самостоятельно заботиться об этом, либо использовать услуги третьей стороны.
Популярные конкуренты в области баз данных без сервера — PlanetScale (MySql), Neon (PostgreSQL) и Xata (PostgreSQL), которые предлагают множество функций, таких как ветвление базы данных, различие схем и мощные поиски/аналитика/инсайты. Когда дело доходит до безсерверных технологий по всему миру, они предоставляют кэширование на краю или распределенную только для чтения базу данных, чтобы переместить данные ближе к пользователям для минимальной задержки.
Если услуга третьей стороны не должна только распределять вашу базу данных, но и ваше приложение, Fly.io пакует все в одну платформу. Это приводит нас далеко за пределы просто баз данных, где также происходит много движения. Railway, видимый как преемник Heroku, приносит все для платформы как сервис (PaaS), чтобы развернуть ваш технологический стек. Если вы хотите перейти на уровень выше по цепочке услуг к бэкэндам как сервису (BaaS), вы получаете открытую альтернативу Firebase с Supabase, которая поставляется с хостингом приложений/баз данных, аутентификацией и функциями на краю.
Движки JavaScript
Все началось, когда Райан Даль объявил о Node.js на конференции в 2009 году. Что началось как эксперимент, который отключил JavaScript от браузера и сделал его доступным на сервере, стало одним из главных двигателей успеха JavaScript за последнее десятилетие. В основном Райан Даль использовал JavaScript-движок под названием V8 (реализованный в Chrome) для Node.js без самого браузера. Таким образом, как браузер Chrome, так и Node.js используют один и тот же JavaScript-движок, но имеют свои собственные JavaScript-рантаймы (например, браузерные API против API Node) для взаимодействия с ним.
Десять лет спустя Райан Даль объявил о Deno в качестве преемника Node с обещанием предоставить разработчикам более безопасную и быструю среду, которая поставляется с похожими на браузер API, TypeScript и стандартной библиотекой из коробки. Deno, который также работает на V8, является лишь одним из многих JavaScript-рантаймов сегодня.
В конкурирующем мире функций края многие провайдеры облачных услуг реализуют свой собственный JavaScript-рантайм (например, Cloudflare Workers), который оптимизируется для своей собственной инфраструктуры (например, Cloudflare). Таким образом, бизнес-модель Deno также становится провайдером облачных услуг с Deno Deploy и их фреймворком для рендеринга на краю с поддержкой SSR (который начался как доказательство концепции) под названием Deno Fresh. Независимые от провайдера облачных услуг решения, такие как Bun (работающие на движке JavaScriptCore и реализованные в Zig), недавно стали другим вирусным хитом в гонке за самым быстрым JavaScript-рантаймом.
Острый ум бы заметил (еще раз) многофрагментность в ландшафте JavaScript из-за разных рантаймов. Если все потеряется из-за разнородности, мы окажемся в той же ситуации, что и в те дни, когда была фрагментированная поддержка JavaScript в браузерах, но уже на сервере, где не все JavaScript может быть одинаково поддерживаемым на разных рантаймах при развертывании на разных провайдерах облачных услуг. Поэтому все участники (например, Deno, Vercel, Cloudflare) присоединились к WinterCG, чтобы сотрудничать по взаимозаменяемости API между своими JavaScript-рантаймами.
Utility-First CSS
Разработчики либо любят его, либо ненавидят: Tailwind CSS является примером для первично применяемого CSS. Хотя одна сторона разработчиков ненавидит его за представление громоздкого кода в интерфейсе пользователя, другая сторона любит его за отличный DX. Как разработчик, вы настраиваете его один раз в проекте и можете использовать предопределенный CSS прямо в HTML.
Этот раздел любви и ненависти к первично применяемому CSS может закончиться с недавним появлением серверной обработки (SSR). Несколько лет в стиле CSS-in-JS, такие как Styled Components (SC) и Emotion, были преобладающей силой для стилизации современных компонентных веб-приложений. Однако, если производительность в мире SSR является одной из основных целей, CSS-in-JS имеет негативные последствия: увеличение размера пакета (SC с 12,7 КБ, Emotion с 7,9 КБ) и, более важно, перегрузка времени выполнения из-за сериализации CSS перед вставкой его в DOM.
Поэтому мы можем видеть разработчиков, переходящих к дружественным для SSR решениям, таким как первично применяемый CSS (например, Tailwind CSS, UnoCSS) в сочетании с предопределенными компонентами интерфейса пользователя (например, DaisyUI), другими равно популярными альтернативами, такими как CSS Modules, или недооцененными называемыми нулевыми временем выполнения/компиляции CSS-in-JS (например, vanilla-extract, linaria, astroturf, compiled).
Монорепы
В прошлом монорепозитории в основном использовались для крупных приложений, где одна проект содержит меньшие проекты в одном репозитории контроля версий. Каждый из этих меньших проектов может быть чем угодно от отдельного приложения (например, SPA, MPA) до переиспользуемого пакета (например, функций, компонентов, служб). Практика объединения проектов ведет свою историю с начала 2000-х годов, когда она называлась общей базой кода.
Однако в настоящее время монорепозитории не ограничены только крупными приложениями, а также меньшими компаниями и проектами с открытым исходным кодом, которые безусловно от них получат пользу. Например, компания может иметь различные пакеты в монорепозитории, от общих компонентов пользовательского интерфейса, общей системы дизайна (например, переиспользуемого корпоративного дизайна) до часто используемых функций утилит для соответствующего домена.
Эти пакеты могут быть импортированы в различные приложения: само приложение (например, app.mywebsite.com с клиентским рендерингом), которое использует все эти общие пакеты, домашняя / продуктовая / лендинг-страница (например, mywebsite.com с рендерингом на стороне сервера или статическим генерированием сайта) с учетом SEO, использует только пакет общей системы дизайна, а также страницу технической документации (например, docs.mywebsite.com), которая использует общие компоненты пользовательского интерфейса и пакеты общей системы дизайна.
Turborepo (приобретенный Vercel) вновь вызвал гипер монорепозитория в JavaScript / TypeScript. Turborepo позволяет командам создавать пайплайны сборки для всех их приложений и пакетов в монорепозитории. Главный аттракцион: кэширование сборок в пайплайне на локальном компьютере или в облаке для всех команд. Пара Turborepo с другими важными инструментами монорепозитория, такими как npm / yarn / pnpm workspaces (управление зависимостями) и changesets (версионирование), делает эту цепочку инструментов местом, которое стоит наблюдать в этом году.
Конкуренты Turborepo — Nx, Rush и Lerna (не поддерживается для давнего времени, затем приобретено компанией Nrwl компании Nx).
Безопасность с TypeScript со обеих сторон
Эволюция от JavaScript до TypeScript неостановима. В этом большом переезде веб-разработки полноценная типизация для полностью стековых приложений, безусловно, является важным трендом. Реализация этой концепции зависит и падает со слоя связи (API), который необходим для привязки типизированных сущностей (например, type User, type BlogPost) от сервера к клиентскому приложению.
Обычными подозреваемыми в веб-разработке для клиент-серверного взаимодействия являются REST и GraphQL. Оба могут быть использованы с OpenAPI для REST и GraphQL Code Generator для GraphQL для генерации типизированного файла схемы для клиентского приложения.
Однако есть новая восходящая звезда для типизированных API под названием tRPC, который может быть использован в качестве замены REST/GraphQL. Если вы работаете в монорепозитории TypeScript, где фронтенд и бэкенд делят код, tRPC позволяет экспортировать все типы из бэкенда в клиентское приложение без какой-либо промежуточной генерации типизированной схемы. В результате клиентское приложение может вызывать API бэкенда, просто используя типизированные функции, которые подключены по HTTP под капотом, чтобы обеспечить фактическое клиент-серверное взаимодействие. Общий тренд, безусловно, движется к использованию большего количества этих типизированных решений для полностью стековых приложений, таких как tRPC, Zod, Prisma и TanStack Router, которые все обеспечивают типизацию на краю приложения.
Билдеры веб приложений
В React-land, create-react-app (CRA) доминировал на поле в течение нескольких лет. Это была небольшая революция в то время, потому что новичкам давался готовый проект запуска React без необходимости настраивать custom Webpack с React setup. Однако за последний год Webpack быстро устарел.
Vite — это новый подросток на блоке, когда речь идет о одностраничных приложениях (SPAs), потому что он работает со всеми популярными фреймворками (например, React.js) для создания проекта запуска. Реализованный Эваном Ю, создателем Vue.js, он называет себя инструментарием для следующего поколения фронтенда. Внутри он получает свою силу от esbuild, который по сравнению с другими пакетами JavaScript написан на Go и поэтому пакует зависимости на 10-100 раз быстрее, чем его конкуренты (например, Webpack).
В то время как экосистема Vite растет благодаря дополнениям, таким как Vitest (альтернатива Jest для тестирования), другие конкуренты, такие как Turbopack от Vercel, появились недавно. Turbopack называется преемником Webpack, потому что его было предложено Тобиасом Копперсом, создателем Webpack. Поскольку Next.js все еще использует Webpack и Turbopack разрабатывается той же компанией, мы можем ожидать, что в будущем Next.js и Turbopack, вероятно, будут идеальным сочетанием.
AI-driven разработка
В конечном итоге ИИ займет ли работу разработчика? На этот вопрос пока нет ответа, но в 2022 году появилось приложение ИИ для разработки. С помощью GitHub Copilot разработчики могут подключиться к ИИ-программисту в их любимой среде разработки. Это просто: написать код (или комментарий, что вы хотите написать) и GitHub Copilot автоматически завершит детали реализации по лучшему пониманию.
Но это не заканчивается здесь: ChatGPT от OpenAI — это более общая модель языка, которая также занимается программированием. Вы можете задавать ChatGPT свободные вопросы, а также выполнять задачи по программированию. Многие разработчики уже заметили, что используют ChatGPT в качестве замены StackOverflow. Во многих ситуациях ChatGPT предоставлял полезные ответы (не всегда безупречно), когда использовался в качестве замены поисковика. Поскольку последний должен сталкиваться со многими SEO-спамом (не только для содержания, связанного с разработкой), ChatGPT сейчас считается достойной альтернативой.
«На данный момент» — важное выражение здесь. С высокоуровневой точки зрения, содержание, созданное ИИ, может (и будет) также наносить вред всемирной паутине. Где ручное создание SEO-контента уже было проблемой раньше, никто не мешает кому-то производить больше автоматически сгенерированного SEO-контента с помощью ChatGPT. В конечном итоге ChatGPT будет обучаться на собственно сгенерированном контенте?
Есть несколько замечательных упоминаний, которые я не хочу забыть, но которые не вошли в перечисленные тенденции: Tauri в качестве альтернативы Electron для настольных приложений, реализованных с помощью JavaScript / CSS / HTML, Playwright в качестве альтернативы Cypress для конечно-конечного тестирования, Warp и Fig в качестве следующего поколения терминалов, CSS Container Queries в качестве альтернативы CSS Media Queries для адаптивного дизайна и, наконец, htmx в качестве обогащенного HTML для создания интерактивных пользовательских интерфейсов без JavaScript. Поскольку я дал только краткое изложение здесь, я призываю вас самостоятельно проверить их!
Итого
Надеюсь, что я смог предоставить вам отличный обзор состояния экосистемы веб-разработки.
Понимание этих трендов позволит лучше планировать свой путь развития и понимать на какие проекты обратить внимание.
Какие то технологии стоить выбирать для экспериментов в рамках своих пет проектов.
И так мы можем быть в тренде.
Основано на базе: https://www.robinwieruch.de/web-development-trends/ + ряд своих мыслей.
