- PVSM.RU - https://www.pvsm.ru -
Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.
Я большой поклонник современной веб-разработки, хотя мне она напоминает некую «магию», со своими плюсами и минусами:
Недавно мне пришлось объяснить «современные рабочие процессы веб-разработки» людям, далёким от этого, и…
Пришлось реально МНОГО объяснять!
Даже поверхностное объяснение оказывается довольно длинным. Но всё же попытаемся проследить эволюцию веб-разработки:
Начнём с «классической» веб-разработки, которая всем должна быть понятна.
В классической разработке мы непосредственно изменяем файлы HTML/CSS/JavaScript. Чтобы просмотреть результат изменений, открываем HTML-файл локально в браузере, а по мере разработки обновляем страницу.
Рабочий процесс выглядит следующим образом:
Редактируем JavaScript, сохраняем файл, обновляем страницу
Когда вы хотите опубликовать свой сайт в интернете, то просто куда-нибудь загружаем эти файлы HTML/CSS/JavaScript.
С помощью сервиса типа Netlify вы можете просто перетащить папку с файлами, чтобы опубликовать страницу в интернете. Вот пример опубликованной страницы [1].
Если вы понимаете, как работает «классический» рабочий процесс, то можете сказать: чёрт, это действительно просто и удобно. Зачем вообще нужно было его изменять?! Почема современная веб-разработка настолько сложна?
Короткий ответ… Окей, два коротких ответа.
Два коротких ответа:
Чтобы понять инструментарий, мы должны понять проблемы современной веб-разработки. В этих статьях рассмотрим каждую из них по отдельности, начиная со старой проблемы веб-разработки, которая существовала в течение десятилетий:
До недавнего времени JavaScript и Web API имели множество ограничений (по множеству причин, которые мы опустим).
Вот некоторые из них:
Браузеры способны выполнять только JavaScript, поэтому вы не можете преодолеть ограничения, используя другой язык.
Возможно, вы заметили, что выше я сказала «JavaScript и Web API». Это две разные вещи!
Когда вы пишете JavaScript для веб-страницы, любой вызов API, взаимодействующий с самой веб-страницей, представляет Web API [2] (которые, так получилось, написаны на JavaScript), но это не часть языка JavaScript.
Примеры:
document
и каждый method
в document
; window
и каждый method
в window
; Event
, XMLHttpRequest
, fetch
и т. д.
const
/let
/var
, массивы, Promise
и т. д.
Например, если вы пишете сервер на Node.js, то пишете на JavaScript и можете использовать, например, промисы, но не можете использовать document.querySelector
(и это не имеет смысла делать).
Ещё в 2006 году вышла библиотека jQuery [3], которая помогла обойти многие недостатки JavaScript и Web API.
jQuery включает в себя API, которые значительно помогают в решении типичных веб-задач, такие как манипуляции с DOM, асинхронная обработка, решение кросс-браузерные несоответствий и фетчинг ресурсов.
Итак, по сути: всё это было технически возможно с использованием старого JavaScript и старых Web API, но процесс был очень раздражающим, утомительным и часто сложными для разработки. Поэтому вместо написания утомительного кода, например, для загрузки и обработки файла JSON, вы могли просто загрузить библиотеку jQuery и использовать отличные jQuery API.
Однако с 2006 года прошло много времени!
С тех пор JavaScript и Web API значительно улучшились, в том числе благодаря помощи от jQuery и других, показавших путь!
JavaScript — это постоянно развивающийся язык. Подобно тому, как обновляется программное обеспечение, сам язык JavaScript обновляется с каждой версией.
Возможно, вы слышали термин “ES6”. Он означает “ECMAScript 6” и относится к 6-й итерации ECMAScript. ECMAScript — это ещё одно название JavaScript. Просто в разговорной речи люди обычно используют “ECMAScript” для ссылки на саму спецификацию, а “JavaScript” — для ссылки на код.
(Кстати, ещё одна путаница и моя любимая мозоль: JavaScript не является реализацией/диалектом ECMAScript; это как называть “HTML” реализацией/диалектом «спецификаций HTML». В любом случае, это неправильно! Википедия, ты ошибаешься [4]! JavaScript и ECMAScript — это одно и то же).
ES6 (выпущенный в 2015 году) [5] примечателен тем, что добавляет много действительно приятных языковых функций в JavaScript, таких как const
, модули и промисы (а ES8 [6] представил мою любимую языковую функцию [7]: async
).
Параллельно и Web API значительно улучшились с 2006 года, с добавлением document.querySelector [8], fetch [9] и мелочей вроде classList [10] и hidden [11].
Поэтому вместо jQuery или других подобных библиотек в 2019 году мы можем, по большей части, просто напрямую использовать JavaScript и Web API.
…вроде того!
Когда выходит обновление языка JavaScript, браузеры также следует обновить для поддержки новых функций (то же верно и для Web API, но для простоты оставим только JavaScript).
Тем не менее, есть задержки между 1) определением новой функции в языке; 2) реализацией функции во всех браузерах; 3) обновлением браузеров у всех пользователей (а это может никогда не произойти).
Дилемма: писать на старом или последнем JavaScript? У обоих подходов есть плюсы и минусы (конкретный пример кода взят отсюда [12])
У разработчиков возникает дилемма. Конечно, мы хотим использовать современные функции языка JavaScript, потому что эти улучшения часто значительно облегчают кодирование определённых вещей. Но мы также хотим, чтобы веб-сайты работали для всех пользователей, независимо от того, когда они в последний раз перезапускали браузер, чтобы обновиться.
Эту конкретную дилемму решает Babel [13].
Babel — это компилятор JavaScript, который преобразует код JavaScript в… другой код JavaScript! В частности, он преобразует код JavaScript, написанный с использованием последней версии JavaScript, в эквивалентный код, написанный с использованием более старой версии JavaScript, которая поддерживается в гораздо большем количестве браузеров.
С Babel мы можем наслаждаться преимуществами кодирования на последнем JavaScript, не беспокоясь о совместимости браузеров
Например, если вы используете fetch
в своём JavaScript, то babel не предоставит резервной поддержки (она называется «полифиллинг»), потому что fetch
— это Web API, а не часть самого JavaScript (эта проблема сейчас решается [14]).
Таким образом, вам понадобится отдельное решение для полифиллинга Web API! Но мы вернёмся к этому в следующей статье.
Итак, теперь мы мотивировали, почему можно использовать babel. Как выглядит рабочий процесс веб-разработки с ним?
Ниже приведён простейший рабочий процесс, который обычно не используется на практике (потому что более удобен бандлер вроде Parcel или webpack, но об этом позже).
Пример: ванильный JavaScript размещается в каталоге src
Когда вы готовы опубликовать сайт в интернете, вы НЕ хотите загружать туда «ванильные» файлы JavaScript, потому что вы использовали функции JavaScript, которые не поддерживаются всеми браузерами.
Вместо этого, вы хотите:
Это создаст новый, скомпилированный файл JavaScript в отдельной папке:
Пример: Babel создаст второй “script.js”, уже с кроссбраузерной совместимостью
Сайт будет* выглядеть и вести себя так же, как в режиме разработки, но пользователям будет выдаваться код, скомпилированный babel для всех браузеров.
(*Надеюсь! Иногда есть различия в сборках Debug и Release, но это баги!)
Обратите внимание, что теперь у нас есть разделение между кодом «разработки» и кодом «релиза» (продакшна):
Мы намеренно хотим разделить эти вещи, потому что:
Во фронтенд-разработке не каждый использует или должен использовать Babel.
Но! Общая картина такова:
Это не просто распространённый, а часто ожидаемая картина для современной фронтенд-разработки.
(Обратите внимание, что наличие отдельных сборок Debug и Release является общим шаблоном в программной инженерии, а не чем-то особенным для веб-разработки. Но он особенно актуален для фронтенда, как по причине распространённости, так и из-за большой разницы во фронтенд-коде Debug/Release).
Краткий список технологий, где ожидается такое разделение между версиями разработки и продакшна:
Это общий шаблон, так что обратите на него внимание уже сейчас!
В следующей части нашего путешествия мы рассмотрим модули npm (что это такое и зачем) и бандлинг (что это и зачем), и как они усложняют рабочий процесс.
Автор: m1rko
Источник [20]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/javascript/326918
Ссылки в тексте:
[1] пример опубликованной страницы: https://sleepy-lichterman-6811cc.netlify.com/
[2] Web API: https://developer.mozilla.org/en-US/docs/Web/API
[3] jQuery: https://en.wikipedia.org/wiki/JQuery
[4] Википедия, ты ошибаешься: https://en.wikipedia.org/wiki/ECMAScript
[5] ES6 (выпущенный в 2015 году): https://en.wikipedia.org/wiki/ECMAScript#6th_Edition_-_ECMAScript_2015
[6] ES8: https://en.wikipedia.org/wiki/ECMAScript#8th_Edition_-_ECMAScript_2017
[7] любимую языковую функцию: https://twitter.com/bictolia/status/1136441515104985089
[8] document.querySelector: https://developer.mozilla.org/en-US/docs/Web/API/Document/querySelector
[9] fetch: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
[10] classList: https://developer.mozilla.org/en-US/docs/Web/API/Element/classList
[11] hidden: https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/hidden
[12] отсюда: https://blog.hellojs.org/asynchronous-javascript-from-callback-hell-to-async-and-await-9b9ceb63c8e8
[13] Babel: https://babeljs.io/
[14] эта проблема сейчас решается: https://github.com/babel/babel/issues/10008
[15] инструкциям CLI: https://babeljs.io/setup#installation
[16] обычную статическую веб-страницу: https://www.notion.so/glitch/Proposal-Debug-Release-without-branching-a7a080fd59644e90a4f22f0a6f31b5ed#1227ca2fe74346a89bcc78e94de166d4
[17] script.js: https://sleepy-lichterman-6811cc.netlify.com/script.js
[18] сайт: https://zen-lamarr-b74cd8.netlify.com/
[19] script.js: https://zen-lamarr-b74cd8.netlify.com/script.js
[20] Источник: https://habr.com/ru/post/463503/?utm_source=habrahabr&utm_medium=rss&utm_campaign=463503
Нажмите здесь для печати.