Формирование инструментального ландшафта с помощью кривых графиков.
В предыдущей серии статей (Часть 4: Разрешение модулей и исполнители задач) мы рассмотрели эволюцию систем разрешения модулей JavaScript за последнее десятилетие и кратко упомянули несколько обработчиков задач. Модули JS превратились из ничего в полностью запеченную встроенную языковую функцию, а средства запуска задач превратились в агрегированные наборы инструментов, которые теперь делают гораздо больше, чем просто сшивание кода JavaScript.
В этом процессе постоянного совершенствования и параллельных инноваций был создан целый набор инструментов, чтобы облегчить использование широкого разнообразия инструментов, форматов и стандартов, доступных на рынке.
Вот примерно так выглядит хронология:
Этот график не является исчерпывающим или полностью точным. Его цель — помочь изобразить параллель между системами разрешения модулей и взаимосвязанными эволюциями инструментов.
Сначала несколько слов о былой славе.
Старая школа
Есть одна константа, инструмент, существовавший до Христа: Делай. Я видел довольно много современных проектов, использующих его, он делает одну вещь, и делает это хорошо. Также очень полезно унифицировать процессы сборки между специальностями (т. е. потоки сборки бэкенда и внешнего интерфейса), особенно в средах, использующих C или C++.
В той же категории находится Browserify, который, как мы видели, позволяет использовать синтаксис require в кодовой базе внешнего интерфейса и выводит пакет, внедренный в HTML-страницу с помощью одного ‹script/› тег.
А таскраннеры Grunt и Broccoli активно использовались в период с 2013–14 по 2015–2016 годы. Gulp является исключением и по-прежнему широко используется, но в основном в долгоживущих проектах.
Материалы текущего/следующего уровня
Чтобы завершить наш общий обзор инструментов сборки современными инструментами (теми, которые ориентированы на CommonJS и в основном на EsModule), Состояние JS (2022) предоставит нам более точное и современное представление о современном инструментальном ландшафте.
Прежде всего, давайте поговорим о слоне в комнате.
В предыдущем посте мы углубились во внутренности Webpack, потому что его архитектура и функции проложили путь на очень многих уровнях. Приведенные выше диаграммы показывают, что Webpack по-прежнему активно используется.
От 75 до 85 % респондентов с 2017 года заявляют, что используют его.
Но люди теряют к нему интерес: через 5 лет пользователи заявили, что их интерес упал с 84% к 61%.
Это в основном связано с нагрузкой на конфигурацию и ограничениями производительности из-за его реализации в JavaScript, который является однопоточным.
Чтобы противостоять этому, новые инструменты предоставили ответы на эти 2 вопроса:
- реализация многопоточного языка (производительность)
- нулевая конфигурация (конфигурация)
Сборщики/компиляторы для повышения производительности
Улучшения производительности были достигнуты с помощью сборщиков и компиляторов следующего поколения. Два языка были использованы из-за их собственных возможностей для выполнения многопоточных вычислений: Go и Rust.
Сборщик на Go: EsBuild
Сборщики на основе ржавчины: SWC, Турбопак (альфа)
Эти инструменты требуют огромного прироста производительности.
Но каждый проект уникален, и единственный способ узнать, насколько это применимо к вам, — это попробовать его в своих репозиториях.
Бандлеры для нулевой конфигурации
Что касается трудоемкой настройки, то появились такие инструменты, как Свернуть или Посылка. Обещание: просто установите его с помощью npm, а все остальное он сделает за счет логических выводов и самоадаптирующихся значений по умолчанию.
За год Webpack также значительно улучшил свои настройки по умолчанию и уменьшил потребность инженеров в расширенных знаниях о его внутреннем устройстве для его использования.
Нет ли способа получить как производительность, так и нулевую конфигурацию?
Да, есть, но за счет создания инструментов упаковки, которые соединяют все воедино и выбирают наиболее интересные функции.
Parcel (v2) построен на основе SWC, поэтому он отвечает как приросту производительности, так и готовности из коробки.
Vite построен на основе EsBuild для объединения процессов и Rollup для разделения кода и обработки CSS.
Турбопак представлен как эволюция Webpack. Его основными сопровождающими являются члены основной команды webpack. Это также часть более крупного проекта, который предлагает поднять существующий инструментарий до уровня Monorepo: Turborepo.
Отзывы, чувства и намерения пользователей
Наконец, State of JS дает очень проницательное представление о том, какие инструменты наиболее интересны сообществу.
Этот график дает довольно хорошее представление о том, что будет дальше.
У вас есть большая вероятность найти Vite, EsBuild, Turbopack, tsc CLI или Webpack на вашей следующей работе (сегодняшний ажиотаж — это привычки завтрашнего дня, если на кривой внедрения не появится разрушителя).
Заключение и открытие
В целом, классифицировать экосистему инструментов JavaScript довольно сложно, поскольку все они реализуют разные наборы функций и все они по-разному комбинируются для создания приложений.
Экосистема развивается быстро и пытается нарушить статус-кво, чтобы обеспечить лучший опыт разработчиков и более высокую производительность за счет повышения производительности.
На этом мы завершаем серию статей о демистификации встроенного кода JavaScript.
Открытие
В ближайшее время я намерен написать еще одну серию, посвященную среде выполнения.
Оставайтесь с нами! :)
Системе сборки бросает вызов философия Monorepo, которую можно рассматривать как новое видение или изменение восприятия.
Если вы хотите узнать об этом больше, ознакомьтесь с серией, которую я написал о том, почему и как мое отделение решило принять ее: Серия Монорепо.
Спасибо за прочтение!
👏🏻 Похлопайте мне и подпишитесь, если вам понравилась эта серия.
