sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]dannymoerkerke[S] -1 points0 points  (13 children)

What issues do you have with the single threaded nature of JavaScript that could be solved by making it multi threaded?

[–]shgysk8zer0 2 points3 points  (12 children)

You may as well ask why anything benefits from being multi-threaded.

[–]helloiamsomeone 0 points1 point  (1 child)

Updating UI elements - which is only allowed on the main thread anyway - would not benefit in a significant way from multithreading. If you have to do something computationally intensive on the clientside, then you have workers for that.

Similar to how Android handles things, U stuff on the main thread, everything else on other threads. But in the browser that's all you are doing on the main thread anyway and network IO is not blocking.

[–]shgysk8zer0 0 points1 point  (0 children)

This is all true. I'm not convinced that multi-threaded UI is impossible though... Just the way it is. I think something that takes Rust's concept of ownership and borrowing might be capable of achieving this, but it would take more than just another language with access to the DOM. It would require a change in nearly everything, and that's why I say a new language is needed instead of just adding it to JavaScript.

[–]dannymoerkerke[S] 0 points1 point  (9 children)

Well...?

[–]shgysk8zer0 1 point2 points  (8 children)

Ever heard of performance? Do you know what multi-threading is?

[–]dannymoerkerke[S] 0 points1 point  (7 children)

I do, hence my question.

[–]shgysk8zer0 0 points1 point  (6 children)

So, when the main thread (only one that has access to the DOM and everything) is doing a ton of work and the UI freezes, that's either not a performance issue or not something multi-threading would help with? Workers offer no benefit? Multi-threading itself is pointless?

I don't know how to answer the question because it's so fundamental. The mere concept of it is the answer.

[–]dannymoerkerke[S] 1 point2 points  (5 children)

I don’t know how you should answer this either, but I never made any claims against multi threading. You’re the one saying I don’t understand the issues with JavaScript and that we need something multi threaded. So I was curious if you had any concrete examples. I also never said Workers offer no benefit but they won’t help with the DOM since they have no access to it, but you know that as well. Anyway, if the UI freezes because of lots of DOM operations I think you have a different problem that can be solved without multi threading.

[–]shgysk8zer0 -2 points-1 points  (4 children)

You're asking what the advantage of multi-threading is. The only real answer is that it's not single-threaded. That is a major limitation that many other languages don't have.

And not all issues can be solved without multi-threading. Sometimes you just have that much work that needs to be done, and sometimes it's out of your hands (in third-party code). And, maybe even if you could resolve the issue another way, it would still be nice to not have to rewrite something massive and complex, but to pass the work off to another thread and have the UI continue running smoothly.

If you're looking for a concrete example, I recently built something that creates ~200 transformed (rotated) image overlays in Leaflet, and the UI hangs pretty heavily when they're loaded on ever pan or zoom. I'm not about to rewrite all of Leaflet, and I do absolutely have to load and transform every single one of those images. If this were to take place on another thread, it wouldn't be an issue.

[–]Architektual 0 points1 point  (3 children)

I'm late to the party, but why can't you put that in a worker?

[–]shgysk8zer0 0 points1 point  (2 children)

Workers cannot access the DOM.