Современные способы генерации веб-сайтов

Современные способы генерации веб-сайтов

В этой статье вы прочитаете о способах генерации веб-сайтов, какие есть типы и т.д.

Также перед прочтением рекомендую прочитать статью «Что такое AJAX и как он работает», тоже очень интересная статья.

Способы генерации веб-сайтов:

Для начала покажу основные способы генерации веб-сайтов, их несколько:

  • SPA веб-приложения (клиентский рендеринг): отправьте только корневой <div> и позвольте JavaScript отобразить все остальное;
  • Статические страницы: полностью готовый HTML;
  • Серверный рендеринг (SSR): позвольте серверу обрабатывать запросы и генерировать HTML-ответы в реальном времени;

Эти варианты не исключают друг друга:

  • Веб-сайт может статически раздавать 75% своих страниц (например, статьи в блогах) и динамически обрабатывать остальные (например, форумы);
  • Встречаются веб-приложения, которые могут предварительно генерировать все страницы на сервере, но иметь пару пустых <div>, содержащих контент с рендером на стороне клиента (например, динамически отображаемое меню на основе данных вошедшего в систему пользователя);
  • Веб-страницы могут создаваться на сервере, но, если перед ним есть кеширование, то сайт будет вести себя как статический;
  • Веб-приложение может рендерить себя статически, но затем заполняться (hydrate) в сайт, полностью визуализируемый клиентом;
  • Веб-сайт может представлять собой сочетание серверного и статического рендеринга, но иметь динамические части, аналогичные рендерингу на стороне клиента, которые на самом деле выполняются в пограничной функции, поэтому в конечном итоге он больше похож на рендеринг на стороне сервера;

Next.js интересен тем, что может использовать все 3 варианта. Тим Нейткенс (Tim Neutkens) сообщил в недавнем интервью:

Next.js позволяет предварительно генерировать страницы. Он создает HTML на сервере во время сборки (статическая генерация) или использует рендеринг во время выполнения (SSR). Также Next позволяет смешивать оба подхода. В отличие от большинства других фреймворков вам разрешено отображать некоторые страницы на стороне сервера, а некоторые страницы генерировать статически.
В новом релизе мы сделали возможным обновлять статически сгенерированные страницы без необходимости запускать процесс сборки всего приложения.

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

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

Клиентский рендеринг также открывает двери для «SPA» ощущения. Лично мне очень нравится создание плавных переходов вместо загрузки новой страницы.

Гэтсби (Gatsby.js) известен популяризацией динамического наполнения (hydration), когда вы получаете предварительно сгенерированный статический сайт, а затем переходите на SPA по мере загрузки JavaScript.

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

Том Макрайт недавно написал об этом в своей статье «Если не SPA, то что?». Некоторые из сегодняшних альтернатив:

Turbolinks… какой минимум вам нужно сделать, чтобы получить ощущение SPA без какого-либо сотрудничества со стороны вашего приложения?

Turbolinks работает следующим образом: происходит щелчок по ссылке, он перехватывается, выполняется запрос Ajax для новой страницы, JavaScript подменяет содержимое страницы новым контентом. Такое поведение довольно легко реализовать, но это все еще JavaScript, и он не особенно подходит для отправки меньшего количества данных по сети.

barba.js и Instant.page — альтернативные подходы к решению данной проблемы.

Barba полностью завязана на переходе между страницами. Instant.page — это предварительная загрузка и рендеринг страниц до того, как пользователь решит перейти на них, поэтому, даже если вы обновляете страницу, это кажется менее навязчивым, особенно с удержанием краски (paint holding).

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

Итак, что еще мы можем попробовать? Есть <portal>. Возможно, слишком упрощенно, но порталы похожи на iframe. Их даже можно визуально отображать как фреймы.

Когда рендеринг URL-адреса на портале выполнен, вы можете подменить активную страницу на портал и даже при этом анимировать его.

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

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

Достаточно взглянуть на статью Сары (Sarah Drasner) «Нативная анимация для перехода между страницами в интернете». Это то, чего так не хватает разработчикам.

Вот почему Джереми (Jeremy Keith) на днях сказал, что «большинство одностраничных приложений — это просто гигантские карусели», указывая на предложение Джейка (Jake Archibald) о navigation-transitions, сделанное несколько лет назад.

Мне нравится это предложение. Оно ориентировано на потребности пользователей и отвечает вопрос, почему люди обращаются к фреймворкам JavaScript вместо того, чтобы использовать то, что предоставляют браузеры. Так происходит, потому что браузеры просто не имеют некоторых функций, таких как нативные вкладки (tabs) или аккордеоны, согласование DOM (DOM diffing), контроль стилизации элементов сложной формы, навигационные переходы. Проблемы, которые фреймворки JavaScript решают сегодня, следует рассматривать как отделы исследований и разработок веб-стандартов завтрашнего дня. И наоборот, я твердо верю, что цель любого хорошего фреймворка JavaScript должна состоять в том, чтобы сделать себя избыточным.

Итак, какой метод рендеринга лучший? Тот, который лучше всего подходит для вас, но, возможно, следующая иерархия имеет некоторый смысл:

  • Как можно больше статического HTML;
  • Пограничные функции поверх статического HTML для динамических вещей;
  • Сгенерированный сервером HTML (SSR);
  • Клиентский рендеринг, только если вы не можете без него обойтись;

Вывод:

В этой статье вы прочитали какие есть способы генерации веб-сайтов, думаю вам было интересно и полезно.

Подписываетесь на соц-сети:

Поделится:

Также рекомендую:

Подписаться
Уведомить о
0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии