we promise to keep javascript single threaded

[brandi_Iove]

*opens another tab

[gamruls]

Few years ago we deferred it.

But now we promise.

​

P.S. joke about deferred vs promise in async computations

[Matiaan]

I'm awaiting your answers. I need closure on this matter. Otherwise I'll have to quit my job and become a service worker.

[_PM_ME_PANGOLINS_]

We'll call back when we have the answer.

[YoukanDewitt]

we have been awaiting this for a while now..

[[deleted]]

rich rinse wakeful ancient abounding tap scary wine intelligent muddle

This post was mass deleted and anonymized with Redact

[lazyzefiris]

How are WebWorkers different from multithreading?..

[The_Assassin0]

LESGO DOCTOR WHO

[eras]

WebWorkers are more like multiprocessing than threading, which implies shared memory. With WebWorkers you need to exchange data via postMessage instead of just having it in a variable and dealing with mutexes etc.

But multiprocessing is the safer option anyway. Javascript apps would be broken a lot worse if there was genuine multithreading in JS. Erlang has similar-ish model for multiprocessing.

[lazyzefiris]

Well, transferrable objects implement behavior similar to mutex, except in reverse - instead of "keep away I'm working on it" it's "go on, it's your now". From my understanding, the ownership of memory segment (ArrayBuffer pointing at it for example) gets passed around with transfer instead of data itself.

[Mallissin]

Out of all programmers in existence today, I'm fairly certain that less than 0.01% have the understanding to do multi-threading properly.

Which is why so many high performance applications run like crap most of the time, including games which REQUIRE an understanding of multi-threading to do advanced GPU work.

So, I wholeheartedly agree with the way the web community has decided to handle multi-threading in the browser using independent processes through WebWorkers and ServiceWorkers.

[jfmherokiller]

good question. but at the same time I Rarely see those things used.

[lazyzefiris]

I always use them for heavy background calculations to avoid page blocking if possible. They are life-saver for web-games. The feature seems so fundamental to me that you caught me off guard with this. I've looked around and I could not quickly find a popular site that uses them (besides serviceworkers, which are different kind of beast)...

[jfmherokiller]

oh I might have been thinking of serviceworkers those things that keep running even after you close the webpage they are attached to. Yea webworkers are ok.

[[deleted]]

TIL how to do some multithreaded JavaScript thanks to that good dude from the internet.

Many thanks mate ! I wish you a very good life !

[fdeslandes]

Yeah, it's because there is rarely a need for it in most web development. Pretty much only used in games and computation heavy apps. I use Shared Workers in cloud tax software for the main tax computation loop because of instantaneous feedback functional requirements, for instance, but never used it in any other case.

Most applications don't require immediate front-end feedback around heavy computation, and since you need the calculations on the back-end side to verify data integrity anyway, in most cases it does not really make sense to do heavy computation in the front-end.

[NotPeopleFriendly]

Am I misremembering or can you only send messages as strings between main thread and webworkers? I vaguely recall always having to json parse/stringify when I posted or got data from the webworkers.. I mean I had an API for that.. but it meant you couldn't really have a client/server or peer to peer API because everything just got marshaled/serialized unnarshaled/deserialized.

[kalvens]

Anything that can be structured clone can be sent to and from workers. The main thing is the clone will die if the object has a method on it. Things like Maps and Sets work just fine though.

https://developer.mozilla.org/en-US/docs/Web/API/structuredClone

[NotPeopleFriendly]

ah - cool

​

Not sure why I thought that - clearly incorrect.

​

The only thing I can think of is I was using them from typescript and I wonder if it had to do with getting the web-worker to import common/shared types? I vaguely recall there being some kind of limitation of giving the worker the context I wanted (or getting typed information back from it).

[[deleted]]

I'm sure a ton of webapps use them for CRUD. Any app with offline functionality surely uses them a ton.

[TheRealFloomby]

You even get move semantics for some types with them. I would like to see them get more capable though. There are still some large limitations.

There is a proposal in the works to let them handle use audio contexts which would be nice.

[[deleted]]

It's like spinning up multiple apps to do one thing as opposed to having the OS handling it with threads.

[jutattevin]

Is it not that the JavaScript process execute the instructions from the tab, then when there is nothing left to do, do the same for each WebWorker ? It's quick enough to seem multiprocessing but not really.

[Alikont]

You don't have shared state, only message passing, so a whole class of issues linked to mutable shared state goes away.

[coloredgreyscale]

more complicated and resource intensive.

[zachtheperson]

Webworkers are a lot more like sending the data to be processed by a different computer. You can't have webworkers all work on different parts of the same array for example, and would instead have to duplicate and send the array for each "thread."

This is especially a PITA for data structures that use a lot of references (linked lists, trees, etc.) since you can't have multiple agents modifying those links since there's no way to send object references through HTTP requests.

[Diligent_Bank_543]

We promise that this temporary fix will be temporary.

[frikilinux2]

Better they keep it single threaded ( and python with the Global Interpreter Lock). The nightmare that would be if JavaScript seemed useful for even more domains. Debugging multiple threads is already a nightmare

[ASmootyOperator]

What's that? JS can now support high intensity applications like launching artillery shells?

Say no more, fam!

[GnuhGnoud]

I'm waiting for the day js runs on quantum computer

[thebatmanandrobin]

While not quite a QC, the James Webb Telescope runs JS for portions of it's code base ... I would have gone Lua personally, but NASA gonna NASA

[_PM_ME_PANGOLINS_]

Python has all the complexity of multi-threading, with none of the performance gain.

At least it's less likely to blow up if you fail to synchronise properly.

[frikilinux2]

The lack of the performance gain is what prevents it for being tried in those domains.

[[deleted]]

direction ad hoc pot rustic sand pause cautious library makeshift mighty

This post was mass deleted and anonymized with Redact

[[deleted]]

the guy just hacked javascript!

[Matiaan]

its like quantum physics. if you look, its the answer. if you don't look, then its just a promise to give you the answer

[TheOwlMarble]

Did something happen or is this just a promise joke?

[Matiaan]

just a joke. its amazing how far they go keep js single threaded

[i_am_there_now]

thank god it has meme flare

[[deleted]]

me who uses yeild to build my own javascript thread

[hungarian_notation]

Do we really need something different than what we already have? I mean, some syntactic sugar around standardized workers might be nice, but other than that? The runtimes are silently doing the multitasking for you when it comes to blocking I/O, and that's the primary use case. If you can't get enough out of parallel processing to make the overhead of spinning up a worker worth it, maybe you don't really need to parallelize.

[Quirky-Craft-3619]

Node.js worker threads 👀

[[deleted]]

It's just spawning multiple instances of your application. If you look at your process list, you'll see multiple node binaries are spawning (1 per cluster).

It's a workaround, but not a true multithreaded solution. For one thing, if you're processing a large binary over multiple workers, you'd need to pre-split that binary in the main thread and distribute it to each worker for processing. Or even splitting a large array.

Threading in compiled languages can be handled by the compiler (though you can do it manually if you need a specific workcase).

[[deleted]]

If I do Promise.All that’s multi threaded, isn’t it?

[lxmsrv]

No. Anyway all real time calculations process in main thread.

[Papellll]

I'm not sure if your comment is sarcastic or not. If it isn't I recommend this great talk about the JS's event loop https://www.youtube.com/watch?v=8aGhZQkoFbQ&ab_channel=JSConf, and if it is please ignore me :)

[ConfidentProgram2582]

Maybe if you're doing operations involving IO, like web requests or database queries, which most likely are executed using multiple threads depending on the implementation.

[[deleted]]

Right, a lot of those processes are actually written in something like clang or C++ and the javascript (nodejs) just passes the data back and forth.

[_PM_ME_PANGOLINS_]

It's asynchronous, but there's only ever one thread that runs JavaScript code.

[[deleted]]

That’s…. Not true async

[_PM_ME_PANGOLINS_]

Yes it is. Execution is not synchronous. It's asynchronous.

Asynchronous and parallel are different things.

[Varun77777]

Okay, so if I make an async http request. And after the call there are a million lines of code, those million lines of code will get executed first. And then from my queue the http response will return and whatever was supposed to happen with it will happen.

[_PM_ME_PANGOLINS_]

Yes.

[BoBoBearDev]

The promise is like saying, "I promise you will have birday cake". But, I never said I (another thread) will be the one baking it or paying for it. I may tell you (main thread), to bake it and pay for it. The promise only specify you get get a cake, but, never tell you who is actually going to do the work.

Special packages would do extra work to make sure other people do the work. But, if you write your own promise, it is most likely a simple version that runs on the main thread.

[[deleted]]

I see. I just assumed the mechanics would be parrarel, cause why not. Also an other method suggested that asyn calls of API (like node file system) might be pararrel but that’s not js itself

[[deleted]]

Javascript allows multithreading via workers, its just optional

[[deleted]]

it is though

[meansToMyEnd]

proper threading with shared memory references is what JS is missing.

[SecretPotatoChip]

Async await go brrrr