|
Цитата:
|
|
ну а у нас свалка в пакетах npm... зачем нужная хорошая STD, если можно засахарить API стандартных модулей и выложить это дело в npm? наверное, такой ход мыслей у иностранных коллег
|
Понимаешь, STD гарантирует стабильность и уменьшает энтропию, например, возьмём DOM парсеры, в NPM их вагон, но не один не следует спецификации, глючит и падает, а если бы в STD был нормальный нативный модуль, то никто бы даже не стал думать от создании такого модуля, т.к. нах не надо.
Касаемо NPM: свалка там только потому, что нет премодерации и любой может создать node.helloworld и добавить его в репозитарий и получается что 2/3 в npm - мусор, но с другой стороны - это не проблема, т.к. есть чёткая модульная система и система контроля версионирования.
Что же должно быть в репозитарии, а что в STD:
В STD должны быть базисные вещи, например, поддержка основных протоколов, поддержка основных транспортных форматов: JSON, YAML, XML и т.д. поддержка веб-сервисов: SOAP и т.д.
В репозитарии должны быть фреймворки и специфичные библиотеки, например, Express или Meteor определённо должны быть в NPM, а модуль Canvas должен быть в STD.
Никакой магии нет, опять приведу пример Java (знаю, что достал с ней, но в этом плане на неё должны все равняться): там офигенная STD, в которой есть всё для нормальной работы без сторонних модулей в принципе, но также есть центральный репозитарий Maven, из которого можно подтянуть дополнительные нужные фреймворки и либы.
Oracle хотели сделать node.jar (но вроде передумали, хотя хз), т.е. реализовать node-like фреймворк на JVM на основе своей JS VM - Nashorn и это было бы реально круто, т.к. с одной стороны мы пишем на JS, а с другой имеем нереально богатую библиотеку Java.