MoscowJS 58 - Темная сторона NextJS - Александр Моргунов

Ғылым және технология

Cейчас почти на каждой фронтенд конференции есть доклад про самый популярный фреймворк, за которым будущее фронтенд разработки - NextJS. Рассказывают про новые фичи: серверные компоненты, серверные экшены, частичный пререндеринг с быстрой отдачей статического ответа и стримингом динамического контента. Кажется наконец-то появилось решение во фронтенде, которым все довольны. Но так ли все хорошо на самом деле? В том ли направлении развивается NextJS? О проблемах говорят не так много, поэтому может создаться впечатление, что их просто нет. Давайте сегодня об этом и поговорим. Спойлер: говорить будем про серверную составляющую и вендерлок.
moscowjs.org/events/moscowjs-58/
Все новости и анонсы MoscowJS в нашем телеграм-канале: t.me/moscowjs

Пікірлер: 25

  • @wardxela
    @wardxelaАй бұрын

    Спасибо за выступление, интересные мысли.

  • @snatvb
    @snatvb2 ай бұрын

    16:33 статически можно собрать, получить куки и хэдеры можно, это ж базовые вещи, странно что такое просочилось в доклад

  • @reactnext13
    @reactnext132 ай бұрын

    Понравилось выступление, стало более понятно в отличие от всяких блогеров

  • @wardxela
    @wardxelaАй бұрын

    26:29 - Не совсем понял претензию про контексты: почему их нет в app router? По-моему любой стейт менеджер можно подружить с этой архитектурой. Важно только вынести компонент инициализации контекста в отдельный файл и прописать 'use client'; В дальнейшем все серверные компоненты можно передавать как children. Единственное ограничение - вы не можете пользоваться этим контекстом в серверных компонентах. Вообще серверные компоненты - это про другой подход к построению приложения. Я их воспринимаю просто как способ что-то сделать на сервере и отдать полученное на клиент без возможности изменения. Любое изменение в серверном компоненте должно подразумевать очередной запрос на сервер.

  • @vladimircreator
    @vladimircreator2 ай бұрын

    18:10 * ещё Remix и Gatsby

  • @romanmed9035
    @romanmed90352 ай бұрын

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

  • @typingaway

    @typingaway

    24 күн бұрын

    Сдерживает то, что придется все приложение переписать. У нас толстый клиент и много логики перенесено на клиент. Из-за этого активно используется редакс и для перехода на AppRouter придется почти все рефакторить, на это к сожалению ресурсов нет. Что бы использовали, ниже ответил, что все зависит от задач. Так как нам нужно SEO (SSR), то использовали NextJS, скорее всего на PageRouter-е, но писали бы код так, что бы потом было просто мигрировать на AppRouter

  • @romanmed9035

    @romanmed9035

    24 күн бұрын

    @@typingaway спасибо за пояснения

  • @yohimik
    @yohimikАй бұрын

    7:38 такое легко делается через кастомный сервер 12:04 аналогично, некстовые либы возвращают хендлер, который работает с дефолтными нодовскими req и res, делай с ним что хочешь, хоть на express повесь, хоть на fastify кастомный логер для логирования некстовых сообщений, правда не добавишь (глобально костылить только типа console.log = () => ... или патчить файлы) рекомендация использовать page router жесть, может классовые компоненты тогда ещё? никто не будет в будущем сильно поддерживать page router, а новые функции будут в app router, тем более когда уже столько времени потратили на него. пока оставили page, чтобы люди успели мигрировать на app

  • @endlesslysorrow

    @endlesslysorrow

    Ай бұрын

    там же написано: для SSR, app router это по дефолту RSC, это не совсем SSR

  • @yohimik

    @yohimik

    29 күн бұрын

    ​@@endlesslysorrow ну если идейно устаревший ssr нужен ради того, чтобы ответы были пререндерены именно на сервере, а не для того, чтобы решать современные проблемы и совмещать разные подходы и при всем этом решать все те же проблемы, что и чистый ssr, то ок)

  • @_ivanoleksiuk
    @_ivanoleksiuk2 ай бұрын

    27:57 а на какой архитектуре писать с нуля?

  • @typingaway

    @typingaway

    24 күн бұрын

    Все зависит от задач же. Если нужно SEO (= SSR), то NextJS (можно посмотреть на альтернативы конечно, но NextJS по развитию вырывается вперед). А какую архитектуру, хороший вопрос. Я придерживаюсь мнения, если проект не критичный для бизнеса, то можно без проблем пробовать новую архитектуру на AppRouter. В ином же случае PageRouter, но писать код так, что бы в дальнейшем было просто перейти на новую архитектуру (например, разделять серверный стейт (кеши запросов), и клиентский для логики на клиенте).

  • @vladimircreator
    @vladimircreator2 ай бұрын

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

  • @izzy7541

    @izzy7541

    2 ай бұрын

    А зачем нам в таком случае некст? Берём генератор статики, получаем готовый хтмл и вуаля

  • @vladimircreator

    @vladimircreator

    2 ай бұрын

    @@izzy7541 SSR

  • @user-sw4ed4gh9n

    @user-sw4ed4gh9n

    2 ай бұрын

    @@izzy7541 , генератор статики это кто, если не секрет?

  • @endlesslysorrow

    @endlesslysorrow

    Ай бұрын

    @@izzy7541 с такими развернутыми комментариями можно предложить просто в html файлик все писать

  • @zapilniy

    @zapilniy

    24 күн бұрын

    В таком случае нужна серверная инфра, которая будет заниматься генерацией хтмлок, в отличие от SPA

  • @user-mi1hq1dz2b
    @user-mi1hq1dz2b2 ай бұрын

    Чет я вообще не понял про куки в next rsc. Да и как-то уже не хочется использовать page router.

  • @developerdiary3136

    @developerdiary3136

    2 ай бұрын

    Из-за стриминга есть проблемы с куками, ишьюсы можете найти

  • @izzei-1614

    @izzei-1614

    2 ай бұрын

    Что такого в page router? Он стабилен, в нем работает вся экосистема реакта, подход к созданию приложений типичный и понятный для всех разработчиков

Келесі