This is totally untrue. Layout can run off the main thread if engineered properly. Painting and compositing already do in some browsers. Layout, painting, and compositing are inherently parallel problems, so any one of these tasks can saturate all your cores if done carefully. Iframe JS can run in multiple threads if engineered right.
Without off screen canvas and threading your UI and logic are all being done in a single thread, causing significant lag problems that every other kind of application has resolved since the 90's. Threading is am essential part of any user facing application, and browsers outside of chrome have continually squandered the ability to put out good quality UI that does intensive background work. Something as simple as a video player in wasm requires at least 1 other thread.
That was really informative, but it raised a question for me:
It described the browser as single threaded, but then talked about multiple concurrent tasks. Aren't those threads?
One more question: are there any browsers that use multiple threads to lay out the various object models and render the page? If it's been found to be too difficult, what were the issues?
To take advantage of multiple cores doesn’t require multiple (heavyweight) processes. A single multithreaded process would do just as well.
Not to say it’s a bad idea, just that we’ve got to remember that multiple processes is nothing revolutionary. A single thread for each tab would probably work just as well from a parallelization standpoint, but you’d lose the ability to kill one without bringing down the entire browser.
It would be really nice to not always have to do a worker thread or iframe to get multi-threading. Web apps with more involved and/or extensive ui's would benefit a lot from this in terms of the ui responsiveness.
I hear what you are saying. I have a very large number of cores in my workstation and it's disappointing/frustrating how many applications—most poignantly, Mozilla Thunderbird—are in practice single-threaded. Even using Firefox with Electrolysis and a bumped dom.ipc.processCount setting yields an experience that seems routinely stuck waiting for a single user interface thread to do something.
And multithreaded JavaScript for webapps seems like a pipedream. Virtually no one uses Web Workers because they were designed to avoid sharing data between threads, making them inordinately cumbersome to use in any routine/real-world cases.
There is a lot of room for improvement across many fronts. But I am hopeful it will occur sooner or later because I suspect adding more cores will be easier than increasing the speed or each core for the foreseeable future.
But without multithreading, you can use 1/4th or 1/8th of the computation power available on your average consumer device.
What kind of issues are you thinking about? Multithreading is not easy but your typical race conditions and multi threaded problems aren't really opening doors to any new security exploits.
Browsers and WASM have quite decent sandboxing to mitigate security issues. There's WebWorkers already which brings a limited form of threads to the browser.
I'm not seeing a problem with multiple threads in a browser.
Expanding on this, if you do all the work on the main thread, you're implementing a cooperative multitasking system, with all of the problems that entails.
It's surprisingly hard to break up potentially long tasks in an ergonomic way without losing a ton of performance, tracking down a long tail of tasks that block rendering, or both. Having multiple threads of execution is so much better.
We already did for a long time. In my business, web applications, that is mostly server side and it came as either running the app in multiple processes (Rails, Django) or with a runtime that natively use all cores (BEAM / Elixir).
The front end is mostly single threaded (JavaScript) but browsers can use multiple threads to speed up the UI and we can also use web workers to do some real multithreading in JavaScript. Maybe some frontend framework uses them to speedup managing its DOM model. I hope I gave the idea, the terms are probably all wrong, I'm definitely more about the backend.
Firefox and chrome use a half-dozen or so threads parsing and compiling JS code so it loads quickly. Firefox's Quantum work adds a lot of threads for rendering as well. In addition, service workers, web workers, and Wasm all spawn additional processes which serve the same purpose if you aren't sharing memory directly.
In this context threading is less about making maximum use of multiple cores and more about "never blocking the main/UI thread". Even on a single core device you usually need to start offloading heavy computation to a background thread to keep the UI responsive.
Even today I'll run into websites that lock up a browser tab because they're running a whole mess of Javascript soup (typically jQuery). I know we were promised WebWorkers like 5 years ago but does anyone actually use them?
> Splitting UI from content means that when a web page is devouring your computer’s processor, your tabs and buttons and menus won’t lock up too.
Well, for that particular problem, there is a much simpler solution than splitting application into two distinct processes. It's called multithreading. Moving UI into a separate thread would not only be simpler than moving it into a separate process, but also wouldn't result in 20-50% memory usage growth.
> not many, we're in the web, you have 15ms max per frame, on a single thread
Isn't the likely way forward to move the computationally heavy parts of the app over to web workers and to keep the main thread almost exclusively for UI work?
By no means would I try and build a high bandwidth graphics pipeline that runs between processes. That's a very specific problem requiring a very specific solution. However it wouldn't be correct to abandon multiple process single thread for the (much more common, particularly on HN) situation of a web app that's running on a server with multiple logical cores in non-evented programming language.
> I expressed quite clearly that different multi-processing solutions apply to different categories of problems, which of course means that there are problems which simple, plain multi-process solutions excel at, for example webservers.
The blog post does mention the main thread, as something that is more complex and in need of further investigation.
Still, even without shared memory being accessible to the main thread, I think sharing between workers can be extremely useful. Yes, you need to proxy information to the main thread in order to render, but that doesn't need to be a big problem. See for example the test here, where a 3D game's rendering was proxied to the main thread, with little loss of performance,
That very small overhead could be worth letting the game run in multiple workers while using shared memory.
Also, things like Canvas 2D and WebGL are APIs that might exist in workers, there are efforts towards that happening right now. That would eliminate the need to copy anything to the main thread, and avoid a lot of latency.
It seems the author is either simplifying things too much in their text or does not know what threads are. Not having multiple processes does not mean a program cannot execute things in parallel, and Firefox uses threads liberally. As far as I know, the multi-process architecture of Chrome is mostly about sandboxing, not performance.
reply