11–20 of 110 posts
What is the use-case? Why is static not better? What are the edges?
The article is mostly aimed at use-cases where some sort of logic in JavaScript is required.
I don't like how the browser has to structured clone objects sent between threads. Seems like on low end devices, that could tie up tons of ram and have out of memory failure modes not seen on beefier phones. Reading the article, the author seems to advocate sending js events over from Dom thread to worker, doing all event processing on the worker, and sending commands from the worker back to the Dom that get process…
That being said, in all the off-main-thread apps I have written so far, the cost of structured cloning was pretty much irrelevant.
What is the use-case? Why is static not better? What are the edges?
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.
If there was a vdom library that moved the diffing part to a web worker, would you have used it? or is it still costly to do any diffing at all?
I wish SharedWorkers were not removed from Safari. They are super useful for sharing a single websocket connection between multiple open tabs. Something you can’t do with ServiceWorkers
Yeah shared worker are awesome. I love having a single instance of the core of my app running in a worker, and then each tab the user opens is just a UI view of that one instance. It greatly simplifies keeping things in sync across tabs. But it's just not possible for Safari... you either have to make your code much more complicated, or add some hack to prevent users from opening your app in multiple tabs at the same…
I realize we need more browser diversity and not less, but at the same time we should encourage all participants to keep up so that the burden doesn't fall on smaller players.
I don't like how the browser has to structured clone objects sent between threads. Seems like on low end devices, that could tie up tons of ram and have out of memory failure modes not seen on beefier phones. Reading the article, the author seems to advocate sending js events over from Dom thread to worker, doing all event processing on the worker, and sending commands from the worker back to the Dom that get process…
You could always use transferable ArrayBuffers and serialize your data with Flatbuffers or something similar. That being said, in all the off-main-thread apps I have written so far, the cost of structured cloning was pretty much irrelevant.
Earlier quoted context omitted.
Yeah shared worker are awesome. I love having a single instance of the core of my app running in a worker, and then each tab the user opens is just a UI view of that one instance. It greatly simplifies keeping things in sync across tabs. But it's just not possible for Safari... you either have to make your code much more complicated, or add some hack to prevent users from opening your app in multiple tabs at the same…
What percentage of your users use Safari? If it isn't impactful to your business, you could ask them to use Firefox or Chrome. I realize we need more browser diversity and not less, but at the same time we should encourage all participants to keep up so that the burden doesn't fall on smaller players.
Web Workers were added to Firefox ten years ago this month, so they're definitely not new technology. I think this is a great call to action to actually start taking advantage of them.