11.01.2015, 12:17
|
|
Быдлокодер;)
|
|
Регистрация: 19.11.2010
Сообщений: 4,338
|
|
Цитата:
|
ну а у нас свалка в пакетах 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.
|
|
11.01.2015, 13:03
|
sinistral
|
|
Регистрация: 28.03.2011
Сообщений: 5,418
|
|
Сообщение от kobezzza
|
Понимаешь, 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 - это немного другой мир, со своим Ынтерпрайзом. я предпочитаю её тихо ненавидеть
|
|
11.01.2015, 14:16
|
|
Профессор
|
|
Регистрация: 26.03.2012
Сообщений: 823
|
|
Сообщение от kobezzza
|
Ну, для начала можно интегрировать ES6 модули, т.к. они уже получили статус готовности, затем заимлементить частично HTML5: canvas, worker, dom и т.д.
|
а зачем нужен на сервере браузерный функционал? Или вы думаете, что кроме браузера node.js ни с чем использовать нельзя?
Самым лучшим решением было бы сдеать canvas, worker, dom в виде npm-модулей
|
|
11.01.2015, 14:25
|
|
Профессор
|
|
Регистрация: 23.12.2013
Сообщений: 1,856
|
|
dmitry111,
Цитата:
|
а зачем нужен на сервере браузерный функционал?
|
Он имел в виду одинаковое API как на клиенте, так и на сервере.
Цитата:
|
Или вы думаете, что кроме браузера node.js ни с чем использовать нельзя?
|
Разумеется можно, но это не значит, что его нужно как-то ограничивать.
|
|
11.01.2015, 14:47
|
|
Быдлокодер;)
|
|
Регистрация: 19.11.2010
Сообщений: 4,338
|
|
Цитата:
|
а зачем нужен на сервере браузерный функционал? Или вы думаете, что кроме браузера node.js ни с чем использовать нельзя?
|
Во первых: единое API;
Во вторых: в каком месте это браузерный функционал?
Работа с графикой, потоками и XML должна быть в любой нормальной платформе общего назначения, коей нода пытается стать.
Цитата:
|
Самым лучшим решением было бы сдеать canvas, worker, dom в виде npm-модулей
|
[сарказм]Угу, ещё круто бы сделать переменные и арифметические операции отдельным модулем![/сарказм]
Последний раз редактировалось kobezzza, 11.01.2015 в 14:50.
|
|
11.01.2015, 15:19
|
sinistral
|
|
Регистрация: 28.03.2011
Сообщений: 5,418
|
|
Сообщение от kobezzza
|
[сарказм]Угу, ещё круто бы сделать переменные и арифметические операции отдельным модулем![/сарказм]
|
почему canvas не должен быть отдельным модулем?
и не обязательно
Сообщение от kobezzza
|
в виде npm-модулей
|
можно сделать как сам npm - он одновременно и встроенный, и есть в npm
... или ты это и имел в виду?
Сообщение от dmitry111
|
а зачем нужен на сервере браузерный функционал? Или вы думаете, что кроме браузера node.js ни с чем использовать нельзя?
|
хотя бы ради того, чтобы убрать гемор тестирования фронтенда
Сообщение от Safort
|
Разумеется можно, но это не значит, что его нужно как-то ограничивать.
|
хоть бы не получился пузырь вроде X server или systemd
Сообщение от kobezzza
|
Работа с графикой, потоками и XML должна быть в любой нормальной платформе общего назначения, коей нода пытается стать.
|
поначалу не было такой цели, как я помню... это всё node-webkit да atom-shell задали моду
Последний раз редактировалось melky, 11.01.2015 в 15:23.
|
|
11.01.2015, 15:28
|
|
Быдлокодер;)
|
|
Регистрация: 19.11.2010
Сообщений: 4,338
|
|
melky, по ряду причин:
1) Это базовое API;
2) Это нативный модуль, который требует дополнительной установки С/С++ либ, которые ставится по разному под разные ОС, добавляет геморой при деплое на хостинг и т.д.
3) Если модуль является частью STD, то это гарантирует его стабильность и поддержку (документация, инфа в книжках и т.д.).
Цитата:
|
можно сделать как npm - он одновременно и встроенный, и есть в npm
|
Так сделать можно, но, зачем?
***
Я не понимаю ваших мотивов, приведите факты почему вы против нормальной STD?
|
|
11.01.2015, 15:32
|
|
Профессор
|
|
Регистрация: 26.03.2012
Сообщений: 823
|
|
вы не сравнивайте это:
Сообщение от kobezzza
|
Работа с графикой, потоками и XML должна быть в любой нормальной платформе общего назначения, коей нода пытается стать.
|
и это:
Сообщение от kobezzza
|
[сарказм]Угу, ещё круто бы сделать переменные и арифметические операции отдельным модулем![/сарказм]
|
|
|
11.01.2015, 15:47
|
|
Профессор
|
|
Регистрация: 24.09.2013
Сообщений: 1,436
|
|
Цитата:
|
Цитата:
|
можно сделать как npm - он одновременно и встроенный, и есть в npm
|
Так сделать можно, но, зачем?
|
Чтобы не толпиться в одном репозитории?
|
|
11.01.2015, 15:54
|
sinistral
|
|
Регистрация: 28.03.2011
Сообщений: 5,418
|
|
kobezzza, до меня допёрло, что мы говорим об одном и том же мне почему то показалось, что ты хочешь запихать canvas в интерфейс global.Canvas, и поэтому я предлагаю его запихать в отдельный модуль, как и обычный функционал node - см. модули fs, os, path ... а ты скорее всего подумал, что я имею в виду под "отдельным модулем" "модуль из npm", но это чутка разные вещи
Сообщение от kobezzza
|
Так сделать можно, но, зачем?
|
изолировать ядро от обвеса
|
|
|
|