11–20 of 46 posts
The example could be better chosen. Why execute an action that is already async like fetching a url on a different thread?
Greenlet would execute the function in an entirely different thread, which isn't possible without the Web Worker API.
Someone please correct me if that's wrong!
The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...
This is really a util method to simplify the call syntax for a web worker.
The example could be better chosen. Why execute an action that is already async like fetching a url on a different thread?
I'm not a browser expert, but my understanding is that JS is still single-threaded in the browser, despite allowing asynchronous functions. Greenlet would execute the function in an entirely different thread, which isn't possible without the Web Worker API. Someone please correct me if that's wrong!
That means that any I/O doens't block the main thread, and other parts of JS can execute.
This example provides literally no benefits, and actually is a performance hit from converting the data from JSON, then sending it back to the main thread (which itself copies the data in a method similar to converting back to JSON then back to an object again in the main thread).
This is off-topic, but at the top of the readme is this: > The name is somewhat of a poor choice, but it was available on npm. npm has supported scoped packages [0] for years now, and it's a fantastic solution to this problem, as well as solving many others (like typosquatting in many cases). I know this package is already named, but I really urge people to use scoped packages more. [0] https://docs.npmjs.com/misc/sc…
This is off-topic, but at the top of the readme is this: > The name is somewhat of a poor choice, but it was available on npm. npm has supported scoped packages [0] for years now, and it's a fantastic solution to this problem, as well as solving many others (like typosquatting in many cases). I know this package is already named, but I really urge people to use scoped packages more. [0] https://docs.npmjs.com/misc/sc…
Why not making scopes mandatory, to fix these issues once and for all? Wait, that's what GitHub did for 10 years ...
What I would like to see is all new unscoped packages being able to be installed/required by their scoped version by default. So if I create a package `coolThing` in npm entirely unscoped, it would be installable by doing `npm -i @Klathmon/coolThing` and by doing `npm -i coolThing`
That would let many of us to use the benefits of scoped packages without the package authors having to do anything. And it would be a big step toward going completely scoped at some point in the future.
The example could be better chosen. Why execute an action that is already async like fetching a url on a different thread?
The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...
It's not just line 18, I barely have any idea what any lines are doing. Single letter variable names are almost always a bad idea except in one case, using `i` as an index, and even then I don't do that any more because `index` is more obvious.
Earlier quoted context omitted.
I'm not a browser expert, but my understanding is that JS is still single-threaded in the browser, despite allowing asynchronous functions. Greenlet would execute the function in an entirely different thread, which isn't possible without the Web Worker API. Someone please correct me if that's wrong!
It's single threaded, but with async I/O. That means that any I/O doens't block the main thread, and other parts of JS can execute. This example provides literally no benefits, and actually is a performance hit from converting the data from JSON, then sending it back to the main thread (which itself copies the data in a method similar to converting back to JSON then back to an object again in the main thread).