DevMan

Ахахахаха и много вы написали хороших десктопных приложений на жс? А интернет магазинов? Так рассуждать всем бы на ассемблере программировать.
Жс убог и ограничен о какой то его универсальности речи вообще не идёт

Ибо не php5-mycript, а php5-mcrypt.

Забавно смотреть, как вы пытаетесь абсолютно всё отнести к одной из трёх букв MVC, как буд-то кроме моделей, видов и контроллеров других паттернов нет.

За работу аутентификацией/авторизацией/сессией/куками может отвечать некий сервис, не имеющий отношения к MVC. А получение доступа из моделей и контроллеров к ним можно осуществлять через Service Locator.

пожалуйста, не рекомендуйте использовать фреймворки вместо велосипедов

Всё же посоветую пересилить свой страх, а то звучит как "пожалуйста, не заставляйте меня идти правильным путём".

1. GWT - скорее мертв, мало в каких новых проектах используется. В существующих стараются уже переползти на другие фреймворки
2. Стек технологий определяется спецификой проекта, над которым ведется работа. Поэтому вначале определись с задачами, которые стоят перед тобой, а потом уже решай посредством чего достигать цели.

clubs.ya.ru/mapsapi/replies.xml?item_no=204

Какая разница какой язык? Чисто технически то, что можно сделать на C, Java, PHP можно так же сделать на Brainfuck.
Любой полноценный веб-язык способен такое сделать, вопрос сам по себе не имеет смысла в принципе, к тому же ответ на него вам по сути ничего не даст, а исходя из постановки вопроса - тем более...

Оффтоп:

новичок в мире IT

высказал свое мнение

в вебе же уже давно не правит Java

Как можно судить о платформе, которую ты еще толком не знаешь?

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

На самом деле основные отличия другие:
Постоянно живущий процесс, фактическая однопоточность. В зависимости от задачи - это может быть и плюсом и минусом. Условно для какого нибудь сокет-сервера - плюс (активно используем на живых проектах). Для middleware - я бы подумал. Для нагруженного сервиса с расчетами - точно нет.

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

Надо смотреть что за инструкции. Телепаты в отпуске.

Вы явно путаете жужжащих мух с теплыми котлетами. Игровые движки создаются разработчиками, также же как и любые другие приложения. Если это игровой движок в классическом понимании (нативный, на D3D или OpenGL) - то это нативное приложение, для создания которого применяются в общем-то обычные хорошо известные инструменты: язык программирования и его тулчейн (компилятор+линковщик) - это минимум, а там уже у кого как - IDE (одну из которых вы упомянули в тегах), просто редактор типа sublime и т.д.
exe-файл, как и любой другой модуль на любой платформе (PE(exe, dll) на винде, ELF (бинарник/so) на линухе и т.д.) - это результат работы линковщика. Линковщик собирает сгенеренные компилятором объектные файлы и другие библиотеки в такой модуль, объектные файлы генерятся компилятором из исходного кода, исходный код пишут разработчики.
Для Microsoft Word, Half-Life и KDE в общем и целом этот процесс - одинаковый. Разница только в инструментах, платформах и мелочах.
Смысл вопроса из заголовка - "как ДВИЖКИ компилируют код?" я так и не понял, если вы имеете в виду скрипты, которые можно выполнять средствами движка - это другая история, многие серьезные двиги используют интепретаторы существующих скриптовых языков (Lua например весьма популярен) или пишут свой для реализации на этом скриптовом языке игровой логики, интерфейсных плагинов (в WoW так делают), ну и так далее.
P.S. Если уж упомянули в тегах студию, поставьте её, создайте простейший консольный проект (Win32 Console Application), скомпильте и запустите - и вы выполните всю ту цепочку, которую выполняют разработчики нативных приложений (только она у них может быть сложнее, кастомизирована под их нужды, и в их проектах не 2 cpp-файла, а 10 тысяч).

Не волнуйтесь, вас уволят и правильно сделают. И вот почему.
Начну со стороны хорошего бизнесмена:
У него уже есть cms и crm, которую он пилил 5 лет, умеет продавать и знает. Да, так получилось, свой велосипед, ужасно написанный, но это его не волнует до тех пор, пока она кормит и его и всех его подопечных. Отказаться от неё означает не только огромные временные затраты на смену всего, начиная от обучения программистов как её пилить, заканчивая обучением всех, кто будет её касаться. Так же это означает поддержка уже двух систем, старых клиентов со старой и новых с новой. Но самое главное - это высокий риск того, что продавать её будет тяжелее.

Со стороны хорошего разработчика:
А хорошему разработчику вообще до фени, с чем ему работать. Спросите у опытных. Эмоционировать при виде говнокода и велосипедов - это максимализм юного программиста. Разработчики с опытом умеют погружаться в любой велосипед, в любой говнокод и работать с ним. А потому что они уже навидались и в своё время тоже кричали и пытались перевернуть мир, но, кому это надо? Вы - наёмный работник, вы не должны писать красивый код, вы должны решать бизнес задачи. Бывалые так и делают, просто иногда про себя вздыхая, т.к. чувство прекрасного всё же не убить :)