Глава 0: Введение и история

Эта статья является частью серии Webpack от нуля до героя. Следующие главы:

Следите за блогом, чтобы увидеть еще больше качественного контента!

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

Вступление

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

Но прежде чем перейти к техническим вопросам, я хотел бы рассказать немного истории о том, как мы сюда попали. Это важно как для новых JS-разработчиков, так и для более опытных разработчиков, желающих сделать «откат назад» в своей карьере и оглянуться на инструменты фронтенд-разработки, которые стали вехами. Эти инструменты дали нам независимость и позволили говорить как настоящие инженеры.

История

Пора возвращаться!

JavaScript всегда считался «вспомогательным» языком и никогда не воспринимался всерьез. Еще в 2007 году, когда я начал заниматься разработкой программного обеспечения, я работал с PHP и JS. Тогда у нас не было терминов backend или frontend, все использовали только «веб-разработчики». Не поймите меня неправильно, у меня нет проблем с этим термином. В то время у технических вакансий не было так много отделений, потому что они следовали тому, что было у нас в то время - все вместе в одном веб-приложении.

С тех пор мне очень понравилось работать со «святой триадой» - HTML / CSS / JS. Это была эпоха «без таблиц», золотой век jQuery и AJAX, это была революция!

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

Теперь ОТДЫХАЙТЕ и позвольте мне решить эту проблему 😴

Прошло несколько лет, веб-приложения становились все крупнее, а разработчики серверной части все преобразовывали в службу. Это была новая тенденция - теперь вы просто используете Ajax, вы полагаетесь на наш REST API, больше никаких форм или пользовательского интерфейса на бэкэнде. Если раньше я был на 40% бэкэнд-разработчиком и на 60% был фронтенд-разработчиком, то теперь я был почти штатным JS-разработчиком, больше не сосредотачиваясь на CodeIgniter, Symfony, Django или Flask.

Начали появляться первые JS-фреймворки, предлагающие перейти на SPA (одностраничные приложения) и принести шаблон MVC, который мы привыкли видеть только на бэкэнде, а теперь и во фронтенде. Я начал работать с Backbone JS, но много слышал и о KnockoutJS. Вместе с jQuery UI и Twitter Bootstrap мы создали несколько веб-приложений, теперь гораздо более богатых и мощных, чем раньше.

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

О боже, на странице так много "‹script›"! 😱

👔 - «Так много сторонних стилей и скриптов, это неконтролируемо! Это блокирует страницу, и наши пользователи всегда жалуются, что наше приложение работает слишком медленно! »

Приложения росли… слишком много! Хорошо, нам нужен какой-то способ разумной доставки, например, требовать его только при необходимости и включать что-то общее для бэкенд-разработчиков: Непрерывная интеграция!

В этой ситуации после некоторого исследования мы обнаружили RequireJS и его прекрасную идею загрузки JS асинхронным способом (AMD - определение асинхронного модуля), никогда не блокируя страницу с многочисленными тегами ‹script›. Был только один сценарий точки входа, для которого требовались все остальные сценарии, которые затем загружались через Ajax и анализировались внутри в зависимости от формата:

Но эй, нам тоже нужен был способ отправить это и минимизировать все эти вещи, которые были взаимосвязаны, но должны были поддерживаться отдельно, поэтому старые concat и minify нам не подойдут. Тогда мы и нашли GruntJS.

Мы начали создавать несколько скриптов с новым ребенком в блоке под названием Node.js (а теперь просто Node), начали использовать LESS внутри Bootstrap и следить за изменениями в таких файлах.

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

«Лучшие» фреймворки 📐 требуют «лучших» наборов инструментов! 🚧

Grunt стал медленным, синтаксис RequireJS был немного грязным, а Backbone было недостаточно. Что-то должно было быть сделано.

Так произошло естественное преобразование в Gulp, который мог выполнять несколько задач асинхронно и намного быстрее, чем Grunt. новым новым ребенком в блоке был AngularJS, обещавший потрясающий способ постоянно обновлять ваш пользовательский интерфейс, реплицируя модели (данные) и создавая для вас данные форм ( или любой другой ввод), который автоматически применяется к вашим моделям. Это был паттерн MVVM.

Кроме того, инструмент под названием Browserify обещал разрешение модуля, что есть в Node.js, но не было в браузерах, и без неприятного синтаксиса AMD. Синтаксис был прост: используйте require () из CommonJS.

Итак, вы говорили о производительности… 🐢 🐇

У приложений, использующих AngularJS, не заняло много времени проблемы с производительностью. Конечно, потому что инструмент родился из прототипа некоторых дизайнеров, но затем стал фреймворком! Чтобы синхронизировать модель с представлением и наоборот, он использовал тяжелый алгоритм для проверки обновлений с обеих сторон: печально известная грязная проверка, регистрирующая наблюдателей для фрагментов данных / представлений, которые были склонны быстро расти и оставаться в память, вызывая серьезные утечки памяти. И вот этот парень пнул дверь:

Он исходил из идеи одностороннего потока данных (в отличие от двусторонней улицы Angular) и алгоритма Virtual DOM, который работает намного лучше, чем Angular. Он также представил новый синтаксис - JSX.

Вместо того, чтобы вручную добавлять полифиллы, мы использовали BabelJS для выполнения этой работы, а поскольку Babel был транспайлером, мы могли вводить JSX и переводить его также в JS. 🎉

Наконец, со всеми этими инструментами мы подошли к эре сборщиков:

Что такое сборщик модулей?

Похоже на сплав решателей модулей и диспетчеров задач. Он берет на себя ответственность того, что сделали RequireJS или Browserify, заботясь о разрешении модулей, но также берет на себя некоторые обязанности менеджеров задач, таких как Grunt или Gulp, просматривая файлы и анализируя файлы разных типов, кроме JavaScript. 💡

Что делает Webpack? 📦

Webpack - это сборщик модулей, который в настоящее время является одним из самых известных (среди прочих, таких как Parcel и Rollup). Он не только заботится о разрешении модулей, но и с помощью загрузчиков анализирует различные типы файлов и обрабатывает их одинаково как модули JS. Обычно мы используем его вместе с импортом скрипта ECMA, но он также поддерживает require CommonJS и AMD require / define и может экспортировать все они используют формат UMD (универсальное определение модуля).

Но может ли Webpack позаботиться обо ВСЕХ ЗАДАЧАХ? 💥

Нет, потому что он не выполняет 100% «управления задачами» таких инструментов, как Gulp или Grunt. Но теперь мы можем использовать простые инструменты для выполнения этой работы. В этой серии статей мы собираемся использовать скрипты npm, поскольку это простое решение, охватывающее все, чего нет в Webpack.

Надеюсь, вам понравилось это краткое введение и вся история, которая привела к созданию сборщиков модулей. До встречи в следующей главе!