babel что это зачем нужен
Полифилы
JavaScript – динамично развивающийся язык программирования. Регулярно появляются предложения о добавлении в JS новых возможностей, они анализируются, и, если предложения одобряются, то описания новых возможностей языка переносятся в черновик https://tc39.github.io/ecma262/, а затем публикуются в спецификации.
Разработчики JavaScript-движков сами решают, какие предложения реализовывать в первую очередь. Они могут заранее добавить в браузеры поддержку функций, которые всё ещё находятся в черновике, и отложить разработку функций, которые уже перенесены в спецификацию, потому что они менее интересны разработчикам или более сложные в реализации.
Таким образом, довольно часто реализуется только часть стандарта.
Можно проверить текущее состояние поддержки различных возможностей JavaScript на странице https://kangax.github.io/compat-table/es6/ (нам ещё предстоит изучить многое из этого списка).
Babel
Когда мы используем современные возможности JavaScript, некоторые движки могут не поддерживать их. Как было сказано выше, не везде реализованы все функции.
И тут приходит на помощь Babel.
Babel – это транспилер. Он переписывает современный JavaScript-код в предыдущий стандарт.
На самом деле, есть две части Babel:
Во-первых, транспилер, который переписывает код. Разработчик запускает Babel на своём компьютере. Он переписывает код в старый стандарт. И после этого код отправляется на сайт. Современные сборщики проектов, такие как webpack или brunch, предоставляют возможность запускать транспилер автоматически после каждого изменения кода, что позволяет экономить время.
Новые возможности языка могут включать встроенные функции и синтаксические конструкции. Транспилер переписывает код, преобразовывая новые синтаксические конструкции в старые. Но что касается новых встроенных функций, нам нужно их как-то реализовать. JavaScript является высокодинамичным языком, скрипты могут добавлять/изменять любые функции, чтобы они вели себя в соответствии с современным стандартом.
Термин «полифил» означает, что скрипт «заполняет» пробелы и добавляет современные функции.
Два интересных хранилища полифилов:
Таким образом, чтобы современные функции поддерживались в старых движках, нам надо установить транспилер и добавить полифил.
Примеры в учебнике
Большинство примеров можно запустить «на месте», как этот:
Примеры, в которых используются современные возможности JS, будут работать, если ваш браузер их поддерживает.
Google Chrome обычно поддерживает современные функции, можно запускать новейшие примеры без каких-либо транспилеров, но и другие современные браузеры тоже хорошо работают.
Что такое Babel и где его используют
Где и зачем используют Babel
Babel это не просто транспайлер, это лучший друг разработчика. ECMA International, пока что, выпускает обновления языка Javascript каждый год. В связи с этим, у разработчиков появляются новые возможности: более короткий синтаксис, стрелочные функции, промисы и.т.д.
Соответственно, не все современные браузеры могут или хотят идти в ногу с этими изменениями. А еще, к этому прибавляем старые браузеры, которые больше никогда не обновятся. Но их все равно пока используют, привет Internet Explorer.
Вот здесь и нужен Babel. Он помогает не ждать обновлений браузеров, а сразу использовать всю мощь современных стандартов Javascript.
Используют Babel вместе с различными сборщиками проектов: webpack и gulp, устанавливая необходимый “функционал” с помощью менеджера пакетов NPM. Сам NPM входит в состав Node.js.
Единственный минус Babel (для меня), это слишком сильное видоизменение изначального кода. Обычно, такое можно прочитать с большим трудом.
После использования Babel.
В целом, вы и так сможете писать нормально работающий код на всех современных браузерах без использования Babel. Например, сегодняшний Safari и Google Chrome уже поддерживают ES2015 Javascript. Поэтому иногда можно обойтись без использования Babel. Естественно, если вам не сильно важно будет ли работать код в старых браузерах.
Опубликовано: 2019-10-13 19:44
Нужен сайт?
Готов за разумную плату разработать сайт, CRM-систему или внедрить дополнительный функционал в существующий проект.
Зачем современную веб-разработку так усложнили? Часть 1
Современная фронтенд-разработка оставляет полярные впечатления: одни её любят, другие презирают.
Я большая поклонница современной веб-разработки, хотя она мне напоминает некую «магию», со своими плюсами и минусами:
Пришлось реально МНОГО объяснять!
Даже поверхностное объяснение оказывается довольно длинным. Но всё же попытаемся проследить эволюцию веб-разработки:
Часть 1: Как мы добрались со статических сайтов до babel
Самый простой сайт: статический
Начнём с «классической» веб-разработки, которая всем должна быть понятна.
В классической разработке мы непосредственно изменяем файлы HTML/CSS/JavaScript. Чтобы просмотреть результат изменений, открываем HTML-файл локально в браузере, а по мере разработки обновляем страницу.
Рабочий процесс
Рабочий процесс выглядит следующим образом:
Развёртывание
Когда вы хотите опубликовать свой сайт в интернете, то просто куда-нибудь загружаем эти файлы HTML/CSS/JavaScript.
С помощью сервиса типа Netlify вы можете просто перетащить папку с файлами, чтобы опубликовать страницу в интернете. Вот пример опубликованной страницы.
Это так просто! Зачем всё усложнили?!
Если вы понимаете, как работает «классический» рабочий процесс, то можете сказать: чёрт, это действительно просто и удобно. Зачем вообще нужно было его изменять?! Почему современная веб-разработка настолько сложна?
Короткий ответ… Окей, два коротких ответа.
Два коротких ответа:
Старая проблема: ограничения JavaScript
До недавнего времени JavaScript и Web API имели множество ограничений (по множеству причин, которые мы опустим).
Вот некоторые из них:
Отдельно: Какая разница между JavaScript и Web API?
Возможно, вы заметили, что выше я сказала «JavaScript и Web API». Это две разные вещи!
Когда вы пишете JavaScript для веб-страницы, любой вызов API, взаимодействующий с самой веб-страницей, представляет Web API (которые, так получилось, написаны на JavaScript), но это не часть языка JavaScript.
Старое решение: jQuery и друзья
Ещё в 2006 году вышла библиотека jQuery, которая помогла обойти многие недостатки JavaScript и Web API.
jQuery включает в себя API, которые значительно помогают в решении типичных веб-задач, такие как манипуляции с DOM, асинхронная обработка, решение кросс-браузерных несоответствий и фетчинг ресурсов.
Итак, по сути: всё это было технически возможно с использованием старого JavaScript и старых Web API, но процесс был очень раздражающим, утомительным и часто сложными для разработки. Поэтому вместо написания утомительного кода, например, для загрузки и обработки файла JSON, вы могли просто загрузить библиотеку jQuery и использовать отличные jQuery API.
Новое решение: давайте улучшим сам JavaScript
Однако с 2006 года прошло много времени!
С тех пор JavaScript и Web API значительно улучшились, в том числе благодаря помощи от jQuery и других, показавших путь!
JavaScript — это постоянно развивающийся язык. Подобно тому, как обновляется программное обеспечение, сам язык JavaScript обновляется с каждой версией.
Возможно, вы слышали термин “ES6”. Он означает “ECMAScript 6” и относится к 6-й итерации ECMAScript. ECMAScript — это ещё одно название JavaScript. Просто в разговорной речи люди обычно используют “ECMAScript” для ссылки на саму спецификацию, а “JavaScript” — для ссылки на код.
(Кстати, ещё одна путаница и моя любимая мозоль: JavaScript не является реализацией/диалектом ECMAScript; это как называть “HTML” реализацией/диалектом «спецификаций HTML». В любом случае, это неправильно! Википедия, ты ошибаешься! JavaScript и ECMAScript — это одно и то же).
Параллельно и Web API значительно улучшились с 2006 года, с добавлением document.querySelector, fetch и мелочей вроде classList и hidden.
Поэтому вместо jQuery или других подобных библиотек в 2019 году мы можем, по большей части, просто напрямую использовать JavaScript и Web API.
Новая-старая проблема: кроссбраузерная поддержка
Когда выходит обновление языка JavaScript, браузеры также следует обновить для поддержки новых функций (то же верно и для Web API, но для простоты оставим только JavaScript).
Тем не менее, есть задержки между 1) определением новой функции в языке; 2) реализацией функции во всех браузерах; 3) обновлением браузеров у всех пользователей (а это может никогда не произойти).
Дилемма: писать на старом или последнем JavaScript? У обоих подходов есть плюсы и минусы (конкретный пример кода взят отсюда)
У разработчиков возникает дилемма. Конечно, мы хотим использовать современные функции языка JavaScript, потому что эти улучшения часто значительно облегчают кодирование определённых вещей. Но мы также хотим, чтобы веб-сайты работали для всех пользователей, независимо от того, когда они в последний раз перезапускали браузер, чтобы обновиться.
Эту конкретную дилемму решает Babel.
Babel — это компилятор JavaScript, который преобразует код JavaScript в… другой код JavaScript! В частности, он преобразует код JavaScript, написанный с использованием последней версии JavaScript, в эквивалентный код, написанный с использованием более старой версии JavaScript, которая поддерживается в гораздо большем количестве браузеров.
С Babel мы можем наслаждаться преимуществами кодирования на последнем JavaScript, не беспокоясь о совместимости браузеров
Оговорка: Babel не поддерживает Web API
Например, если вы используете fetch в своём JavaScript, то babel не предоставит резервной поддержки (она называется «полифиллинг»), потому что fetch — это Web API, а не часть самого JavaScript (эта проблема сейчас решается).
Таким образом, вам понадобится отдельное решение для полифиллинга Web API! Но мы вернёмся к этому в следующей статье.
Возвращаясь к рабочему процессу: статический сайт + babel
Итак, теперь мы поняли, почему можно использовать babel. Как выглядит рабочий процесс веб-разработки с ним?
Ниже приведён простейший рабочий процесс, который обычно не используется на практике (потому что более удобен бандлер вроде Parcel или webpack, но об этом позже).
Установка
Рабочий процесс разработки
Пример: ванильный JavaScript размещается в каталоге src
Развёртывание
Когда вы готовы опубликовать сайт в интернете, вы НЕ хотите загружать туда «ванильные» файлы JavaScript, потому что вы использовали функции JavaScript, которые не поддерживаются всеми браузерами.
Вместо этого, вы хотите:
Это создаст новый, скомпилированный файл JavaScript в отдельной папке:
Сайт будет* выглядеть и вести себя так же, как в режиме разработки, но пользователям будет выдаваться код, скомпилированный babel для всех браузеров.
Различия между кодом в разработке и в продакшне
Обратите внимание, что теперь у нас есть разделение между кодом «разработки» и кодом «релиза» (продакшна):
Но! Общая картина такова:
(Обратите внимание, что наличие отдельных сборок Debug и Release является общим шаблоном в программной инженерии, а не чем-то особенным для веб-разработки. Но он особенно актуален для фронтенда, как по причине распространённости, так и из-за большой разницы во фронтенд-коде Debug/Release).
Краткий список технологий, где ожидается такое разделение между версиями разработки и продакшна:
Использование Babel и Webpack для настройки React-проекта с нуля
Существует немало инструментов, позволяющих подготовить среду для React-разработки. Например, в наших материалах учебного курса по React используется средство create-react-app, позволяющее создать шаблонный проект, содержащий всё необходимое для разработки React-приложений. Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как самостоятельно настроить окружение для разработки React-проектов с использованием Babel и Webpack. Эти инструменты используются и в проектах, создаваемых средствами create-react-app, и мы полагаем, что всем, кто изучает React-разработку, интересно будет познакомиться с ними и с методикой создания React-проектов на более глубоком уровне. А именно, речь пойдёт о том, как сконфигурировать Webpack таким образом, чтобы это средство использовало бы Babel для компиляции JSX-кода в JavaScript-код, и как настроить сервер, используемый при разработке React-проектов.
Webpack
Webpack используется для компиляции JavaScript-модулей. Этот инструмент часто называют «бандлером» (от bundler) или «сборщиком модулей». После его установки работать с ним можно, используя интерфейс командной строки или его API. Если вы не знакомы с Webpack — рекомендуется почитать об основных принципах его работы и посмотреть его сравнение с другими сборщиками модулей. Вот как, на высоком уровне, выглядит то, что делает Webpack.
Webpack берёт всё, от чего зависит проект, и преобразует это в статические ресурсы, которые могут быть переданы клиенту. Упаковка приложений — это очень важно, так как большинство браузеров ограничивает возможности по одновременной загрузке ресурсов. Кроме того, это позволяет экономить трафик, отправляя клиенту лишь то, что ему нужно. В частности, Webpack использует внутренний кэш, благодаря чему модули загружаются на клиент лишь один раз, что, в итоге, приводит к ускорению загрузки сайтов.
Babel
Babel — это транспилятор, который, в основном, используется для преобразования конструкций, принятых в свежих версиях стандарта ECMAScript, в вид, понятный как современным, так и не самым новым браузерам и другим средам, в которых может выполняться JavaScript. Babel, кроме того, умеет преобразовывать в JavaScript и JSX-код, используя @babel/preset-react.
Именно благодаря Babel мы, при разработке React-приложений, можем пользоваться JSX. Например, вот код, в котором используется JSX:
Выглядит такой код аккуратно, он понятен, его легко читать и редактировать. Глядя на него, сразу можно понять, что он описывает компонент, возвращающий элемент
Преимущества первого примера перед вторым очевидны.
Предварительные требования
Для того чтобы настроить проект React-приложения, нам понадобятся следующие npm-модули.
Готовый проект, которым мы будем здесь заниматься, можно найти в этом репозитории.
Настройка Webpack
Свойство entry задаёт главный файл с исходным кодом проекта. Значение свойства mode указывает на тип окружения для компиляции (в нашем случае это окружение разработки — development ) и на то, куда нужно поместить скомпилированный файл.
Работа над проектом
с идентификатором root мы будем использовать для вывода React-приложения.
Теперь установим пакеты react и react-dom:
Внесём в index.js следующий код:
Это — стандартный код для подобных файлов React-приложений. Тут мы подключаем библиотеки, подключаем файл компонента и выводим приложение в тег
Вот код файла app.component.js :
Вот код файла app.component.css :
Настройка Babel
Благодаря этим настройкам Babel будет знать о том, какие пресеты ему нужно использовать. Теперь настроим Webpack на использование Babel.
Настройка Webpack на работу с Babel
Тут мы воспользуемся библиотекой babel-loader, которая позволит использовать Babel с Webpack. Фактически, речь идёт о том, что Babel сможет перехватывать и обрабатывать файлы до их обработки Webpack.
▍JS-файлы
Вот правила, касающиеся работы с JS-файлами (этот код пойдёт в файл webpack.config.js ), они представляют собой одно из свойств объекта с настройками, экспортируемого этим файлом:
▍CSS-файлы
Добавим в массив rules объекта module настройки для обработки CSS-файлов:
▍Статические ресурсы
Если система встретит файл с расширением PNG, SVG, JPG или GIF, то для обработки такого файла будет использован file-loader. Обработка таких файлов важна для правильной подготовки и оптимизации проекта.
Настройка сервера разработки
Вот полный код файла webpack.config.js :
Сейчас всё готово к тому, чтобы запустить сервер разработки следующей командой:
Если теперь перейти по адресу http://localhost:9000, можно будет увидеть страницу нашего проекта.
Страница проекта в браузере
Для того чтобы собрать проект воспользуйтесь следующей командой:
После этого можно будет открыть файл index.html в браузере и увидеть то же самое, что можно было видеть, запустив сервер разработки и перейдя по адресу http://localhost:9000.
Итоги
В этом материале приведён обзор настройки Webpack и Babel для их использования в React-проектах. На самом деле, на той базе, которую мы сегодня разобрали, можно создавать гораздо более сложные конфигурации. Например, вместо CSS можно воспользоваться LESS, вместо обычного JS писать на TypeScript. При необходимости можно, например, настроить минификацию файлов и многое другое. Конечно, если сегодня состоялось ваше первое знакомство с процессом самостоятельной настройки React-проектов, вам может показаться, что всё это очень сложно и куда легче воспользоваться готовым шаблоном. Однако после того, как вы немного в этом разберётесь, вы поймёте, что некоторое увеличение сложности настроек даёт вам большую свободу, позволяя настраивать свои проекты именно так, как вам это нужно, не полагаясь полностью на некие «стандартные» решения и снизив свою зависимость от них.
Уважаемые читатели! Какой подход вы чаще всего используете при подготовке рабочей среды для React-проектов?
Почему вы можете обойтись без Babel
Также приглашаем всех желающих на открытый вебинар «Код как проект — настройка окружения для разработки на JavaScript». На вебинаре участники вместе с экспертом рассмотрят основные инструменты, которые помогают делать код лучше и чище — prettier, eslint, husky.
В наше время фронтенд-разработчики все еще тратят много времени на чрезмерную подготовку и настройку программного обеспечения. Babel воспринимается некоторыми как вынужденная необходимость, но я намерен показать вам, что это не так.
Ознакомившись с этой статьей, вы поймете:
как выяснить, какие браузеры действительно требуют дополнительной поддержки в каждом конкретном случае.
как использовать редактор Visual Studio Code, чтобы обойтись без Babel.
существует другая альтернатива программного обеспечения, чтобы сделать ту же работу быстрее.
Что такое Babel и какую проблему он решает?
Babel — это компилятор, который преобразует ваш современный JavaScript для запуска в старых браузерах. Он также может выполнять и другие задачи, такие как преобразование синтаксиса JSX, но это не единственный инструмент для этого.
По мере развития браузеров добавляются новые функции API и ECMAScript. Различные браузеры развиваются с разной скоростью и расставляют акценты в качестве приоритетных для разных задач. Это ставит нас перед непростым выбором: как мы можем их все поддерживать и при этом использовать современные функции? Некоторые из них будут несовместимы.
Обычное решение заключается в том, чтобы использовать новейшие возможности и трансформировать их в более старый код, который будет понятен браузеру. Транспилирование (Transpiling — сочетание двух слов: transforming — преобразование и compiling — компиляция) описывает специализированный тип компиляции. Она имеет различные значения в разных контекстах. В нашем случае также существуют две отдельные составляющие для переноса (транспилирования).
Разница между транспилированием (transpiling) и полифилингом (polyfilling)
Транспилирование (Transpiling) — это процесс преобразования синтаксиса нового языка, который старые браузеры не могут понять, в старый синтаксис, который они распознают.
Приведем пример переноса оператора let :
Полифилинг (Polyfilling) — это процесс добавления недостающих методов, свойств или API к старым браузерам путем предоставления собственной версии недостающего родного кода.
Это можно рассматривать как дополнение недостающих элементов. Например, вот полифил (polyfill) для isNaN :
Наилучшим способом для получения полифилов является использование core-js.
Транспилирование и полифилинг иногда невозможны и могут значительно увеличить объем кода, лучше всего их вообще избегать, если это возможно. Поэтому альтернатива, которую мы будем рассматривать в первую очередь, является наиболее оптимальным решением.
Альтернатива №1: не поддерживать древние браузеры
Если бы пользователи просто обновили свои браузеры, мы могли бы избежать хлопот, связанных с транспилированием, и они могли бы наслаждаться усовершенствованными функциями и производительностью нового браузера. К сожалению, все не так просто.
Главный виновник — крупные корпорации, которым приходится поддерживать старое программное обеспечение. Классическим примером является Internet Explorer, который с самого начала был помехой для веб-разработок.
Тем не менее, за последние годы многое изменилось в лучшую сторону. Теперь большинство существующих браузеров актуальны, то есть они постоянно обновляются. Microsoft продвигает свой современный браузер Edge, который, что удобно, использует тот же движок V8, как и Chrome, что означает сокращение количества поддерживаемых движков на один.
Чтобы определить, нужно ли поддерживать определенный браузер, задайте себе следующие вопросы.
1. Какие браузеры в настоящее время используют Ваши клиенты?
Если у вас уже есть веб-сайт или приложение, которое обслуживает одну и ту же клиентскую базу, вы можете получить эту информацию из программы аналитики. Ниже приведены некоторые последние статистические данные с британского сайта звуковой инженерии, которым я управляю. Если бы это было JavaScript-приложение с теми же клиентами из той же категории, я бы предположил, что они будут использовать те же браузеры.
Если у вас не установлено аналитическое программное обеспечение, вы не будете знать, какие браузеры вам нужно поддерживать. Вы должны будете сделать обоснованное предположение. Если у вас есть корпоративные клиенты, гораздо больше шансов, что вам понадобится поддержка IE11 (Internet Explorer 11), чем если бы вы занимались маркетингом для фанатов web-literate (грамотное программирование) технологий.
Когда вы поддерживаете браузер, то принимаете на себя обязательства. Вы действительно хотите иметь лишние тесты в каждом выпуске, дополнительные инструменты для настройки и больше различных функций, чтобы это обслуживать?
Должна быть ясная финансовая причина, чтобы пойти на все эти хлопоты. Будет ли потеря тех клиентов, которые не могут получить доступ к вашему сайту или приложению, стоить дороже, чем поддержка браузера?
2. Какие современные функции браузера вы хотите использовать?
Использование современных функций языка и API (Application Programming Interfaces) браузера делает написание кода проще, быстрее и интереснее. Это также делает ваш код более удобным в обслуживании.
3. Какие современные функции браузера поддерживают браузеры ваших клиентов?
Эти данные доступны через Can I use (могу ли я использовать), но это напрасная трата времени на их поиск вручную. Теперь, когда вы знаете названия браузеров, которые вы хотите поддерживать, поиск совместимых функций может быть автоматизирован с помощью удивительного приложения Browserlist (подробнее об этом в следующем разделе).
Альтернатива № 2: Используйте eslint-plugin-compat
Вы можете вообще избежать всего процесса переноса (transpiling) и вместо этого позволить вашему редактору кода предупредить вас, если вы используете какие-либо функции, которые слишком сложны для браузеров ваших клиентов. Это самый простой вариант, потому что он:
исключает любую зависимость от транспилиров (transpilers). Возвращает вам практический контроль над рабочим кодом.
если имеется современная функция, без которой вы не можете жить, то ее можно использовать применив полифил (polyfill).
В противном случае, вы можете просто использовать старый синтаксис, когда это необходимо.
Создать тест
Прежде чем мы сможем разобраться в плюсах и минусах, надо убедиться, что наши альтернативы Babel могут выполнять ту же самую основную работу. Давайте сделаем небольшой тест.
Ниже приведен современный код, который должна поддерживать наша целевая среда после переноса (transpiled).
После переноса (transportation) для каждой функции есть console.assert (метод записи сообщений на консоли для пользователя), чтобы убедиться, что она работает, как положено. В случае eslint-plugin-compat вместо этого проверим, что несовместимый код помечен в linting (Linting — это процесс, выполняемый программой linter, которая анализирует исходный код на определенном языке программирования и отмечает потенциальные проблемы, такие как синтаксические ошибки, отклонения от предписанного стиля кодирования или использование конструкций, о которых известно, что они небезопасны).
Использование eslint env свойства с помощью eslint-plugin-compat
Нам нужен обходной путь для объединения функций языка и API браузера.
Полную инструкцию можно найти в eslint-plugin-compat repo. Мы воспользуемся browserlist defaults как предустановками по умолчанию. Замените их по своему выбору, основанному на аналитике.
Что такое browserlist?
Browserlist автоматически выбирает список браузеров, основываясь на различных критериях, которые Вы ему предоставляете.
defaults — использует быстрый доступ к таким версиям браузеров:
> 0,5 процента (версии браузеров, выбранные по глобальной статистике использования)
Последние две версии (каждого «живого (not dead)» браузера)
Firefox ESR (Extended Support Release)
“Живые (not dead)” (браузеры без официальной поддержки и обновлений в течение 24 месяцев).
Перейдите на GitHub, чтобы получить полный список запросов, доступных для выбора поддерживаемых браузеров.
Настройка eslint-plugin-compat для Visual Studio Code
Добавьте следующие пакеты в свой проект.
Было бы неплохо, если бы eslint-plugin-compat автоматически добавил и возможности языка, но на данный момент это является нерешённой задачей.
IE 11 с выбранной настройкой —
— наш API fetch() помечен.
Альтернатива № 3: Используйте другое программное обеспечение для замены Babel
Прежде чем рассматривать альтернативы, давайте быстро рассмотрим, как использовать Babel.
Использование Babel для транспилирования (transpile) и полифилинга (polyfill)
Сначала создайте директорию мини-проекта и установите нужные нам взаимосвязи.
Наконец, запустите файл, чтобы проверить, что тесты все еще работают.
Вот результирующий транспилированный (transpiled) код. Обратите внимание на весь лишний мусор и хлам.
Преимущества и недостатки использования Babel
Эта базовая установка была относительно несложной.
У Babel есть большое сообщество для поддержки и постоянных обновлений с 36.8k GitHub звездами на момент написания статьи.
Медленное время компиляции
Множество зависимостей (dependencies), даже если они являются зависимостями (dev-dependencies). (установлено 269 пакетов)
Использование swc для транспилирования (transpile) и полифилинга (polyfill)
Swc — новый конкурент Babel. Он написан на языке программирования Rust и в 20 раз быстрее. Это может быть очень важно, если вы долго ждете, чтобы построить свой проект.
Чтобы все устроить:
Запустите полученный файл, чтобы проверить, что тесты все еще работают.
В итоге swc-transpiled (транспилированный) файл, выглядит вот так:
Преимущества и недостатки использования swc
Гораздо меньше зависимостей (установлено 43 пакета)
Не все функции Babel в настоящее время поддерживаются
Меньшая пользовательская база и количество постоянных участников
Другие альтернативы: Google Closure Compiler и TypeScript
Я не включил Google Closure Compiler в качестве опции, потому что он, как это ни печально, сложен в использовании. Тем не менее, он может сделать хорошую работу по транспилированию (transpile) и полифилингу (polyfill). Если у вас есть свободное время, я рекомендую вам проверить его — особенно если вы цените небольшой размер файла, так как встроенная функция минификации демонстрирует отличные результаты.
Вы также можете использовать TypeScript для переноса (transpile) и core-js для ручной полифил (polyfill) обработки, но это неуклюжее решение, которое может с легкостью создать больше проблем, чем решить их.
Заключение
Вам не нужно автоматически поддерживать старые браузеры. Важно сначала взглянуть на свои аналитические данные, чтобы увидеть, какие браузеры на самом деле используют ваши клиенты.
При необходимости Вы можете использовать функцию linting, чтобы убедиться в их совместимости друг с другом. Это избавит Вас от лишних хлопот, связанных с созданием специального сборочного процесса и транспиляции (transpilation).
Если вы выберете автоматический перевод, то SWC будет намного быстрее, чем Babel, и будет содержать гораздо меньше зависимостей. Также есть возможность использовать Google Closure Compiler или TypeScript, но для их настройки потребуется немного больше усилий.
LogRocket: Полная видимость ваших веб-приложений
LogRocket — это передовое решение для мониторинга приложений, позволяющее воспроизводить проблемы так, как если бы они возникали в вашем собственном браузере. Вместо того, чтобы гадать, почему происходят ошибки, или спрашивать пользователей на скриншотах и дампах логов, LogRocket позволяет воспроизводить сеанс, чтобы быстро понять, что пошло не так. Он отлично работает с любым приложением, независимо от фреймворка, и имеет плагины для записи дополнительного контекста из Redux, Vuex и @ngrx/store.
В дополнение к регистрации действий и состояния Redux, LogRocket записывает журналы консольных сообщений, ошибки JavaScript, следы стеков, сетевые запросы/ответы в формате заголовок + тело, метаданные браузера и пользовательские журналы. Кроме того при помощи DOM (Document Object Model) позволяет записывать страницы HTML и CSS, воссоздавая превосходные в пиксельном отношении видео даже для самых сложных одностраничных приложений.
Смотреть открытый вебинар «Код как проект — настройка окружения для разработки на JavaScript».