Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
1–10 of 63 posts
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#2What's wrong with async/await?
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#3What's wrong with async/await?
It's a kludge. Syntactic sugar to remove one level of nesting.
Other languages come either with great concurrency support out of the box (Go, Erlang) or enough constructs to implement cooperative schedulers without having to specify async/await (Lua).
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#4What's wrong with async/await?
It's a kludge. Syntactic sugar to remove one level of nesting. Other languages come either with great concurrency support out of the box (Go, Erlang) or enough constructs to implement cooperative schedulers without having to specify async/await (Lua).
What's wrong with that?
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#5What's wrong with async/await?
It's a kludge. Syntactic sugar to remove one level of nesting. Other languages come either with great concurrency support out of the box (Go, Erlang) or enough constructs to implement cooperative schedulers without having to specify async/await (Lua).
Not disagreeing, but as a long time JavaScripter it is remarkable to me that no matter how delightful or expressive or ergonomic the language tries to become, the same old criticisms manage to evolve with it (this may not be unique to JS).
[Edit] JS has long been criticized (fairly or not) for offering clunky "concurrency" strategies. If you must down vote, please have the decency to offer a counter perspective.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#6What's wrong with async/await?
2 main reasons:
1. If some nested function is async/await, all the callers (and whole graph) need to be converted to async/await. I feel that language shouldn't force programmer to do this type of tedious work.
2. It's not compatible with some browsers, only via Babel
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#7So interesting project! I'm skeptical on the practicality of it but it's still interesting.
>> global.nsynjs = global.nsynjs || require('nsynjs');
Don't do this. The module pattern is pretty well known and you can use it to return a singleton. Global has some built in node.js stuff but I wouldn't mess with it.
>> Example of wrapper to setTimeout, that will be gracefully stopped in case if pseudo-thread is stopped:
This seems overly complex and unintuitive. Also, there are lots of references to `synjs` but the project's name is `nsynjs` which seemed confusing to me.
Honestly, like I mentioned at first, cool project but callback hell is very easy to avoid even without Promises or async / await as long as you follow solid development patterns.
I would be interested if you have benchmarks / comparisons against callbacks, promises and async / await.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#8What's wrong with async/await?
2 main reasons: 1. If some nested function is async/await, all the callers (and whole graph) need to be converted to async/await. I feel that language shouldn't force programmer to do this type of tedious work. 2. It's not compatible with some browsers, only via Babel
#1 is a misleading claim. An async function returns a promise when called, which can be used in any non-async context.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#9What's wrong with async/await?
It's a kludge. Syntactic sugar to remove one level of nesting. Other languages come either with great concurrency support out of the box (Go, Erlang) or enough constructs to implement cooperative schedulers without having to specify async/await (Lua).
If you have callbacks, you end up with hard to read and debug code.
If you have transparent async, then:
Then how do you know what blocks and what doesn't ? What's asynchronous and what's going to trigger a switch ? What's a disguised callback and what's the next line ?
What's the solution then ?
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#10What's wrong with async/await?
While I don't use async / await right now, mostly because it's not natively available in all of the target browsers I want to use, I'm not the biggest fan of the pattern. It takes previously asynchronous functions and makes them appear as synchronous. The worst part is with some asynchronous methods you can't use async / await so now you have synchronous and asynchronous code that appears identical while also having some other asynchronous code that appears more traditional.
Overall it just ends up being a bit inconsistent for my tastes. But I like that we're trying more things to evolve the language to avoid common pitfalls like callback hell