Пикабушники народ странный. И методы у них странные. Но, что занимательно, эти методы работают. Не так давно я оставил безобидный комментарий про JS, и, по нелепому стечению обстоятельств, неожиданно попал под радары половины сайта и получил что-то около четырехсот подписчиков. Почему? А не знаю. Люди просто подписывались на меня, хотя я ничего им не обещал. Даже не давал намеков. Ты оставил комментарий про JS, я на тебя подписался и теперь ты мне торчишь целый пост про JS. Не знаю, как это работает, но раз вы это читаете, то их план исполняется.
Само собой, я понятия не имел о чем писать. Уроков и без меня хватает на любой вкус и цвет. И серьезных и несерьезных. Но потом я, все таки, задумался. Прям со всей силы. И как итог, додумался до этого поста. Очень надеюсь, что это единственное, что я напишу про JS, только чтобы вас, четырех сотен, не разочаровывать. Я не особо то горю желанием писать целые курсы, да и куда уж мне, скажем прямо
А рассказать я хочу о том, о чем сам бы очень хотел услышать в начале своего обучения, когда робко вступал на территорию бесконечной содомии и анархии под общим названием “Современный фронтэнд”. Некий экскурс, объясняющий общие понятия и положение дел, чтобы было проще разобраться в ситуации. Наверняка этому посту найдутся аналоги, и в свое время я просто плохо их искал. Однако, хуже от еще одного никому не станет, верно? Так что, будем посмотреть.
Я попробую рассказать все как можно проще, не залезая без необходимости в глубокие дебри и не пугая всякими сложными для понимания вещами. Потому что во многом, оно того стоит. Важная деталь состоит в том, что это просто экскурс по основным понятиям, я не буду пытаться обучать вас как пользоваться тем или иным инструментом, вам придется искать это самим. Я просто хочу раскидать все по полкам и только, потому что по себе знаю, что новички просто теряются от всего этого нагромождения.
Node.js
Разумеется, мы начнем именно с node.js, вокруг которого сейчас все и крутится. Если вы никогда с ним до этого не сталкивались, то наверняка задаетесь вопросом, на кой хер он вам вообще нужен и почему его тычут вам в лицо каждый раз, когда вы пытаетесь изучить какую-то современную фронтенд библиотеку или фрэймворк?
И я вас прекрасно в этом понимаю. Когда я пытался в это вникнуть, меня сбивал с толку этот node.js. Я очень хотел изучить какой-нибудь крутой и современный фреймворк по типу React, Angular или Vue. Но каждый раз, когда я пытался это сделать, диктор из видеоуроков упорно начинал с node.js, который я не понимал от слова совсем. Это сильно сбивало с толку, а все из-за одного единственного нюанса.
Почему то, по какой-то совершенно тупой причине, многие продолжают называть Node.js не иначе, как серверный JavaScript. Само собой, от такого определения я начал считать, что все современные технологии для фронтенда работают исключительно с серверами, написанными на JavaScript. Иначе почему Node.js преследует меня повсюду, хотя в сервера я пока лезть не хочу. Ну ладно, думаю я, раз везде нужен этот Node, то изучу Node. Но в каждом уроке по Node мне втирали какую-то совсем уж невразумительную дичь. Очень долго я мучался, пока не нашел то, что описало мне смысл в общих чертах.
И сейчас я постараюсь все расставить по своим местам.
Начнем с того, что JavaScript (только не упадите) — это скриптовый язык. Что это значит? Это значит, что программы для этого языка пишутся в обычном текстовом файле, отличающимся от обычного файла только другим расширением. И все, вот она ваша программа. Открываете блокнот, пишете там console.log(‘Hello World’) и сохраняете в формате .js. Вот и все, ваша программа готова. Вы восхитительны.
Появляется логичный вопрос, раз команды пишутся в обычный текстовый файл, то как нам его запустить? Как заставить эту программу работать? Ответ — скормить этот файл интерпретатору. Это такая программа, которая нужна для исполнения скриптовых файлов. Она их открывает и начинает выполнять строчка за строчкой. Не самый быстрый способ в сравнении с теми же компилируемыми языками, которые просто один раз перегоняются прямо в машинный код и потом запускаются на любом ведре схожим с тем, на котором они были написаны. Но зато, в отличии от них, скриптовый язык запустится на любом ведре, на котором запустится его интерпретатор. Кроссплатформенность!
Каждый скриптовый язык работает так. И Python, и PHP, и, прости господи, Perl. И у каждого свой интерпретатор.
Где же нам, тогда, взять интерпретатор для нашего JS? Ну, самое очевидное — использовать браузер, куда он, само собой, встроен по умолчанию. Браузеры, можно сказать, это естественная среда обитания JS. Вам придется постараться, чтобы найти в сети сайт, работающий без единой строчки этого, позвольте выразиться, кода (DarkWeb не считается!). А заодно, можете попробовать найти в современном мире хоть одно устройство, на котором этого самого браузера нет. Сейчас они везде. Буквально. А раз браузер — это интерпретатор, значит, ваша замечательная программа сработает на любом из этих устройств. Теоретически, само собой.
Но вот проблема, браузеры запускают JS скрипты внутри своей собственной среды, и не дают им никакого доступа во внешний мир. Ваша JS программа, в отличии от любой другой, может действовать только в рамках этого самого браузера, и не может управлять, к примеру, файлами, не может взаимодействовать с операционной системой, с устройствами подключенными компьютеру и так далее. Она изолирована. Для безопасности, само собой. Только представьте, какой был бы ад, если бы любой сайт имел полный доступ к вашему компьютеру. Но с другой стороны, какие безграничные были бы возможности!
А так, не покидает чувство, пардон, стерильности этого языка. И тут на сцену врывается NODE.JS! Платформа (читай как интерпретатор), которая позволяет вам запускать свой ненаглядный JS прямо из под операционной системы, а не из под браузера! Ваш любимый жаваслипт больше не хер собачий, нужный только для написания жалких сайтиков! Теперь, на нем можно писать настоящие взрослые программы! Можете теперь смело подойти к вашему знакомому Python программисту, который всю жизнь смотрел на вас как на говно, расстегнуть ширинку, и вывалить ему на стол ваш огромный мощный движок V8 (Не автомобильный, просто так интерпретатор назвали. Ну круто же! V8!)
И да, само собой, на Node.js можно написать и сервер, кто же вас остановит. Именно написать, потому что, опять таки, из-за того что node все называют серверным JavaScript, многие думают, что можно просто его скачать, установить, и сразу получится нечто вроде PHP в придачу со встроенным в него Nginx. А потом оказывается, что ничего такого там и в помине нет, и чтобы сервер заработал, надо его сначала написать. Доколе!
Но не будем о серверах. Мы уже поняли, что node не только про это. Но по прежнему непонятно, нахрена он нам нужен, ведь приложения для компа мы тоже писать, вроде как, не планировали. Пока.
А нужен он для удобства. На основе node.js мы будем создавать для себя собственную среду разработки. Мы, конечно, будем писать на JavaScript очень многое, ведь мы, все таки, фронтенд разработчики. Вот только этот код, пусть он и написан на JavaScript, исполняться на Node не будет, Node будет работать только с нашими файлами, ведь в отличии от браузерного JS он это умеет!
Более того, он не умеет многое из того, что умеет браузерный JS, так что большую часть кода, даже банальный и всеми любимый alert() вы там не запустите. И это логично. Как вы обратитесь, к примеру, к объекту window, который есть в браузере, если в node.js никакого window не существует?
Знаю, о чем вы думаете. Ты тут столько времени объяснял, что теперь наш JS может работать на компе, но теперь говоришь, что мы этот код даже запускать на Node не будем. Какого хера...
Сейчас все объясню подробнее.
Давайте вернемся в прошлое (для кого-то, впрочем, все еще настоящее, но это мы и пытаемся исправить). Раньше, разработка фронтэнда представляла собой подключение пары библиотек через обычный тег <script>, пару собственных скриптов и, конечно, CSS стили. HTML, CSS, JS. Все прекрасно и лаконично.
Но современный фронтенд намного сложнее. Парой библиотек уже не ограничишься. Приходится подключать их целыми десятками. Это уже само по себе вызывает массу проблем, ведь даже не смотря на то, что все они сжаты и оптимизированы по самая нимагу, их по прежнему много, вес страницы раздувается до неприличных размеров. Неужели нам каким-то образом придется выдергивать из каждой библиотеки только нужное, лишь бы хоть немного уменьшить вес? А ведь порой еще приходится следить за обновлениями этих библиотек, да еще и так, чтобы все остальное к херам не полетело.
И сам JavaScript, будь он неладен, не стоит на месте! Он обновляется, в него добавляют новые возможности, делают его удобнее а иногда даже исправляют в нем старые косяки. И ведь очень хочется писать на самой свежей и красивой версии, со всеми ее возможностями. Но, конечно же, эти современные версии не поддерживаются старыми браузерами. Как быть? Ну, либо писать на старых версиях, либо на новой, но потом перегонять ее в старую. С помощью онлайн утилит, вроде babeljs.io/repl. И так каждый раз. Не очень то удобно. Особенно если вы там накодили на целый вагон.
Да и кому, в общем то, нужен этот идиотский нелогичный JavaScript? Хочу писать на новом, модном, молодежном TypeScript! А вот потом, когда я напишу на нем свою роскошную программу, я перегоню ее уже в JS. А потом этот JS перегоню в JS старой версии, для больше поддержки. А потом то, что получилось, еще прогоню через оптимизатор, для экономии места. Не такая уж и длинная цепочка.
Но и этот HTML уже достал, честно говоря. Шаблонизатор хочу! Буду теперь клепать странички с околосветовой скоростью на pug, потом pug превращать в обычный HTML, и уже туда вставлять свой пережатый перетранслированный JS. Ну и сжимать в конце. Скорость загрузки - наше все! Нам дорог каждый килобайт.
Ах да, забыл, только лохи в 2К20 прописывают стили на лоховском CSS. Все уже давно пересели на Less, SCSS, SASS и тому подобное, с шикарными возможностями, невероятным удобством и мега скоростью! Но да, надо бы сжать да перегнать.
Благодаря всем этим технологиям мы оптимизировали скорость нашей разработки в разы! Да, мы потратили полдня чтобы все это в итоге привести обратно к HTML, CSS и JS, чтобы хоть какой-то браузер нас понял, но мы по прежнему восхитительны и современны!
Вот для чего вам нужен Node.js. Для автоматизации. Только представьте, что у вас есть огромный набор исходных файлов, все разбросанные по своим папочкам, с идеальной архитектурой, на каких угодно технологиях. Современный и большой проект! А потом вы ввели одну единственную команду в консоль и начала происходить настоящая магия! Все это дерьмо превратилось в обычную статику! На выходе вы получаете самые обычные HTML страницы, в каждую из которых подключен всего один общий файл со всеми вашими стилями, сжатый и переведенный в обычный CSS, да еще и с автоматическим добавлением всех этих надоедливых префиксеров и костылей для старых браузеров. И всего один единственный JS файл, в котором объединены все ваши скрипты и весь код из ваших библиотек. Причем, только нужный код! И да, само собой, все сжато и в самом поддерживаемом формате. По итогу, проект, который в исходном виде весил под сотню мегабайт, на выходе превратился в набор страничек общим весом в 5 килобайт! Это ли не чудо?
Я вам больше скажу, вы можете даже не утруждать себя вводом этой единственной команды каждый раз, после любого изменения в файлах! Запустите другую команду, всего единожды, и она запустит вам локальный сервер, куда забросит все ваши файлы в уже готовом виде, и будет обновлять их каждый раз, как только вы что-то поменяете в ваших исходных файлах! Даже открытая страница в браузере перезагрузится сама собой!
О, вам и этого мало? Тогда я подготовил вам напоследок самое сильное колдунство. Истинное мракобесие и самую темную сторону магии! Страница может даже не перезагружаться! Ее части просто будут заменяться динамично! Вы можете разместить на ней текстовую область, напечатать что-то в ней, потом вернуться в редактор и изменить атрибуты тега или внешний вид этой же самой текстовой области. У вас даже текст внутри нее не пропадет! Состояние вашего приложения сохранится неизменным, и это не дешевые фокусы, перезагрузки реально не происходит.
Но я обещал кое что объяснить. Node.js действительно не исполняет наших файлов. Он нужен нам для другого, для запуска всех этих программ и утилит, которые будут позволять нам вытворять такие финты с нашими исходными файлами, написанными на чем угодно и как угодно. И в итоге мы получим сразу готовый сайт для закидывания его на сервер. Или же удобный сервер для разработки прямо на локальной машине, который будет нам все удобно и оперативно обновлять.
Для того, чтобы установить себе node, вам надо тупо его скачать с официального сайта. Ничего сложного в его установке нет.
NPM
Итак, с Node.js мы разобрались. Он крут, офигеннен и V8. Вот только это просто платформа для запуска программ. Самих программ для этой магии еще попусту нет. И не самим же нам их писать! Мы установим готовые модули для Node.js.
Разумеется, это теперь будет осуществляться не так, как мы привыкли. Не надо лезть в интернет, искать библиотеки и скачивать их на комп вручную. Хотя, конечно, и так тоже можно. Кто же вас остановит. Но мы не психи.
После того, как вы установите node.js на свой компьютер, сразу вместе с ним установится програмка npm. Npm - это менеджер пакетов. Именно эта штука будет отвечать за загрузку нужных вам модулей и библиотек из общего репозитория. И не только за загрузку, но и за установку, обновление, удаление и так далее и до бесконечности. На то она и менеджер. И чтобы прикоснуться к ее чарующему миру, нам нужно просто напросто создать новую папку с названием вашего блистательного проекта. Желательное, конечно, называть латиницей, без всяких пробелов и спец знаков, иначе потом будете долго выть.
Тут начинается страшное. Для многих. Консоли! Но какими бы страшными они не казались, к ним придется привыкать, ибо работать через них придется много. Очень скоро вы поймете, что консоль - ваш друг. Ну и будете чувствовать себя мамкиным хакером.
К счастью, там ничего сложного. Разберетесь. Просто заходите через консоль в вашу созданную папку и инициализируете там проект npm. Инициализация будет представлять из себя создание в этой папке служебных файлов npm. И пока он их создает, он будет спрашивать вас кое-какие вещи, чтобы заполнить информацию об авторе. Можете пока все пропустить, это не суть как важно. Важно то, что в конце он создаст важный файлик - package.json.
В этом файле будет прописана информация о проекте, его название, его версия, все это вы можете менять как вам захочется. Информацию о вас, как об авторе проекта, информацию о лицензии проекта, если таковая имеется, а также список всех установленных вами библиотек и их версий. Список будет пополняться, когда вы что-то устанавливаете. А можно пополнять список самостоятельно а потом приказать npm свериться со списком и установить недостающее. Именно поэтому этот файл так важен, потому что вы можете просто перенести его куда угодно, инициализировать установку, и npm сам скачает все прописанные библиотеки, в нужных вам версиях.
Таким нехитрым образом, вам не обязательно повсюду таскать с собой огромную папку node_modules, куда устанавливаются все библиотеки. Они сами установятся, был бы package.json.
У npm есть альтернативы. Самый популярный из которых Yarn. По факту, то же самое, только лучше, быстрее, выше, сильнее. Можете установить его. Само собой, это уже отдельная программа, а не модуль для node. Ее вы просто ищите и скачиваете в интернете с официального сайта.
Также, стоит упомянуть и то, что при установке любой из библиотек в папке node_modules появится не одна единственная папка с нужной вам библиотекой. Все слегка сложнее, но не пугайтесь, вам об этом заморачиваться не придется. Устанавливаемая вами библиотека для своей работы может использовать другие библиотеки. А те — третьи. И так далее, до победного конца.
В этом и прелесть менеджеров, что он сам этим всем занимается, иначе это было бы попусту невозможно для человека. Например, в одном из своих проектов я использую 24 модуля. А в папке node_modules их уже 807. Такая вот арифметика. Кажется страшным, но на самом деле это здорово. Чтобы один и тот же код не повторялся в нескольких библиотеках, они используют какие-то общие библиотеки. В конечном счете, это позволяет значительно уменьшить повторяемость кода а значит и выходной вес объединенного файла. Просто помните, что каким-то мистическим образом из всех этих файлов будет выбрано только все самое нужное и сожмется в считанные килобайты.
Webpack
Самое время поговорить об этом самом мистическом образе. Webpack это как раз то, что и будет упаковывать все ваши файлики в конечный проект. Это уже модуль, который устанавливается через npm прямо в ваш проект.
Сразу предупрежу, что с его настройкой вам будет тяжко. А настраивать его придется. Из коробки он умеет работать только с JavaScript файлами, причем самыми обычными. Сейчас я объясню как именно он это делает.
Вы задаете ему точку входа. Это ваш главный js файл. Вы указываете где он хранится и что с этим файлом надо будет делать. Например, в классическом примере, он находится в папке src и называется index.js. Он его берет и помещает туда, куда вы ему пропишете в настройках. По умолчанию это папка dist, а сам файл будет называться, по умолчанию, bundle.js.
Но не будете же вы весь код хранить в index.js, так ведь? ТАК ВЕДЬ?
Поэтому этот файл и называется точкой входа. Вебпак заглядывает внутрь этого файла и обрабатывает его. И в случае, если вы делили код на несколько файлов (как и нужно делать если кода много), то вы подключаете эти файлы через функцию require (или import, в более новых версиях языка).
Как только он находит эту команду, то он переходит к указанному в ней файлу, и начинает обрабатывать его. Если тот файл тоже подключает какие-то дополнительные файлы, то он продолжает путь дальше. И таким образом, от точки входа он проходит по всему дереву вашего проекта, а на выходе выдает объединенный файл, или, как его принято называть, бандл. О нем мы уже говорили.
И тут есть одно очень важное отличие, которое может сбить с толку тех, кто раньше подключал библиотеки и скрипты только через теги script в HTML файле. Сейчас попробую на пальцах его объяснить.
Если вы в ваш HTML файл подключите два скрипта, то они, как бы, склеятся в единую программу. Как будто это один файл. И если в первом файле вы объявили какую-то переменную, а потом решили вывести его во втором, то это сработает.
Но в случае webpack, вы не просто склеиваете файлы в один. Вы именно импортируете что-то из одного файла в другой. Т.е файл подключился, отработал а на выход отдал то, что получилось. Как функция.
Все остальное в нем — закрыто. Если в вашей точке входа вы сделали импорт двух JS файлов один за другим, то надо помнить, что они независимые модули. Если в одном файле вы объявили переменную, а во втором файле вы попытаетесь ее вывести, то ничего не сработает. Второй файл ничего не знает о переменных, которые находятся в первом файле. И даже главный файл, в который вы импортировали оба этих файла, ничего об этой переменной не знает. Логика каждого отдельного файла инкапсулирована и недоступна для любых других. Это как кокон, у которого есть только вход и выход. Что то импортируется на вход и экспортируется через выход. Что там происходит внутри кокона — секрет)
Откровенно говоря, при попытке импортировать эти два файла в ваш index.js не произойдет вообще ничего. Они просто отработают и все. Разве что второй файл выведет ошибку, так как во время работы он попытается вывести переменную, которой для него не существует. А вот первый файл, по сути, вообще ничего не сделает. Да, он создал переменную. Которая так в нем и осталась.
Но нам не хочется, чтобы они просто работали. Нам хочется получить от этих файлов какие-то данные или какие-то функции, которые мы просто выделили в отдельный файл для удобства. Как же тогда использовать весь этот код и/или данные, если они инкапсулированы внутри файла и доступа к ним нет?
Собственно - экспортировать. Вы можете сделать один общий экспорт в конце файла, тогда у файла будет только один выход для данных. В случае с первым файлом, мы объявляем нашу переменную, и в конце ее экспортируем.
let importantNumber = 42
export default importantNumber
Вот и все, число 5 пошло на экспорт. Именно число, а не сама переменная. В нашем главном файле мы можем задать любую другую переменную для этого числа. Вы можете даже переменную не использовать, просто написать export default 42. И это сработает.
import bukvalnoLubayaPeremennaya from './fileOne.js'
console.log(bukvalnoLubayaPeremennaya) //42
Вот и все. Мы извлекли секретные данные из нашего первого файла. И на месте этих данных может быть все что угодно, функции, обычные переменные, сложные объекты. Можно экспортировать все разом, как сделали мы, используя слово default, а можно все экспортировать по отдельности.
Главное, что нужно уловить из всего этого, это то, что мы не импортируем файл. Мы импортируем что-то из файла.
Точно так же вы подключаете библиотеки и модули. Просто вместо адреса файла вы прописываете название плагина, а он уже автоматически найдется в node_modules. Вы подключаете библиотеку каждый раз заново в тех файлах, где она вам нужна. И не подключаете там, где не нужна. Некоторые библиотеки экспортируют все и сразу, некоторые могут экспортировать функционал по кускам.
const $ = require('jQuery');
Здесь мы назначили jQuery привычную переменную в виде доллара. Но можем любую другую. Как я уже сказал, require это почти то же самое, что и import. Об их различиях (кроме того что одна из них новая а другая - старая) почитаете как нибудь сами.
Ну вот, с JS мы более менее разобрались. Но только лишь с ним.
Вспомним опять import и require. Import более новая и удобная возможность, вот только она не будет работать. Почему? Потому что это возможности новой версии языка JavaScript (на самом деле ECMAScript, но не заморачивайтесь), и они не поддерживаются. Зачем мы тогда написали import, а не require? Вот тут то и начинается самое интересное. Мы будем перегонять написанный нами код из новой и удобной версии - в старую, но поддерживаемую. И рыбку съедим, и пик точеных избежим.
Для этого существуют специальные плагины для вебпака, называемые лоадерами (loaders). Мы прописываем специальные инструкции, согласно которым вызывается тот или иной лоадер. В данном случае, мы хотим, чтобы каждый раз, когда вебпак сталкивался бы с файлом формата .js, он запускал babel-loader. Этот лоадер, в свою очередь, автоматически запустит для файла плагин, который называется просто babel (Если вы помните, сайт для перегонки, который я скидывал, был babeljs.io/repl). Нам надо установить в наш проект и сам babel, и babel-loader который служит перемычкой между babael и webpack, а так же один из пресетов для babel, что то вроде настроек. Порой лоадеры не работают сами по себе.
И вуаля! Наши новомодные import и export прекрасно работают, потому что babel перевел их в старый формат за нас.
И вот это очень важный момент. Вы можете сказать вебпаку, что делать с теми или иными файлами. Просто скопировать их нетронутыми или изменить при помощи какого-нибудь из плагинов. Все эти плагины, конечно же, устанавливаются в ваш проект через npm.
Например, вы можете импортировать в ваши js файлы не только другие js файлы, но и какие только захотите! Хотите импортировать css? Пожалуйста. Так и пишите
import './style.css'
Но как? Да очень просто. Вебпак все так же продолжает гулять по файлам через эти импорты, и каждый раз смотрит на то, что и с каким файлом надо делать. Ага, попался js, значит, надо прогнать его через babel-loader. Ага, а теперь попался css, значит, надо прогнать его сначала через css-loader, а потом еще и через style-loader.
Да, лоадеров может быть несколько для одного и того же типа файлов. Выполняться они, в таком случае, будут поочередно (почему то начиная с последнего. Просто запомните этот факт чтобы меньше ломать голову при настройке)
Например, импортировали мы файл в формате SASS. На этом типе файла у нас в настройках висят сразу 3 лоадера. Первый это sass-loader. Он берет файл и превращает его из sass в обычный и привычный нам css. Потом уже идет css-loader, который добавляет поддержку такого импорта. В конце идет style-loader, он берет весь этот css и вставляет его в шапку нашей будущей страницы. Т.е объединяет все собранные стили и прописывает прямо в HTML.
Вместо style-loader можно использовать, к примеру, mini-css-extract-plugin. Он, в отличии от style-loader, не прописывает стили в шапку страницы, а собирает их в отдельный файл css и просто его подключает. Прямо как bundle.js.
И так вы можете делать для всех типов файлов. Картинки, шрифты, HTML - все что угодно. Главное для каждого прописать свои правила, что с этими файлами делать и куда их складывать.
Отдельного внимания заслуживает HTML, потому что, как правило, не HTML подключают в JS, а наоборот. Для этого есть html-webpack-plugin, он тоже прописывается в настройках вебпака и в нем явно указывается ссылка на HTML. Именно этот плагин скопирует эту HTML страницу куда надо, сделает с ней что надо, и, самое главное, сможет встроить ссылку на получившийся бандл прямо внутрь. Вам не придется прописывать ее самому.
Думаю, главную суть вы уловили. Несмотря на то, что вебпак изначально работает лишь с JS, мы можем с помощью плагинов настроить его под что угодно, прописывая правила отдельно для каждого файла. В начале это будет достаточно муторно и сложно, но с другой стороны, это нужно сделать всего один раз. И вуаля, он будет генерировать нам готовый и собранный проект.
Но что там с локальным сервером разработки? Это плагин webpack-dev-server, который, во многом, использует тот же самый файл с настройками вебпака. Только не создает готовый проект а разворачивает сервер для удобной разработки. Сам следит за обновлениями в файлах, сам обновляет страницу, и именно к нему можно подключить модуль замены содержимого без перезагрузки.
Возможностей у вебпака очень много. Всех их даже не перечислить. Он может даже проверять ваш код на соответствие каким-то стандартам, может проверять совместимость вашего css с поддержкой в браузерах, может даже сам генерировать вам иконки для сайта. Все зависит от того, что вы на него поставите и как настроите. Пусть он и плохо поддается обучению.
Фронтэнд и Бекэнд.
Если вы вдруг хотите начать писать и бенкенд на node.js, то у вас может что-то переклинить в голове, ведь теперь и там и там будет JS, как же его отличить друг от друга?
Ну, код сервера уже будет исполняться самим node.js, и настраивать его нужно так, чтобы он работал уже с готовыми файлами, которые подготовит вам вебпак. Вам придется отказаться от прелестей, которые даст вам webpack-dev-server, потому что заставить их работать синхронно - та еще задача. Но с другой стороны, представить себе ситуацию, где вам нужно прям одновременно работать и с фронтендом и с бенкэндом в одно и то же время — достаточно сложно.
Вы также можете настроить сервер таким образом, чтобы он перезапускался каждый раз, когда вы что-то меняете в его файлах.
Итог
Я надеюсь, что смог для кого-то прояснить общую картинку, что над чем идет и кто под кем работает. Я не уверен, что это кому-то будет нужно, потому что, само собой, сейчас я считаю себя единственным идиотом, кто в свое время не смог в этом разобраться. Но когда только только пытаешься в это вникать, то попусту теряешься от всех этих технологий.
