Хабрахабр

[Перевод] Зачем современную веб-разработку так усложнили? Часть 1

Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.

Я большой поклонник современной веб-разработки, хотя мне она напоминает некую «магию», со своими плюсами и минусами:

  • Когда вы поймете, как использовать волшебные инструменты (babel! бандлеры! вотчеры! и так далее!), ваш рабочий процесс становится быстрым, мощным и восхитительным
  • Если вы не понимаете волшебные инструменты, всё ужасно запутанно
  • …и попытки освоить магию слишком часто неудачны, если вам кто-нибудь не поможет продраться через джунгли жаргона, преувеличений и устаревшей информации в интернете

Недавно мне пришлось объяснить «современные рабочие процессы веб-разработки» людям, далёким от этого, и…

Пришлось реально МНОГО объяснять!

Но всё же попытаемся проследить эволюцию веб-разработки: Даже поверхностное объяснение оказывается довольно длинным.

Часть 1: Как мы добрались со статических сайтов до babel

Начнём с «классической» веб-разработки, которая всем должна быть понятна.

Чтобы просмотреть результат изменений, открываем HTML-файл локально в браузере, а по мере разработки обновляем страницу. В классической разработке мы непосредственно изменяем файлы HTML/CSS/JavaScript.

Рабочий процесс

Рабочий процесс выглядит следующим образом:

  1. Редактируем HTML/CSS/JavaScript в текстовом редакторе, таком как Atom.
  2. Сохраняем файл в текстовом редакторе.
  3. Открываем или перезагружаем файл в браузере.


Редактируем JavaScript, сохраняем файл, обновляем страницу

Развёртывание

Когда вы хотите опубликовать свой сайт в интернете, то просто куда-нибудь загружаем эти файлы HTML/CSS/JavaScript.

Вот пример опубликованной страницы. С помощью сервиса типа Netlify вы можете просто перетащить папку с файлами, чтобы опубликовать страницу в интернете.

Если вы понимаете, как работает «классический» рабочий процесс, то можете сказать: чёрт, это действительно просто и удобно. Зачем вообще нужно было его изменять?! Почему современная веб-разработка настолько сложна?

Короткий ответ… Окей, два коротких ответа.

Два коротких ответа:

  • Вы не обязаны усложнять ситуацию. «Классический» рабочий процесс веб-разработки — это здорово! Его вполне достаточно для множества задач! Не добавляйте лишние инструменты или те, назначения которых не понимаете.
  • Для некоторых проектов вы выиграете от более сложного рабочего процесса. Каждый новый инструмент предназначен для решения конкретной проблемы.

Чтобы понять инструментарий, мы должны понять проблемы современной веб-разработки. В этих статьях рассмотрим каждую из них по отдельности, начиная со старой проблемы веб-разработки, которая существовала в течение десятилетий:
До недавнего времени JavaScript и Web API имели множество ограничений (по множеству причин, которые мы опустим).

Вот некоторые из них:

  • Не было модулей
  • Не было констант
  • Не было промисов / async
  • Не было Array.includes() (!!)
  • Неуклюжий / отсутствующий синтаксис для многих общих примитивов (нет for-of, литералов шаблона, синтаксиса стрелочных функций, распаковки шаблона…)
  • (Web API) Бесчисленные операции DOM были бесполезно сложными (например, добавление/удаление имён классов, скрытие элементов, выбор элементов, удаление элементов…)

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

Отдельно: Какая разница между JavaScript и Web API?

Возможно, вы заметили, что выше я сказала «JavaScript и Web API». Это две разные вещи!

Когда вы пишете JavaScript для веб-страницы, любой вызов API, взаимодействующий с самой веб-страницей, представляет Web API (которые, так получилось, написаны на JavaScript), но это не часть языка JavaScript.

Примеры:

  • Web API: document и каждый method в document; window и каждый method в window; Event, XMLHttpRequest, fetch и т. д.
  • JavaScript: функции, const/let/var, массивы, Promise и т. д.

Например, если вы пишете сервер на Node.js, то пишете на JavaScript и можете использовать, например, промисы, но не можете использовать document.querySelector (и это не имеет смысла делать).
Ещё в 2006 году вышла библиотека jQuery, которая помогла обойти многие недостатки JavaScript и Web API.

jQuery включает в себя API, которые значительно помогают в решении типичных веб-задач, такие как манипуляции с DOM, асинхронная обработка, решение кросс-браузерные несоответствий и фетчинг ресурсов.

Поэтому вместо написания утомительного кода, например, для загрузки и обработки файла JSON, вы могли просто загрузить библиотеку jQuery и использовать отличные jQuery API. Итак, по сути: всё это было технически возможно с использованием старого JavaScript и старых Web API, но процесс был очень раздражающим, утомительным и часто сложными для разработки.

Однако с 2006 года прошло много времени!

С тех пор JavaScript и Web API значительно улучшились, в том числе благодаря помощи от jQuery и других, показавших путь!

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

Он означает “ECMAScript 6” и относится к 6-й итерации ECMAScript. Возможно, вы слышали термин “ES6”. Просто в разговорной речи люди обычно используют “ECMAScript” для ссылки на саму спецификацию, а “JavaScript” — для ссылки на код. ECMAScript — это ещё одно название JavaScript.

В любом случае, это неправильно! (Кстати, ещё одна путаница и моя любимая мозоль: JavaScript не является реализацией/диалектом ECMAScript; это как называть “HTML” реализацией/диалектом «спецификаций HTML». JavaScript и ECMAScript — это одно и то же). Википедия, ты ошибаешься!

ES6 (выпущенный в 2015 году) примечателен тем, что добавляет много действительно приятных языковых функций в JavaScript, таких как const, модули и промисы (а ES8 представил мою любимую языковую функцию: async).

Параллельно и Web API значительно улучшились с 2006 года, с добавлением document.querySelector, fetch и мелочей вроде classList и hidden.

Поэтому вместо jQuery или других подобных библиотек в 2019 году мы можем, по большей части, просто напрямую использовать JavaScript и Web API.

…вроде того!

Когда выходит обновление языка JavaScript, браузеры также следует обновить для поддержки новых функций (то же верно и для Web API, но для простоты оставим только JavaScript).

Тем не менее, есть задержки между 1) определением новой функции в языке; 2) реализацией функции во всех браузерах; 3) обновлением браузеров у всех пользователей (а это может никогда не произойти).

У обоих подходов есть плюсы и минусы (конкретный пример кода взят отсюда)
Дилемма: писать на старом или последнем JavaScript?

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

Эту конкретную дилемму решает Babel.

В частности, он преобразует код JavaScript, написанный с использованием последней версии JavaScript, в эквивалентный код, написанный с использованием более старой версии JavaScript, которая поддерживается в гораздо большем количестве браузеров. Babel — это компилятор JavaScript, который преобразует код JavaScript в… другой код JavaScript!


С Babel мы можем наслаждаться преимуществами кодирования на последнем JavaScript, не беспокоясь о совместимости браузеров

Оговорка: Babel не поддерживает Web API

Например, если вы используете fetch в своём JavaScript, то babel не предоставит резервной поддержки (она называется «полифиллинг»), потому что fetch — это Web API, а не часть самого JavaScript (эта проблема сейчас решается).

Но мы вернёмся к этому в следующей статье. Таким образом, вам понадобится отдельное решение для полифиллинга Web API!

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

Ниже приведён простейший рабочий процесс, который обычно не используется на практике (потому что более удобен бандлер вроде Parcel или webpack, но об этом позже).

Установка

  1. Установить* Babel
    (*Можете следовать инструкциям CLI, понимая, как работает npm. И эти инструкции рекомендуют устанавливать babel локально в качестве зависимости npm dev для каждого проекта, а не глобально на вашем компьютере)

Рабочий процесс разработки

  1. Разработайте свой сайт как обычную статическую веб-страницу.


    Пример: ванильный JavaScript размещается в каталоге src

Развёртывание

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

Вместо этого, вы хотите:

  1. Скомпилировать JavaScript с помощью babel, чтобы получить совместимый с браузером код:

    Это создаст новый, скомпилированный файл JavaScript в отдельной папке:


    Пример: Babel создаст второй “script.js”, уже с кроссбраузерной совместимостью

  2. Загрузить скомпилированный JavaScript в интернет вместе со своими HTML и CSS:

    Сайт будет* выглядеть и вести себя так же, как в режиме разработки, но пользователям будет выдаваться код, скомпилированный babel для всех браузеров.

    (*Надеюсь! Иногда есть различия в сборках Debug и Release, но это баги!)

Обратите внимание, что теперь у нас есть разделение между кодом «разработки» и кодом «релиза» (продакшна):

  • Код разработки: код, который вы пишете во время разработки веб-приложения.
  • Код продакшна: код, который требуется запускать при посещении пользователем.

Мы намеренно хотим разделить эти вещи, потому что:

  • Код разработки хорош для разработчиков, но плох для пользователей
  • Код продакшна хорош для пользователей, но плох для разработчиков

Во фронтенд-разработке не каждый использует или должен использовать Babel.

Общая картина такова: Но!

  • Написание кода разработки, который не отображается пользователям,
  • а вместо этого компилируется в другой код продакшна, который следует показывать пользователям

Это не просто распространённый, а часто ожидаемая картина для современной фронтенд-разработки.

Но он особенно актуален для фронтенда, как по причине распространённости, так и из-за большой разницы во фронтенд-коде Debug/Release). (Обратите внимание, что наличие отдельных сборок Debug и Release является общим шаблоном в программной инженерии, а не чем-то особенным для веб-разработки.

Краткий список технологий, где ожидается такое разделение между версиями разработки и продакшна:

  • модули npm
  • Любой препроцессор CSS
  • React/Vue/Angular/любой веб-фреймворк

Это общий шаблон, так что обратите на него внимание уже сейчас!
В следующей части нашего путешествия мы рассмотрим модули npm (что это такое и зачем) и бандлинг (что это и зачем), и как они усложняют рабочий процесс.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть