61–70 of 110 posts
Earlier quoted context omitted.
Pro tip: if you ask a user to install a different browser, they're just as likely to use a different site instead.
they're just as likely to use a different site instead. just as likely, or more likely?
Earlier quoted context omitted.
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.
Pro tip: if you ask a user to install a different browser, they're just as likely to use a different site instead.
So if someone asked her, she would just switched the windows.
Earlier 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.
Yes @dassurma. But web workers are not everything. Your own blog post does not score 100 : https://developers.google.com/speed/pagespeed/insights/?url=... And those issues are not necessarily addressed with web workers. Good basic static design matters too.
Earlier quoted context omitted.
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.
Pro tip: if you ask a user to install a different browser, they're just as likely to use a different site instead.
Earlier 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).
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.
Earlier quoted context omitted.
IndexedDB is shared between workers and main thread, in case that helps.
Indeed, and it is something I'm looking at. But at the moment my database is really native Clojure data structures, which has fantastic advantages. I would need to start storing them in a "traditional" database, introducing additional layers, serialization, overhead and bugs.
If the app state is stored in a single atom, I would use localForage[1] (available as a cljsjs package[2]) to keep it in sync between web workers and the main thread. It would also make the app accessible offline.
Hey @dassurma, can you explain your task scheduling function? As far as I can tell it schedules a micro task, and there is no meaningful difference between that and other microtask scheduling systems: https://codepen.io/ruphin/pen/qzbgYr?editors=0012
All your logs are executed immediately. .then() takes a callback function!! FYI: AsyncTask and MicroTask are equivalent, and so are my task() function and your OnMessageTask
I expaned my tests a bit and your version does indeed queue a task and not a micro task. I did find it to be somewhat less reliable than setTimeout, is there a particular reason why you used this scheme instead of a setTimeout based solution to queue tasks? Why did you choose this method in particular to queue tasks?
Also, AsyncTask and MicroTask are not fully equivalent. MicroTask is equivalent to a bare `await 0;`, but because AsyncTask wraps that in another async function it will queue a second micro task when the first one resolves, and resolve the promise when the second micro task resolves :)
Earlier quoted context omitted.
All your logs are executed immediately. .then() takes a callback function!! FYI: AsyncTask and MicroTask are equivalent, and so are my task() function and your OnMessageTask
Ah, I messed up in my haste to experiment :) I expaned my tests a bit and your version does indeed queue a task and not a micro task. I did find it to be somewhat less reliable than setTimeout, is there a particular reason why you used this scheme instead of a setTimeout based solution to queue tasks? Why did you choose this method in particular to queue tasks? Also, AsyncTask and MicroTask are not fully equivalent.…
Earlier 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).
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.
Outside of that edge case the best solution is usually to use JS to sprinkle functionality not doing heavy lifting.