Потоки исполняются в одном реальном потоке. Модель потоков примерно такая же, как и в одноядерных системах: т.е. задачи делятся на кванты и потихоньку выполняются. У задач есть приоритет, который определяет выделяемые ресурсы и шанс того, что задача попадёт на исполнение в данной итерации событийного цикла, а рулит всем - планировщик потоков.

Плюсы легковесных потоков Collection:

1) Они гарантируют, что сколько бы потоков ты не создал - ты не залочишь главный поток.

Т.е. допустим у тебя сервак на ноде, и у тебя есть синхронная задачка, например, валидация файлов, а файлы большие, то ты рискуешь занимать слишком много времени главного потока и от этого пострадают твои пользователи. Тебе придётся руками дробить задачу на setImmediate и делать кусочками, а твой код превратится в какашку. С Collection тебе просто думать об этом не надо, завернул задачу в поток и всё, а т.к. потоки реализует интерфейс промисов, то с async/await твой код остаётся синхронным. Задач миллион.

Пример на клиенте: у тебя сложный СПА, куча виджетов который что-то там делают и в какойто момент времени их совместная деятельность начинает фризить UI, ну например, у тебя есть селект с автокомплитом и список данных на пару тыщ элементов и ты делаешь поиск по мере заполнения, а т.к. по мимо этого виджета у тебя там целое приложение, которое живёт своей жизнью, то фризы по 50-100 мс вообще обычное дело, но они заметны и это реально напрягает. С Collection ты вообще не думаешь много данных или нет, просто оборачиваем узкое место в поток и всё, никаких фризов.

2) Async-flow

Collection предоставляет API для создания дочерних потоков (потоков в потоке и т.д.), а также поддерживает промисы, что позволяет ловко манипулировать асинхронными потоками данных без награмаждений в коде.

$C(['file1.json', 'file2.json']).thread().reduce(async (map, file) => Object.assign(map, await fs.readFile(file)), {})

3) Доступ к переменным замыкания и DOM.

Тут конечно спорный момент, ибо легко сделать гонку :D Но при аккуратном подходе - это удобно.

4) Потоков может быть много: если Worker-ы ограничины на вкладку (по моему не больше 15 или 20-ти), то потоков Collection можно создавать пока память не кончиться) На практике это сотни тысяч.

Минусы:

1) Скорость - потоки заоптимизированы на неблокирующее выполнение, но при этом страдает скорость, т.к. всё в одном реальном потоке.

2) Можно легко устроить гонку.

***

В общем относится нужно к таким потокам, как к очень удобной абстракции.

Готовлю новый бета релиз Collection 6. Из главных нововведений - это поддержка промисов на уровне самого Collection, т.е. теперь можно делать асинхронные фильтры:

$C(...)
  .thread()
  .filter(async () => await doSomething())
  .filter(async () => await doSomethingAgain())
  .map(...)

А также появилась поддержка нового типа данных - асинхронная коллекция. Теперь если Collection работает в режиме потока и элемент итерируемой коллекции является промисом, то Collection будет ожидать его выполнения.

Реальный кейз: читаем в NodeReadable потоке огромный файл и сразу по мере получения данных отдаём в Collection, который их как то мапит и т.д. Экономия памяти и универсальность интерфейса.

kobezzza, т.е ты по сути розбиваешся каждую задачу на отдельный setImmediate?

Да, никакой магии. Есть допуcтим forEach с приоритетом normal: за один раз он может потратить не более 10 мс, поэтому после каждой итерации я сравниваю затраченное время и если оно уже превышает лимит, то делаю yield, т.е. всё операция обёрнута в генератор, а со следующего итерационного цикла, если задача конечно туда попадёт по приоритету, продолжу с места, где закончил.

Всего за один так событийного цикла Collection тратит не более 40 мс.

kobezzza, спасибо, интересно))

kobezzza,

$C(document.querySelectorAll('.foo')).forEach((el) => {
  ...
}

почему не написать так ?

HTMLCollection.prototype.forEach = NodeList.prototype.forEach = Array.prototype.forEach;
// ................
document.querySelectorAll('.foo').forEach((el) => {
  ...
}

то-же самое с get, map
как по мне без $C выглядит красивее, переопределив прототип

Poznakomlus, определение методов в прототипе для встраиваемой функциональной библиотеки не самая лучшая идея, особенно учитывая что Collection поддерживает работу с Object, Map, Set, TypedArrays, Array, Generator и Promise.

В TS и JS stage-0 есть более правильные способы:

function forEach(cb, params) {
  return $C(this).forEach(cb, params);
}

[1, 2, 3]::forEach(() => {
   ...
});

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

Poznakomlus, в Collection есть разные плюшки, один из примеров http://javascript.ru/forum/project/4...tml#post422959

А где модель потоков с использованием динамически созданных worker? :)

Потоки Collection платформонезависимы (т.к. имплементятся исключительно силами языка) и легко работают внутри Worker. А создавать какуе то специальную абстракцию ради этого - идиотизм.

Poznakomlus, из того что я помню воркеры в ноде не работают

Есть плагины, которые добавляют этот функционал. Но суть не в этом. Никто не запрещает юзать потоки Collection внутри каких либо "настоящих" потоков или процессов, будть то браузер или нода, или ещё кто.

Например в Nashorn есть потоки, т.к. он использует Java, а там с этим всё оч хорошо.

Реализация многопоточности на фронте - идиотизм? :(

Она уже есть. Идиотизм создавать ненужную абстракцию.

2 или 3 года назад, когда я впервые реализовал потоки на генераторах, я писал заметку:

Ок уговорили потестим в свободное время :)

Опубликовал beta.9

Выпустил beta.11

Появился новый метод .extend (который делает расширения объекта другими). Метод заменил собой статический метод $C.extend (но ссылка для удобства осталась). Также метод теперь поддерживает расширение Map и Set при глубоком копировании, а сам обход копируемого объекта теперь делается с помощью $C forEach, поэтому стали доступны все его параметры.

kobezzza,
не нашел документацию, ссылки на вики не работает

Это бета, дока будет как только у меня появиться время на неё. Думаю это произойдёт в августе.

kobezzza,
спасибо, ясно..

Кстати, тоже с java)
Сделал как java stream?)

Да не, тут просто делал по аналогии с библиотекой Async, только для промисов :) Хотя сходство с java stream есть, но никакой совместимости по API нет )

kobezzza,а)
А вообще есть что из java можно взять в js)
На java приятно писать)

Java, имхо, слишком многословна :) А взять можно много чего, да :) А вообще в Java из коробки есть неплохой JS, который можно юзать из Java и наоборот и есть оч крутой фреймворк, который позволяет также писать веб-сервера на JS в Java (вообще он поддерживает кучу языков), с прикрученым бабелем :)

http://vertx.io/#ws_js
http://vertx.io/docs/vertx-core/js/

По архитектуре похож на ноду.

Вопрос: Зачем?)
Если нужна java, то почему сразу не взять java?
Единственая проблема которая у меня была это websockets, хотя больше фанат ноды, но на работе back-end на java и пришлось учится)

kobezzza,
Наступит день, наступит час и количество скачиваний у collection.js будет больше чем у lodash.
Lodash
Подозреваю, что этот миллион не знает о существовании collection? :)

Java многословна и в вопросах ФП у неё много гемора, поэтому и появились Scala, Groovy, Ceylon, Kotlin, Clojure и т.д.

Всё JVM совместимые языки (будь то Jython или Kotlin) компилятся в Java байткод, поэтому они спокойно юзают модули Java и написанные на других JVM языках, тут вопрос именно удобства.

До появления Java8 в жабе даже лямбд не было :)

Я не пиарюсь, не пишу статьи и т.д. Мне всё равно юзают или нет - я пишу для себя. Если отбросить предрасудки и трезво ответить на вопрос что же лучше? То ответ однозначен:

1) Collection поддерживает все возможные виды данных и итераторов JS;
2) Collection поддерживает работую в асинхронном режиме и режиме потока;
3) Collection по скорости равен нативным циклам за счёт хитрой компиляции;
4) Все итеративные методы collection поддерживают огромный набор параметров, которых в lodash впринципе нет;
5) Collection реализует монады, т.е. цепочка методов выполниться в один проход.

Кстати, в последней версии добавил поддержку потоков чтения (интерфейс потоков ноды).

await $C(fs.createReadableStream('./big.txt')).async.map((chunk) => {
  ...
});

kobezzza,
Ну вообще это прикольно, что разрабатывая свои проекты, появляются полезные инструменты, которые доступны другим разработчикам для использования за "спасибо". Плохо только, что пиара как раз таки нет. О Collection я узнал минут 30 назад, нечаянно наткнувшись на эту тему. О Snakeskin - прочитав твою и trikadin статью на хабре, кстати до сих пор продолжаю юзать :)

Может где-то есть список всех бесплатных полезных инструментов, твоей разработки?

Я иногда пишу статьи и выступаю, но в российском комьюнити всем интересны только Gulp vs Grunt и React vs Angular :) Но перевод на инглиш я планирую, просто времени не хватает.

Приятно это слышать :)

https://github.com/kobezzza :)

Также следует отметить организации, в которых я состою, т.к. Snakeskin или Monic вынесены в отдельные организации для удобства поддержки.

А так из актуального и открытого список не оч большой:

https://github.com/SnakeskinTpl
https://github.com/MonicBuilder
https://github.com/kobezzza/Collection
https://github.com/kobezzza/Escaper

Планирую в августе или сентябре заопенсорсить свою платформу: https://github.com/kobezzza/Henchman
Это будет UI библиотека (с большим набором встроенных компонентов) для разработки SPA на Vue2, Snakeskin и т.д. А также каркас для Koa2 для node.js. Платформу я пишу для коммерческих проектов уже довольно давно, но сейчас появилась возможность (разрешение) её опубликовать.

kobezzza,
ок, запомним)

kobezzza, ссылки
и
на документацию ведут на индексную страницу репозитория

Можно натравить генератор документации, если хочется документации)

kobezzza, для бейджей npm, downloads, dependencies поставь ссылки на npm по примеру того, как у меня сделано или хоть в том же koa. Это удобно)

nerv_ Доки по новой версии в принципе нет (вернее отличная дока есть в самом коде), всё никак руки не дойдут.