Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 31
Гембеля много с настройкой. Появляются лишние файлы в файловой системе. Но в grunt есть например возможность автоматом запускать тесты.
Сори за одессизм. «Гембель» это тоже самое, что и «геморрой» в переносном смысле.
Простите, с чем конкретно связан гемор?
Один раз настроил, и потом наслаждаешься результатом.
Банальная связка sass + coffee + uglify + filerev + copy + watch дает вам возможность иметь статику с версионностью, и минимизацией.
Один раз настроил, и потом наслаждаешься результатом.
Банальная связка sass + coffee + uglify + filerev + copy + watch дает вам возможность иметь статику с версионностью, и минимизацией.
А если не хочется лишних файлов, то, возможно, вам стоит посмотреть на Gulp.
Или, как еще одна альтернатива — заюзать grunt-contrib-clean, и вручную прописать пути к runtime/tmp директориям, которые надо чистить «до» и «после» сборки.
Лишний гембель — у меня все это идет из коробки.
Ну нет же… Это фрагментация сборки. А что если у вас появится необходимость генерировать спрайты и подставлять их в CSS? А если возникнет задача делать сборку CommonJS? AMD? Как ни крути, эко-система Gulp/Grunt покрывает 100% задач сборки, а ваш вариант, увы, нет. Плюс поддержка и расширение вашего инструмента — то еще приключение для пользователей.
Я понимаю ваше желание найти собственное решение, и это здорово, но попробуйте критически посмотреть на Gulp/Grunt — их использование обойдется гораздо дешевле в долгосрочной перспективе именно благодаря комьюнити, эко-системе, и сотням готовых конфигов.
Я понимаю ваше желание найти собственное решение, и это здорово, но попробуйте критически посмотреть на Gulp/Grunt — их использование обойдется гораздо дешевле в долгосрочной перспективе именно благодаря комьюнити, эко-системе, и сотням готовых конфигов.
Спасибо за ваш труд, полезная штука.
У нас мы изобрели внутренний велосипед, который формирует список подключаемых файлов автоматически, добавляя все файлы из целевой папки. То есть, чтобы добавить, переименовать или удалить файл, достаточно сделать это физически и сбилдить проект.
Я думаю, в вашем случае тоже было бы здорово иметь возможность просто указать папку, чтобы все файлы из неё подключались автоматически.
У нас мы изобрели внутренний велосипед, который формирует список подключаемых файлов автоматически, добавляя все файлы из целевой папки. То есть, чтобы добавить, переименовать или удалить файл, достаточно сделать это физически и сбилдить проект.
Я думаю, в вашем случае тоже было бы здорово иметь возможность просто указать папку, чтобы все файлы из неё подключались автоматически.
А есть ли возможность автосборки при изменении файлов, входящих в проект?
Из script и link урлы парсить?
Сделаю, как опцию, если с регулярками кто поможет. (это не моя сильная сторона).
Но, имхо, use удобнее.
Сделаю, как опцию, если с регулярками кто поможет. (это не моя сильная сторона).
Но, имхо, use удобнее.
Ой, что я несу, вы же написали что сборка на лету, извиняюсь, я думал он собирает один раз и потом не обновляет кеш при изменении исходников, извиняюсь
Ой я тоже несу. При env=development он ничего не кеширует при production — он кеширует и не смотрит на время.
Сверять время не нужно на production. При обновлении ведь его рестартят.
Да и невозможно поскольку в haml, jade, less, sass есть подключаемые файлы и большинство компиляторов не возвращают их список. Даже если бы возвращали, то для показа одного файла могло бы потребоваться получение статистики по 10-20 файлам, что могло тормозить при сильных нагрузках.
Сверять время не нужно на production. При обновлении ведь его рестартят.
Да и невозможно поскольку в haml, jade, less, sass есть подключаемые файлы и большинство компиляторов не возвращают их список. Даже если бы возвращали, то для показа одного файла могло бы потребоваться получение статистики по 10-20 файлам, что могло тормозить при сильных нагрузках.
Меня одного смущает идея хранить статику в оперативной памяти?
В большинстве случаев отдача через res.sendfile более эффективна по всем критериям (отдача ядром ОС, использование кэширования ОС, меньший объем потребляемой памяти). А для gzip лучше бы использовать идею nginx gzip_static.
Хотя в большинстве случаев проще повесить nginx перед node.
В большинстве случаев отдача через res.sendfile более эффективна по всем критериям (отдача ядром ОС, использование кэширования ОС, меньший объем потребляемой памяти). А для gzip лучше бы использовать идею nginx gzip_static.
Хотя в большинстве случаев проще повесить nginx перед node.
Отправляется не строка а Buffer, который по сути является низкоуровневой областью памяти (V8 heap).
Он точно не копируется и, как мне кажется, не маршалится. Т.е. потерь нет никаких, в теории.
А если если даже маршалится то это делается через одно memcpy().
Т.е. вне зависимости от числа обращений к файлу в памяти будет хранится только зипованный и обычный буферы, каждый в единственном экземпляре. Который передается по ссылке.
Я не могу представить себе нагрузку, которая может убить ноду на примерно таком коде
var buffer=new Buffer(«bla bla bla… 50K»);
app.get('/',function(req,res){
res.send(buffer);
});
Узкое место у вебсервисов почти всегда — диск. Будет ли работать ngnix быстрее зависит от нагрузки на диск. ngnix, как мне кажется, полюбому mtime проверяет. Т.е. диск грузит.
Он точно не копируется и, как мне кажется, не маршалится. Т.е. потерь нет никаких, в теории.
А если если даже маршалится то это делается через одно memcpy().
Т.е. вне зависимости от числа обращений к файлу в памяти будет хранится только зипованный и обычный буферы, каждый в единственном экземпляре. Который передается по ссылке.
Я не могу представить себе нагрузку, которая может убить ноду на примерно таком коде
var buffer=new Buffer(«bla bla bla… 50K»);
app.get('/',function(req,res){
res.send(buffer);
});
Узкое место у вебсервисов почти всегда — диск. Будет ли работать ngnix быстрее зависит от нагрузки на диск. ngnix, как мне кажется, полюбому mtime проверяет. Т.е. диск грузит.
sendfile API просто требует read and write descriptors, ему mtime ни к чему. ну и всегда можно еще добавить file open cache.
А как он кеш на стороне браузере поддерживает? Нужен либо mtime или посчитать чексум файла. etag или modified-time ведь не посчитаешь без этого.
Дескриптор по любому юзает диск при считывании.
Дескриптор по любому юзает диск при считывании.
статику обычно отдают с expires max.
мы просто к имени файла прибавляем git sha. смотрите плагин grunt-urlrevs.
и никаких проблем с кэшированием.
мы просто к имени файла прибавляем git sha. смотрите плагин grunt-urlrevs.
и никаких проблем с кэшированием.
grunt-urlrevs это только для картинок
к урлу хтмл-файлов хеш не добавишь.
В общем можно сделать все что угодно на чем угодно даже на си++. Вопрос в том насколько сложно.
Hash к урлам добавляет грунт, а вот max-age должен отправлять ваш код. Т.е. этот пример хорошо иллюстрирует почему решение сборщик+стат-мидлеваре в одном флаконе лучше.
Реализовал в последней версии эту фичу. Из коробки идет по умолчанию.
к урлу хтмл-файлов хеш не добавишь.
В общем можно сделать все что угодно на чем угодно даже на си++. Вопрос в том насколько сложно.
Hash к урлам добавляет грунт, а вот max-age должен отправлять ваш код. Т.е. этот пример хорошо иллюстрирует почему решение сборщик+стат-мидлеваре в одном флаконе лучше.
Реализовал в последней версии эту фичу. Из коробки идет по умолчанию.
А чем ваше решение лучше уже существующих (например, mincer, connect-assets)?
Решил подобную задачу с помощью Grunt тасков:
grunt-include-source
Вставляет теги script и css в html один раз при добавлении нового файла
grunt-usemin
Пробегает по html и находит все коментарии вида:
И прогоняет их через concat, uglifyjs для js, и csso и autoprefixer для сss, и заменяет эти коментарии на подключение собранного файла, то есть для примера выше будет:
Плюс в дальнейшем добавлю grunt-filerev, что бы он менял номер ревизии у файлов во избежании загрузки из кэша браузера старых вместо новых версий файла.
Вполне себе так удобно и очень гибко. Возможно конечно настройка и займет немного больше времени.
grunt-include-source
Вставляет теги script и css в html один раз при добавлении нового файла
grunt-usemin
Пробегает по html и находит все коментарии вида:
<!-- build:js /app/app.min.js -->
<script src="/js/app.js"></script>
...
<!-- endbuild -->
И прогоняет их через concat, uglifyjs для js, и csso и autoprefixer для сss, и заменяет эти коментарии на подключение собранного файла, то есть для примера выше будет:
<script src="/app/app.min.js"></script>
Плюс в дальнейшем добавлю grunt-filerev, что бы он менял номер ревизии у файлов во избежании загрузки из кэша браузера старых вместо новых версий файла.
Вполне себе так удобно и очень гибко. Возможно конечно настройка и займет немного больше времени.
сравните синтаксис. Какой более чистый у USE тега или у кучи script/style да и еще и с комментами? Какой проще использовать?
сколько времени нужно настраивать и устанавливать плагины?
сколько времени нужно настраивать и устанавливать плагины?
У USE чище наверно, но я же не добавляю теги руками, а только размечаю комментариями куда плагин их добавит. Плюс на выходе у меня просто html без кастомных тегов. Также мне не нужно каждый файл прописывать вручную. И в моем подходе можно использовать всю мощь и гибкость грунта, то есть я могу изменить процесс обработки файлов так как мне нужно.
А так, установка и настройка занимает минут 10 — 15. И в итоге подход получается более универсальным, так как можно не только с nodejs и express использовать.
А так, установка и настройка занимает минут 10 — 15. И в итоге подход получается более универсальным, так как можно не только с nodejs и express использовать.
Ну необязательно Express у многих фреймворков ноды совместимость middleware
Кстати, насчет миддлвейров, хочется отметить, что комплексное решение уступает набору простых миддлвейров в гибкости. Это похоже на философию UNIX, где есть миллионы маленьких утилит, данные между которыми можно передавать через пайпы, контекст использования каждой из таких утилит достаточно широк, плюс создание цепочек обработки обеспечивает гибкость и настраивоемость решения, в вашем же случае, увы, при возникновении задачи, не предусмотренной вашим решением, возникает проблема, исправить которую можно а) написав PR, дождавшись вашего обновления, б) Открыв issue, но не факт6 что вы будете заинтересованы в проблеме, в) добавив сборщик (grunt/gulp и тд), но это приведет к фрагментированности сборки, что не правильно. Но в случае с простыми mw, проблему возможно решить, просто подключив нужный mw к express. Ну вот, например, я использую stylus, и я боюсь, что подключить его к вашей системе у меня не получится без приключений.
Насчет гибкости то есть фильтры: Вот вам стилус:
Для статика кроме фильторв единственный полезный middleware это gzip, которые идет в комплекте с кешированием.
var stylus= require('stylus');
fastStatic.addFilter({
exts:'stylus,styl',
ext:'css',
order:100,
fun:function(data,filename, ext, cb){
stylus.render(data,{},cb);
}
});
Для статика кроме фильторв единственный полезный middleware это gzip, которые идет в комплекте с кешированием.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Fast-static — Node.js модуль сильно облегчающий жизнь