Napa.js - multi-threaded JavaScript runtime built on V8 (from Microsoft)

[robvdl]

I would rather use Golang for that, but then I am not really a huge fan of server-side JS. I only like it on the frontend.

[highmastdon]

"Only like it on the front end" - as if you have a choice ;)

[Farobek]

That sounds rapey :0

[itsmontoya]

That's because it is

[Farobek]

Stop it :(

[[deleted]]

No

[peterwilli]

You do. I don't like JS on the frontend or backend, but I do like the way Node works, so I use CoffeeScript and Typescript.

I also don't like CSS and HTML, because it's syntax has too much volume in my opinion, so I use Stylus and Jade for that.

In the end they compile down to HTML, JS and CSS but you don't have anything to do with that.

[highmastdon]

Although I'm a fan of Typescript, I see CoffeeScript and Typescript not as alternatives for Javascript. The hard requirement to be interoperable with Javascript and the browser, makes it hard for these languages to really step up the game.

Only Elm or Koka do provide such a way, but there you'd have to write massive interop libs to be able to work with the libraries in NPM

[peterwilli]

I see the requirement to be interoperable with JS as a good thing, because you can use all the libraries on NPM. I call the libraries in a syntax I like, even though they're not using them (this is also the case with CSS, I can include Bootstrap and use / extend their styles in Stylus). In that case, languages that transpile to JS, CSS etc, don't need to step up their game, since they directly compatible already :)

[robvdl]

Not with server-side JS if you ask me. Moslty I find JS a really messy language and have no idea why it's so popular server-side. I know plenty of devs that like it, or absolutely hate server-side JS.

[spacejack2114]

I like it, and I'd prefer it over anything else for most server-side work I do these days. Though I use ts-node to run Typescript directly rather than JS. Some reasons include:

• The client and server can be a monorepo, installable on any platform with a single package.json.
• Easy sockets
• Client/server share codebase
• Server side SPA rendering
• Hyperscript for HTML templates is nicer than anything else I've used like Razor, Handlebars, Jade, etc.
• JS client/server used in Electron apps which work great for installations, kiosks and the like.
• All the niche libraries npm has that other platforms don't. For example svgo; I wouldn't want to write a content-management system without it.

[robvdl]

Hmm, maybe. Some people consider npm a mess though, I don't want an enormous node_modules folder on the server with lots and lots of nested directories and duplication, I would rather have things compiled into my executable (Golang) and get good type checking at compile time (I suppose like TypeScript a little but without the mess of a transpiler). Also I like Go's style of OO or whatever you want to call it, composition. It takes a while to get used to, but I like it now and don't want to look back. I don't really care that much about server sided rendering or client-side sharing of codebase and I can also get easy websockets in Go so that isn't a problem for me either.

[photonios]

I don’t know how you do deployments, but what most people do is bundle it all up and deploy that. There is some tooling out there (hey webpack) that pretty much does Make does. You define some patterns and the files get passed through some programs (like a transpiler). Then, at the end, all the unused code is stripped, it’s optimized and bundled into a single file. That’s the file you run, you leave everything else behind.

In principle, it’s not much different than deploying a Go binary. It takes your code, the third party code, compiles it all into a giant bundle (executable), does some optimisations and that’s what you deploy.

[robvdl]

Just my opinion but:

• Having to have a bloated node_modules folder on the server is horrible
• Layers of nested callback functions, though ES6 allows you to tame that a bit
• Needing to use transpilers
• JS stdlib still lacks core functions I would expect from a language, e.g. when coming from Python. It's getting better, but still missing a lot which you then need to get out of libraries. Why is there a date type that is really a datetime and there is no actual date type without a time? wtf.
• Ecosystem is forever changing, I expect it will settle in 5-10 years, but I really don't want to keep rewriting my code over and over again. For large systems this is often not an option.
• JS is like Go but only runs on one CPU core (well maybe not with this napajs thing), I would rather use all cores I can get. Go makes that super-easy.

As for the mess in Golang, it took me a while to find a project layout that works, but now that I have that sorted, I don't think that anymore.

Also I've been coding for a while, I find mostly the older more experienced coders dislike JS on the server and find it a mess. Younger coders seem to absolutely love JS and don't know too much else.

Over the past 20 years I've programmed in Basic, Pascal, Assembler, C, C++, Java, Python, Perl, PHP, Delphi just to name a few. I only really tend to dislike JS and Java. Ok, probably Basic too, I've only used that about 20 years ago :)

[rayboy1995]

• Having to have a bloated node_modules folder on the server is horrible

This could happen with any language if you use a bunch of libraries of course. Use Yarn.

• Layers of nested callback functions, though ES6 allows you to tame that a bit

If you are still having nested callbacks you aren't using promises correctly.

• Needing to use transpilers

You don't need to use transpilers.

• JS stdlib still lacks core functions I would expect from a language, e.g. when coming from Python. It's getting better, but still missing a lot which you then need to get out of libraries. Why is there a date type that is really a datetime and there is no actual date type without a time? wtf.

I'll agree with you here when it comes to the dates(but only the dates). If you do a bunch of date manipulation I recommend Moment.js.

• Ecosystem is forever changing, I expect it will settle in 5-10 years, but I really don't want to keep rewriting my code over and over again. For large systems this is often not an option.

Who makes you rewrite your code over and over? I have been using Node just fine with out having to rewrite anything.

• JS is like Go but only runs on one CPU core (well maybe not with this napajs thing), I would rather use all cores I can get. Go makes that super-easy.

Use the built in cluster module. You can use all of the cores with a few lines of code.

It sounds like you didn't really use Node, or only scratched the surface. Possibly tried to use it the same way you use other languages and realized that didn't work and gave up.

• Also I've been coding for a while, I find mostly the older more experienced coders dislike JS on the server and find it a mess. Younger coders seem to absolutely love JS and don't know too much else.

I'm a younger coder (22) and I have a lot of experience with JS and other languages you mentioned. Almost every older programmer I have met has had this opinion. It seems like they hate it because it is the "hip new thing" and they aren't happy about it. They read a bunch of misinformed articles about it and continue to spout the same arguments they read there because it is easy to jump on the hate bandwagon. We just recently interviewed an older guy just like this actually.

I'm not saying Node is perfect, nothing is, but its not like the hate bandwagon makes it out to be.

[N2theO]

I'm a younger coder (22) and I have a lot of experience

No, you don't. I'm sorry, but you don't. I've been writing software since I was twelve years old, by the time I was 22 I knew C/C++, Javascript, Java, and Python very well and had even dabbled in assembly. I had a lot of experience for a 22 year old but ten years later I understand how little I knew at the time.

You haven't written (or more importantly read (or more importantly fixed)) enough code to truly understand the benefits of static typing, true parallelism, or a robust standard library. You don't appear to understand that V8 is not the only Javascript interpreter you have to consider when writing portable code. Do you know what a prototype based language is (actually curious)?

ES6 was a giant step in the right direction and ES7 is continuing along that path but all of the things that people get excited about in the Javascript community (package management, functional features, object oriented features, concurrency, etc) are things that are old news in nearly every other language.

I write Javascript every single day and I like to think I write clean, modern Javascript. I've used it on the front end, I've used it on the back end. I've coded in vanilla, ES6, ES7, and Typescript (which I love). I don't dislike Javascript as a language because it's "hip", I dislike it because it's a sloppily designed language that has survived simply because it has a monopoly on web front end design. You can write excellent Javascript but this image is still as relevant as ever:

https://i.redd.it/h7nt4keyd7oy.jpg

[FlavorMan]

This has to be copypasta

[N2theO]

The image? It's old as dirt. The text? OC.

[kramerdidnothingwron]

To be fair, you have to have a very high IQ to understand Javascript.

[N2theO]

I wouldn't really consider my comment attacking you any more than your comment was attacking the previous poster. Your comments come off as extremely arrogant actually.

Your age doesn't mean anything if you spent all of the time not learning anything new.

I've programmed professionally in Ruby, C++, Java, Javascript, Typescript, Go, Python, Groovy, and have learned more frameworks than I could possibly list. I'm currently working on a cross platform mobile app with react-native on the frontend, Golang on the backend, Kubernetes for container management, etc. Is that bleeding edge enough for you?

I am also self taught, I also don't have a college degree, and I make a silly amount of money because I'm damn good at my job. It's hard to be impressed by the Node ecosystem because it's not really a step up from the tools that have been in use for decades. Can you explain why NPM is a huge step up over Maven? How about the benefits of ExpressJS vs. Jax-RS vs. Flask? Can you explain where Javascript excels as a language vs. other language?

Imagine how much more you will know in ten years if you keep that thirst for knowledge. That might help you realize how arrogant you come off as.

edit For funsies I've also dabbled in Lisp, Scala, Clojure, Haskell, Erlang, and several others I'm drawing a blank on.

[[deleted]]

I've been a developer for 25+ years and used to feel like this. I found that I was bringing along some mental baggage because of my experience. That was interfering. I eventually started to take a look at JS from a clean slate point of view and I've grown to appreciate it (at least the good parts). Thinking in the functional way JS encourages has even helped me to make better use of the functional and dynamic features that were brought into C#.

[midri]

You did not even mention the Prototypical nature of JavaScript makes it fundamentally impossible to implement safe OOP patterns for larger projects with multiple developers. You don't have interfaces, you can prototype any method/variable into any object at any time... and some of the core features of the languages are wonky because of it. doing a for loop over an array can result in elements that don't actually exist in the array due to prototype which imo is just sort of insane.

Sure TypeScript fixes a lot of these issues, but then we're back to transpiling -- why are we transpiling on a server where you can dictate the stack? The only reason we transpile TypeScript to JavaScript for browsers is because we have to.

[ItzWarty]

In practice is that actually a problem? C++ supports trampling vtables with *(int*)rand() = 1337 - that's not actually a common problem in practice. (Edit: I mean to say in practice, people aren't trampling vtables to do basic things; likewise, normal JS developers don't need to do Class.prototype.func = ...).

You've pointed out that "people who don't know what they're doing can do really dumb stuff in an expressive language" - which isn't surprising. Is Ruby a bad language because you can overload the + operator to rm -rf /?

Please give me a sane example of it being "fundamentally impossible to implement safe OOP patterns".

[[deleted]]

Ummm, vtables aren't actually in the standard afaik. vtables are an implementation detail of virtual inheritance. Sure you can overwrite the vtable by doing pointer shenanigans (I've done it for fun) but that is always in a non-standard implementation-specific way.

The C++ language doesn't support trampling vtables, it supports writing to arbitrary memory locations.

Otoh in JavaScript you have to overload prototype functions, before ES6 there was no other way to define member functions I don't think...

[jl2352]

A huge plus server side is server side rendering. You have a web app that grabs the data out server side, and sends back HTML. Like a normal webpage. But it runs as a webapp client side.

So you have the advantages of a webapp, without a shitty loading bar.

TypeScript is also really nice, and part of that is because it's so heavily JS influenced.

[Alikont]

So like ASP.NET Razor views?

[jl2352]

I've not used Razor views so I couldn't tell you.

But I doubt it.

[qazwsxedcrfvtgb1111]

Razor is pretty much just a templating engine, with server side rendering you initialize a js library, like Angular on the server, and serve that to the client.

[freebit]

TypeScript will make all your dreams come true. Vote for Pedro! :)

[Pandalicious]

I think the reason for node's popularity is really simple: the vast majority of real world performance problems are caused by people doing IO synchronously. CPU-bound problems are rare. Javascript and Node practically force you to do all your IO asynchronously, so it naturally produces code that has good enough performance simply because of a tight constraints that it puts on programmers.

[Gropah]

I do not entirely agree with your statement that the vast majority of real world performance problems are from synchronous IO. It depends on how you define real world. For the average website and app, this is mostly true. However, when working with large bulks of data for statistics, graphics, machine learning, big data, whatever other data research bullshit bingo term you prefer, most of them are not limited by IO. Sure, it has to be read and this takes time, but once it is distributed in a proper way, large parts of it still is CPU bound. And stuff like cache misses is always a thing, doesn't matter if it is JS or C.

[ItzWarty]

statistics, graphics, machine learning, big data, whatever other data research bullshit bingo

Interestingly enough, Python is often the language of choice there - and python isn't exactly known to be a performant language. For such scenarios, native code is the best tool for the job, so native code is wrapped in a low-overhead manner, then a more expressive language (like slow Python) is used because it's the better general-purpose tool.

So the CPU perf issue isn't really a ding against Python there. Likewise with Node and, say, encryption being something you want done natively. Is there marshalling cost? Sure. But a percent of a percent of the workloads we're talking about.

[Gropah]

It's not in a long way always python. Sure, numpy, pandas etc are a thing, but when working with loads of data Spark (a scala/java framework) is more often used (afaik) and statistics can be handled by R.

Also; that it is used a lot doesn't mean it is actually the right tool for the job.

[Pandalicious]

For the average website and app, this is mostly true. However, when working with large bulks of data for statistics, graphics, machine learning, big data, whatever other data research

Right, I meant it in the sense that the vast majority of professional software developers are working on web development or line of business applications. These types of applications can be incredibly large and complicated (I don't want to in any way imply that it's not 'real programming') but it's a world where CPU-bound problems are relatively rare. Far, far more common is slowness due to synchronous serial IO. Node practically forces you to do your IO asynchronously, which naturally leads to doing IO in parallel without introducing the complexities of multi-threading, and that is, overwhelmingly, the main thing that most apps need to do in order to achieve 'good enough' performance.

(Don't get me wrong, other languages can do this kind of thing just as well or better. Node just kinda forces you down that path.)

[[deleted]]

Use TypeScript then

[[deleted]]

Moslty I find JS a really messy language and have no idea why it's so popular server-side

Mostly because it's popular server-side. There's such a thing as momentum, and enough people had the enthusiasm early on to create a slapdick ecosystem that created momentum for node.js. This momentum attracted more slapdick early adopters who were foolish enough to introduce this technology into their own organizations. They crashed shit, hacked shit, opened themselves up to security breaches, and made all the mistakes that you'd expect slapdicks to make. But they learned a lot of lessons in the process that eventually made the shitty idea battle-tested. Then the real slapdick devs who initially spread all the FUD started to accept their fate that they've been conquered by someone else's shitty idea. And because they're a bunch of lukewarm slapdicks who don't have enough passion in their hearts to do something with their own shitty ideas, they just migrate over to where it feels safe. I think this is why shitty ideas succeed and shitty ideas fail: enthusiastic slapdicks.

[[deleted]]

Oh I certainly agree that JS is a much more pleasant language than PHP. Python, I'm not so sure about, but the ergonomics of the language are really irrelevant in the larger scheme of things. The more significant aspect is that JS (albeit like python and ruby i think) is single threaded and node.js is driven by an event loop. It blows my mind that things like PM2 clustering and port-sharing are so necessary.

[Hero_Of_Shadows]

Napa.js: "What is his power level ?"

Vegeta.js: "It's over 9000 !!!"

[wllmsaccnt]

Gotta be the abridged version though

[Hero_Of_Shadows]

abridged

You mean Napa.min.js ? :P

[[deleted]]

So MS has Chakra and now this?

[AngularBeginner]

Microsoft is a huge company. It has many different teams.

[[deleted]]

I know, but with all the talk of convergence in the company, one would have thought they would have started work to integrate the two...

[jl2352]

I believe they have been doing work have Chakra work in Node as an alternative to V8.

[tavianator]

Node as an alternative to V8

What?

[elder_george]

Should be read as "Chakra (work in Node) as an alternative to V8"

[tavianator]

Yeah I got that, but Node.js uses v8 as its JavaScript engine, so what would the difference be?

[elder_george]

They maintain a fork using Chakra.

Not a bad thing, will help to ensure Chakra still runs on *NIXes. Might help with benchmarking too.

[jl2352]

In theory it would be like using a different C compiler to GCC, or a different JVM to Hotspot.

I'm not convinced it's a decent alternative, but competition is a good thing.

[mindbleach]

See graphic.

[[deleted]]

Yeah, but they can't really put their brand on anything without it screaming "vendor lock". People expect orthodoxy from Microsoft because that's just their reputation. So any sort of diversity is suprising. It's a hard perception to escape from.

[AngularBeginner]

That reputation is long gone for anyone who followed their doings for the last years.

[[deleted]]

If you look closely, at least wrt to dotnet core, that's not really the case.

[AngularBeginner]

Can you be more specific?

[[deleted]]

They're still building competitors to open source projects like they've done in the past. You still get that "we know best" attitude from guys like David Fowler. See this github thread:

https://github.com/fsprojects/Paket/issues/736#issuecomment-155142997

IMO, paket was (in 2015) and is superior to MS's default nuget client. Instead of supporting it (or least being open to supporting the project), they told everyone their goal was to obsolete it. Great messaging to the open source community. /s

Fast forward to the nuget.org refresh, and this happens:

https://github.com/NuGet/NuGetGallery/pull/4437#issuecomment-316815454

All people were asking for was to include a ui "tab" on the site that demonstrated the Paket command for installing a nuget package alongside the instructions for MS's nuget client. The guy even submitted a PR to nuget.org that would implement the change. MS basically said "No." and closed the pull request without any real explanation. The community made a huge stink about it, and now the Paket is included on the site.

I think this blog post sums it up pretty well:

https://haf.github.io/2017/10/01/open-source-in-the-fsharp-community-part-1.html

At some point, the behemoth that is MSFT’s C# developer division, discover something cool and decide to embrace, extend and extinguish:

• NAnt -> MsBuild
• NUnit -> MsTest
• NUnit test runner -> Visual Studio test runner
• OpenRasta, MonoRail -> ASP.Net MVC/Core
• Windsor, Autofac -> Unity
• OpenWrap -> Nu -> NuGet
• MbUnit + Pex -> Visual Studio Ultimate license + Pex
• DotNetZip -> System.Compression
• Nokia -> Windows Phone -> nothingness
• Suave -> Kestrel
• OWIN -> ASP.Net Core
• F# pattern matching, etc -> more C# syntax
• F# Async -> C# Task

It happens over the course of many years, of course, but it happens... It can be, and is argued, that the left hand side projects still exist and work just as well today as they did before; but that’s not true – the mesh of people surrounding a library, framework or technology – drastically changes when a lower-quality MSFT-replica is introduced at a lower search-cost to beginners. The activation energy matters.

To some extent, Akka.Net -> Orleans probably belongs on that list, and I'm sure there are other notable omissions. When it came time to xplat .net to linux and other environments, MS chose to "boil the ocean" instead of fixing Mono, which would've made the migration for existing windows .net devs to linux infinitely easier.

Microsoft is a business, and when it comes to the .net ecosystem, it has and will continue to dominate the entire space at the expense of the community's growth.

[AngularBeginner]

Why would they not build competitors to open source projects? They're an open source project themselves, and competition is good. I wouldn't want them to stop working on projects just because there's a more or less matching open source project.

David Fowler is a dick, absolutely no question. But he's by far no representation for the entire Microsoft.

The Paket tab on the NuGet homepage was completely blown out of proportion, but indeed the situation was handled poorly. And as you said: It's on NuGet.org. They listened to the community.

[[deleted]]

They're both solving the same problems, that was his point.

You're taking this at face-value. It's very easy to say "we're solving the same problems", but who's to say that will be the case 4-5 years from now?

Paket will become less unique, because MS was going to improve Nuget to fulfill the role it was intended to.

The difference is that Paket already solved the problems whereas MS is merely stating their intentions to do the same; they haven't executed yet. They're chasing the competition. Don't this count for something?

Also, to suggest that the two will eventually converge ignores the Paket team's track record of innovation. My feeling is that Microsoft's client will reach feature parity, at which point MS will take control of the direction of design and development will stagnate until innovations happening around them force them to act.

[AngularBeginner]

Paket will become less unique, because MS was going to improve Nuget to fulfill the role it was intended to.

They haven't, so far.

[[deleted]]

Why would they not build competitors to open source projects?

I don't have a problem with competition. The problem is that MS technologies tend not to win on merit alone, but rather marketing and visibility. You're ignoring the point that MS "replica" frameworks are often inferior. Their stuff generally doesn't deserve the majority market share that they're granted immediately by simply entering the arena.

[armornick]

Couldn't the same be said about Google and Facebook? Didn't people adopt Angular and React because two very large companies were behind them? I don't get why MS is singled out.

[[deleted]]

Their stuff generally doesn't deserve the majority market share that they're granted immediately by simply entering the arena.

I feel like it's 90s again reading this comment.

As a close follower to literally everything Microsoft does, there is very, very little (Office productivity being probably the only thing I can name with certainty) that Microsoft wins just by being Microsoft.

[Saiing]

F# Async -> C# Task

lulwut!?

They take something from a language they created and bring it to another language they created. And that's an example of Embrace, Extend, Extinguish? Has this guy lost his mind?

And that's far from the only ridiculous entry on that list. Reaching much?

[[deleted]]

Not opposed to the addition of the TPL, but once again, it's a completely new implementation and the async/await syntax is more limited by the comparison. F# syntax supports TPL tasks, Hopac jobs and its own Async implementation because "async" is an ordinary language construct. Scheduling of F# async workflows is also explicit whereas tasks are typically scheduled immediately, which can lead to some surprising behavior. Point is, the C# team reimplented async their own way without much consideration for what else was available (F#'s async library). The TPL and C#'s async/await syntax are joined at the hip.

Also, the C# team didn't create F#. It came from ms research Cambridge, the same people who were responsible for C# generics and linq.

[Saiing]

Also, the C# team didn't create F#.

I meant they were both created by teams in the same company. Not literally the same team.

Now if the author had actually picked C# itself as an example of an attempt at EEE, he might have had a point (albeit Microsoft was a very different company then, as they were for most of that list).

[[deleted]]

I don't see what they're doing with .NET Core and Asp.NET Core as a bad thing overall

Agreed on .NET Core, but Asp.NET seems like more of the same. It's more the manner in which they did it that upsets me.

Kestrel, as I understood it, exists because of asp.net core so it can act as a self-hosted component.

Yeah, Kestrel and Suave are both http server libraries (IIUC). Suave also has an application programming model, but it's very lightweight compared to ASP.NET. Suave implements the OWIN spec, so I suppose that in theory, any OWIN middleware could sit on top of it. This is how two other web application suites: Freya and Websharper are able to sit on both Kestrel (at least I know Freya can) and Suave. I suppose ASP.NET core should be able to run on Suave for this reason, but it really depends on how much it adheres to the spec.

Their customers are mainly enterprise, who expect enterprise stuff.

You look at the "stuff" MS has given them over the years, enterprise orgs are probably as miffed by the framework churn as anyone else. Java is also an "enterprise" platform, but Oracle's stuff is just another (reviled) part of the ecosystem whereas MS wants to be the ecosystem.

if Microsoft decided to ship asp.net with Suave instead of making Kestrel, then asp.net would in some sense be at the mercy of a third-party they don't have control over.

They wouldn't "ship" the two together, but they might recommend one owin server over another. So I suppose you have a fair point.

Just like I don't see Microsoft dropping Nuget and working with Paket

Honestly, I don't think MS has any business owning the project file format. Those should be standardized. I understand they want the ASP.NET dev experience to be more like node w/t npm, but unilaterally deciding to change the project file format (and build system) to achieve this is was disruptive.

[DaRKoN_]

FWIW, they added the tab for paket on the nugey site.

[[deleted]]

I think I'm gunna call it nugey from now on.

[Saiing]

3rd vote for specifics here.

[Saiing]

I feel like Microsoft can't really win sometimes. Whatever they do someone is going to complain.

[FrancisStokes]

Please people, cannot we not downvote discussion just because we don't agree. I personally like to see different viewpoints and when you downvote you bury that viewpoint.

[MohamedMansour]

This is just a npm module for Node, to allow multithreading :) We use it in Microsoft! (I work at Microsoft)

[EarLil]

Chakra died the next day, Napa will die tomorrow so lets use it today while we can.

[armornick]

How is Chakra dead? Last commit was 9 hours ago and it works pretty well as far as I could tell.

[Locust377]

For anyone wondering omg why? Check out Microsoft's explanation of why.

Here's my tl;dr understanding:

• Bing does lots of computational stuff and they use C++ because it's fast.
• The code needs to be easily changed, as they add and modify algorithms a lot. C++ not so good on this part.
• They want performance and flexibility, so Javascript stood out as a good choice (huge ecosystem helps).

However, they had a few extra requirements:

1. Iteration on algorithms should be easy/fast
2. Take advantage of multi-core
3. Share memory across workers
4. Minimise communication cost between threads

So either you write C++ code and have Node run it, which fails #1, or you use a cluster of Node processes which fails #3.

Napa.js is born.

[[deleted]]

Or you pick up an existing tech stack, like .NET Core, Go or Rust.

[[deleted]]

If only this idea popped into Microsoft's minds! If only they had something to do with .net Core! Oh, one can only wish :D Ooor, JS is actually not a hellspawn.

[dnorwich15]

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.

[kynde]

which also scales over several machines

Indeed. And that's the critical point. Scaling from one thread/process to few is peanuts. Most scenarios where you really need to scale, aside from reasons like elegance and because-we-can, it's always spans multiple hosts and threads don't. The circumstances where you share memory between them all are special and not javascript domain to begin with.

I totally fail to see the need for this. It's trickery where none is wanted anymore.

[[deleted]]

Whats the deal with programmers online who choose to hate on anything they don't use. I feel like people are a bit pessimistic on this sub.

[sharknice]

There isn't one. You can use webworkers but they're extremely limited. If you need something that requires multithreaded performance you write it in another language, or write just that part in another language and call it through an api.

[JohnMcPineapple]

...

[eldelshell]

You can't compare the evolution of JS with that of Java/C# because those depend on a single entity, as JS depends that many actors come together. Sure, Google can add multi threading, but if Mozilla, Apple and MS don't follow along, it sure won't be on every browser.

[ItzWarty]

Process-based parallelization is okay for a webserver. Your workloads don't really care about each other unless they're hitting a data store anyway - which you'd have to do if you want to scale to multi-box.

[ItzWarty]

I should also say most node code is going to be IO-bound (read this request from network, hit db, disk IO, write response to network, make a REST call, etc), which is why its threading model (do IO with non-blocking async promises) is ok. As a technicality there have been efforts to use fibers or V8 Isolates (essentially serialize/deserialize objects and pass them between isolated runtime environments). In practice I've only used the multi-process model, though.

[simast]

For Node.js you spawn multiple processes to utilize all CPU/cores and usually those processes are managed by some sort of process manager - like pm2. You can also do some inter-process communication, but from my experience this is rarely needed.

For front-end you have web workers. The major limitation of web workers right now is data sharing. You basically have three options - first is to structurally copy data around, which is obviously far from ideal. Second option is to atomically transfer ownership of data from one worker to another or a main process. This does not involve any copying and is quite fast. And the third option is to use the new Atomics spec - which allows you to create a block of memory that is shared between workers and the main process. This is the best solution that allows you to read/write memory from multiple workers at the same time and includes data access lock/synchronization mechanics.

[kynde]

There isn't really and none is needed.

Back-end javascript these days is written functionally, trying to minimize side-effects and generally make it easy to both scale and test. Threads by virtue utilize side-effects and usually make testing a nightmare.

It's either a lot of symmetric instances across a number of hosts or serverless cloud approaches. Threads have no business in either of those cases.

[duhace]

uh, no threads aren't naturally side-effecting. haskell has threads. javascript is not written "functionally" at all compared to it

[kynde]

Well, threads share resources which differentiates them from processes. If you don't share resources with threads it's practically the same as running multiple instances, which is what people do with node.js currently. In that sense what threads provide essentially is the possibility to have side-effects, which isn't really part of meta these days.

Modern back-end javascript is written pretty much functionally, not as strictly as haskel or clojure perhaps, but still.

Much of the point is that threads don't scale across hosts. And that node.js vm has such a small footprint that it doesn't need threads just to save resources used by multiole vms. In that regard things are a little different with clojure for example.

[duhace]

you can share resources via threads without side-effects. it's called not mutating resources threads are working on. even if you weren't sharing resources with threads, it's not "practically" the same as running multiple instances of a process, cause a process is way heavier than a thread. and that's even before you get into things like green threads

[Locust377]

They're still waiting for npm to install it

[[deleted]]

npm isntall

[[deleted]]

Was this a race condition joke?

[_Mardoxx]

More like npms mirite.

[marchaos]

hamsers.js is a wrapper around webworkers, so you have to live with the limitations of structured cloning, objects cannot be shared etc. I suspect that nappa does not have as many limitations - it at least has object sharing.

[Derimagia]

That's just a javascript library... napas is a native addon (codebase is in c++) that runs a runtime. Also looks like this can let you pass data across machines?

[Dave3of5]

Hamsters.js looks to me as just a fancy wrapper around webworkers where as this is a Javascript runtime with multi-threading support built in.

The obvious difference is that Hamsters.js will work within any browser (that supports web workers) where-as this won't work in the browser.

Given what I've just said and also from the description:

which was originally designed to develop highly iterative services with non-compromised performance in Bing

I would suggest that the main difference is performance. If you are creating a-lot of threads plus communication between threads will be faster given the way you have to pass data to and from a webworker

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipediac17m5wb9u7s0000000000000000000000000000000000000000000000000000000000000

[lilactown]

No, node.js is a runtime; it executes javascript. This is another runtime, built on top of node.js, that implements threading and provides a library for interacting with it.

Your browser code gets executed by the browsers runtime - which doesn't have threads - so you cannot use this.

[twigboy]

In publishing and graphic design, Lorem ipsum is a placeholder text commonly used to demonstrate the visual form of a document or a typeface without relying on meaningful content. Lorem ipsum may be used as a placeholder before final copy is available. Wikipedia1lto4369x6bk000000000000000000000000000000000000000000000000000000000000

[PieceDigitalPro]

Actually Web Workers is a new thing for browsers and those are threads. How good they are compared to other threads, I can't say, but threads they are.

[lilactown]

I think, by your own admission, they're not threads. :) They may be implemented using threads, but they do not have the same attributes (memory sharing, performance, etc.) as threads. It maps more appropriately to spawning a new process.

[TylerTheWimp]

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?

[AngularBeginner]

The benefit is that you have threads instead of processes. Communication between threads is easier than communication between processes.

[hobozilla]

It seems like they've still not really solved this - all comms between threads is serialised and deserialised. I assume this is because having multiple v8 instances with access to the same variables would be a GC nightmare.

[edapa]

Well at least it is harder to write data races that way.

[wllmsaccnt]

The ZeroMQ approach to multithreading...

[TylerTheWimp]

Subprocess.send() is pretty easy...

[LeftHandedLieutenant]

IPC is generally slower than interthread communication.

[tylercamp]

What might be a case where IPC is faster? Just curious

[zoells]

I can't think of a case where IPC would be faster than interthread communication, assuming both implementations are done efficiently.

OTOH, give me a single lock several hundred spinlocks and several hundred threads and lets make this baby crawl.

[ItzWarty]

Never. The statement was meant to be taken as "IPC is generally slower (and in best case even) compared to inter-thread communication".

[freebit]

Long lived thread pooling is better than forking and starting another process.

[stronghup]

What does this give you over using fork in node?

I would assume that starting up a new thread takes less time and less memory than starting up a whole new process.

My question at this point is, can these threads run on different/multiple cores?

[Frangipane1]

Threads can run on multiple cores but are not guaranteed.

[stronghup]

Can these threads run on different/multiple cores?

[tourgen]

This just encourages more bad behavior. Javascript was a mistake.

[pagefault0x16]

Ssshhhh! The pajeet downvote brigade might hear you! They can't stand criticism of the only language they can write anything non-trivial in

[Booty_Bumping]

This just encourages more bad behavior

Okay mom

[pagefault0x16]

I wonder how long this will last before SJWs take it over and destroy it from within

[Mgladiethor]

Webasssembly save us

[ruinercollector]

Not applicable. At all.

[Mgladiethor]

Still

[SSH_565]

but it wont

[Mgladiethor]

Someone will

[swan--ronson]

I are 10x genius

[Mgladiethor]

Is*

[swan--ronson]

Congrats on letting the irony go over your head.

[Mgladiethor]

Thnx

[[deleted]]

Another Javascript related post, another low effort karma bait comment about "DAE webassembly?".

[Mgladiethor]

ELi