Пачка статей на хабре пролетала как работать красиво с вложенными коллбеками. Есть туча модулей с разными подходами на любой вкус. Это уже теперь не проблема, у nodejs есть другие проблемы, похуже. Например падение всего nodejs сервера при неотловленном исключении в любом коллбеке.
Автор переписал приложение с Django на Node.js потому что LAMP мертв? В огороде бузина а в Киеве дядька. Типа на LAMP не работает ajax. Данные прекрасно доставляются на клиент в любом современном фреймворке, REST архитектура раздаст все красиво в любом формате хоть в Django, хоть в ROR, хоть в нодовском Expressjs. В Node.js такие же возможности доставки данных как в PHP.
Согласен, важно понимать различие var handler = function(){...}
от function handler(){...}
но kmike наверное, имел ввиду то, что для него проблематично скроллить код от места вызова обработчика до описания обработчика и обратно, а вверх скроллить или вниз, в поисках кода обработчика, какая разница?
Вы правы по поводу целей этих библиотек — они реализуют асинхронные шаблоны. Если использовать их, то проблема «лестничного» кода решается автоматически (лестницы критически уменьшаются до удобоваримых 2х-3х этажей) без именования коллбеков. И избавление от такого кода — первое, что может оценить человек, который пока не оценил или не разобрался с этими бибиотеками.
Вы в nodejs еще столкнетесь с ситуацией, когда у вас будет 20 вложенных коллбеков, такой код читать и править — ад, это только одна из проблем асинхронного JS. Тогда вы вспомните про эту статью.
Async.js умеет. В браузере и на сервере. По цепочке, параллельно, водопадом (когда результат одной асинхронной функции передается на вход следующей) и много еще чего. Для меня лично — самый понятный вариант среди всех async и combo библиотек и подходов. Использую на нескольких проектах, пока не подводил.
expressjs видел и использовал. я так и не понял, как согласно их философии разные ф-ции обработки роутов скинуть в директорию в отдельные файлы, чтобы не загромождать один.
Код, который загружается через require, компилится и кешируется, и после разогрева приложение летает :).
Вообще expressjs — очень хороший, стабильный и быстрый движок на node с очень качественным набором middleware, в том числе и роутером. Я вот тоже пишу свой MVC-велосипед, но уже поверх expressjs. Хотя, если учитывать ваши цели — вскипятить интерес к node, то свой велик с нуля тоже нужная вещь :)
А, тогда все понятно. Мне подумалось, что вы о том, чтобы сложить контроллеры в .node-libraries и грузить их обычным require, тогда и кода бы поуменьшилось. А вы имели ввиду сам spirit и mootols — здесь вы точно правы, такие вещи нужно складывать в общие директории.
По библиотекам согласен, но одно дело складывать в общие для проектов папки атомарные модули, и совсем другое — файлы контроллеров. Доступ к контроллерам из других проектов — наверное, не совсем правильно по соображениям секьюрности. Тут автору лучше использовать что-то вроде nodules или на крайний случай использовать require.paths.unshift, что впрочем не снимает всех проблем с секьюрностью.
Ну смотри, ты вот jQuery интересуешься, выкатываешь неплохую статью под названием «Оптимизируем производительность селекторов jQuery». Первым же комментом от Dimon012 получаешь: «Вообще не понял что это, для чего и зачем, дальше не читал». Что начнешь делать? Объяснять, что такое производительность, что такое селекторы или что такое jQuery?
Сам он статику раздавать не умеет. Нужно писать свой модуль. Как бы читать файл и отдавать его большой проблемы нет, но если сделать все по хорошему — надо отдавать много всяких заголовков — Content-Length, Last-Modified — это первое что приходит в голову. А правильный mime отдать для Content-Type — вай, а кеширование — Cache-Control, If-Modified-Since, 304 статус отдавать когда надо, все варианты правильно разрулить. Все как бы решаемо, но проще nginx использовать.
В чем tenshi не прав? Это же не eye-tracking, по которому мы можем определить, что какую-то важную ссылку не замечают, это всего лишь способ определить, по какой ссылке на странице кликали. Люди кликают туда, куда им дают кликать, разве нет?
Сейчас гораздо большей эффективности добавит разделение селектора на те, которые написаны по CSS3 правилам и на остальные. Первые выполнятся очень быстро через нативный querySelectorAll, остальные фильтранет Sizzle:
$("#id .class tag:visible")
лучше выбрать так: $("#id .class tag").filter(":visible")
Ну, и не стоит забывать о совсем олдскульных трюках: в примере, где формируется DOM-строка, в IE6 все равно все будет грустно. Все маленькие строки лучше складывать в массив, а потом join-ить его. Я понимаю, что здесь речь о перфомансе jQuery, но в этом примере с водой выплеснули и ребенка:
вместо: var li_items = "";
for (var i=0; i< top_100_list.length; i++)
li_items += '' + top_100_list[i] + '';
$mylist.append(li_items);
лучше: var li_items = [];
for (var i=0; i< top_100_list.length; i++)
li_items.push('' + top_100_list[i] + '');
$mylist.append(li_items.join(''));
Оборачивать замыканием для $ надо в любом случае. + в моем примере ошибка, там $.extend(true, popup.timeSlider, options);
надо заменить на $.extend(true, timeSlider.settings, options);
копипастил с другого плагина и не то заменил :)
Не понял, что вы имели ввиду под односторонним API
var handler = function(){...}от
function handler(){...}но kmike наверное, имел ввиду то, что для него проблематично скроллить код от места вызова обработчика до описания обработчика и обратно, а вверх скроллить или вниз, в поисках кода обработчика, какая разница?
Способов масса, первое, что приходит в голову:
app.get('/blog/posts/:id', function(req, res, next){
require('./controllers/blog-posts')(req, res, next);
});
а в файле ./controllers/blog-posts.js:
module.exports = function(req, res, next){
// .... обработка роута
}
Код, который загружается через require, компилится и кешируется, и после разогрева приложение летает :).
Вообще expressjs — очень хороший, стабильный и быстрый движок на node с очень качественным набором middleware, в том числе и роутером. Я вот тоже пишу свой MVC-велосипед, но уже поверх expressjs. Хотя, если учитывать ваши цели — вскипятить интерес к node, то свой велик с нуля тоже нужная вещь :)
Сейчас гораздо большей эффективности добавит разделение селектора на те, которые написаны по CSS3 правилам и на остальные. Первые выполнятся очень быстро через нативный querySelectorAll, остальные фильтранет Sizzle:
$("#id .class tag:visible")лучше выбрать так:
$("#id .class tag").filter(":visible")Ну, и не стоит забывать о совсем олдскульных трюках: в примере, где формируется DOM-строка, в IE6 все равно все будет грустно. Все маленькие строки лучше складывать в массив, а потом join-ить его. Я понимаю, что здесь речь о перфомансе jQuery, но в этом примере с водой выплеснули и ребенка:
вместо:
var li_items = "";
for (var i=0; i< top_100_list.length; i++)
li_items += '' + top_100_list[i] + '';
$mylist.append(li_items);
лучше:
var li_items = [];
for (var i=0; i< top_100_list.length; i++)
li_items.push('' + top_100_list[i] + '');
$mylist.append(li_items.join(''));
$.extend(true, popup.timeSlider, options);надо заменить на
$.extend(true, timeSlider.settings, options);копипастил с другого плагина и не то заменил :)
Не понял, что вы имели ввиду под односторонним API