The JavaScript callback hell thing is pretty much solved now isn't it?
yes. I also never had it in the first place.
Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
41–50 of 63 posts
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#42Earlier quoted context omitted.
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 ?
embrace higher-order functions. Use named functions and closures!
example code:
var anchors = document.getElementsByTagName(“a”);
for(var i=0,len=anchors.length; iRe: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#43I can't quite see the need of this now we have async/await.
Me too. For the sake of sanity we should stick with async / await and forget the time we had to choose from dozens of different ways of doing async code (most of time requiring tedious wrappers). Lets the winner takes it all.
async/await doesn't change the fact that we have two types of functions, async and sync.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#44Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#45What's wrong with async/await?
Even as a huge async/await fan, this is a great explanation of the problem: http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y... VMs that offer lightweight, blocking, non-shared memory, threads provide a great developer experience. The Dart team was experimenting with this with the Fletch VM.
While it gives good insight to the problem of sync vs async functions, I've come to find its conclusions problematic (and it rather blatantly ignores Chesterton's fence), especially with "Java did it right, but they have started to do it badly now", and especially "Go has eliminated the distinction between synchronous and asynchronous code".
Ouch. You are going to think that - until your hit first deadlock or race condition.
While implementation quality of the "colored function" concept varies greatly (and JS async/await is not a good example IMO - look at C# for one that doesn't neccesarily suffer the "async all the way up" problem, for example), there are reasons it's so prevalent. Async is fundamentally different, and more importantly: In the end, it's all about the data.
That's why the most important part of goroutines is the channel/send/receive(EDIT: And especially select, of course. :)) implementation. And that's why the simple "go func" syntax itself or whether it's different from normal function is a bit of a red herring, since the implementation and data access/communication inside the function will likely be different.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#46Sightly related question, is there a library that
- takes in a function and returns a promise returning function
- the new function will use a web worker in the browser and something like a thread worker in NodeJs.
- isomorphic, as in same API in browser as in the server (so maybe usable in nextjs and nuxtjs based applications
Just curious if anything like that exists.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#47[flagged]
> Wrong wrong wrong wrong, wrong wrong wrong wrong! https://www.youtu.. . What kind of person do you have to be to act like this when people try to show what they have made? Very sad.
Have some sense of humor. I would not take that literally / seriously.
I would rather focus on the next paragraph which is the one that matters.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#48Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#49Earlier quoted context omitted.
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 ?
Why would you need to know, except in some special cases? If you're using async/await, your next line is not executing anyway until the result comes, blocking or not.
Because otherwise you block the even loop or mismatch life cycle. Espacially reading an unfamiliar code base.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#50Earlier quoted context omitted.
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 ?
embrace higher-order functions. Use named functions and closures! example code: var anchors = document.getElementsByTagName(“a”); for(var i=0,len=anchors.length; i
This makes anything but basic life cycles very hard to read.