IO.JS серверная реализация JavaScript
 

Оф. сайт https://iojs.org/

Текущее состояние IO.JS https://github.com/seegno/io.js/wiki...f-ES6-on-io.js

Релиз планируется 13 января.


Собственно, обсуждаем)

Это всё здорово, но мне бы ещё хотелось иметь нормальную стандартную библиотеку, а то получается, что сейчас нода - это кривой костыль, т.к. часть АПИ глючит, а часть откровенно не проработана, я уже молчу про скудность (нет даже работы с куками).

Потом, нужно внедрить новую модульную систему, чтобы писать код в едином стиле, как на клиенте, так и на сервер без костылей, в виде либ-трансорматоров.

И ещё для ноды нужно сделать опережающую поддержку Async-ов.

***

Что касается архитектурных реализаций: ноде нужна реализация потоков, причём провязка их через всё стандартное АПИ: на эту тему даже форк есть.

Вывод: работы ещё лет на 5 вперёд точно есть, но лучше бы, если развитие продукта взяла бы под крыло крупная фирма, навроде Гугла или Mozilla, т.к. сейчас развитие проекта идёт про Броуновское движению.

kobezzza,
да, сейчас у АПИ Ноды будет сильная ломка) Но я надеюсь на IO, у них релизы чаще => должны быстрее новые фичи внедрять. Модули я, наверное, больше всего жду)

что-то не совсем вкурсе, а что с node.js? И зачем нужен io.js, не проще ли дорабатывать node.js?

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

Кстати, а создатель node.js (Ryan Dahl) к кому примкнул?

dmitry111,
они кормят завтраками под названием 0.12, но пока только выпустили багфиксы к текущей стабильной версии.

Постарайся найти инфу в поиске. Если будет совсем уж сложно, тогда я тебе помогу.

Что значит "дырявая"? С чего ты взял, что Нода дырявая?

да я видел статью на хабре, что они там перессорились все и проект раскололся)



судя по отзывам:

Сам я с node.js работаю и меня особо не парит, что и где там хреново работает. Я просто использую рабочий функционал

Ну а мажорную версию делают тогда, когда весь функционал работает стабильно и ничего меняться и допиливаться не будет.

Поэтому не совсем понятно чего разработчики iojs хотят сказать своей мажорной версией. :yes:

Конкуренция - двигатель прогресса, а у ноды все конкуренты отвалились ещё на старте (всякие RingoJS и т.д.), поэтому хорошо, что теперь появился iojs.

dmitry111, утверждение, мол нода же работает, то значит всё норм - это подход ПХП прогеров, которые привыкли использовать свой костыль и не хотят видеть ничего вокруг.

Нода ужасна, я могу привести хренову тучу фактов, но думаю и так всем всё понятно, поэтому выделю самое главное:

1) Невероятно медленное развитие проекта;
2) Ужасно скудная стандартная библиотека (просто посмотрите стандартную либу Java - это небо и земля);
3) Архитектурные косяки, например, отсутствие потоков.

Есть небольшой шанс, что разработчики iojs смогут это исправить, поэтому держим кулачки.

ЗЫ: прежде чем нападать на меня с контр аргументами, учтите, что я 8 лет пишу на JS и из-них 3 года на ноде, каждый день 8+ часов, поэтому знаю о чём говорю.

было бы классно, если бы не пришлось переписывать проект под iojs.

хоть они и заявили о совместимости, всё может измениться

Поломка совместимости будет даже в самой ноде, т.к. многие АПИ ещё очень сырые, но то, что уже стабильно (например, костяк методов для работы с FS) вряд ли будут меняться.

Мне вот, например, не очень понятен смысл доменов, т.к. гораздо правильнее было бы запилить фьючерсы и использовать обычный try-catch, как это делается в других языках.

async function getData() {
  try {
      let data = await db.getData(...);

  } catch (err) {
      ...
  }
}

А вот такие простые вещи, вроде статик сервера, обработки куков или модуля принятия файлов через post нет Оо
Я понимаю, когда веб-фреймворк - это отдельный модуль, но есть элементарные вещи которые ДОЛЖНЫ быть в стандартной библиотеке.

***

Потоки: нет, серьёзно, меня тошнит от рекомендаций "используете setImmediate" чтобы не лочить поток, вот спрашивается, почему это нельзя инкапсулировать, как например я сделал это в Collection, а ещё лучше сделать реализацию Worker, чтобы была единая кодовая база с клиентом.

***

Графическая библиотека: почему модуль canvas не является частью стандартной библиотеки, особенно учитывая что он требует установки С либы Cairo.

***

Собственно поэтому я и хотел бы, что за ноду взялась крупная компания, т.к. она принесла бы систематический подход к инструменту, а не "о крутая фича, давайте запилим", как это делается сейчас.

dmitry111,
Не то что бы перессорились, просто одни хотят развития проекта, а другие не очень хотят)

Ну, как мне кажется, кобеззза имел в виду не столько уязвимости и бажность, сколько кривизну АПИ.


kobezzza,
:stop:
:(
:cray:
//как же мало тут смайлов.

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


melky,

хоть они и заявили о совместимости, всё может измениться

Так это только до первой версии



kobezzza,
Надо как-нибудь написать об этом в ишью к IO.JS)

Тоже был расстроен отсутствием канваса.

Баги тоже есть, например уже 100 лет висит тикет, о багах в файл вотчерах под виндой, но воз и ныне там.

Нафиг промисы, если в ES7 есть (да и сейчас на генераторах тоже) фьючерсы, т.к. промисы - это теже колбеки с своими проблемами, но в профиль.

Но некоторые вещи, например потоки ввода / вывода, лучше всего делать именно на колбеках.

Это только один пример, а почему нет стандартного нативного DOM парсера, почему нет поддержки веб-сокетов и т.д.

Почему, чтобы сделать простой статик-сервер я должен гуглить сторонний модуль, половина из который не работает без Express - бред.

В STD должны быть основные вещи, а модули должны расширять функционал, но в ноде это доведено до идиотизма, что на чистом STD писать просто анриал.

kobezzza,
А я то думал, что оно у меня как-то странно работало)

Ок. Просто я к тому, что эту, казалось бы, стабильную в плане API часть так же было бы не плохо улучшить.

Согласен. По хорошему нужно сесть и написать спеку для Ноды, где все как следует обдумать.

kobezzza,
это было бы круто, но, как ты и сам понимаешь, многое осложняется тем, что тот же ES6 ещё изменяется, не говоря уже о ES7, по этому "самодельничать" нужно осторожно.

Ну, для начала можно интегрировать ES6 модули, т.к. они уже получили статус готовности, затем заимлементить частично HTML5: canvas, worker, dom и т.д.

Почему нельзя было пойти путем PhantomJS, т.е. взять не голый V8, а chromium (в мечтах: Servo + SpiderMonkey :) ).

После этого добавить необходимые для серверных задач вещи: стандартный http статик-сервер, поддержку блобов в post запросах, работа с куками и т.д.

Только вдумайся: mime-типы и таблица HTTP кодов - это 2 сторонних модуля, кто это проектировал Оо Или они считают, что это не нужно...

kobezzza,
согласен. + если мы говорим о Ноде, то было бы не плохо, чтобы они плотнее взаимодействовали с сообществом.

Ссылку можно?

+1 Только хотел попросить ссылку:)

https://github.com/lukehoban/ecmascr...nd-parallelism

async function getData() {
  var items = await fetchAsync('http://example.com/users');

  // Внутри async асинхронные операции похожи на синхронные,
  // поэтому можно юзать try-catch для отлова исключений
  console.log(items);
}

Такой подход оч удобен и используется во многих языках, например С# или Go.

Юзать уже можно сейчас (но на свой страх и риск, т.к. стандарт может поменяться в любой момент), т.к. подобных механизм делается на основе генераторов, а 6to5 поддерживает эту фичу.

http://6to5.org/repl/

А можно юзать co (поддерживается вплоть до ES5 с помощью полифилов)

А ты уверен в терминологии?
В Python и C# Futures используется для параллельного запуска задач, мне кажется больше похоже на Promises (если не брать во внимание многопоточность), даже не так: Promises частный случай Futures получается.

async-await в ES7 это реализация на уровне языка следующей конструкции:

co(function * () {
    var result = yield request();
    result… //здесь можно использовать result;
});

подробнее про принцип работы co
будет:

async function () {
    var result = await request();
    result… //здесь можно использовать result;
}

await всегда ждет promise, сам yield не обладает никакой асинхронностью, это просто точка выхода, тут опять все завязано на промисах

Дык, никто не мешает в await скормить массив задач, которые будут работать параллельно (ну во всяком случае такое оч легко сделать), но наверн ты прав, это ближе к промисам, но промисы которые done right :)

Вообще я взял термин из Java

http://doc.akka.io/docs/akka/2.0/java/futures.html

Future<Integer> f2 = f1.map(new Mapper<String, Integer>() {
  public Integer apply(String s) {
    return s.length();
  }
});
 
int result = Await.result(f2, Duration.create(1, SECONDS));

А вот C#

public async void Foo() {
    int length = await ExampleMethodAsync();
}

***

Главное отличие от промисов в том, что мы избавляемся от ненужных функций и можем использовать try-catch.

Это всё понятно, но yield позволяет создать прерывание в текущем контексте, что гораздо удобнее промисов на колбеках. Похожий принцип я использовал в Collection, для реализации потоков http://jsfiddle.net/kobezzza/hut2jhL9/

Мне вот интересно что мешает в nodejs сделать нормальные потоки?

Религия :) Ну а вообще, смотря что считать нормальными потоками, ибо относительно Java в 90% языков нет нормальных потоков. Как по мне: добавили хоть какие бы.

Так нода же не только для www. Я бы и http в сторонний модуль вынес - нафиг он в каком-нибудь сборщике/компиляторе/игровом сервере?

Не в каждом приложении нужна математическая библиотека, предлагаешь тоже вынести?

Есть такое понятие стандартная библиотека, в которую должны входить все основные инструменты, с которыми может работать платформа. Посмотри, например, стандартную библиотеку Java - там несколько тысяч классов.

эти слова да девелоперам в уши
только хоть бы не получилось, как в php :)

Проблема PHP, что у него до сих пор нет спеки и общепринятых стандартов, а стандартная либа - это свалка в глобалспейсе с кастомными биндингами различных C-либ.

В JS, слава Богу, всё иначе.

Ну... логично, да, но тогда надо и для остальных основных протоколов нативные модули добавить.

Угу.

ну а у нас свалка в пакетах npm... зачем нужная хорошая STD, если можно засахарить API стандартных модулей и выложить это дело в npm? наверное, такой ход мыслей у иностранных коллег :write:

впринципе, это философия UNIX

проблема одна - избыточность и как следствие, тормоза. но последнего я пока не заметил, так что вангую в 2015 продолжение данного подхода*

*и очень надеюсь, что я ошибаюсь

Понимаешь, 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", но это чутка разные вещи

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