Comments 42
Большая просьба ко всем минусующим: обосновывайте своё решение.
Я не минусовал, но написанное не тянет на статью. Есть уже много примеров использования es6 в продакшене. На сайте бейбела есть куча документации, есть в конце концов systemjs, умеющий все это собирать и также с кучей документации. У вас же пост в стиле «ребят смотрите, я в первый раз собрал es6».
А это и не статья, а просто специфический туториал, там около заголовка написано. И так как люди добавляют его в избранное, то польза от него есть, а это самое главное.
Вы предлагаете людям не ставить минус (то есть не считать бесполезным), только исходя из того, что кто-то добавил пост в избранное? Тут нет какой то логики. У любого заминусованного поста есть добавления, и что? Раз те, кто добавили в избранное, не поставили плюс, значит у них для этого нет кармы, то есть их мнение менее ценно, чем мнение тех, кто имеет карму (подразумевается, что он ее заслужил ценным вкладом). В данном случае какие-то опытные люди вас заминусовали. Ну, бывает, не расстраивайтесь.

А это и не статья, а просто специфический туториал.

Я повторяю, что это не тянет на пост (статья, туториал, не важно), т.к. гуглится за 10 секунд.
Я и не расстраиваюсь.
Нагуглите мне подобный туториал за 10 секунд.
Жду ссылку.
Значит не гуглится за 10 секунд и тем более в нём используют task-manager, а я показываю пример использования CLI. Да и вообще там на буржуйском написано.
а я показываю пример использования CLI

И зачем? А потом через CLI еще прикручивать sass/less/postcss+autoprefixer. Лучше сразу через таск менеджеры.
В конечном итоге всё зависит от необходимости прикручивания тех или иных присосок.
Использую с SailsJS. А на пост действительно не тянет, скорее введение, до P.S. думал что вот сейчас будет интересно. На 2ality много интересного по ES6 есть, включая Babel. А буржуйский нужно знать разработчику.
> P.S. А какой способ используете Вы?

А мы ставим nodejs версии >= 0.12 и просто используем ES6.
Это вы наверное про back-end говорите? Я забыл добавить, что имел ввиду front-end.
А, теперь ясно.
К слову, в браузерах, насколько я вижу, более-менее большая часть фич тоже поддерживается уже.
Если честно вот такие фразу меня, как разработчика и как юзера жутко раздражает:
Мобильные браузеры (планшеты, коих уже в купе с «глупо»фонами поболее десктопов будет) вообще в рассчёт не берёте?)
А что не так с мобильными браузерами (я немного не в теме разработки под мобильные браузеры)?
В андроиде есть chrome/FF, которые вроде бы обновляются регулярно, а в iOS есть еще Сафари.
Множество людей сидит на устаревших версиях ОС, для которых новые версии браузеров просто не выходят.
Ну я в курсе, но фичи, которые мне нужны, вполне уже есть. И остальное будет достаточно скоро.
Стойте, а вы уверены, что та табличка не устарела? Там пишут, что nodejs не поддерживает, например, генераторы.
Генераторы спрятаны под флагом --harmony. В свою очередь, io.js (https://iojs.org/) поддерживает их нативно.
Краем уха читал про io.js, но не вглядывался особо. Вы им пользуетесь? Как оно?
Если честно, сразу перешел на него из-за как раз ES6 «из коробки». Темп развития и вклад сообщества колоссальные, что не может не радовать. Некоторые считают, что так не должно быть, если это используется в enterprise, но тут мнения очень сильно расходятся.

Хорошим аргументом в пользу io.js для меня было решение команды node-webkit перейти на io.js.

Лично мне нынче по душе io.js. Все проекты в данный момент работают на версиях >=1.7.0.

Попробуйте, ES6 очень сильно ускоряет и упрощает разработку. :)

Сейчас, кстати, активно идет обсуждение обратного объединения Node.js и io.js, но с учетом нынешней политики разработки последнего, дабы изменить принцип разработки и релизов Node.js. Подробнее можете почитать здесь – github.com/jasnell/dev-policy/blob/master/convergence.md
> Попробуйте, ES6 очень сильно ускоряет и упрощает разработку. :)

Это я уже заметил :)
Спасибо, попробую io.js как чуть времени свободного будет.
to dannyzubarev: Я не использовал node-webkit и поэтому вопрос: зачем оно надо, если есть CEF?
Что есть CEF? Гугление дает странные результаты, вроде «Child Evangelism Fellowship».
Может я не правильно понимаю, но какое отношение имеет node-webkit к server-side, если это вроде как тулза для десктопных приложений?
Ну мы же в этой ветке вроде про node/io в контексте server-side говорили?
А так — «NW.js is an app runtime based on Chromium and node.js»
А мы используем grunt-*. Потому что кроме скриптов надо еще тесты прогонять, jade/stylus компилять…
А у нас совсем другой подход. Используются в системе `file accessor middlewares`: У статического сервера (если разрабатывается лишь front-end вэб приложение) или у обычного бэкэнда (разрабатываем на nodejs) есть плагины (или прослойки на чтение файлов). Например все `*.es6` на лету компилируются в ecmascript 5. За файловым расширением может быть зарегистрировано несколько прослоек: трансформировать все `if conditional comments`, a потом трансформировать в ecmascript 5.
Плюсы:
— Трансформации принимаются по шаблону имени файла, например только с расширением `es6`
— Приложение и система сборки не зависит от содержимого самого файла,
— «Совместное существование и легкий переход». Мы просто переименовываем `*.js` в `*.es6` и всё работает как обычно, учитывая что ес6 обратно совместим, но мы можем и переименовать в `*.coffee` и подправить содержимое.
— Система кеширование файлов и file watchers позволяют только один раз трансформировать файл, а при изменение просто файл «перечитать».
— Такой же подход используется одинаково для *.less, *.yml файлов — достаточно лишь установить плагин.

Пример `babel` плагина: Loader.Babel
Зря вы глобально всё ставите. А что, если у вас будет два проекта, один на babel@x.x.x, а другой на babel@y.y.y? Все пакеты необходимо устанавливать локально, в папку проекта, и уже оттуда запускать. Для многих пакетов есть специальные CLI (command line interface) пакеты, которые уже можно ставить глобально, и они будут работать интерфейсом к локально установленным пакетам.
Но ещё лучше использовать NPM scripts, скрипты, описанные в них, ищут исполняемые файлы локально в проекте. И наверняка приятнее написать
npm start
чем
watchify src/main.js -t babelify -o build/main.js
Может быть с NPM scripts и лучше — это уже на усмотрение каждого. Я в статье не об удобствах пишу.
я делаю так. Для инкремент билдов просто прогоняю все через babel с транспайлом системы модулей в формат system.js и использую полифил. Для продакшена же я обычно использую es6-module-transpiler с форматтером bundle, что бы не париться со всякими богомерзскими browserify которые там нафиг не сдались. Оно берет все модули, заворачивает все в замыкания и формирует бандл без всяких зависимостей и футпринтов от использования сборщиков аля r.js или browserify. Ну и да, все через gulp.

Но в целом да, все это есть в документации к тому же babel, кроме момента с bundle.
Может быть подробнее опишите?

При таком подхоже есть возможность разбивать на несколько бандлов (или более двух)? То есть собственные модули апликухи в отдельный бандл, языковые ресурсы отдельно, и библиотечные отдельно (с browserify это делается с помощью опции/метода external).

Чем browserify богомерзский кроме небольшого избыточного кода обертки модуля?
Ну в свете нативных ES6-модулей browserify действительно не так уж хорош.
Нативные модули это хорошо конечно, но можно ли там реализовать описанную выше схему (деление на бандлы). Предполагаю что такой опции нет из коробки, те все равно нужен будет некий обработчик/препроцессор.
Если честно у меня просто небыло такой необходимости, вечерком посмотрю отпишусь.
Only those users with full accounts are able to leave comments. Log in, please.