How is this an improvement over `await` and `async`?
Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
31–40 of 63 posts
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#32I 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.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#33Earlier quoted context omitted.
Not that big of an if. The id was most likely pulled out of the database itself in cases like: >friends: dbQuery("select * from firends where user_id = "+userId).data
or it was pulled from a GET parameter. The point is that regardless of where it came from parameterized queries are a staple of programming now, and having an example without it would be like having an example of a login system be if (username in db && password in db) { login() }
I'd much rather read a straightforward example like that in an intro, then reading the complicated prepared statement when going through what's essentially pseudocode.
There are valid cases where you're sure that the thing you're looking at is a valid id (ie. you already pulled it out of the database or by generating it yourself), not every program is a webapp that's handling user input, and examples like this aren't meant to teach you best security practices.
And yes the login system example would be acceptable if you're discussing something entirely unrelated to actually implementing one.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#34Could you please not advocate SQLinjection in your example code? > friends: dbQuery("select * from firends where user_id = "+userId).data, > comments: dbQuery("select * from comments where user_id = "+userId).data, > likes: dbQuery("select * from likes where user_id = "+userId).data I'm no js developer, but there has to be a way of using prepared statements, even if just for sample code. It's not 2001 anymore, securi…
I agree with you. It's just for illustration purposes I intentionally oversimplified it to pseudo-code.
That's the wrong thing to be oversimplifying, tbh.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#35Earlier quoted context omitted.
or it was pulled from a GET parameter. The point is that regardless of where it came from parameterized queries are a staple of programming now, and having an example without it would be like having an example of a login system be if (username in db && password in db) { login() }
I'd much rather read a straightforward example like that in an intro, then reading the complicated prepared statement when going through what's essentially pseudocode. There are valid cases where you're sure that the thing you're looking at is a valid id (ie. you already pulled it out of the database or by generating it yourself), not every program is a webapp that's handling user input, and examples like this aren't…
I think the disconnect here is that a prepared statement isn't really more complicated. As pseudocode it's more like
dbquery('select * from friends where user_id = $1', userId)
And the benefits of prepared or parameterized statements don't end at security, they can often have performance benefits as well.
And as for the login pseudocode, if it doesn't have anything to do with the example, hide the implementation:
if (userIsAuthenticated === true) { login() }Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#36[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.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#37Earlier quoted context omitted.
I'd much rather read a straightforward example like that in an intro, then reading the complicated prepared statement when going through what's essentially pseudocode. There are valid cases where you're sure that the thing you're looking at is a valid id (ie. you already pulled it out of the database or by generating it yourself), not every program is a webapp that's handling user input, and examples like this aren't…
I think the disconnect here is that a prepared statement isn't really more complicated. As pseudocode it's more like dbquery('select * from friends where user_id = $1', userId) A few extra characters is all it takes. And the benefits of prepared or parameterized statements don't end at security, they can often have performance benefits as well. And as for the login pseudocode, if it doesn't have anything to do with t…
I've been enjoying sql-template-strings lately, which build on ES6 tagged template literals so you get the best of both worlds:
dbquery(sql`select * from friends where user_id = ${userId}`)
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#38Earlier 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 ?
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.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#39What'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.
When calling a function, you know what arguments/parameters to use, right!? Then you also know if it's sync or async. The browsers way of dealing with async seems to be forgotten, for example:
button.onclick = buttonClicked;
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#40The JavaScript callback hell thing is pretty much solved now isn't it?