This looks great, but it's important to bear in mind the architecture you intend to run on. I recently made an application blazingly fast by - among other things - parallelization using the node cluster module. On my 4-core laptop it flies. Imagine my surprise when I deployed to the cloud environment and found the typical virtual server in our cluster has only a single CPU core. The worker threads just sit around waiting for their turn to run, one at a time. On the other hand, the platform for serverless functions has 8 cores. At a minumum, before you jump into multi-threading, know what `require('os').cpus()` tells you on your target platform.

An alternative approach to concurrency is the one that Erlang (and your operating system) take: memory-isolated processes, preemptively multi-tasked, where neither IO nor computation in one process can adversely affect the others because the scheduler prevents it.

I wrote this up: https://news.ycombinator.com/item?id=15499629

You can get rid of the need to multi threading by deploying more containers in the same machine or via orchestration.

I don't understand why people keep insisting that the lack of multi threading support is a Javascript problem when there are better and more scalable ways of using your machine resources.

I will circle back in a year or so to see if this 'sticks' -- very few Microsoft open source projects provide enough value / demonstrate enough inertia this early in their lifecycle to justify any investment on my part.

https://github.com/MicrosoftArchive/redis/issues/556 (Jun-Sep 2017)

>Why do MS always do this??? Start something, announce it aloud "we are now open source, we are now this and that blah blah" then quietly do a 360 and moonwalk away

Looks almost the same as something using fork and message passing, which also scales over several machines. The examples should show use cases that use shared memory or examples where it wouln't be possible to use worker processes.

Here is why napajs is started: https://github.com/Microsoft/napajs/wiki/Why-Napa.js

This is far from the first attempt to do bring multithreading/parallelism into JS. A (failed) example:

https://en.wikipedia.org/wiki/River_Trail_(JavaScript_engine...

Another attempt (although a different approach) is here : https://github.com/tc39/ecmascript_sharedmem

Hopefully, Microsoft will learn from the errors of others. Interestingly, napa is build on V8, not on MS own javascript engine.

Nice, but:

1. It is exposed as a nodejs module, but some other modules may be at conflict because they may wrongly assume that they are the only thread running. E.g., some modules may be using global variables in C++.

2. Still, it doesn't support fast immutable communication (structural sharing) to other threads through shared memory.

One of the great practical examples of this repository is to serve as a counter-argument against people, who complain that NodeJS is not multi-threaded.

For anything else, IMHO the use-case will be so narrow, that I wonder how MS will justify the development resources for maintaining it.

I know that the history of projects at a giant company isn't always straightforward, but it's interesting that they chose V8, even though Chakra is maintained by the same company (and supports Node APIs).

I think this could be useful but I really hope they get it right (especially the broadcast and other cross-worker communication features). Right now it looks like the broadcast feature cannot target specific workers - That's already a red flag. If they push too hard on thread locking and data consistency across workers, then it's not going to scale and it may lose all the advantages of being able to run on multiple CPU cores.

I'm excited. My friend is working on extending rpgmaker, a game engine built on node. Say what you will about building a game engine on top of Node but this could be a very useful way to offload CPU heavy tasks from the main render thread

Any informed commentary on the pros/ cons of this vs cluster?

As far as I can see, cluster workers are all uniform (no task-specific pools) and cluster has no broadcast (just `worker.send(message)`.)

This looks very similar to the concurrency and isolation patterns of the Dart VM.

"Use Isolates for secure, concurrent apps. Spawn an isolate to run Dart functions and libraries in an isolated heap, and take advantage of multiple CPU cores." -- https://dart-lang.github.io/server/server.html

This is interesting. I see some negativity in the comments, but I think this was really a missing piece of the Node ecosystem, and I hope this solution ends up getting good adoption. On a slightly related note, I wonder if ClojureScript + Node would be the best way to take advantage of this. Has anyone here used ClojureScript with Node?

One of the reasons npm modules are largely compatible with each other is the fact that they share the same threading model, which is what the event loop offers.

Then, this has a lot of compatibility issues, and release-wise it will be hell. I don't think this is a good idea.

This looks a lot like web workers, which Node.js does not have. Hopefully they will add it. https://github.com/nodejs/worker/issues/2

It makes you wonder why they choose V8 instead of their own JavaScript engine

https://github.com/Microsoft/ChakraCore

What does this give you over using fork in node? The zone concept seems nice but I'm not understanding why I would use napa when node is designed to easily spawn nodes of parallel execution?

I was expecting something like this for a long time. Thanks!

I dont think JavaScript needs threads.

Is this multi threaded Node workers that can only share read access to their parent process' pid?

Can we please stop calling things ".js" if they are not actually JavaScript files or libraries written in JavaScript meant for direct inclusion in JavaScript source? Call it NapaJS, not Napa.js.

How does it compare the (discontinued) JXCore?

Sounds great! Now, We can make memory efficient Electron with this kind of runtime. It will make JavaScript to be used in creating desktop application more reasonable.

undefined

This is good however IMO if you need parallelism you should not use node period.

Shared memory!

undefined

undefined

Took long enough for threads to reach JS as well

Wait what? Why are they getting rid of simplicity and model that just works. Once again Microsoft managed to put on some C# programmers on JS. The first thing they thought was why doesn’t it support threads! Let’s build thread support and get a promotion!

Edit: I would question usage of Node if everything you are doing is CPU bound. I think people started down-voting me without going through docs, I mean just read this documentation page and tell me this is right https://github.com/Microsoft/napajs/blob/master/docs/api/mem...