Комментарии 15
НЛО прилетело и опубликовало эту надпись здесь
Да, постараюсь. Как только обновлю проект на новую версию с рекомендациями (оно пока убрано в дев-ветку по ряду причин), сразу же опубликую.
Только это не nodejs приложение, все на клиентсайде :) В Web Workers. Пересчет сети на ~600 тренировочных данных и выдача около 100 значений занимает около 0.15 секунды, что вызывает просадку по перформансу. С воркерами — все нормально работает.
На всякий случай: я использовал готовую библиотеку, но там были достаточно интересные ньюансы, связанные именно с обучением.
Постараюсь в течении недели это все сделать.
Только это не nodejs приложение, все на клиентсайде :) В Web Workers. Пересчет сети на ~600 тренировочных данных и выдача около 100 значений занимает около 0.15 секунды, что вызывает просадку по перформансу. С воркерами — все нормально работает.
На всякий случай: я использовал готовую библиотеку, но там были достаточно интересные ньюансы, связанные именно с обучением.
Постараюсь в течении недели это все сделать.
дежавю
Обработку ошибок без подвисания стрима можно сделать через gulp-plumber. Его офигенный плюс, что он работает на уровне pipe, следовательно нет необходимости в каждом плагине делать .on
Насчет замены sass на stylus ради ускорения компиляции — gulp-sass использует для компиляции node-реализацию процессора, libsass. Отрабатывает практически моментально даже на здоровенных файлах.
К нему можно добавить compass с помощью bower-пакета compass-mixins, специально созданного для замены ruby-compass в libsass.
Жаль, что не была затронута тема инкрементальных билдов.
gulp.src('*.js')
.pipe(gulp_plumber())
.pipe(something_what_can_throw_error())
.pipe(gulp.dest('build'));
Насчет замены sass на stylus ради ускорения компиляции — gulp-sass использует для компиляции node-реализацию процессора, libsass. Отрабатывает практически моментально даже на здоровенных файлах.
К нему можно добавить compass с помощью bower-пакета compass-mixins, специально созданного для замены ruby-compass в libsass.
Жаль, что не была затронута тема инкрементальных билдов.
Про plumber — спасибо, гляну, я в свое время видел его, но понял, что он просто решает какую-то специфическую проблему под windows, поэтому его все пихают «на всякий случай».
libsass быстрый, но поддерживает, что пародоксально, не sass, но только scss-синтаксис (во всяком случае, так было полгода назад, насколько я помню). А у нас в той команде почему-то так завелось, что форматирование не отступами доставляло всегда кучу проблем при мердже — потому и был переход с хтмл на jade, та же самая ерунда была. Форматирование отступами позволило сливать ветки гита с куда меньшей кучей геммороя.
Про инкрементальные билды — в моем случае все решалось установкой кэша для browserify в последнее время — у меня в том числе стили подключаются через JS по ряду причин.
libsass быстрый, но поддерживает, что пародоксально, не sass, но только scss-синтаксис (во всяком случае, так было полгода назад, насколько я помню). А у нас в той команде почему-то так завелось, что форматирование не отступами доставляло всегда кучу проблем при мердже — потому и был переход с хтмл на jade, та же самая ерунда была. Форматирование отступами позволило сливать ветки гита с куда меньшей кучей геммороя.
Про инкрементальные билды — в моем случае все решалось установкой кэша для browserify в последнее время — у меня в том числе стили подключаются через JS по ряду причин.
Используете ли gulp-watch? С ним часто происходят ошибки при создании/удалении каталогов, и gulp-plumber не подавляет их. Нет ли решения такой проблемы?
github.com/gulpjs/gulp/issues/660 github.com/floatdrop/gulp-watch/issues/83
github.com/gulpjs/gulp/issues/660 github.com/floatdrop/gulp-watch/issues/83
Да, gulp-watch использую очень активно, но ни разу не встречался с вышеупомянутыми ошибками. Посмотрел issues — может быть это потому, что у меня OS X.
Уже решено: github.com/floatdrop/gulp-batch
НЛО прилетело и опубликовало эту надпись здесь
эм, жесть кое-где
я хоть и использую сейчас grunt, но почему, почему не использовать хотя бы gulp-changed?
инкрементальный pipeline гораздо эффективнее. и не приходится отказываться от нормального Coffee или Type.
Перевести весь coffeescript на JS для ускорения компиляции — благо, это были в основном старые виджеты;
я хоть и использую сейчас grunt, но почему, почему не использовать хотя бы gulp-changed?
инкрементальный pipeline гораздо эффективнее. и не приходится отказываться от нормального Coffee или Type.
Там действительно был старый код, который уже не модифицировался — разные либы и так далее :) С инкрементальным билдом были определенные проблемы из-за особенностей сборки, там довольно были специфичные детали типа shared-кода и кода, генерируемого и хранящегося на сервере в памяти, сейчас я вижу это решаемым, тогда — это вызывало неллюзорные проблемы. И если правильно помню, один замороченный не очень популярный плагин тек, так что сборку приходилось перезапускать регулярно.
Плюс — как выше заметили уже, тогда в gulp-watch была проблема с удалением (или переименованием) новых папок, из-за этого оно стабильно вылетало. Компонетный подход с кучей папок был, которые периодически переименовывались.
В любом случае, собрать старые либы, которые уже не изменялись, в том числе для первоначальной «раскрутки» сборщика — лишним не было.
Плюс — как выше заметили уже, тогда в gulp-watch была проблема с удалением (или переименованием) новых папок, из-за этого оно стабильно вылетало. Компонетный подход с кучей папок был, которые периодически переименовывались.
В любом случае, собрать старые либы, которые уже не изменялись, в том числе для первоначальной «раскрутки» сборщика — лишним не было.
Потому что нельзя было просто взять и настроить в browserify сборку Stylus-стилей, которые бы еще и высасывали base64-картинки, и проходили бы через автопрефиксер и минификацию.
Ах, вы ещё не слышали про webpack?
Хм. Посмотрел — да, действительно, есть какой-то аналог пайплайна.
Из явных минусов — отсутствие подсветки путей в IDE (я в webStorm обычно набираю имя файла, жамкаю cmd-enter и там есть пункт «создать файл по заданному пути и сразу открыть его»).
Очень вряд ли — возможность создавать свой синтаксис для инклуда одних типов файлов в другие. У меня лично последние два проекта — модули для хрома, там очень много компонентов, всунутых через shadow DOM, там нужно объявлять стили внутри шаблона, соответственно их нужно как-то подключать. Вариант, когда какой-то символ просто превращается в ..." + require($1) + "… — куда удобнее.
Сомневаюсь (просто не понял, честно говоря), как там подсасывать base64, так что 50/50%, может и есть оно.
В любом случае, это выбор каждого, но я пока что продолжу доверять gulp и browserify, которые мейнтейнятся двумя жирными такими сообществами, чем вебпаку, у которого автор явно пишет «чуваки, я это делаю в свободное время». Может, когда-нибудь потом, тем более что мои задачи вполне решаемы именно так.
Из явных минусов — отсутствие подсветки путей в IDE (я в webStorm обычно набираю имя файла, жамкаю cmd-enter и там есть пункт «создать файл по заданному пути и сразу открыть его»).
Очень вряд ли — возможность создавать свой синтаксис для инклуда одних типов файлов в другие. У меня лично последние два проекта — модули для хрома, там очень много компонентов, всунутых через shadow DOM, там нужно объявлять стили внутри шаблона, соответственно их нужно как-то подключать. Вариант, когда какой-то символ просто превращается в ..." + require($1) + "… — куда удобнее.
Сомневаюсь (просто не понял, честно говоря), как там подсасывать base64, так что 50/50%, может и есть оно.
В любом случае, это выбор каждого, но я пока что продолжу доверять gulp и browserify, которые мейнтейнятся двумя жирными такими сообществами, чем вебпаку, у которого автор явно пишет «чуваки, я это делаю в свободное время». Может, когда-нибудь потом, тем более что мои задачи вполне решаемы именно так.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Продвинутый Gulp и Browserify: интересные трюки