введение

как фронтенд-разработчик, когда я начинаю код с JS и jQuery, все действительно просто и понятно. вставьте свой код, используя тег script, затем начните писать свой код. через некоторое время в наш мир приходят angularjs и другие js-фреймворки для лучшей командной работы и большего сотрудничества между разработчиками с меньшим конфликтом и упрощением обслуживания кода и инициации SPA. мы учимся делать наш код структурным и делаем модуль, контроллер,…. в джс.

после angular2 я просто запутался в том, что такое npm? что такое типскрипт? что такое глоток? и все становится так сложно. После некоторых исследований я знакомлюсь с современными подходами к веб-разработке и начинаю использовать фреймворк Aurelia для написания современного веб-приложения SPA около 4 лет назад.

через некоторое время и переключившись на реакцию я сталкиваюсь с новым вопросом Webpack или systemjs, что лучше? после некоторых исследований мы выбираем systemjs, и через 9 месяцев, когда появляется новый проект, мы выбираем webpack, потому что он более трендовый, и к этому времени мы сделали 4 проекта, два с webpack и два с systemjs, и я вижу отсутствие хорошего объяснения по этому поводу вопрос Я начинаю писать эту статью, чтобы помочь сообществу сделать лучший выбор.

В чем разница между SystemJS и Webpack?

Первое, что вам нужно знать, это то, что это не одно и то же. они разные. systemjs — это библиотека js, которая загружает файл JS по запросу в браузере, а Webpack — это библиотека nodejs, которая работает на бэкэнде для переноса и объединения всех файлов вашего проекта в один файл. но оба здесь, чтобы помочь вам легко создать приложение SPA.

в рабочем процессе SystemJS nodejs создает HTTP-сервер, который обслуживает файлы, gulp — это средство запуска задач, которое отслеживает изменения в файле и запускает инструкцию по минимизации js, превращает файл Scss в CSS после изменения и создания. а задача SystemJS заключается в загрузке js-файла по запросу и переносе ES6,7 в старый код, который может понять браузер.

в Webpack у нас есть два подхода. один из них - это nodejs, создающий HTTP-сервер, который обслуживает файлы. затем веб-пакет получает точку входа вашего веб-приложения и начинает его сканировать и собирать все файлы, необходимые вашему приложению, включая файл CSS, файл изображения, файл JS и т. д., и транспилировать Typescript в javascript, Scss в CSS, файл изображения в код изображения base64 и после всех преобразований поместите их все в один файл. поэтому webpack не работает с вашим браузером. это просто библиотека nodejs, которая преобразует все файлы в язык, понятный браузеру, и помещает их в один файл, и потому это всего лишь один файл. когда вы используете оператор «импорт» для загрузки какого-либо файла в свой браузер, он уже загружен, и браузер не отправляет запрос на получение файла, а просто выполняет его в вашем едином файле.

второй подход в веб-пакете: вы просто создаете пакет в nodejs и копируете полученный файл bundle.js в другой проект в asp.net, PHP или Java, поэтому nodejs даже не обслуживает файл в финальном проекте, и вы просто используете его для создать бандл.

как вы понимаете из приведенных выше абзацев, в SystemJS каждый выполняет свою работу и, наконец, обслуживает ваше приложение, но в веб-пакете веб-пакет выполняет всю работу сам. это первое большое отличие от них, потому что в SystemJS вы можете заменить работника, когда он работает недостаточно. например, вы можете заменить gulp на grunt js или изменить свой препроцессор Scss, но в веб-пакете у вас недостаточно контроля, и ваш вариант ограничен только веб-пакетом. способ выполнения работы.

Другое дело, что когда вы используете веб-пакет и хотите выполнить какой-то более сложный заказ, например, использовать Scss для стиля, в подходе systemjs вы указываете gulp найти файл Scss и скомпилировать их в CSS и сохранить их рядом с исходным файлом или в другом месте и затем импортируйте его с помощью простого «импорта «url_to_file/style.css»», и если возникнет ошибка или проблема, вы можете легко найти проблему, увидев, создан ли файл CSS, чтобы gulp работал правильно. так что проблема в вашем коде, возможно, вы просто пишете неправильный URL-адрес для импорта файла и видите ошибку 404 на вкладке сети вашего инструмента отладки браузера. но в веб-пакете в большинстве случаев вы не знаете, что сделали не так, и веб-пакет просто выдает бессмысленную ошибку, которую вы не можете понять. например, я пытаюсь импортировать какой-либо шрифт в свой файл CSS и получаю сообщение об ошибке, что веб-пакет не может скомпилировать файл scss. после 3 часов поиска я обнаружил, что веб-пакету нужна специальная конфигурация загрузчика шрифтов, если мы хотим использовать собственный шрифт CSS в нашем проекте.

Еще одним отличием является загрузка файла systemjs по запросу, например, он загрузит вашу страницу JS и файл CSS, когда вы хотите показать страницу пользователю по умолчанию. но в веб-пакете все файлы всех страниц загружаются при загрузке страницы и просто выполняются, когда пользователь хочет увидеть страницу. способ веб-пакета состоит в том, чтобы увеличить время загрузки первой страницы, но убрать время ожидания для порядка загрузки второй страницы или следующих, поэтому он подходит для небольшого сайта с 1–12 страницами, которые используют общую библиотеку и модуль, но создают проблемы с более крупными веб-приложениями и т. д. комплексный проект. Чтобы решить эту проблему, веб-пакет создает решение, которое представляет собой файл с несколькими входами или несколькими фрагментами, который создает несколько файлов для проекта и загружает их по запросу пользователя. но проблема в том, что вы должны настроить и определить каждый фрагмент, который вы хотите для своего проекта в веб-пакете, и это становится очень сложно в большом проекте.

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

когда вы используете webpack или systemjs с babel для переноса кода. вы должны использовать карту кода, поэтому, когда вы ставите точку останова или отладчик в своем коде, вы видите, что ваш исходный код и переменная не обнаружены. в systemjs карта кода работает отлично. когда я говорю «отлично», я действительно имею в виду это, потому что большую часть времени вы даже не замечаете, что ваш транспилированный код выполняется, и вы думаете, что ваш исходный код выполняется. но в веб-пакете карта кода действительно беспокоит вас, например, в точке останова, когда вы вводите «это» в консоли инструментов разработчика браузера, вы получаете неопределенный или оконный объект или неправильный объект, потому что веб-пакет транспилирует и меняет его имя на что-то вроде «_this3» и переименовывать и изменять слишком много вещей, которые делают отладку действительно задачей разочарования.

используя CDN и файл условного кода

когда у вас есть несколько проектов со слишком большим количеством общих модулей и библиотек, вам понадобится CDN, чтобы упростить обслуживание кода. чтобы использовать CDN в SystemJS, вам просто нужно импортировать свой модуль по URL-адресу:

import CommonModule from 'http://companycdn.ir/modules/commonmodule'

даже вы можете предопределить свой URL-адрес CDN (объяснено здесь) и использовать его даже без полного URL-адреса:

import CommonModule from '@CDN/modules/commonmodule'

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

другая проблема возникает, когда вы хотите вернуть некоторое изображение или базу файлов JSON или JS в режиме реального времени, например, вы делаете контроллер с определенным URL-адресом для возврата базы файлов js для роли пользователя в приложении, например, в /controller/getAdminPageJsfile/ вы пишете код, который, когда пользователь является администратором, возвращает admin-component.js, а в других случаях возвращается другой файл или проверяет некоторую безопасность, чтобы вернуть файл или вернуть базу файла CSS в ночь или день времени запроса. в этом случае веб-пакет действительно бесполезен, поэтому, если у вас есть такой случай, вы должны избегать веб-пакета.

создать производственную сборку

когда вы хотите создать производственную сборку приложения для публикации. webpack действительно гладкий и хороший. вам просто нужно создать новый файл конфигурации для вашего проекта и со временем улучшить его. например, скажите веб-пакету удалить весь отладчик, минимизировать все файлы js, изменить имя переменной на более короткое имя, чтобы человек не мог его понять. удалить библиотеку анализа и модуль и т. д., но в systemjs вы должны сначала изучить gulp или другое средство запуска задач, а затем начать кодировать обо всем, что должно произойти для меня, требуется 450 строк кода, чтобы сообщить gulp список всех файлов, а затем сгруппировать их затем удалите исключительный файл и выполните необходимую работу для каждого из них и т. д. вы можете понять процесс по следующему коду:

publish() {
//Initialize Options
this.initOptions();
// Application Files
this.extractAndGroupAllFilesBaseOnExtension(this.appDir);
this.doAppropriateActionsForHTMLFile();
this.doAppropriateActionsForJSFiles();
this.doAppropriateActionsForCSSFiles();
this.doAppropriateActionsForJSONFiles();
this.doAppropriateActionsForOtherFiles();
this.clearFileList();
//Server Files
this.extractAndGroupAllFilesBaseOnExtension(this.serverDir);
this.doAppropriateActionsForServerDir();
this.clearFileList();
//NPM and JSPM Packages Config File
this.copyNPMPackageConfigFile();
this.copyJSPMPackageConfigFile();
//Create JSPM Packages Vendor
this.createJSPMVendorPackages();
}

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

Результат

в результате я могу сказать, что systemjs и webpack — отличные инструменты, и чтобы выбрать между ними, вы должны посмотреть на свой проект, чтобы увидеть, что лучше для него. на мой взгляд, веб-пакет великолепен, потому что он быстрее и проще в настройке, поэтому он подходит для проекта небольшого или среднего размера, но система js больше подходит для большого и долгосрочного проекта поддержки, потому что для разработки требуется больше энергии, но дает вам больше контроля над проектом и получить меньше энергии для выполнения работы по-своему и индивидуальному способу выполнения работы, а также дать вам больше гибкости за счет использования CDN или любого другого метода совместного использования кода.