Что делает Next.js таким хорошим?

Он упрощает рабочий процесс разработки, проще говоря, предоставляет множество встроенных решений и оптимизаций. Next.js — это платформа React, которая использует последнюю, чтобы облегчить жизнь разработчика при создании веб-приложений.

Как я раньше разрабатывал веб-приложения/веб-сайты

Это своего рода ретроспектива того, как все было до модных технологий. Это короткое путешествие о том, как мы придумали React. Не стесняйтесь пропустить его и узнать больше о Next.js в следующих разделах.

Чистый HTML, эпоха CSS: простые веб-сайты

Когда я только начинал заниматься веб-разработкой, я помещал простые блоки <div> в Блокнот, добавляя некоторые стили CSS. Это просто. Мне не нужно знать никаких фреймворков, дополнительных технологий. Еще несколько блоков <div>, немного текста и кнопок, и я получил боковую панель, меню и блок контента с текстом.

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

Не идеальный метод, но он хорошо работает для простого одностраничного веб-сайта.

Использование шаблонизаторов для повторного использования компонентов

![Шаблонный движок, такой как Pug, позволяет создавать атомарные компоненты, чтобы избежать дублирования кода]

Существовали (и до сих пор существуют) инструменты, уменьшающие дублирование кода. Такие инструменты, как Pug и другие, представляют собой сценарии Javascript, которые компилируют пользовательский синтаксис HTML в стандартный HTML. С их помощью разработчик может создать один компонент (например, шапку со ссылками) и разместить его на многих страницах, не дублируя код компонента. Если мне нужно изменить стиль или структуру компонента, я изменяю код в одном месте.

Они также предоставляют помощники для форматирования HTML. Например, функции Javascript для написания текста заглавными буквами. Теперь проще создать многостраничный сайт. Я создаю несколько основных компонентов для своего веб-сайта и повторно использую их почти на каждой странице.

От веб-сайтов к веб-приложениям: обработка состояния приложения

Было время, когда компании начали заменять настольные приложения веб-приложениями. Они хотели автоматизировать многие вещи для клиентов. Например, они начали создавать сайты для приема заказов.

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

Мы можем хранить состояние на сервере, но таким образом мы усложняем сервер. К тому же это не всегда удобно. Например, я хочу хранить много информации о текущем пользователе и сразу использовать ее на следующей странице, а потом забыть об этом. Скажем, это преобразование изображения в черно-белое с помощью Javascript. Было бы эффективнее не нагружать наш сервер, а вместо этого сделать такое преобразование на стороне клиента.

Мы могли бы сохранить состояние или даже несколько состояний в локальном хранилище браузера или в IndexedDB, верно? Правильный. Однако затем нам нужна логика для обновления нашего пользовательского интерфейса при изменении состояния. Мы можем обновить все, когда что-то изменится в нашем состоянии, но тогда появится другая проблема. Отзывчивость нашего веб-сайта не в порядке: производительность плохая.

React, например, решает проблему компонентов (шаблонов) и проблему управления состоянием. С его помощью я могу создавать оптимизированные веб-приложения, упрощая взаимодействие между многими компонентами.

Почему стоит выбрать React или Vue? Они упрощают разработку сложных веб-приложений. Обработка локального (на уровне компонента) и глобального состояния проще. Повторное использование компонентов намного проще.

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

React: плюсы и минусы

Мы говорили о том, как трудно не дублировать код на других веб-страницах. React позволяет разработчику создавать маленькие или большие компоненты и повторно использовать их где угодно. Мы можем включать маленькие компоненты в более крупные и включать их в более крупные компоненты. Таким образом, мы уменьшаем повторяемость кода и получаем полный контроль над состоянием локального компонента. Следовательно, мы оптимизируем веб-приложение.

Pro: производительность благодаря виртуальному DOM

React создает дополнительный уровень API [DOM] (https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model/Introduction) для оптимизации производительности. Так как библиотека позволяет создавать UI, состоящий из множества компонентов, она пытается обновить как можно меньшее их количество, чтобы избежать стандартной нагрузки на повторный рендеринг браузера. Стандартно я имею в виду не обновлять всю веб-страницу, когда у нас есть только незначительное изменение состояния. Зачем перерисовывать все элементы в DOM, если мы можем перерисовать те, которые зависят от измененных данных, верно?

Pro: огромное сообщество

Любая великая технология поддерживается большим сообществом. Если он небольшой, то сложно найти ответы на странные (или любые) вопросы в Stackoverflow или найти библиотеку для рисования простого зеленого круга. В мире Javascript это сообщество является одним из крупнейших. То же самое относится и к React, его части.

Если мне нужно сделать стилизованную таблицу в React, я могу найти ее в Google. Если мне трудно понять какое-то странное поведение с библиотекой, найти ответ несложно.

Минусы: не для меня

React хорошо работает для задач, которые он решает. Легко создать новый проект и начать программировать. Для меня не сложно научиться. И, в дальнейшем, это ускоряет развитие. Тогда зачем эта статья о Next.js?

Преимущества Next.js после использования React

Сообщество React создало CLI-инструмент create-react-app для создания экземпляра нового проекта и немедленного просмотра результата. И мне понравилось это для моих простых веб-приложений.

Однако у моих следующих проектов были публичные страницы, блог. Решение может состоять в том, чтобы настроить сервер и отображать страницы там, чтобы возвращать подготовленный HTML. Или использовать другие инструменты: движок блога, движок статического сайта.

Встроенный сервер/статический рендеринг

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

Зачем заботиться о серверном рендеринге?

При предоставлении веб-страницы поисковым системам лучше предоставить им HTML-страницу без Javascript. Google, например, также может понимать Javascript (следовательно, обычное приложение React может быть «понято»), но он отправляет веб-сайт в очередь рендеринга, что занимает больше времени, чем обработка страниц, когда робот Googlebot читает веб-сайт с простым HTML.

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

Другая вещь, связанная с предыдущей, — это улучшенная производительность для пользователей (и поисковых ботов). Сервер отображает страницу, а браузеры показывают ее без необходимости компилировать Javascript. Однако это связано с дополнительной нагрузкой на сервер: он должен отображать страницу для каждого пользователя (особенно если страница состоит из динамических данных).

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

Next.js позволяет мне создать страницу, которая [предварительно отображается по умолчанию] (https://nextjs.org/docs/basic-features/pages). Либо во время сборки (статическая генерация, страницы повторно используются для каждого запроса), либо во время компиляции (SSR, следовательно, рендеринг при каждом запросе).

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

Программное SEO

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

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

Однако это ключевое слово популярно, и новый веб-сайт не получит поддержки Google. Следовательно, мы можем ориентироваться на ключевые слова с длинным хвостом, мы сохраняем основное намерение («лучшие риелторы»), но указываем местоположение. Таким образом, «лучшие риелторы Киева» не так популярны, как «лучшие риелторы», и мы ориентируемся на более конкретные цели на нашей веб-странице.

Однако нам потребуется больше времени, чтобы построить такие страницы одну за другой, верно? Большую часть кода можно было скопировать-вставить, отличается только список с риелторами. Если мы нацелимся на «лучших риелторов» в 10 000 различных городов, это будет очень много работы. Что, если мы хотим настроить таргетинг на ключевые слова типа «лучшие агенты в Киеве»? Мы меняем слово, и нам нужны дополнительные 10 000 веб-страниц.

Вот в чем дело: у нас уже есть списки риелторов в разных городах, у нас есть шаблон веб-страницы. С Next.js создать множество страниц для программного SEO очень просто. Имейте список ключевых слов, один код (шаблон), и фреймворк создаст страницу для каждого указанного вами ключевого слова.

Встроенная маршрутизация

Помните, как вы выбираете маршрутизатор для нового проекта React? Они почти одинаковы, имеют некоторые отличия, а некоторые библиотеки работают стабильно. С проектом Next.js мне не нужно думать о том, какой маршрутизатор использовать на этот раз (может быть, какую-то другую библиотеку?). Есть встроенный роутер. И это просто: вы помещаете файл в папку pages, и он становится страницей.

Например, я хочу создать страницу с URL-адресом <myapp>/sign-in. Я помещаю туда компонент sign-in.tsx или папку sign-in с компонентом index.tsx, и все работает.

Маршрутизатор предоставляет все необходимые функции: динамические маршруты, вложенные маршруты, страницы ссылок.

Встроенный сервер API

Там есть папка pages/api, где я могу указать конечные точки API. Вот несколько хороших вариантов использования:

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

1. Запросите ресурсы на других доменах. Чтобы избежать проблемы с CORS ([пример проекта] (https://github.com/vercel/next.js/tree/canary/examples/api-routes-cors)). Часто мне нужно запросить сторонний ресурс, но я не могу это сделать из-за CORS. Одно из решений — создать сервер, отправить туда запрос, а затем перенаправить его на сторонний сервер. Однако сэкономим время. Для простых запросов (и даже немного сложных, Next.js тоже может с этим справиться) лучше использовать pages/api.

Встроенная оптимизация изображений и шрифтов

Я не хочу оптимизировать такие активы на каждой странице, которую я кодирую. В начале некоторых проектов это обычно не является главным приоритетом. Но здорово, когда фреймворк выполняет огромную часть работы по оптимизации ресурсов (есть и другие сложные приемы оптимизации, которые нам обычно не нужны). Вы вставляете изображение, и оно автоматически уменьшается, без изменения макета, и загружается лениво!

Переменные среды

При кодировании приложения Next.js доступны две среды: браузер и сервер. Переменные среды в браузере видны, если вы хотите найти их в связанном коде. Переменные сервера скрыты, поскольку пользователи не имеют доступа к удаленным хостам и их коду.

С Next.js я могу создать как env. переменные без настройки webpack и установки другой библиотеки для обработки env. переменные для сервера. Фреймворк имеет встроенную поддержку для них!

Есть файл .env, в котором я указываю переменные сервера, и в том же файле я могу указать переменные браузера, добавив префикс к переменной – NEXT_PUBLIC_. Мне невероятно удобно.

Резюме

Next.js экономит мне много времени при работе с текущими и новыми проектами. Я могу легко комбинировать несколько приложений и иметь только одну кодовую базу. Однако преимущества, о которых я писал, могут не относиться к вашему варианту использования. Если вы используете React сейчас, стоит попробовать Next.js, фреймворк добавляет полезные функции поверх плюсов React.

Если у вас есть вопросы или отзывы, дайте знать мне.

Также опубликовано [здесь] (https://metacognitive.me/why-do-i-use-next-js-in-my-projects/)