Философия Qwik

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

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

1. Максимально отсрочить загрузку и выполнение JavaScript.
2. Сериализовать состояние выполнения приложения и фреймворка на сервере, а затем возобновить его на клиенте.

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

Отсрочка исполнения

Отсрочить выполнение JavaScript настолько, насколько это возможно.

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

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

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

Возобновляемость & Сериализация

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

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

В чем проблема?

Современные веб-сайты требуют огромного количества JavaScript, чтобы стать интерактивными. Слишком большое количество JavaScript приводит к двум проблемам:

1. Пропускная способность сети: клиенту отправляется большой объём кода, что может занять много времени в медленных сетях.
2. Время запуска: код на клиенте должен быть выполнен (как часть гидратации), чтобы сайт стал интерактивным.

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

Что ещё хуже, JavaScript является однопоточным, поэтому наши сложные сайты не могут использовать преимущества современных многоядерных процессоров.

Как мы здесь оказались?

Решение вышеупомянутой проблемы одновременно и очевидно, и сложно: отправляйте меньше JavaScript.

Это очевидно, потому что все мы согласны с тем, что сайты с меньшим объёмом JavaScript будут работать лучше.

Это сложно, потому что наши инструменты не помогают нам. Почти все они решают проблемы таким образом, что получить меньший объём JavaScript-кода становится сложно. Это происходит потому, что большинство наших инструментов создаются для решения конкретной задачи, не задумываясь об объёме JavaScript, который они генерируют.

Вам нужно решать задачи рендера, стилизации, анимации, A/B тестирования, аналитики и т.д. Для них существуют инструменты. Вы просто импортируете модуль или добавляете тег <script>, и эти инструменты решают ваши проблемы, но за счёт увеличения начального бандла.

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

Каково решение?

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

Qwik - это не про создание меньшего объёма JavaScript-кода. Qwik - это про отсутствие необходимости отправлять весь этот код клиенту сразу при запуске приложения. Qwik - это то, что получается, когда вы доводите идею "задержки загрузки JavaScript" до крайности.

Да, Qwik требует другого образа мышления и проектирования приложения, но в результате вы получаете околонулевой начальный объём JavaScript с прогрессивной подгрузкой на основе взаимодействия с пользователем.

Размер - не проблема разработчиков

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

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

Мантра Qwik заключается в том, что размер бандла - это не то, о чём должен думать разработчик. Это должно происходить естественным образом, как часть машинерии фреймворка.

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

Почему бы не исправить существующие фреймворки/инструменты?

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

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

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

Почему мы создаём Qwik?

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

Действительно ли скорость страницы имеет значение?

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

Некоторые примеры с web.dev: