I don't think it's entirely true that desktop applications use separate threads for all tasks except UI related tasks. At least not for old win32 based applications. I think it's pretty common to do other small tasks too in the main thread, and to spawn new threads only when doing queues or other stuff that you know will perceptibly halt the running of the main user interface thread.
When to use web workers
101–110 of 110 posts
Re: When to use web workers
#102I think this is BS, practically all of the performance problems on the Web are related either to the DOM or CSS, which Web Workers can't fix. If you have a phone from 2014, something's gonna jank. It doesn't mean you're excluded . It means you'll have to live with jank. You'll get over it.
Many websites have too much of everything , but UI-thread JS is definitely the most common largest performance problem that prevents you from using pages. It’s the biggest thing where an architectural re-think has the biggest effect—though certainly just cutting down on all things will improve performance too.
Can you show me an example? Like I said, I call BS on this. What website does a non-trivial amount of pure JS on the main thread? What even is the use-case? React reconciliation?
Secondly, how does it prevent you from using a website? Sure, jank is annoying, but it doesn't entirely prevent you from using the site. Perhaps you give up on the site, but that's up to you.
Re: When to use web workers
#103Earlier quoted context omitted.
Depends on the user. My GF for some reason uses FF, Edge and Chrome at the same time, most of the time (she's not in/into tech). So if someone asked her, she would just switched the windows.
That sounds like a fairly rare workflow. I've heard of people using different browsers for different things but I don't think it's common.
I guess some people don't care about the browsers very much, and will just use whatever is installed. If there are multiple browsers installed, they may learn to use different browsers as a simple way to have different easily distinguishable browsing contexts (different icon/app name) - instead of having multiple windows of the same browser that looks pretty much indistinguishable.
Re: When to use web workers
#104Thank goodness for Safari's reader mode. This article was unreadable without it. Why do people do this?
Can you elaborate? I enjoyed the layout, colors, fonts etc, but curious on why the page is not acceptable.
Re: When to use web workers
#105Earlier quoted context omitted.
Static _is_ better for a good bunch of performance metrics. But what about interactive content like https://proxx.app ? The article is mostly aimed at use-cases where some sort of logic in JavaScript is required.
Heavily interactive content in the browser is an edge case for vast majority of mobile users. Outside of that edge case the best solution is usually to use JS to sprinkle functionality not doing heavy lifting.
Within that edge case, an app (possibly using react native, if you love js) is often a better choice.
Re: When to use web workers
#106Earlier quoted context omitted.
I do understand, was just mobile and in a hurry so I failed to fully qualify the statement. What I was saying is if you're in the WASM toolchain/ecosystem, something like pthreads would already be implemented by Emscripten[0]. In other words, spinning up web workers is handled for you seamlessly. It's all dealt with at a very low level of abstraction. You're literally using the SharedArrayBuffer as memory. Contrast t…
As you already hinted, SABs have been widely disabled. Chrome is currently the only browser who has SABs and therefore the only browser with support WebAssembly threads. Workers, on the other hand, are available everywhere. And serialization seems to be far less costly than most people think. In the apps that I have written that make use of a off-main-thread architecture, structured clone has not been my bottle-neck.
>And serialization seems to be far less costly than most people think. In the apps that I have written that make use of a off-main-thread architecture, structured clone has not been my bottle-neck.
If you're working within a render loop it does hurt, but I agree it isn't an issue for a typical use case. I think what detracts more is the ergonomics of the serialize/deserialize operations. Those are just largely seamless on the emscripten side. On the other hand, a full wasm/emscripten toolchain in your project arguably comes with its own ergonomic cost.
Re: When to use web workers
#107Earlier quoted context omitted.
I suggest you look up why they disabled it. And that is still not an application of WebWorkers! It would be much more helpful to the cause if you could point to some actually used app out there principally relying on WebWorkers. Until then, it's been a lot of pain, zero gain.
a bit niche, but here's one of my projects - svgnest.com in addition to the render blocking issue brought up by this article, there are a lot of applications for cpu-bound web apps (eg. anything requiring machine learning or computer vision), but in my experience web workers are not very reliable for this purpose.
I use webworkers to run an in-memory streaming pivoting engine (compiled from C++ to wasm) to build real-time Tableau-like dashboards that run fully in the browser (which runs fairly well for 10M row datasets or less). Network IO and the compute is handled in the webworker, which allows the main UI thread to remain responsive.
Re: When to use web workers
#108Earlier quoted context omitted.
Many websites have too much of everything , but UI-thread JS is definitely the most common largest performance problem that prevents you from using pages. It’s the biggest thing where an architectural re-think has the biggest effect—though certainly just cutting down on all things will improve performance too.
Can you show me an example? Like I said, I call BS on this. What website does a non-trivial amount of pure JS on the main thread? What even is the use-case ? React reconciliation? Secondly, how does it prevent you from using a website? Sure, jank is annoying, but it doesn't entirely prevent you from using the site. Perhaps you give up on the site, but that's up to you.
> What website does a non-trivial amount of pure JS on the main thread?
I challenge you to run a browser with no ad-blocker installed for one week, then block JavaScript (e.g. with NoScript; or with uMatrix and block scripts; or by setting javascript.enabled to false in Firefox).
Your eyes will be opened at just how much JS is run and how much it slows things down.
> What even is the use-case?
Mostly analytics, ad-serving, privacy invasion and laziness/inefficient coding.
> how does it prevent you from using a website?
When it’s bad enough (which it often is, on slower mobile devices), you reach the point where you can’t perform tasks in a timely fashion. I chose the word “prevents” deliberately, because that is how it ends up.
Re: When to use web workers
#109Earlier quoted context omitted.
Can you show me an example? Like I said, I call BS on this. What website does a non-trivial amount of pure JS on the main thread? What even is the use-case ? React reconciliation? Secondly, how does it prevent you from using a website? Sure, jank is annoying, but it doesn't entirely prevent you from using the site. Perhaps you give up on the site, but that's up to you.
> What website does a non-trivial amount of pure JS on the main thread? I challenge you to run a browser with no ad-blocker installed for one week, then block JavaScript (e.g. with NoScript; or with uMatrix and block scripts; or by setting javascript.enabled to false in Firefox). Your eyes will be opened at just how much JS is run and how much it slows things down. > What even is the use-case ? Mostly analytics, ad-s…
> I challenge you to run a browser with no ad-blocker installed for one week, then block JavaScript (e.g. with NoScript; or with uMatrix and block scripts; or by setting javascript.enabled to false in Firefox).
I was looking for an example of a "bad website" that I could profile, not to see how disabling Javascript makes things faster. Of course it does make things faster. It also breaks everything.
> Mostly analytics, ad-serving, privacy invasion and laziness/inefficient coding.
I remain unconvinced that most any of this could be moved out to a web worker. It sounds more like a "death by a thousand paper cuts".
> When it’s bad enough (which it often is, on slower mobile devices), you reach the point where you can’t perform tasks in a timely fashion.
I do use slower mobile devices for testing other websites, I have yet to come across one site that's absolutely unusable. Granted, I didn't test the whole WWW.
I'll ask you again: Show me one example of such a site, where I can fire up the profiler and observe that it's really the Javascript code and not the DOM or CSS/Layout reflows that's causing the performance issues. Only then can we start figuring out if Web Workers might help - which often they can't, because they are very limited.
Re: When to use web workers
#110Earlier quoted context omitted.
People have been taking plenty advantage, they are an indispensable tool to turn all of these CPU bugs or DRAM attacks into working browser exploits. Also those bitcoin miners of course. Maybe if no one else is taking advantage it is time to simply throw them out.
“I don’t use it, therefore no one else uses it” As an example, emscripten uses WebWorkers and SharedArrayBuffers to implement multithreading (unfortunately or not, Chrome is the only browser that supports SharedArrayBuffer, others have disabled it).
are you updating diep.io? it is showing lastModified 17th June 2019