Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Greenlet – Move an async function into its own thread in the browser

github.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Greenlet – Move an async function into its own thread in the browser

#31

Post by Klathmon »

lhorie wrote: post #29
vog wrote: post #16

Earlier quoted context omitted.

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

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/rollup/rollup - https://github.com/cherow/cherow - https://github.com/hyperapp/hyperapp Wouldn't we end up with a similar situation?

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.

Re: Greenlet – Move an async function into its own thread in the browser

#32

Post by thomasfoster96 »

smt88 wrote: post #12
michaelmcmillan wrote: post #6

The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...

If I had a desire to deeply understand JavaScript syntax, I'd probably use this as a learning task.

The syntactic complexity of line 18 isn’t really the issue (in fact, it shouldn’t really require a deep understanding of JS syntax), it’s the meaningless single-letter variable names.

Re: Greenlet – Move an async function into its own thread in the browser

#34

Post by gvx »

michaelmcmillan wrote: post #6

The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...

For future reference: https://github.com/developit/greenlet/blob/8f51450aab0e1f988...

(The issues that were discussed in this thread had been resolved by the time I wrote this comment, and so the link above pointed to the wrong commit.)

Re: Greenlet – Move an async function into its own thread in the browser

#35

Post by lhorie »

Klathmon wrote: post #31
lhorie wrote: post #29

Earlier quoted context omitted.

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/rollup/rollup - https://github.com/cherow/cherow - https://github.com/hyperapp/hyperapp Wouldn't we end up with a similar situation?

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-a…

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?

Re: Greenlet – Move an async function into its own thread in the browser

#36

Post by Klathmon »

lhorie wrote: post #35
Klathmon wrote: post #31

Earlier quoted context omitted.

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-a…

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?

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.

Re: Greenlet – Move an async function into its own thread in the browser

#37

Post by acdha »

lhorie wrote: post #29
vog wrote: post #16

Earlier quoted context omitted.

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

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/rollup/rollup - https://github.com/cherow/cherow - https://github.com/hyperapp/hyperapp Wouldn't we end up with a similar situation?

Each of those organizations has a number of other projects alongside the main ones. This seems like a good outcome since it allows them to easily refactor things into separate repos or manage support tools rather than having inertial pressure making it easier to lump things into a single main project.

Re: Greenlet – Move an async function into its own thread in the browser

#38

Post by michaelmcmillan »

gvx wrote: post #34
michaelmcmillan wrote: post #6

The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...

For future reference: https://github.com/developit/greenlet/blob/8f51450aab0e1f988... (The issues that were discussed in this thread had been resolved by the time I wrote this comment, and so the link above pointed to the wrong commit.)

Gah, that always gets me. Thanks.

Re: Greenlet – Move an async function into its own thread in the browser

#39

Post by 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.

Re: Greenlet – Move an async function into its own thread in the browser

#40

Post by yeukhon »

blurspline wrote: post #21
michaelmcmillan wrote: post #6

The code could use some work. I have no idea what's going on L18. https://github.com/developit/greenlet/blob/master/greenlet.j...

after the web worker executes its function, it post a message to the original context with 3 arguments - the call id (c), error string(e), the successful result object(d). the greenlet function when invoked returns a promise waiting to be resolved or rejected. the resolver and rejector functions are stored in object p with the key with a unique call id. so line 18 `p[c][e?1:0](e||d);` basically means resolve or rejec…

Wow! Nice! Thank you!! WOW!

I haven't touched Javascript for a long time, especially using shiny features in ES5, ES6... those arrows always throws me off. Is this a typical JS & NodeJS style nowadays? Does anyone ever feel your code and your co-workers' code are barely readable?

Disclaimer: Python programmer.

Post reply on HN