Александр Прозоров

0) Ванилла js это и есть обычный js.
1) Начинать надо с одновременного изучения ваниллы и jQuery. По ванилле будете читать книги и всякие статьи, типа как работают замыкания, this, hoisting и так далее. А на jQuery вы собственно будете писать код, который будет что-то, да делать. Никто вам конечно не мешает забить на jQuery и по хардкору угарать только по ванильному жсу, но с огромной вероятностью, вместо того чтобы как то реально практиковаться в написании кода и выполнении каких-то простых задач, вы будете биться головой о стену, ибо для начинающего, работа с DOM (а только и этим можно заниматься поначалу) в ванилле это настоящая пытка. Очень важно пилить много велосипедов.
2) Параллельно прокачиваете css. Там просто поле непаханных возможностей и фишек. Со временем скорее всего придет понимание того, что чего то в обычном css не хватает. Тогда и начнете юзать препроцессоры. Можно конечно и сейчас сразу начать, но я не уверен что от этого будет хоть какая-та польза (а вот риск начать юзать вложенность в full-retard mode имеется).
3) Как только начнете писать хоть какой-то вменяемый js или юзать css с препроцессорами, тогда и придет пора автоматизации фронтэнда. Галпы, автопрефиксеры, склеивание/миницирование стилей/js и все такое. Об этом пункте вообще можно будет не париться долгое время, ибо все ваши задачи будут решаться установкой какого-нибудь генератора yeomana с маджонгом и гейшами.
4) Фрейморвки. Ангулары, реакты, эмберы и так далее. Будете их изучать на основе статей и пет-проджектов, ибо на нормальную работу, где эти самые фрейморвки применяют, с 90% вероятностью не возьмут без опыта владения ими. Учить их все естественно не надо. Достаточно хорошенько покопаться в 1-2, чтобы понять принципы работы основных частей.
4 пункт может с легкостью идти сразу за вторым, если вас больше интересует копание в жсе, и не особо интересно представление. Параллельно со всем перечисленным изучите стайлгайды, методолгии, модульные системы и все подобные вещи, которые необходимы для написания приличного кода.

Адрес: Москва, Дмитровское шоссе, д. 9
Проезд: м. "Тимирязевская": в метро — первый вагон из центра; в подземном переходе налево до конца, подняться по левой лестнице, далее по Дмитровскому ш. около 400 м по ходу движения транспорта. Помещение 1С:Центра исследования, разработки и обучения — 7-этажное здание за ограждением, калитка находится по центру здания.

схему проезда на автомобиле давать?

Возьмите какой-нибудь модуль и посмотрите - все делают на setTimeout...

Мне стыдно, но я должен признаться, что использую для отладки console.trace, console.dir, console.log. Пошаговая отладка мне нужна вообще 2-3 раза в год , а что нужно часто при разработке Impress (сервера приложений), так это наблюдение за структурами памяти внутри процессов. Для чего я использую node-inspector, так это сделать в консоли нечто типа Object.keys(impress.applications.example.cache.files) и получить ["/app/examples/access.js", "/app/examples/request.js", "/app/examples/simple/jsonPost.json/post.js", "/app/end.js", "/app/lazy.js"]. Это удобно, но вот брекпоинт поставить на обработчик приложения под Impress или где-то в системном коде Impress, мне ни разу не удалось: обработчики вылетают где-попало в системных библиотеках ноды (events, stream, net, fs) в каких-то местах, совершенно не относящихся к тому брекпоинту, которые я ставил. Если использовать cluster/fork Impress не запускается, но слава Аллаху, что у меня есть режим 'single', при котором все происходит в одном процессе и так как-то можно покопаться в памяти. Когда мы допилим Impress до стабильной версии и выпустим доки, то я собирался выделить время и разобраться в отладке, покопаться в этих проблемах и, возможно, что-то соптимизировать специально для совместимости. Вообще спасибо за работу, иногда очень пригаждается!

Я не удивлюсь, если this подменяет express. Вообще в документации express рекомендуется замыкать midleware

MainController.prototype.findAll = function() {
  var self = this;
  return function (req, res) {
    self.model.find({}, function (err, results) {
      if (err)  res.json({"findAll": err}); 
        res.json(results); // вы забыли else, здесь будет ошибка повторной отправки данных!
     });
   }
};
/* -------------- */
app.get('/users', userController.findAll());

var count = 0;
var app = express();

http.createServer(app).listen(8080)
  .on('connection', function(socket) {
    count++;

    socket.on('close', function () {
      count--;
    })
  });


function getConnectionsCount () {
  return count;
}

UPD. Есть еще асинхронный стандартный метод:

var app = express();
var server = http.createServer(app).listen(8080);

server.getConnections(function (err, count) {
  
});

А стрим тут и не нужен, делайте fs.readFile, потом ставьте fs.watch и при изменении fs.readFile в другую переменную и сравнивайте, только нужно создать еще очередь сравниваний, потому, что файл может меняться чаще, чем закончится предыдущее сравнивание (но это чисто теоретически, если по специфике задачи известно, что он меняется с малой периодичностью, то это можно и опустить). Результат fs.readFile это объект Buffer, для сравнения двух буферов, скорее всего, если они содержат текст их можно перегнать в строки .toString() и парсить. А вот понять, идентичны ли буферы, можно при помощи Buffer.compare(buf1, buf2).

https://nodejs.org/api/http.html#http_class_http_c...
Читайте документацию, да гайды. Благо, по стандартным API функциям их туевы хучи через тот же гугл найти можно.

Что же до вашего примера, то записывайте данные куда-нибудь в пределах области видимости вашего замыкания.

var _json='';

socket.on('data', function(chunk) {
    _json+=chunk.toString();
});

socket.on('end', function() {
    var result=JSON.parse(_json);
    ...
});

Покажите код.
full stack engineer, my ass.

P.S. Читать не пробовали, что генератор-то пишет?

run the app:
     $ DEBUG=myapp:* ./bin/www

Node.js должна идеально подойти судя по описанию. С другими языками не думаю, что будет лучше. Может быть, так же, но не лучше. Тем более раз вы уже что-то писали на ноде, то зачем переходить на что-то еще.

Часто применяется для:

1. Локальные приложения и утилиты командной строки

• Сборщики и трансляторы
  
• Пакетная обработка и сценарии отложенной обработки
  
• Скрипты, CLI (интерфейсы командной строки)
  
• Генерация документации, отложенное формирование отчетов
  
• Сценарии тестирования для других систем
  

2. Серверы

• Серверы веб-приложений и SPA
  
• Серверы и API для мобильных приложений
  
• Любые другие веб-API (RPC, JSON, REST)
  
• Серверы сообщений и трансляция событий (чаты, игры, интерактив)
  
• Заплаты на уже готовые системы, написанные на других языках, для реализации вебсокетов, SSE, лонг-пулинга и т.д., т.е. для затыкания дыр, для решения проблем в узких местах уже работающих систем.
  

3. Клиенты

• Оконные приложения (nw.js, node-webkit)
  
• Кравлеры, парсеры и сбор данных
  

4. Железо

• Программирование микроконтроллеров (arduino, espruino, tessel)
  
• Промышленная автоматизация
  

Редко применяется (но подходит) для:

• CMS, публикация контента (просто ниша уже занята и в этой задаче нода не дает чего-то принципиально нового или сверх соблазнительного).
  
• Массовая электронная коммерция и торговля (не применяется для массовых движков магазинов, но используется отдельными крупными компаниями для торговых и платежных задач в качестве дополнительного средства к уже имеющемуся ПО, по сути закрывает узкие места).
  

И плохо подходит:

• Вычисления и моделирование, со скоростью математических операций нода и JS, как не типизированный язык, не дают хороших показателей
  
• Научные приложения (по тем же причинам)
  

Не пиши каку и все ок будет, там же в выводе написано, что не так. И это не "гребанный валидатор", а ОЧЕНЬ эффективная система по выпрямлению кривых рук.

Ваша проблема в непонимании того, как работает JavaScript. Коллбек переданный в `https.request` будет выполнен уже после того, как вы проверите существование переменной, хранящейся в сессии. Гуглим описание работы event loop и асинхронности в JavaScript.