> Быстрый на какой задаче? Математику на нем считать? Ну да
> не быстрый. Это скриптовый язык общего назначения, адаптированный для 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-пилота бамбукового самолета.
> Куча эмоций в основном из-за непонимания, что создавать на нем С++-образные
> объекты и потом ныть, что язык кривой, как минимум, непрофессионально.
Я про это вроде бы нигде не возмущался? Или ты сам придумал и сам опроверг? :)
