Сегодня фронтенд-разработка и JavaScript являются синонимами. И в то время как новый, передовой JavaScript-фреймворк или инструмент экосистемы, кажется, появляются каждые несколько месяцев, обещая более быстрое время сборки или более быстрый пользовательский опыт, «простые» React и основанные на React фреймворки, такие как Next.js, продолжают доминировать. Когда мы смотрим на устоявшиеся фреймворки пользовательского интерфейса браузера, используемые клиентами Sentry, неудивительно, что экосистема React опережает их — во многом.
ЧасовойВ Sentry мы смотрим как на отраслевые показатели, так и на наши собственные внутренние данные о внедрении SDK, чтобы решить, в какие фреймворки инвестировать. много данных, говорящих нам, чего хотят разработчики.
В этой статье мы используем эти данные, чтобы определить некоторые интересные тенденции в отношении того, куда движутся интерфейсные фреймворки, и почему мы думаем, что фреймворки на основе React, такие как Next.js — фреймворки, которые упрощают отображение веб-страниц на сервере — могли бы как это ни парадоксально, быть будущим фронтенд-разработки.
«Обычный» React лидирует… пока
React позволяет быстро и относительно легко создавать динамические пользовательские интерфейсы, оставляя ручные манипуляции с DOM вне поля зрения и внимания. Хотя разработчики React могут не тратить много времени на отладку проблем из базовой библиотеки React, ошибки все же случаются. А поскольку Sentry сообщает своим пользователям «когда, что и почему» за ошибками приложения, мы можем измерить, как часто возникают ошибки проекта на основе React.
ЧасовойПомимо ошибок, нельзя отрицать, что React стал фреймворком для JavaScript. Одна из причин, по которой React стал популярным, заключается в том, как легко разработчики могут создавать динамические пользовательские интерфейсы в браузере, «из коробки». Но инновации в JavaScript еще не закончены.
Возможности рендеринга на стороне сервера (SSR) быстро становятся все более заметной функцией фреймворков JavaScript. SSR не является чем-то новым (например, PHP, Ruby и т. д.), и SSR не работает на основе JavaScript (Node.js). Что нового, так это то, что новые фреймворки позволяют разработчикам интерфейсов легко брать инструменты, которые они используют для создания клиентских приложений, таких как React, и эффективно использовать их для рендеринга контента на сервере.
Фреймворки с поддержкой SSR, такие как Next.js, который находится поверх React, позволяют разработчикам писать React так, как они привыкли, но фреймворк помогает как в первоначальном рендеринге этого контента на сервере, так и в «регидратации» частей клиента. Пользовательский интерфейс после его загрузки в браузере.
Это большое дело по двум причинам. Во-первых, это означает, что передние разработчики теперь владеют частью внутреннего стека — у них есть развернутый сервис, который необходимо отслеживать и поддерживать. Во-вторых, он разделяет фронтенд-разработчиков на две части: одна группа сосредотачивается на внешнем интерфейсе (например, CSS и специальные возможности), а другая — на внутреннем интерфейсе (выборка данных, дизайн API и информационная архитектура).
Вернувшись к конечному пользователю, рендеринг на стороне сервера предлагает большое преимущество по сравнению с платформами рендеринга на стороне клиента (CSR): доставка готового контента в браузер быстрее. И когда у всех нас продолжительность концентрации внимания на уровне золотой рыбки, ожидание на полсекунды дольше, пока загружается страница, может быть разницей между пользователями, оставившим свою корзину, и проверкой. Стоит отметить, что SSR также может помочь с SEO, но сначала давайте сосредоточимся на скорости.
SSR ведет к более быстрой сети
В отличие от CSR, с SSR вашим пользователям не нужно ждать, пока пакет JavaScript будет загружен и выполнен на клиенте. Это особенно важно для библиотек рендеринга, таких как React, где JavaScript используется для рендеринга и обновления контента, а не только для добавления интерактивности. Поскольку HTML обрабатывается сервером, браузер может отображать контент, как только он передается по сети, — гораздо быстрее, чем пользователь мог бы работать через CSR.
Небольшой недостаток заключается в том, что пользователю по-прежнему необходимо загрузить файлы JavaScript вашего приложения, прежде чем страница станет интерактивной. Но поскольку первоначальный HTML будет загружаться намного быстрее, чем большой пакет JavaScript, а JavaScript можно загрузить асинхронно, приложение будет «чувствовать» себя намного быстрее. Подводя итог, SSR будет отображать контент быстрее, чем CSR, но, поскольку вам придется ждать, пока функциональность не будет заполнена на клиенте, возможна заметная задержка интерактивности.
Рендеринг на стороне сервера с помощью Next.js отлично подходит для улучшения воспринимаемой производительности вашего приложения, но остерегайтесь затрат на гидратацию вашего потока JS. Ваша страница может казаться быстрой, но потребуется больше времени, чтобы пользователь мог ее использовать.
– Бен Зохарстарший инженер-программист, Arcade
Откуда мы знаем, что разработчики, использующие SSR, заботятся о скорости? Учтите, что пользователи Sentry могут отслеживать производительность приложений, отправляя данные транзакций в Sentry. Мы разумно ожидаем, что если пользователи Sentry, создающие приложения с SSR-фреймворками, заботятся о производительности, мы увидим больше активности в этих проектах.
ЧасовойНа графике слева показано, какой процент организаций (также известных как учетные записи Sentry) с главным образом установленным проектом CSR или SSR отслеживают производительность (то есть отправляют транзакции в Sentry). Для фреймворков CSR мы включили обычных подозреваемых: React, Vue, Ember и Angular. В категорию SSR мы включили Svelte, Remix и Next.js. Учитывая, что 91% проектов SSR отслеживают производительность, а 81% проектов CSR отслеживают производительность, можно без преувеличения сказать, что разработчики, использующие платформы с поддержкой SSR, уделяют больше внимания производительности своих приложений.
В Sentry любимый фанатами Next.js, в котором большое внимание уделяется SSR, быстро становится вторым по популярности интерфейсным фреймворком после традиционных приложений React CSR. Это неудивительно, учитывая, что фреймворк ориентирован на производительность и опыт разработчиков. Такое внимание к производительности, вероятно, является причиной того, что мы наблюдаем рост числа проектов Next.js. колоссальные 240% в годовом исчислении в Сентри.
ЧасовойОптимизация для SEO
Поскольку Google хочет направлять пользователей на страницы, которые загружаются быстро (то есть не вращающиеся пляжные мячи), страницы с более быстрой загрузкой занимают более высокое место в результатах обычного поиска. Улучшенная скорость загрузки страницы является большим преимуществом SEO для фреймворков SSR, но есть нечто большее, чем скорость загрузки страницы, которая делает SSR лучше, чем CSR для SEO.
Когда поисковый робот Google (также известный как Googlebot) решает, что показывать в результатах поиска, он индексирует HTML-код страницы и отображает его в JavaScript, когда у Google есть доступные вычислительные ресурсы. Если вы используете CSR, эта часть «когда ресурсы будут доступны» означает, что вы зависите от Googlebot для отображения вашего веб-сайта. С помощью SSR Google сканирует полностью отображаемые страницы, поэтому весь ваш контент индексируется. Версия TLDR: SSR позволяет роботу Googlebot быстрее рассматривать весь ваш контент, поэтому у вас больше шансов появиться в результатах поиска.
В конечном итоге мы решили, что рендеринг на стороне сервера лучше всего создает кодовую базу для успеха SEO; и выбрал Next.js в качестве основы для его облегчения.
– Рэйчел Черч, инженер-программист, Airtable
Это конец КСО?
Не существует универсального решения для интерфейсных фреймворков. Поскольку CSR и SSR решают разные потребности, мы не ожидаем, что они исчезнут в ближайшее время. Но поскольку разработчики ищут способы сделать свои приложения быстрее, мы считаем, что фреймворки, упрощающие SSR (например, Next.js), будут продолжать набирать обороты.
Как упоминалось выше, SSR предлагает скорость и преимущества SEO, с которыми CSR (в большинстве случаев) не может сравниться. Но SSR не для всех. Для команд, которые хотят быстро создавать динамический контент, CSR-фреймворки, как правило, проще в использовании. Другая причина – стоимость. CSR передает вычислительную мощность конечному пользователю, в то время как SSR требует, чтобы вы платили за вычисления. Это может означать большой счет от вашего поставщика облачных услуг, если вы создадите следующую сенсацию веб-приложения за одну ночь.
Независимо от типа веб-приложения, которое вы создаете, новые веб-фреймворки и инструменты упрощают создание динамического контента. А с постоянно снижающейся стоимостью вычислительной мощности (спасибо поставщикам облачных услуг) будущее фреймворков, упрощающих SSR, таких как Next.js, выглядит ярким.
Бен Винегар в настоящее время является вице-президентом по новым технологиям в Sentry, где он работает с командами над расширением платформы мониторинга ошибок и производительности Sentry для решения новых проблем разработчиков. Он также является соавтором Сторонний JavaScript, а иногда и выступающим на конференциях. Он живет и работает в Торонто, Канада.
—
New Tech Forum представляет собой площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор субъективен и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Присылайте все запросы на newtechforum@infoworld.com.
