function Base() {
this.el = $('<div></div>');
// ...
}
Base.someStaticMethod = function() { /* ... */ };
Base.prototype.someMethod = function() { /* .. */ };
Base.prototype.constructor = Base;
function Sub() {
Base.apply(this, arguments);
this.el.append('I am subclass object');
// ...
}
Sub.prototype = new Base();
Sub.prototype.constructor = Sub;
Sub.prototype.someOtherMethod = function() { /* ... */ }
var el = new Sub();
el.someMethod();
el.someOtherMethod();Погуглите puppet, chef, salt, vagrant, docker
$.post('/get_comments', { id: parseInt($(this).parent().data('id')) }, function(data) { console.log(data); });
Sails - на самом деле просто шаблон приложения с предустановленным набором модулей и заданной структурой, а не полноценный фреймворк. И да, метеор это не Rails или Django. Express - да, это микрофреймворк. Но особенность (я не говорю, что это явное преимущество, а именно особенность) ноды в том, что в ней не делается все так, как в привычных фреймворках. Просто берутся только те модули (отвертки, если хочешь), которые в данном случае нужны, их "долгая" логика запихивается в какой-нибудь async.parallel или как middleware в express и затем просто обрабатывается результат. Подход применим для любого сложного случая. Если попробуешь сам, то убедишься в этом. На самом деле очень сложно передать это текстом, нужно просто попробовать.
Я согласен, что не во всех проектах нужен асинхронный подход. Но то же верно и для любого другого подхода/шаблона. Это вообще очень философский вопрос - что и для чего больше подходит) Но асинхронная обработка, однозначно, хорошо вписывается в приложения, где есть много работы с данными, коими является большая часть интернета. И синхронный код не "проще и надежнее", а просто "привычнее".
Про прослойку я согласен, это как-то странно, но о такой форме извращения я не упоминаю)