Понимаешь, 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.

ну, хорошо что у нас есть на кого равняться
с другой стороны, платформа Node.js очень молодая
думаю, что стоит подождать ещё годок-два и мы придём к нормальному рабочему инструменту, который пестрит у нас в имени темы


насчёт Java - это немного другой мир, со своим Ынтерпрайзом. я предпочитаю её тихо ненавидеть :)

а зачем нужен на сервере браузерный функционал? Или вы думаете, что кроме браузера node.js ни с чем использовать нельзя?

Самым лучшим решением было бы сдеать canvas, worker, dom в виде npm-модулей

dmitry111,
Он имел в виду одинаковое API как на клиенте, так и на сервере.

Разумеется можно, но это не значит, что его нужно как-то ограничивать.

Во первых: единое API;
Во вторых: в каком месте это браузерный функционал?

Работа с графикой, потоками и XML должна быть в любой нормальной платформе общего назначения, коей нода пытается стать.

[сарказм]Угу, ещё круто бы сделать переменные и арифметические операции отдельным модулем![/сарказм]

почему canvas не должен быть отдельным модулем?
и не обязательно
можно сделать как сам npm - он одновременно и встроенный, и есть в npm

... или ты это и имел в виду?
хотя бы ради того, чтобы убрать гемор тестирования фронтенда
хоть бы не получился пузырь вроде X server или systemd :D
поначалу не было такой цели, как я помню... это всё node-webkit да atom-shell задали моду

melky, по ряду причин:

1) Это базовое API;
2) Это нативный модуль, который требует дополнительной установки С/С++ либ, которые ставится по разному под разные ОС, добавляет геморой при деплое на хостинг и т.д.
3) Если модуль является частью STD, то это гарантирует его стабильность и поддержку (документация, инфа в книжках и т.д.).

Так сделать можно, но, зачем?

***

Я не понимаю ваших мотивов, приведите факты почему вы против нормальной STD?

вы не сравнивайте это:

и это:

Чтобы не толпиться в одном репозитории?

kobezzza, до меня допёрло, что мы говорим об одном и том же :) мне почему то показалось, что ты хочешь запихать canvas в интерфейс global.Canvas, и поэтому я предлагаю его запихать в отдельный модуль, как и обычный функционал node - см. модули fs, os, path ... а ты скорее всего подумал, что я имею в виду под "отдельным модулем" "модуль из npm", но это чутка разные вещи

изолировать ядро от обвеса