Really, really wish you could do canvas manipulation with web workers. There's some experimental browser stuff, but nothing standard. I'd like to be able to do image manipulation with web workers.
When to use web workers
51–60 of 110 posts
Re: When to use web workers
#52Really, really wish you could do canvas manipulation with web workers. There's some experimental browser stuff, but nothing standard. I'd like to be able to do image manipulation with web workers.
OffscreenCanvas is exactly that! It's standardized, but only chrome has implemented it so far, sadly.
Re: When to use web workers
#53Hey @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
Re: When to use web workers
#54Web 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.
Reading this thread I was thinking this seems like it's turning into XHR all over again. It was a long time from XHR to 'ajax'
Re: When to use web workers
#55Earlier 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.
they're just as likely to use a different site instead.
Re: When to use web workers
#56Hey @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
Re: When to use web workers
#57If you really care about the performance of your site on the mobiles that poor people use then render server-side as much as you can.
But they may have a bad network connection as well.
Correct me if I'm wrong, but isn't one of the uses of web workers to do resource management via local storage, so that multiple tabs can share one set of resources?
Not everybody is using web workers for that, but that could address both issues to a degree.
Re: When to use web workers
#58Earlier quoted context omitted.
I don't really publish libraries so I didn't run into your main gripe. Is there any other reason why you didn't like worker-loader? I experimented with it and found it pretty straightforward. For anyone who wants to try it, you can even get it working from a create-react-app project with the webpack inline loader syntax without ejecting: /* eslint import/no-webpack-loader-syntax: "warn" */ import Worker from 'worker-…
Would it be possible to draw off screen or canvas somehow? To preserve WebGL compatibility while still using the workers?
Re: When to use web workers
#59Earlier quoted context omitted.
Can someone explain why the ES standard doesn't have something like this: new Worker(function(params) { ... compute heavy stuff here ... });
The problem is mostly in that all these functions are closures, and scope can’t easily be transferred. Domenic and I have been working on a proposal[1] called Blöcks to introduce transferable functions to JavaScript. In the meantime, I wrote Clooney[2] ontop of Comlink[3] that gives you almost that. [1]: https://github.com/domenic/proposal-blocks [2]: https://github.com/GoogleChromeLabs/clooney [3]: https://github.co…
Oo, I'm really interested that you're working on that, although I don't love the syntax (particularly `worker` seems awkward).
It seems like you should stick with function invocation syntax:
`worker = (endpoint) => {| block |}`
`worker(endpont) // does what you want`
with the difference that the result isn't a closure. As a bonus this syntax would let you write 'pure functions' even if you weren't working with workers. Perhaps the worker version then is `worker = async (endpoint => {| block... |}`.
Although considering the precedence for `async function` maybe the way to do this ought to be `pure function`.
Re: When to use web workers
#60My experience with Web Workers was terrible. It's not because of the Web Workers itself but there is no proper standard way to use modules inside of the worker. Because it requires a separated .js file to instantiate, bundlers like webpack tend to introduce weird and non-standard way to work with [1]. It is usually fine when you use it your own project since you are going to stick with a bundler you choose anyway, bu…
I did a thing where I used data URIs instead of explicit files to load up web workers. Don't know if that still works, as this was a few years ago, but it definitely helped a lot with those sorts of issues at the time.