Комментарии 98
Господа гуру и просто глубоко понимающие JS. Поясните человеку, владеющему в разной степени понимания более, чем 4-мя языками программирования — в чем преимущества JS? В смысле, как языка… Я понимал его всегда как неизбежное зло — монопольный стандарт на клиентский код в web. Когда появился node.js, я смотрел на него как на странную фанатскую поделку — ну кому, — думал я, — взбредет в голову писать на таком нелестный эпитет языке что-то, помимо кнопочек и картинок в браузере?

А потом оказалось, что я неправ. Просто статистически. Объявилась толпа людей, которые реально пишут на нем целые серверы. И теперь я в недоумении. То ли эти люди просто не решились выучить Java или, хотя бы, Ruby, то ли у меня лыжи не едут…

Прошу, не холивара ради, а токма прояснения истины для — объясните мне, что особенно хорошего в нем?
В языке ~4 концепции. Его красота именно в минимализме. Он позволяет писать в функциональном стиле. Объектное наследование отличается от классического, но это не хуже или лучше, просто другое. А когда V8 довёл его скорость до ~1/3 сишного компилированного — стало разумно утягивать это на сервак. Компиляция на лету. Собственно вот сравнение с руби.
Объектное наследование отличается от классического

Объектное

Прототипное, не?
Да, и прототип — тоже объект (или, иногда — примитив).
Сообщество писателей на ЯС — это популяция живых организмов. И как и любая другая она стремится захватить как можно большее пространство. Это закон природы. Они не могут по-другому. Если кто-то придумает компилятор ЯС, они и операционки будут на нём писать.
Так они уже придумали. V8 именно компилирует код, только за счёт этого можно добиться такой скорости, причём умудряется делать это очень быстро. Есть компиляторы си в am.js код, когда asm.js только появился — чуваки скомпилили таким образом квейк и он не тормозил в браузере.
если отойти от канонов, и генерировать исполняемый файл компилятора который так же пакует в исполняемый файл… то почему нет?
Я почти уверен что кто-то уже забавы ради через llvm компилировал код v8 в js. Погуглил. Не v8, но llvm.js.
Прошу, не холивара ради, а токма прояснения истины для — объясните мне, что особенно хорошего в нем?

Каков минимальный размер программы на Java?
Каково обычное потребление памяти виртуальной машиной Java?
Люди привыкли к тому, что Java это медленно и много памяти. Жалобы на тормозной OpenOffice(Libre etc) их валом.
Он даже стартует медленно.

Парсер кода в PhpStorm(как по мне, он лучший) на большом количестве текста вешается и остановить это можно только выключив процесс.
То же и в других Java-based редакторах. А вот NuSphere PhpEdit, который написан на С++ переваривает любое количество текста, кода, чего угодно, что было открыто в нём. И делает это относительно легко.

Я не слышал про интерпретаторы Ruby для STM32, а Javascript есть. Я писал на С для контроллеров, но как же удобно делать мелкие проекты на Javascript. Причём, интерпретатор же событийный и сам управляет питанием чипа, в отличии от большинства программ новичков, где просто
while(1){ 
  включили диодик
  цикл пауза - считаем до 1 000 000 
  выключили диодик
  цикл пауза - считаем до 1 000 000 
}

Я слышал про Ruby, который всегда на рельсах. Про Ruby без рельс вообще кто-то слышал? ;) А на рельсах оно всё тяжёлое.

Javascript даёт
  • быстрый старт. При изучении. При минимальном размере кода для программы. При запуске программы.
  • Малое потребление памяти.
  • Множество библиотек.
  • Скорость виртуальной машины почти равна, а в некоторых случаях превосходит результаты компилируемых языков, таких, как С и С++.
  • Можно писать на коленке, т.е. нужен браузер и блокнот, и уже можно начать.
  • Можно делать GUI в лёгкую, без каких либо библиотек.
Что есть у приведённых вами языков, что сравниться с jQuery (и т.д.) + Bootstrap? Минимум размера файлов и кода — максимум результата.

Продолжать можно долго.
Про Ruby без рельс вообще кто-то слышал? ;)

Да ладно вам, а как же руби скрипты? Например тот же homebrew ;)
Не понимаю минусов. Лично для меня писать руби скрипты удобнее чем баш скрипты. И я считаю что это не плохо, они выполняют свою задачу, на них удобно писать тесты, их можно объединять в гемы, etc.
Люди привыкли к тому, что Java это медленно и много памяти.

Тут не соглашусь, медленно разрабатывать — да, но скорость выполнения у Java приложения будет выше чем у JS/Ruby приложения.
Вы не подумайте, я обеими руками за JS, но стоит признать, что Java работает быстрее.
Стоит показать сравнительные тесты. Только в качестве примера — клиент-сайд приложения, которые запустил, поработал, выключил. А не те, что через 1000 часов непрерывной работы на сервере виртуальная машина идеально оптимизирует.
Я вам говорю про сервер сайд конечно же, не думаю что сейчас можно вообще рассматривать клиент сайд на джаве.
Мне всё равно было бы интересно увидеть тесты, даже в случае сервер-сайд. Интересно же, на чём основываются ваши слова.
Ну в большинстве то у ява, причём в разы. А ещё javascript однопоточен и многопоточность в нём реализуется только через костыли и модули написаннные на других (нормальных) языках.
Вебворкеры и webgl творят чудеса. В продакшене у меня крутится несколько серверов, на каждом через node-cluster в 4 потока работает приложение, cинхронизация через redis. Внешний round robin балансер на сервера и внутренний между ядрами. Загрузка ядер при тысячах rps меньше процента.
Вебворкеры — это не потоки! Потоки разделяют адресное пространство, а вебворкеры — нет. Но это не самое страшное, а страшно то, что из вебворкера я не могу сказать «вот тут подожди секунду и продолжай» или «отправить запрос к БД и подожди, пока он не выполнится». Всё это даже в вебворкерах делается через привычные колбэки, и даже promises решают проблему лишь частично. Когда мы говорим о сервере, то в node.js есть webworkers? А синхронную работу с БД там можно организовать?
А тут делается через асинхронность. Так работает nginx, на пример. От shared memory столько же минусов, сколько и плюсов. Например в JS сложно получить deadlock, чего не скажешь о многопоточных приложениях.
А тут делается через асинхронность

А как делается в JS, я прекрасно знаю. Весь посыл в том, что типичный бэкэнд писать в колбэчном стиле крайне неудобно по сравнению с тем

Например в JS сложно получить deadlock, чего не скажешь о многопоточных приложениях.

Зато очень просто получить live lock :-) И даже гонка за общими ресурсами может быть, я по всем этим граблям даааавным давно прошёлся.
Гм, ну посмотрите на современный js. Есть промисы, есть, пока не стандартизованные, но таки доступный к использованию async/await.
app.get('/users', async (req, res) => {
  const users = await User.findAll();
  res.json(users);
});

Вот пример из реального проекта, авторизация:
async authorize(username, password) {
  const user = await User.findOne({
    where: {username}
  });
  if (user && await user.checkPassword(password)) {
    return user;
  }

  throw new Error(`Unknown user ${username}`);
}

Если не нравится не стандартизованные фичи, вот во что это компилируется:
const authorize = bluebird.coroutine(function *authorize(username, password) {
  const user = yield User.findOne({
    where: {username}
  });
  if (user && yield user.checkPassword(password)) {
    return user;
  }

  throw new Error(`Unknown user ${username}`);
});

Можно писать так. Это уже доступно и прекрасно работает в io.js.
А можно пример, как в многопоточных приложениях решается гонка за ресурсами? Я думаю и там и там нужно держать пул соединений к базе, или вы о чем то другом?
Я не про базу, а про общие области памяти (например, поля объектов, которые видны нескольким потокам). И там для разруливания гонки используются блокировки. Есть несколько примитивов синхронизации, которые позволяют более-менее удобно управлять ресурсами (семафоры, мониторы, fork-join), есть CAS, который работает аппаратно, а не через средства ОС (а значит быстрее), но при этом он сложнее. Так же бывают многопоточные коллекции, которые гарантируют сохранение внутренней согласованности при условии параллельного доступа из нескольких потоков. На потоках прекрасно реализуются альтернативные средства для работы с параллельными задачами: акторы, транзакционная память.
Я не понимаю к чему вы мне это рассказываете. У нас однопоточное приложение, IO которого работает асинхронно. Это ровно все, что предоставляет нам node. Какие общие области памяти могут быть у одного треда?
Я рассказываю это к тому, что «работает асинхронно» — это через колбэки. А колбэки разрастаются в кромешный ужас, и promises не всегда справляются. С синхронным IO и возможностью создавать потоки я просто пишу код без колбэков, не опасаясь того, что поток может «подвиснуть» на IO. Пусть себе подвисает — другие-то потоки в это время выполняются.
Можно пример, когда промисы не спасают? Ну и если так наплевательски относиться к IO, у вас все встанет в какой-то момент, что с колобками, что с потоками. Помимо прочего потоки — это лишняя память и лишнее процессорное время.
Можно пример, когда промисы не спасают?

  • алгоритм Дейкстры по графу, который хранится на диске (или в БД);
  • сортировка слиянием большущего объема данных, не умещающихся в памяти;
  • ленивая загрузка ассоциаций через прокси, как в Hibernate;
  • синтаксический разбор кода через LR-парсер, если код хранится на диске;
  • банальный вложенный цикл с break'ом по условию, зависящему от элемента, выбранного на очередной итерации.


Ну и если так наплевательски относиться к IO, у вас все встанет в какой-то момент, что с колобками, что с потоками.

Что значит «наплевательски относиться»?

Помимо прочего потоки — это лишняя память и лишнее процессорное время.

Потоки — это не лишнее процессорное время. Ну да, на шедулинг потоков тратится процессорное время. Но на шедулинг корутин разве не тратится? А как по памяти? Я понимаю, на каждый поток создаётся по своему стеку. А на замыкания разве память не тратится? Я понимаю, бывают задачи вроде раздачи большущих файлов, когда логика простейшая, а IO много, но в типичном enterprise экономия памяти на корутинах — это экономия на спичках.
банальный вложенный цикл с break'ом по условию, зависящему от элемента, выбранного на очередной итерации.

Мне кажется, что вы заблуждаетесь. Чтобы исключить неясности, приведите, пожалуйста, этот цикл в синхронном виде, а я попытаюсь переписать его асинхронно с помощью промисов.
Ок. Если вы реально упретесь в что-то из выше перечисленного, можно написать расширение на любом языке с поддержкой ffi, или просто взять плюсы и написать эту конкретную задачу нативно.
Я думаю каждый инструмент имеет ограниченную область применения. Но я всего лишь не согласен с тем, что у JS — это только браузер.

А по поводу потоков — я не достаточно компетентен, чтобы продолжать тут спорить. На вскидку — да, свой стек, конкурентный доступ к общей памяти.
Парсер кода в PhpStorm(как по мне, он лучший) на большом количестве текста вешается и остановить это можно только выключив процесс.

А можно пример такого же парсера на JS, который это все переварит лучше Шторма в том же окружении?
tern.js, на пример, проект. Пользуется популярностью у любителей простых редакторов, а не IDE. То есть vim/atom/sublime etc.
ну атом не катит как пример, он разве научился переваривать файлы > 2 мб?

RubyMine хоть в состояние логи открыть, это может затянутся конечно… Приходится Sublime для здоровенных файлов использовать
Научился. Только он зависает на некоторое время, прежде чем можно скроллить. Sublime тоже зависает, но показывает прогресс-бар.
IDEA тоже не открывает большие файлы нормально)
А можно пример IDE? Иначе какое то получается сравнение странное. Это все равно что Notepad с MS Word сравнивать по потреблению ресурсов.
Ну, code, наверное. На JS нет IDE, во всяком случае в вашем понимании. А WebStorm — это не IDE для JS. Это маркетинговый булшит.
Хотя, посмотрите на Nuclide. Это одна из попыток, сделать из Atom IDE. Судя по презентации, facebook использует Atom, как IDE вместо xcode, phpstom и webstorm. Там есть много возможностей, которые дает полноценная IDE.
Из википедии: Written in C++[3] and Java
Насколько я понимаю, на С++ оболочка, а нутро на Java. Возможно я ошибаюсь, найдёте подробности?
Откройте код, там только C++ (я немного патчил Либру). А так даже на вики написано:
ru.wikipedia.org/wiki/LibreOffice
Написана на
C++


Java там только для нескольких плагинов.
Я говорил в первую очередь про OpenOffice. Вики: Написана на C++, Java
Не думал, что Либре за несколько лет сумели отказаться от Java. Спасибо, было интересно узнать.
В OpenOffice аналогичная ситуация. Там только C++ старый… в Libre смогли перенести всё на стандартный STL с самопала (что сильно сократило размер кода, ускорило сборку и кое где скорость работы).
Каков минимальный размер программы на Java?


Размер JAR обычно ничтожен — там байткод. Если вы хотите считать размер вместе с JRE, то не забудьте приплюсовать к размеру программы на JS и размер браузера и движка JS. И у JRE круг решаемых задач будет поболее чем у браузера.

Каково обычное потребление памяти виртуальной машиной Java?


Посмотрите сколько отъедает одна открытая вкладка с JS приложением типа твиттера.

Люди привыкли к тому, что Java это медленно и много памяти. Жалобы на тормозной OpenOffice(Libre etc) их валом.
Он даже стартует медленно.


OpenOffice написан на C++. И скорость его старта это следствие сложности самого приложения. К слову на JS пока что-либо такой сложности я не встречал.

Парсер кода в PhpStorm(как по мне, он лучший) на большом количестве текста вешается и остановить это можно только выключив процесс.
То же и в других Java-based редакторах. А вот NuSphere PhpEdit, который написан на С++ переваривает любое количество текста, кода, чего угодно, что было открыто в нём. И делает это относительно легко.


Вы доказываете превосходство JavaScript сравнивая Java и C++? Вы точно сравнивали PHPStorm и PhpEdit по возможностям? PHPEdit тоже поддерживает все рефакторинги, дает API для траснформации AST, поддерживает встроенные в PHP шаблонизаторы?

Я не слышал про интерпретаторы Ruby для STM32, а Javascript есть.


Равно как и питон есть для микроконтроллеров. Потому что и питон и JS минималистичны в плане грамматик. Когда JS будет поддерживать столько же возможностей как Ruby вроде постфиксных условий, операторов, возможностей для создания DSL, его тоже врядли запихнут в микроконтроллер.

Я писал на С для контроллеров, но как же удобно делать мелкие проекты на Javascript. Причём, интерпретатор же событийный и сам управляет питанием чипа, в отличии от большинства программ новичков, где просто

while(1){
включили диодик
цикл пауза — считаем до 1 000 000
выключили диодик
цикл пауза — считаем до 1 000 000
}


Наверное если новичок не знает про режимы работы STM32, то не сильно огорчится если его программа будет работать на максимальном режиме энергопотребления. А если перед нами профессионал и он умеет работать с прерываниями и таймером, то бог ему судья. Более натужный пример нужно было бы еще постараться придумать.

Я слышал про Ruby, который всегда на рельсах. Про Ruby без рельс вообще кто-то слышал? ;) А на рельсах оно всё тяжёлое.


Про JS без веба кто-то слышал? Ну может конечно уже и слышал — когда такая толпа программистов на одном языке появляется, то индустрия начинает адаптироваться и совать язык куда только можно.

Javascript даёт

быстрый старт. При изучении. При минимальном размере кода для программы. При запуске программы.
Малое потребление памяти.
Множество библиотек.
Скорость виртуальной машины почти равна, а в некоторых случаях превосходит результаты компилируемых языков, таких, как С и С++.
Можно писать на коленке, т.е. нужен браузер и блокнот, и уже можно начать.
Можно делать GUI в лёгкую, без каких либо библиотек.


Ответ не верный. Python дает:

быстрый старт. При изучении. При минимальном размере кода для программы. При запуске программы.

cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-us-universities/fulltext

Малое потребление памяти.


www.cdotson.com/2014/08/nodejs-vs-python-vs-pypy-a-simple-performance-comparison

Множество библиотек.


pypi.python.org/pypi

Скорость виртуальной машины(PyPy) почти равна, а в некоторых случаях превосходит результаты компилируемых языков, таких, как С и С++.


morepypy.blogspot.com/2011/02/pypy-faster-than-c-on-carefully-crafted.html

Можно писать на коленке, т.е. нужен браузер и блокнот, и уже можно начать.


А для питона — питон и блокнот.

Можно делать GUI в лёгкую, без каких либо библиотек.


IUP, Tkinter, PyQt, PyQt, WxWidgets.

Просто JS всотребован из-за вынужденного отсутствия альтерантив в данной области. Если в браузеры запилят байткодную виртуальную машину независимую от языка и JS там продержится как топовый язык еще 3 года, то тогда можно будет о чем-то говорить.

Что есть у приведённых вами языков, что сравниться с jQuery (и т.д.) + Bootstrap? Минимум размера файлов и кода — максимум результата.


Что есть у JS, что сравится с Microsoft Excel и его VBA? Минимум размеров файлов и кода — максимум результата.

Продолжать можно долго.


Несомненно, ведь количество аругментов, которые человек готов привести в защиту чего-то, прямо пропорционально симпатии к защищаемому объекту.
Событийность из коробки? Возможность писать в разных стилях (императивный, функциональный, объектный, процедурный, да даже декларативный прости господи) без принуждения к какому-то конкретному? Отсутствие необходимости осваивать мегабайтные фреймворки, чтобы написать hello world?
Ну и да, хотя изоморфность довольно спорна сама по себе, перспектива писать на одном и том же языке в бэкенде и фронтенде достаточно интересна и привлекательна. Плюс сокращение объема кодобазы.
Я так понимаю вы говори о nodejs, но bigfatbrowncat говорил именно о языке
Неправильно понимаете.
К тому же, если рассматривать любой язык в отрыве от реализации, в любом языке из коробки нет ничего, кроме формальной грамматики.
К большинству языков прилагается стандартная библиотека. Так где в js event loop?
Не вижу ни одного упоминания event loop в стандартной библиотеке языка. Плохо гуглите или его там нет?
Я правильно понял, что вы утверждаете об отсутствии event loop как такового в js? Вы это серьезно?
Абсолютно. Кстати, сами бы посмотрели чего нагуглили — «как в спецификации» :) В стандарте ECMAScript 5 абсолютно ничего про основной цикл, разве что в ECMAScript 6 появляется Promise.
А вы дальше первого абзаца, очевидно, не читали? «У браузеров (и в node.js) основная петля вшита.» Спецификация это безусловно круто, только в спецификациях говорится о том, как это должно работать, но ничего не говорится о том, как это должно быть реализовано.

И да, покажите хотя бы одну реализацию, где нет event loop.
А должен был? Что я когда-то там в комментариях отметился вас явно не смущает :)

Отличайте язык (в котором, по вашему, событийность есть искаропки) и окружения.

Вы забыли или не знаете про различные встраиваемые реализации JavaScript, например, V7?
Паттерн observable пишется на js в 15 строк. Десятки их писал под разные задачи, в том числе компилирующий новую функцию при каждом невешивании события (профит скорости ~30%).
В node.js есть eventemitter из коробки, под браузер уверен что есть полный полифилл (если это не прям тот же код).
В браузере события приходят из window, элементов, xhr и других ассинхронных штук. Чертовски удобно.
В браузерах из коробки можно забавляться с подписыванием на кастомные события дом элементов.
Он идеально подходит для прототипирования. У нас на серваках есть и Java, и Node.js сервисы. Я много лет пишу на Java, но вынужден признать, что многие вещи проще и быстрее сделать на Node.js.

Другое дело, если бы было время и деньги, то мы бы не использовали Node.js (:
Другое дело, если бы было время и деньги, то мы бы не использовали Node.js

А зачем? Если есть инструмент, который даёт тот же результат быстрее и дешевле, значит он оптимальнее? Это как Шаттл и Союз. Можно летать на Шаттле, но на Союзах оптимальнее.
Зависит от нагрузки. Для софт-ланча оно подойдёт. Но вот релизиться с нодой я побаиваюсь.
Мы и планируем её потестить на софт-ланче (да и остальные сервисы). Если нагрузку выдержит, то оставим )
Потому что прототип потом не придётся поддерживать. А рефакторинг большой системы на JS — это по моему опыту гораздо и гораздо больнее, чем сопоставимой системы на Java. В общем, как всегда — хорошо можно только одну вещь: или быстро делать или легко поддерживать.
JS — противоречивый язык. Он содержит как замечательные элегантные возможности, так и отвратительные, просто ужасные вещи.

Понять его мне помогли лекции и книга Дугласа Крокфорда, в которых он очень подробно и честно рассказывает о том, как появился этот язык, почему он стал популярным, что в нем есть хорошего и плохого (очень немногие рассказывают подробно о недостатках), почему так получилось и как жить дальше.

Лекции на youtube: Crockford On Javascript
Книга: Javascript: The Good Parts

Попробуйте посмотреть цикл лекций, затем прочитать книгу. Возможно, как и я, в них вы сможете найти ответы на ваши вопросы о JS.

монопольный стандарт на клиентский код в web

Нет монополии. Живые и энтерпрайзные: typescript и clojurescript.

что особенно хорошего в нем?

Изоморфизм же.
typescript это язык надстройка (superset), то есть это попытка сделать js не таким ужасным. Не было бы монополии js, не было бы typescript.

С clojurescript я близко не работал, но опять таки если бы в web`е можно было применять любой язык то наверное не было бы clojurescript, был бы просто clojure
чем вам как enteprise не угодили elm и coffeescript? тем более в es6 по ощущениям куча всего из coffee взяли
Безумная идея овладела Райаном Далом (Ryan Dahl) годы спустя: подружить движок V8 с библиотекой libev, дабы могли программисты выполнять свой JavaScript-код за пределами браузера.
Эта «безумная идея» была реализована ещё во времена того же Нетскейпа. Был их сервер, который это мог. Кроме того, был ASP (который не .Net ещё) и JScript, на котором достаточно активно (в России менее активно) клепались сайты.
Да, немного обидно, когда люди постоянно забывают про ASP :)
Превосходная иллюстрация того как история переписывает по незнанию.
Собственно, чем эти начинания кончились, все мы знаем. И слава богу.
Чем? Со временем JScript умер и всё. Он был нестандартный, не выдержал конкуренции. Ну и что? О чём это говорит.
«Но потом они передумали и решили, что Java хотят они. И вот, рождён был JavaScript. И было это (достаточно) хорошо.»

Как понять эту фразу? Java и JavaScript кроме четырёх букв ничего общего не имею же.
Java и JavaScript кроме четырёх букв ничего общего не имею же.
Неправда, порядок этих букв в названии тоже общий.
В следующем абзаце тоже ошибка — серверный JS как идея был почти сразу.
Просто реализация в тот момент не потянула
Лично я давно бы перешёл на JS для всего, если бы

1) Если бы был простой интерпретатор JS типа интерпретатора Lua или Python. Я не хочу, чтобы моё приложение было ни на что не способно без монструозного браузера или NodeJS. Почему бы тот же V8 не выпустить отдельно?
2) Если бы JS умел просто открывать файлы с диска без NodeJS. Отсутствие у него до сих пор этой функции в стандартной библиотеке — наследие браузерного окружения.
3) Если бы можно было создавать GUI-приложения без HTML+CSS. Т.е. привязки к Tk, GTK, wxWidgets… а может быть написать новую библиотеку, которая победит монструозный Qt? Надо кончать с браузерным прошлым и поскорее.

А пока JS вызывает у меня только раздражение как узкоспециализированный инструмент, который суют везде к месту и не к месту.
P.S. Заголовок статьи — ложь. JS _не_ универсальный.
Спасибо за наводку, конечно, но у меня ссылка фиолетовая.

В том то и дело, что лично я хочу пользоваться JS полноценно вне web-технологий. Без HTML+CSS, без браузеров. Мухи отдельно, котлеты отдельно. Ведь сам по себе язык очень симпатичный. Глядя на JS я мечтаю — вот бы Lua имел такой крутой JIT-компилятор, такую огромную базу библиотек и такое активное сообщество.
У меня симметричные мечты: хочется, чтобы JS, а не Lua, был языком игровых скриптов. Моддить лично мне стало бы гораздо удобнее)
Чем JS был бы удобнее LUA?
И почему именно JS, а не, например, ActionScript 3 (именно третья версия)?
Не хочу разводить холивар, просто для меня JS наиболее комфортен. Поигравшись с парой десятков языков и поработав на трёх из них, я нашёл в JS свой идеал.
1) Как раз из-за пункта №2. Ведь именно NodeJS добавляет те вещи, которые в других языках есть изначально.
2) Стоит понимать, что JS просто не может развиваться так же быстро, как и остальные языки, т.к. чтобы добавить новую фичу в язык производители самых популярных браузеров должны договориться, нужна ли эта фича и как она будет выглядеть. В других языках, например, выкатили новую версию и можно пользоваться. NodeJS можно считать немного отдельным языком. Сейчас наоборот, фичи из NodeJS добавляют в клиент-сайд (require, например) и библиотеки делают такими, что использовать их можно и на сервере и на клиенте.
3) Так можно же. Если я правильно понимаю, то Вы имеете ввиду это, это, это и это? Все это есть, но для десктоп приложений сейчас именно активнее всего развивается nw.js, о котором уже упоминали выше. Все дело в том, что как раз намного проще писать веб приложения для десктопа, т.к. опять же можно переиспользовать код с сервера или с сайта. Кроме того, дизайн приложения в таком случае можно делать очень гибким и делать его могут верстальщики, а не только программисты.

Я не считаю JS узкоспециализированым. Он и правда универсальный. Например, мне всегда не нравилось, что для валидации данных нужно по сути описывать одну и ту же логику на клиенте и на сервере (чтобы проверять все что можно не обращаясь к серверу и чтобы сам сервер не пропускал не правельные данные, если что). И в случае с JS на клиенте и на сервере это реально возможно и реально удобно. Одну и ту же систему валидации можно использовать и там и там.
1) node.js как раз для этого и создан. v8 и выпущен отдельно. Это просто JIT машина для js. Как JVM для java/scala/closure.
2) JS — это просто язык. В любом просто языке нет никаких функций, есть переменные, типы данных, арифметика, возможность объявлять функции, классы и тп. Node.js — это в том числе стандартная библиотека для JS вне браузера. На пример в node.js нет DOM Api, или localStorage. Потому что это расширения для языка внутри браузера.
Ну и возьмите C++, там нет библиотеки для работы с файловой системой, ну так, к слову.
3) Как минимум десяток таких есть. Более того есть библиотеки, которые также как node.js, или браузер прокидывают нативное api в JS. React Native/Nativescript.

Прежде чем делать громкие заявления — разберитесь в теме.
www.espruino.com это пример JS интерпретатора без привязки к браузеру. Причём там нет VM, только интерпретатор. Это конечно очень узкий пример ) Показывает, что такие вещи существуют.
Пройдет время и JS уйдет в забвение или останется в своей нише. Он существует довольно давно, но популярность получил только в последние годы — потому что взрывными темпами стала расти отрасль в которой он применяется, а не потому что он хороший. Все его фичи так или иначе присутствуют в других современных языках. Асинхронность — это не фича языка, а следствие того, что язык используется в среде, где доминирует событийная модель. Фреймворки для асинхронности есть во всех языках, просто из-за их более широкой ориентированности они там не так заметны. А что касается скорости — это просто следствие того, что из-за роста числа тяжелых приложений на JS у google и mozilla просто не оставалось выхода кроме как оптимизировать реализации языка в своих браузерах, вкладывая в это деньги.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.