Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Большая просьба ко всем минусующим: обосновывайте своё решение.
Я не минусовал, но написанное не тянет на статью. Есть уже много примеров использования es6 в продакшене. На сайте бейбела есть куча документации, есть в конце концов systemjs, умеющий все это собирать и также с кучей документации. У вас же пост в стиле «ребят смотрите, я в первый раз собрал es6».
А это и не статья, а просто специфический туториал, там около заголовка написано. И так как люди добавляют его в избранное, то польза от него есть, а это самое главное.
Вы предлагаете людям не ставить минус (то есть не считать бесполезным), только исходя из того, что кто-то добавил пост в избранное? Тут нет какой то логики. У любого заминусованного поста есть добавления, и что? Раз те, кто добавили в избранное, не поставили плюс, значит у них для этого нет кармы, то есть их мнение менее ценно, чем мнение тех, кто имеет карму (подразумевается, что он ее заслужил ценным вкладом). В данном случае какие-то опытные люди вас заминусовали. Ну, бывает, не расстраивайтесь.
Я повторяю, что это не тянет на пост (статья, туториал, не важно), т.к. гуглится за 10 секунд.
А это и не статья, а просто специфический туториал.
Я повторяю, что это не тянет на пост (статья, туториал, не важно), т.к. гуглится за 10 секунд.
Я и не расстраиваюсь.
Нагуглите мне подобный туториал за 10 секунд.
Жду ссылку.
Нагуглите мне подобный туториал за 10 секунд.
Жду ссылку.
advantcomp.com/blog/ES6Modules — ~15 секунд на поиск и пролистывание.
Использую с SailsJS. А на пост действительно не тянет, скорее введение, до P.S. думал что вот сейчас будет интересно. На 2ality много интересного по ES6 есть, включая Babel. А буржуйский нужно знать разработчику.
> P.S. А какой способ используете Вы?
А мы ставим nodejs версии >= 0.12 и просто используем ES6.
А мы ставим nodejs версии >= 0.12 и просто используем ES6.
Это вы наверное про back-end говорите? Я забыл добавить, что имел ввиду front-end.
А, теперь ясно.
К слову, в браузерах, насколько я вижу, более-менее большая часть фич тоже поддерживается уже.
К слову, в браузерах, насколько я вижу, более-менее большая часть фич тоже поддерживается уже.
В nodejs версии 0.12 ES6 поддерживается на 23%. Тогда как babel дает аж 76.
Ну я в курсе, но фичи, которые мне нужны, вполне уже есть. И остальное будет достаточно скоро.
Стойте, а вы уверены, что та табличка не устарела? Там пишут, что 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
Хорошим аргументом в пользу 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 как чуть времени свободного будет.
Это я уже заметил :)
Спасибо, попробую io.js как чуть времени свободного будет.
А мы используем grunt-*. Потому что кроме скриптов надо еще тесты прогонять, jade/stylus компилять…
Webpack.
Простейший пример работы с es6-модулями (экспорт/импорт) под front-end со сборкой на webpack + babel-loader:
github.com/rauschma/webpack-es6-demo
Простейший пример работы с es6-модулями (экспорт/импорт) под front-end со сборкой на webpack + babel-loader:
github.com/rauschma/webpack-es6-demo
А у нас совсем другой подход. Используются в системе `file accessor middlewares`: У статического сервера (если разрабатывается лишь front-end вэб приложение) или у обычного бэкэнда (разрабатываем на nodejs) есть плагины (или прослойки на чтение файлов). Например все `*.es6` на лету компилируются в ecmascript 5. За файловым расширением может быть зарегистрировано несколько прослоек: трансформировать все `if conditional comments`, a потом трансформировать в ecmascript 5.
Плюсы:
— Трансформации принимаются по шаблону имени файла, например только с расширением `es6`
— Приложение и система сборки не зависит от содержимого самого файла,
— «Совместное существование и легкий переход». Мы просто переименовываем `*.js` в `*.es6` и всё работает как обычно, учитывая что ес6 обратно совместим, но мы можем и переименовать в `*.coffee` и подправить содержимое.
— Система кеширование файлов и file watchers позволяют только один раз трансформировать файл, а при изменение просто файл «перечитать».
— Такой же подход используется одинаково для
Пример `babel` плагина: Loader.Babel
Плюсы:
— Трансформации принимаются по шаблону имени файла, например только с расширением `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 scripts, скрипты, описанные в них, ищут исполняемые файлы локально в проекте. И наверняка приятнее написать
npm startwatchify src/main.js -t babelify -o build/main.jsя делаю так. Для инкремент билдов просто прогоняю все через babel с транспайлом системы модулей в формат system.js и использую полифил. Для продакшена же я обычно использую es6-module-transpiler с форматтером bundle, что бы не париться со всякими богомерзскими browserify которые там нафиг не сдались. Оно берет все модули, заворачивает все в замыкания и формирует бандл без всяких зависимостей и футпринтов от использования сборщиков аля r.js или browserify. Ну и да, все через gulp.
Но в целом да, все это есть в документации к тому же babel, кроме момента с bundle.
Но в целом да, все это есть в документации к тому же babel, кроме момента с bundle.
Может быть подробнее опишите?
При таком подхоже есть возможность разбивать на несколько бандлов (или более двух)? То есть собственные модули апликухи в отдельный бандл, языковые ресурсы отдельно, и библиотечные отдельно (с browserify это делается с помощью опции/метода external).
Чем browserify богомерзский кроме небольшого избыточного кода обертки модуля?
При таком подхоже есть возможность разбивать на несколько бандлов (или более двух)? То есть собственные модули апликухи в отдельный бандл, языковые ресурсы отдельно, и библиотечные отдельно (с browserify это делается с помощью опции/метода external).
Чем browserify богомерзский кроме небольшого избыточного кода обертки модуля?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Простой пример использования ES6 уже сегодня