LINUX.ORG.RU

ES6, Babel, загрузчик модулей. Как вы используете?

 , es5, ,


1

1

Привет.

В связи с выходом ES6 решил немного прокачать свои скилы.

Допустим я использовал RequireJS (для ленивой подгрузки модулей), AngularJS (основной фреймворк, биндинги) и Gulp (или Grunt, для сборки основных модулей с использованием r.js optimizer).

Захотел попробовать фичи ES6, но пока ES6 не готово нужно использовать Babel. Так же хочу попробовать ReactJS (не замена AngularJS конечно, но для одной странички мне достаточно). Через gulp-babel я без проблем могу собрать свой ES6 JS в ES5, но что делать с загрузчиком модулей? У babel есть опции для компиляции с использованием Common.js, AMD и прочих модулей, но я так понял нужен еще загрузчик, который я никак не могу найти и подключить. Куча каких-то вариантов, от которых разбегаются глаза. Хотелось бы AMD модули и что-нибудь максимально похожее на RequireJS. Конечно мне никто не запрещает продолжать использовать RequireJS, но раз уж в стандарте есть загрузчик, то хочется им пользоваться (понятно что через polyfill). А еще Babel поддерживает ReactJS и это тоже хочется учесть.

В общем что хочу:
1. Собирать Gulp'ом ES6 код в ES5. Конвертирование в браузере «на лету» не нужно.
2. Использовать define, require (ну или import, export, уже хоть что-нибудь). Причем собирать все в один файл мне не нужно. Хочу lazy load, а в один файл собирать только основные модули (как это делает r.js optimizer). Browserify мне тоже не нравится. Хочу ставить модули через bower, а не npm.
3. Подключать «legacy» модули (ES5), типа jQuery.
4. Прикрутить ко всему этому поддержку JSX (ReactJS).

Может я наговорил ерунды и так делать не нужно. Поделитесь опытом как вы готовите ES6?

Как, как, втыкаю в страничку файлики и всё. В особо запущеных случаях помогает pagespeed.

ya-betmen ★★★★★
()

ReactJS (не замена AngularJS конечно, но для одной странички мне достаточно)

Посмотри ещё riotjs. Умеет в babel тоже, если что.

Собирать Gulp'ом ES6 код в ES5. Конвертирование в браузере «на лету» не нужно.

gulp-babel же.

Использовать define, require (ну или import, export, уже хоть что-нибудь).

Babel умеет (режим по дефолту) выплёвывать commonjs модули (т.е. твои import'ы транслируются в require(..)), а чем грузить ты будешь это второй вопрос. Лучше таки собирать чем-то вроде browserify, duo.js или webpack, чтобы не тянуть всякие requirejs. Ну и, конечно, все умеют sourcemap'ы, так что проблем не будет.

Подключать «legacy» модули (ES5), типа jQuery.

Имхо, бери browserify (умеет babel с babelify или, если таки используешь gulp, достаточно по-отдельности). Во-первых, для таких модулей там уже есть обёртки (из npm тянутся), а во-вторых, для непопулярных легаси можно прописать экспорты и импорты и он сам их обернёт. Requirejs, кстати, тоже умеет это, через r.js утилитку.

Прикрутить ко всему этому поддержку JSX (ReactJS).

Babel умеет в JSX. Алсо, для многих редакторов (atom, sublime etc) есть подсветки синтаксиса для babel (es6 + jsx). Ещё советую глянуть на loose мод.

loyd
()
Ответ на: комментарий от loyd

Посмотри ещё riotjs. Умеет в babel тоже, если что.

Мне бы пока этим разобраться :) Если что посмотрю.

browserify

Не нравится идея смешивания модулей фронтенда и бэкенда.

webpack

Вроде то что нужно, надо посмотреть как оно работает.

duo.js

Сейчас использую Bower, не хотелось бы менять.

чтобы не тянуть всякие requirejs

Сейчас с RequireJS сделал: компилю весь ES6 в ES5 с такой же структурой файлов, а дальше уже RequireJS подключает модули и исполняет. А чем плохо тянуть RequireJS и почему лучше browserify?

Babel умеет в JSX. Алсо, для многих редакторов (atom, sublime etc) есть подсветки синтаксиса для babel (es6 + jsx).

Да, я знаю что поддерживает. Модули к Atom тоже прикрутил.

Ещё советую глянуть на loose мод.

Интересно, спасибо.

Black_Roland ★★★★
() автор топика

use webpack

поддержка babel, react, всех видов модулей(require, import и т.д.)

есть gulp плагин

Stribog
()
Ответ на: комментарий от Black_Roland

Не нравится идея смешивания модулей фронтенда и бэкенда.

npm перестал позиционироваться как хранилище для node/io модулей. Теперь это просто js-хранилище, всключая всякие bower (это официальная позиция разрабов). Следовательно, browserify тоже общий сборщик. В добавок, стандартные нодовские модули (stream, buffer, events и прочие) имеют довольно неплохие шимы для браузера. Вот такие дела.

компилю весь ES6 в ES5 с такой же структурой файлов

Реальная структура уже не важна, ибо sourcemap'ы (и внешние и инлайновые) отлично это описывают. Проще собирать в один .js файл: быстрее (всего один файл), меньше запросов нужно, лучше жмётся, можно вообще его в .html включить.

А чем плохо тянуть RequireJS и почему лучше browserify?

Mеньше запросов (нужно стягивать только bundle.js). Нет лишних рантайм зависимостей => кода меньше, меньше размер. Ну и commonjs стиль однозначно лучше, чем amd/umd/lmd. requirejs тоже можно упаковать (см r.js), но тогда это тот же browserify, только урезанный.

loyd
()
Ответ на: комментарий от loyd

npm перестал позиционироваться как хранилище для node/io модулей

Ну не знаю, все равно что-то смущает.

Проще собирать в один .js файл: быстрее (всего один файл), меньше запросов нужно, лучше жмётся, можно вообще его в .html включить.

Если приложение большое, то будет лишний код, который может никогда и не будет использоваться, но будет висеть в памяти и отнимать время на парсинг. А так же один файл может получится мегабайта на 2 и такой монолит вряд ли будет быстро загружаться даже с учетом gzip.

requirejs тоже можно упаковать (см r.js), но тогда это тот же browserify, только урезанный.

Обычно так и использую. Упаковывает только то, что требуется на каждый запрос. Остальное подтягивается только если оно действительно требуется на странице.

Black_Roland ★★★★
() автор топика

Вот такой вот говнокод получился: https://github.com/black-roland/pi-control RequireJS все таки оставил.

Еще надо попробовать WebPack и Riot. Забавно, раньше всегда по рукам били за вставку <script></script> где попало во вьюхах, теперь в Riot это основной подход :) Размер либы по сравнению с React радует конечно.

В общем спасибо всем за ответы, в целом разобрался с волнующими вопросами.

Black_Roland ★★★★
() автор топика
Ответ на: комментарий от Black_Roland

Если приложение большое, то будет лишний код ...

Слишком спицифично. Если бы приложение было действительно большим, причём речь идёт об обфусцированном и сжатом коде, то и вопрос бы тут никто не задавал.

Остальное подтягивается только если оно действительно требуется на странице.

И что, много экономишь?)

И да, всяких ненужных монстров вида jquery можно стягивать из cdn.

loyd
()
Ответ на: комментарий от loyd

И что, много экономишь?)

Например сканер штрихкодов - либа на 120 КБ. Какой-нибудь jQuery плагин, а может и не один. А если с телефона? Парсинг, оперативка - пару таких сайтов открыл и девайс завис.

И да, всяких ненужных монстров вида jquery можно стягивать из cdn.

От них мало толку. Если нет в кэше, то получится дольше (распаралеливание немного поможет, но не существено). Используются разные версии одной и той же либы, разные CDN, в итоге шансы найти либу в кэше очень не велики.

Black_Roland ★★★★
() автор топика
Ответ на: комментарий от Black_Roland

Вот такой вот говнокод получился:

Во-первых, Reactjs таки умеет в ES6 классы, незачем использовать это убожество createClass().

Во-вторых, можно было бы и бекенд на es6 перетащить. В-третьих, зачем сетка из purecss, если в бутстрапе она умеет то же?

Ну и вообще, для просмотрщика состояния малины слишком мудрёно: jq ради простого ajax'а, Reactjs ради пары небольших виджетов, lodash ради map() и get()...

P.S. Если добавишь мониторинг cpu/mem и выхлоп vcgencmd, будет здорово.

loyd
()
Ответ на: комментарий от loyd

Во-первых, Reactjs таки умеет в ES6 классы, незачем использовать это убожество createClass().

не знал, спасибо.

Во-вторых, можно было бы и бекенд на es6 перетащить.

лениво. уже был некоторый код написан, который пришлось бы переписывать, да и babel-node надо ставить.

В-третьих, зачем сетка из purecss, если в бутстрапе она умеет то же?

Она убогая. В Pure inline-block процентная сетка на 24 колонки, а в Bootstrap сетка с float, всего на 12 колонок и кажется пиксельная. Бутстрап там не целиком подключен, основной все равно Pure.

Ну и вообще, для просмотрщика состояния малины слишком мудрёно: jq ради простого ajax'а, Reactjs ради пары небольших виджетов, lodash ради map() и get()

да это понятно :-) я изучениние ноды начал с написания мониторинга для малины. вот уже третий раз переписываю. просто учебный проект. при наличии установленного Monit я уже вообще не вижу смысла от этой софтины. использую только чтобы Transmission включать/выключать :-)

P.S. Если добавишь мониторинг cpu/mem и выхлоп vcgencmd, будет здорово.

Раньше cpu/mem было (в самой первоий версии). Потом выкинул за ненадобностью.

Black_Roland ★★★★
() автор топика

Ну так этот бэйбел не может весь код в один файл собрать? Если нет, то просто сконкатенируй и проминифицируй. Подключать как-либо по особому жквери и прочие «legacy» модули не нужно.

React

Это не фреймворк, либа решает вполне конкретную прикладную задачу. :)

Хочу lazy load, а в один файл собирать только основные модули (как это делает r.js optimizer). Browserify мне тоже не нравится. Хочу ставить модули через bower, а не npm.

Смысла в этом мало. То что ты думаешь микрооптимизация на деле может обернутся дополнительным головняком, гемором и оверхедом. Мобиле 120кб исходников как два пальца, поверь. А вот взять блок, раскрасить градиентом и дёргать по странице будет тяжелее.

riot.js

Говно.

tensai_cirno ★★★★★
()
Ответ на: комментарий от tensai_cirno

Ну так этот бэйбел не может весь код в один файл собрать? Если нет, то просто сконкатенируй и проминифицируй. Подключать как-либо по особому жквери и прочие «legacy» модули не нужно.

Это не задача Babel. Concat может. Про legacy уже тоже понял, что Babel ES5 код оставляет как есть.

Это не фреймворк, либа решает вполне конкретную прикладную задачу. :)

Я знаю. Мне для того чтобы поиграться вполне достаточно. Просто захотелось попробовать React. Да и вообще я бы React везде на мелких сайтах пихал, чтобы не возится с управлением DOM на jQuery или чтобы не тянуть тормозной Knockout. Только вот размер либы React'а в 100КБ удручает. По сути это просто шаблонизатор, а весит как полноценный фреймворк.

Смысла в этом мало. То что ты думаешь микрооптимизация на деле может обернутся дополнительным головняком, гемором и оверхедом. Мобиле 120кб исходников как два пальца, поверь. А вот взять блок, раскрасить градиентом и дёргать по странице будет тяжелее.

Первый попавшийся бенчмарк говорит что парсинг jQuery (90КБ) может занимать до 725мс. http://timkadlec.com/2014/09/js-parse-and-execution-time/ Ну и смотря какое приложение, может быть не 120КБ а пару мегабайт.

Говно.

Че так? :) Вроде как в HTML5 грядут вэб-компоненты. Так вот это тоже самое.

Black_Roland ★★★★
() автор топика
Последнее исправление: Black_Roland (всего исправлений: 2)
21 мая 2016 г.
Ответ на: комментарий от Black_Roland

Webpack с uglify, отдельным сорсмапом и aggresivemerging жмет 2 метровый бандл с реактом, underscore и десяткой компонент в 200 килобайт
А с гзипом 100кб

mystery ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.