Краткая история инструментария ES6
Перевод статьи A Brief History of ES6 Tooling с сайта ponyfoo.com, опубликовано на css-live.ru с разрешения автора — Николаса Беваквы.
За последние дни я написал несколько статей про React и ES6, и сегодня хочу немного пояснить, чего это меня вдруг словно заклинило на ES6. Я уже давно интересуюсь ES6, но раньше мы были не готовы писать на нём код. В этой статье я хочу кратко затронуть историю инструментария ES6, и считаю, что сегодня гораздо лучшее время для внедрения ES6, чем полгода назад.
Главным образом за это надо благодарить Browserify, Babel и то, что спецификация наконец дописана. Но эти инструменты не сразу достигли сегодняшнего уровня.
Прежде чем транспилерам JavaScript в JavaScript стать «серьёзными» инструментами, были модули, которые добавляли конкретные кусочки функциональности ES6 в приложения. Были такие вещи, как gnode, который позволяет использовать генераторы в node, интерпретируя ваш код во время процесса выполнения (или включая флаг Harmony для генераторов в node >= 0.11.x)
Простой вопрос: сколько разных названий накопилось у ES6 за все годы?
Затем мы увидели библиотеки, которые реализовали загрузку модулей ES6, напр. es6-module-loader. Эти библиотеки способствовали продвижению спецификации, давая на растерзание разработчикам хоть что-то, пока появлялись реализации. Конечно, уже тогда была возможность использовать CoffeeScript или TypeScript, в которых были реализованы такие же возможности языка, как в ES6.
Мне не нравился синтаксис CoffeeScript и то, что с ним меньше возможностей участвовать в опенсорсных проектах, поэтому он мне не подошёл. TypeScript может и ничего, но в нём много лишнего сверх новинок ES6, а я по возможности стараюсь изучать то, что пригодится мне надолго. И надо признать, что долгое время они были практически единственной возможностью попробовать в деле язык со всеми теми же фичами, что у ES6.
В итоге транспилеры вышли в свет. Первым был Traceur, и он вышел в то время, когда спецификация ещё не устоялась. Спецификация в ту пору то и дело менялась, поэтому использовать ее можно было разве что для того, чтобы наскоро поиграть с новым синтаксисом. Я моментально разочаровался, когда писал пример кода для своей книги по проектированию приложений. Примерно в то же время начал набирать обороты 6to5, и был ещё esnext, но esnext никогда не реализовывал модули ES6. В начале этого года эти проекты объединились в известный нам сегодня Babel.
Наступил июнь, и спецификация была завершена.
То, что особенности языка наконец устоялись, было критически важно для его внедрения. Это означало, что компиляторы могли теперь наконец-то реализовать что-то и не оказаться с устаревшим синтаксисом всего через месяц. Поскольку спецификация уже готова, а Babel — фактически основной инструмент сборки JavaScript из исходников, я снова обратил внимание на ES6 и решил снова взяться за эксперименты с этими увлекательными штуковинами
Теперь мы можем сочетать Browserify и Babel с помощью babelify. В процессе разработки можно применять babel-node на сервере — и компилировать в ES5 перед выпуском из соображений производительности. Если увлекаться CSS -модулями, можно использовать Webpack, и есть ряд возможностей ES6, готовых к использованию. Но надо быть осторожным и не переусердствовать. Когда столько всего происходит, нелегко бывает поспевать за технологиями и в то же время поддерживать качественный код, не пихая в него все подряд новые модные штучки просто чтоб было.
К сожалению, в инструментарии фронтенда достаточно возможностей для ползучего загромождения фичами, но с этим нам сейчас нужно бороться.
Завтра я опубликую статью о тех перспективах, ожидающих наш любимый JavaScript, от предвкушения которых мое сердце сильнее всего замирает, и о моих опасениях насчет бездумного внедрения фич ES6.
P.S. Это тоже может быть интересно: