Давайте поговорим про разработку без бандлеров.
Было время, когда можно было начать разработку без настройки бандлеров, транспиляторов и т.п. Просто подключаешь скрипт на страницу с помощью <script> и всё начинает работать.
В этом была какая-то магия, которую современная web-разработка потеряла. Хотя и были проблемы с тем, что ручное управление зависимости вызывало боль — в сложных js-приложениях нередко можно было увидеть десятки подключённых скриптов.
Какие рекомендации даёт сейчас, например, современный фреймворк: React, Angular, Vue и т.п. Скачайте cli-инструмент, и он всё сделает за вас.
И это понятно — TypeScript без транспиляции не заработает в браузере, надо сконвертировать JSX в нативный JS, собрать модули в единый бандл и т.п.
То что было раньше, и то что есть сейчас — небо и земля.
Но если не требуется делать большое приложение и просто иногда хочется поэксперементировать. Это всё начинает вставать на пути. Зачем мне скачивать 230Мб зависимостей реакта, когда я хочу сделать минимальный пример, воспроизводящий ошибку в девтулзах реакта? (true story)
Вы можете сказать про codesandbox.io (очень клёвая штука), но именно в моём случае он не подходил из-за того, что react devtools не мог подцепиться к моему приложению.
Итого иногда хочется использовать старые добрые подходы при работе с современными фреймворками. Поэтому хочу поделиться своими изысканиями и мыслями.
Конечно, разработчики давно об этом задумывались. При разработке и популяризации формата AMD возможность разработки без бандлеров было той фичей, которая противопоставлялась как преимущество относительно CommonJS. CommonJS в итоге победил.
Сейчас, когда все современные браузеры поддерживают нативную модульную систему и фичи ES2015 у нас так-то нет очень большой необходимости использовать бандлер и Babel, если мы пишем на чистом js caniuse.com/#feat=es6
Для того, чтобы забустрапить приложение с использованием ESM-модулей без бандлера, надо добавить type=module в тег скрипт.
Если у вас не бизнес-критичные задачи, то тогда вполне можно жить без бандлера с приложением, состоящим из 100 модулей, но если используется HTTP/2. Вот тут можно потыкать мой бенчмарк esmtest.myshov.com. Приложение из 100 файлов загружается меньше чем за секунду.
Окей. Загружать можем. Но куча библиотек написана с использованием CommonJS. Вот тут на подмогу приходит snowpack.dev
Snowpack преобразовывает зависимости из node_modules в esm-совместимые ресурсы и кладёт их в web_modules, вот их можно использовать напрямую из браузера
Можно забыть про долгие пересборки проекта — snowpack надо запускать только тогда, когда в проекте появляются новые зависимости.
Snowpack не нужен, если библиотека предоставляет esm-совместимый билд twitter.com/v1rtl/status/1…
Окей, а что делать c jsx? Этому посвящена статья в доках реакта reactjs.org/docs/react-wit…
Как альтернативу прямого использования React.createElement можно использовать специальные библиотеки, облегчающие описание вёрстки компонентов с использованием простого js. Например, hyperscript github.com/mlmorg/react-h…
Ещё есть другой интересный проект — htm. Он использует template strings github.com/developit/htm
Как эксперимент полтора года назад пробовал сконвертировать TODO-приложение Redux в bundler-free приложение. С проблемами не столкнулся, всё завелось сразу github.com/myshov/react-e…
@jsunderhood Мне кажется кейс паралельной загрузки не покрывает реальные примеры работы без сборщика. В теории можно preload, но это уже сборщик для генерации карт.
В реплаях @andrey_sitnik пишет, что мой бенчмарк синтетический и может не отражать реальное приложение. Это, действительно, может быть так
twitter.com/andrey_sitnik/…