«Это революция»: React и Next.js мертвы — и новый фреймворк готов их заменить

Кажется, это начало следующей революции JavaScript-фреймворков. Об этом в своем блоге на Medium пишет Сомнатх Сингх. Передаем ему слово.

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

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

Вы не сможете обойти JavaScript. Осознайте это и облегчите свою жизнь.

Беспорядок, в котором мы находимся

Массы всегда ошибаются… Мудрые делают то, чего не делает толпа. Измените то, что они изучают, и вы получите вожделенное — то, чего они ищут.

(Чарльз Буковски)

Нам трудно признать, что то, что сейчас происходит в веб-разработке – это просто беспорядок. Мы давно пришли к выводу (и это было грубой ошибкой), что отправка HTML (от клиента к серверу) слишком дорога, и начали разрабатывать альтернативы похуже.

Все эти годы мы разрабатывали разные фреймворки: разрушали фундамент, на котором строился интернет.

Сейчас я объясню, что именно имею в виду.

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

Несмотря на то, что мы послали клиенту всю структуру, все равно нужно ждать, пока она станет интерактивной.

Время запуска безосновательно увеличивается. Наверное, это проблема, не правда ли?

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

Мы называем это гидратацией (да, знаю, звучит причудливо) — подразумевается, что браузер читает части JavaScript и определяет, какие разделы кода чему отвечают на веб-странице.

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

После того, как мы отправляем серверный HTML, а клиент загружает и выполняет его, мы стараемся отложено загрузить веб-приложение отдельными фрагментами.

И угадайте, что происходит?

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

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

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

Люди этого не понимают. Когда вы говорите, что ваша программа слишком велика, они выкрикивают: «И что? Просто используйте ленивую загрузку и все будет хорошо».

Они не понимают, что это не так просто. И в частности из-за нюанса, который мы только что обсуждали выше.

У нас также есть эти островные архитектуры (популяризированные Astro). Где вместо того, чтобы гидратировать все сначала, мы это делаем, когда клиент взаимодействует с конкретным компонентом. Если я взаимодействовал с меню, я гидратирую только его, если я взаимодействую с любыми конкретными компонентами — я гидратирую только их, а не всю программу.

Это уже лучше. Но эти острова все еще достаточно велики. И связь между ними становится проблемой, потому что вы просто превратили свой компонент в остров, остров — это программа. Теперь у вас есть проблема связи между программами, которую нужно как-то решить.

И здесь на сцену выходит Qwik.

Когда я взаимодействую с определенным компонентом, решается только этот конкретный компонент.

Учтите, что в этом случае не нужно было решать ни родительские, ни дочерние части компонента в отличие от того, что происходит при использовании Astro.

Qwik говорит: «Мне нужно сделать только это и больше ничего».

Qwik также достаточно умен, чтобы распознавать, когда один компонент зависит от другого (представьте кнопку «добавить в корзину» в e-commerce приложении) и активировать зависимый компонент.

Давайте откроем вкладку Network: здесь нет JavaScript на начальной загрузке страницы.

Отсутствие JavaScript в этом случае не слишком впечатляет. Это может сделать любой фреймворк (если вы просите статическую страницу).

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

«Брызги» JS превращается в водопад. Но, несмотря на это, время загрузки не будет увеличиваться. Qwik позволяет писать столько кода на JavaScript, сколько пожелаете. И вам не нужно переживать о снижении производительности.

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

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

Изобретательность часто маскируется под магию

Это был такой волшебный момент, когда я узнал о существовании виртуальных машин. Я думал: «Разве такое возможно? Как можно запустить OS внутри OS?». Но то, что казалось мне магией, было просто технологией.

Я мог скачивать Linux внутри моей машины с Windows: для меня это было невероятно.

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

Вам не нужно снова что-то загружать. Не нужно открывать текстовый процессор, вводить буквы. Вы просто оказываетесь точно в том моменте, где остановился я. Это больше всего привлекло мое внимание. И именно так работает Qwik.

Программа запускается на сервере и доходит до определенного состояния. Мы берем снимок, присылаем его в форме HTML клиенту, а на клиенте продолжаем с того места, где остановились.

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

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

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

«Лучший код — это полное отсутствие кода»

Qwik быстр не потому, что очень эффективен, а потому, что отлично избегает лишней работы.

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

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

Qwik открывает множество новых возможностей. Вы можете, например, рендерить свою страницу на нескольких серверных периферийных службах и собрать ее как единый ответ.

Вывод

Тысячи лет назад Гаутама Будда рекомендовал выбирать срединный путь. Но мы, разработчики, слишком упрямы: все время впадаем в крайности.

Одни говорят вам использовать JavaScript (для SPA), другие советуют вообще не иметь дело с JS (фреймворки на основе WebSocket, такие как LiveView). А остальные позволяют вам использовать JS за счет производительности.

Qwik — это глоток свежего воздуха во всех этих случаях. Он совсем не похож на то, что мы когда-либо раньше использовали.

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

Текст адаптировала Евгения Козловская