
Greenlet – Move an async function into its own thread in the browser - rbanffy
https://github.com/developit/greenlet
======
mxstbr
Worth mentioning: workerize[0], which Jason released a couple weeks ago,
allows you to move entire modules to a web worker.

greenlet is a bit like "workerize-lite" in the sense that it allows you to
move individual functions to their own thread.

Also relevant: a discussion with Jason yesterday about when it's worth moving
functions to a web worker:
[https://twitter.com/mxstbr/status/957312201987063808](https://twitter.com/mxstbr/status/957312201987063808)

[https://github.com/developit/workerize](https://github.com/developit/workerize)

~~~
dh-g
workerize looks very nice. I've used
[https://github.com/borisirota/webworkify-
webpack](https://github.com/borisirota/webworkify-webpack) in the past but
wasn't 100% satisfied.

Does anyone know of write-ups documenting performance of the various methods
of pushing data to and from WW across different browsers?

------
michaelmcmillan
The code could use some work. I have no idea what's going on L18.

[https://github.com/developit/greenlet/blob/master/greenlet.j...](https://github.com/developit/greenlet/blob/master/greenlet.js#L18)

~~~
Klathmon
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.

~~~
developit
Agreed! There's an open issue to address this - the single letter names are
silly, since they get uglified anyway.

~~~
Moter8
Yeah, saw the comment and opened an issue :D

------
whalesalad
The name is certainly misleading. Green threads (greenlets) are a totally
different concept entirely.

This is really a util method to simplify the call syntax for a web worker.

------
callumlocke
> ️ Caveat: the function you pass cannot rely on its surrounding scope, since
> it is executed in an isolated context.

That's a pretty major caveat and makes the project's tagline basically false.
It's just a hacky way to spawn a Web Worker on the fly by evaluating a string
that was made by coercing a local function declaration into a string.

------
bwindels
The example could be better chosen. Why execute an action that is already
async like fetching a url on a different thread?

~~~
untog
JSON parsing (also in the async function) is CPU-heavy, though. If you had a
huge, huge amount of JSON it might be worth it. Maybe.

~~~
Klathmon
Not in this case, because copying data to and from a web-worker uses
"Structured Copy" which is about as fast as JSON unmarshaling, but in this
case it's actually doing significantly more work:

* read request

* parse from JSON to an object

* read the data from the object in the worker to the main thread

* create a new object in the main thread with the data from the worker

Those last 2 steps are about as slow as a JSON.stringify and JSON.parse, and
are completely unnecessary. As others have said, adding some filtering to the
example makes this example worlds better.

------
gbuk2013
JS, browser only (uses Web Worker).

~~~
smt88
These two details should be in the title.

------
AshleysBrain
On a related note, we could use Proxys to have pretty good cross-worker APIs
handled automatically, but unfortunately we need cross-heap collection for it
to work: [https://www.scirra.com/blog/ashley/38/why-javascript-
needs-c...](https://www.scirra.com/blog/ashley/38/why-javascript-needs-cross-
heap-collection)

------
Klathmon
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/scope](https://docs.npmjs.com/misc/scope)

~~~
vog
Why not making scopes mandatory, to fix these issues once and for all? Wait,
that's what GitHub did for 10 years ...

~~~
lhorie
Would it though? I've noticed a trend of libs being created under orgs of the
same name, e.g.

\- [https://github.com/angular/angular](https://github.com/angular/angular)

\- [https://github.com/rollup/rollup](https://github.com/rollup/rollup)

\- [https://github.com/cherow/cherow](https://github.com/cherow/cherow)

\-
[https://github.com/hyperapp/hyperapp](https://github.com/hyperapp/hyperapp)

Wouldn't we end up with a similar situation?

~~~
Klathmon
It does at least partially solve the problem of "typosquatting" where
installing `anglar` could potentially be a malicious version. It makes it more
obvious when it's happening (oh, you setup the `anglar` and created a ton of
typo'd packages with a few lines changed each? That's probably safe to ban...)

It also allows those orgs to group "sibling" or sub-packages under their main
name. So I know that `@angular/cool-angular-plugin` is actually from angular.

~~~
lhorie
I get the benefits of namespacing. I'm just not sure making it mandatory
solves any issues. For example, what's stopping someone from publishing
`@developit/greenlet` or `@greenlet/greenlet` without owning the respective
org/username in github?

~~~
Klathmon
Nothing is stopping that.

But for the downside of "having to type a little bit more", I think it's more
than useful enough at what it does fix/solve.

In other words, it solves between 0 and "a bunch" of problems for packages,
and the downside is fixed at "needs to type a little more".

Even in the worst case, it's not that much harm, but in the best case could
prevent exploits.

------
rattray
@dang, can the title be modified to include the programming
language/environment? (browser-only JS)

~~~
dang
Sure.

Btw it's better to email us (hn@ycombinator.com) than to try to get our
attention this way, since we don't come close to seeing all the comments, or
even all the threads.

~~~
rattray
Oh cool, gtk! Today I learned.

