> Быстрый на какой задаче? Математику на нем считать? Ну да
> не быстрый. Это скриптовый язык общего назначения, адаптированный для web-приложений.

Общего не получается: general-purpose алгоритм сжатия, видеокодека или чего там еще фиг сделаешь. Потому если браузер не умеет LZMA штатно - ну, гм, теоретически то декодер вроде можно сделать а практически - выглядит как ужас и работает так же. Генерал не не Пурпоз а Фэйлор.

> 2) "Он позволяет легко сравнить доски с шурупами и получить результат" -
> не он первый, не он последний.

Без н3гров и линчевок - отмазка будет не полная.

> 3) "В нем штатно нет ни модулей ни библиотек". Для загрузки модуля
> с жёсткого диска требуется наличие стандартной библиотеки,

На сях кстати не требуется. Можно хоть самому себе стандартную либу написать. Хоть это и будет системозависимо и такой уровень доступа к системе все-таки не для вебни. Но я не понимаю - а что, нельзя было сделать стандартный builtin у которого просишь модуль, а builtin разбирается как в своей имплементации дать, если модуль есть? Это слишком сложно и круто?

> которая изначально не была предусмотрена из-за web-специфики.

А что мешает в этом случае вгрузить модуль по URL с того же сервера что и остальной сайт? Некоторые так даже делают, но у них свои плагины/модули которые совместимы только с ними.

> Node.js как раз реализация, коротко говоря, там реализована функция,
> которая загружает модули с диска и кэширует.

И все бы ничего но в вебе это не работает.

> Принципиально другой подход - AMD в Dojo, например.

В результате есть какие-то "модули для dojo" и "модули для node.js". А когда кто-то захочет "распаковать данные сжатые LZMA" - они не могут на js взять библу для этого как сишники и парой вызовов сделать что хотели. Как максимум - можно прицепить 10 фреймворков ради 10 незначительных плагинов. Сайтик hello world начинает весить пять мегабайтов, поэтому пользователи не дожидаются окончания загрузки или ловят клин браузера и уходят.

> через очередную реализацию require? Откуда их грузить с файлухи клиента?

А вот пусть конкретная имплементация и разбирается - откуда. Нода с диска, вебня с урлы. Это слишком просто и логично? :)

> 4) И что имеется в виду под "Работать с бинарными данными"?

Ну вон сожми файлик LZMA. А теперь, допустим код утянул это с сервера в оперативку и хочет распаковать. Если в сях для этого подцепил либу да распаковал - на js оказывается что ложки нет. И либы нет. В лучшем случае есть мегакостыль с кучей проблем и ограничений на непонятных условиях лицензирования, в хучшем - сам такое пиши.

> Цеплять бинарные библиотеки или работать с бинарными буферами? И то и то
> работает, несмотря на то, что язык изначально не предназначен для работы с таким.

И то и другое работает, но опционально и через джеппу. Как и все остальное в js.

> IMHO_1 мода на JS и желание пихнуть его куда попало - это
> плохо. У него есть свои сильные стороны и у Node.js тоже.

Единственной сильной стороной которую я могу придумать: подсвечивает жеппоруких хистюков с кривыми проектами которые сдохнут через несколько лет, потому что майнтайнить их таки боль а js хотят использовать потому что резульат быстро и без усилий. На первый взгляд js такой и есть. Но внешность обманчива.

> IMHO_2 Javascript вызывает лютую ненависть у разработчиков C++, потому что синтаксис C-образный
> а семантика иная.

Попробуй пересадить КВС-а из эйрбаса А320 в бамбуковый самолет и послушай его мнение о летных качествах и умениях конструкторов этой штуки. Матерый плюсовик отличается от яваскриптера так же как КВС в эйрбасе отличается от wannabe-пилота бамбукового самолета.

> Куча эмоций в основном из-за непонимания, что создавать на нем С++-образные
> объекты и потом ныть, что язык кривой, как минимум, непрофессионально.

Я про это вроде бы нигде не возмущался? Или ты сам придумал и сам опроверг? :)