Не так давно Посылка была представлена ​​интернет-сообществу и вызвала большой ажиотаж.

Некоторые из обещанных преимуществ заключались в том, что это было быстро и без настройки. и он начал комплектацию из HTML-файла.

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

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

В последнее десятилетие мы видели, как это происходит на наших предприятиях. Раньше нам приходилось настраивать сервер, включая оборудование, мы перешли через IaaS, и теперь у нас есть Heroku, Gatsby, Now или вы можете использовать FaaS. Все эти подходы пытаются сократить время, которое мы тратим на технические вещи, а не на бизнес.

Также в передней части приложения мы видим, что есть продукты SaaS, ориентированные на скорость и кэширование. Cloudflare, пожалуй, крупнейший игрок в этой области.

Можем ли мы сделать что-то подобное для транспиляции и связывания? Вернемся ненадолго к Parcel. Мне очень понравилось, что посылка начиналась с HTML-файла. Поразмыслив над этим, я понял, что мы должны разделить _что_ мы делаем (приложение) и _как_ оно обслуживается.

Таким образом, посылка принимает HTML-файл в качестве входных данных, я думаю, что это хорошая отправная точка для посылки. Но что, если бы мы сделали эту среду выполнения? Звучит как плохая идея, но потерпите меня.

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

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

Выполнив эту среду выполнения и разместив ее у поставщика SaaS (или через проект OSS). Я думаю, что должно быть возможно многое:

Что, если бы стратегия фрагментации обновлялась во время выполнения в зависимости от производительности пользователя?

Что, если бы один фрагмент был разделен на несколько более мелких фрагментов и сохранен в локальном хранилище, и вы получили бы только те части, которые вам нужны, без необходимости платить авансом в основном файле js или помещать небольшой фрагмент в каждый файл JS?

Что, если бы мы предоставили только префикс CSS, необходимый для рассматриваемого браузера (Facebook уже делает это)

Что делать, если неиспользуемый код был обнаружен и пропущен?

Что, если бы все веб-сайты, которые используют react, jquery, moment или другую популярную библиотеку, могли бы совместно использовать кешированную версию этих библиотек? или, по крайней мере, все клиенты с платформы, предоставляющей эту услугу (например, heroku или cloudflare или аналогичные)

Что, если сервис-воркер перехватил запрос на реакцию 16.1 и вместо того, чтобы загрузить его, он загрузил этот патч между 16.0 и 16.1 и применил его к кешированной версии 16.0, потому что это было приростом производительности?

Что, если ….?

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

Мы все хотим одного и того же. Оптимальная производительность для пользователя. И вариант использования почти всегда один и тот же. это html, js и картинки. Конечно, есть исключения, и, возможно, мы сможем дать подсказки или переопределить. И, возможно, это неправильно для некоторых приложений. Но для большинства пользователей это может стать огромной победой.

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

Я уверен, что Google и Facebook делают невероятные вещи по кэшированию и оптимизации этого материала, у них есть много долларов, чтобы сэкономить на энергопотреблении! Они действительно должны бросить вызов CloudFlare в кэшировании и оптимизации доставки!

Крутые? Видите ли вы какие-либо технические проблемы? Это неправильный подход? Хотелось бы получить больше отзывов об этой идее и позволить ей созреть до чего-то, что можно реализовать.

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

Кстати: хотелось бы увидеть, как кто-то делает то же самое с веб-пакетом :)