What'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
Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
11–20 of 63 posts
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#12So 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: Th…
"wrapper to setTimeout...This seems overly complex and unintuitive"
Typical web app most likely would have very few wrappers ($.ajax, setTimeout, etc), and they need to be written only once. But then everywhere in nsynjs-executed code you can just use them, connect with any necessary logic that JS can offer (not only by chaining .then...then.), without thinking what function is async/await and when it actually executed. My intention was to be able to write logic on JS in step-by-step manner the same way as if it was Visual Basic.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#13Earlier quoted context omitted.
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.
Maybe the confusion was the async here has two meanings:
1. asynchronous in general, which means it doesn't return a result immediately, but returns it through a Promise which is fulfilled later or a callback.
2. Using the async/await syntax. As we all agree this one is just sugar around Promises.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#14So 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: Th…
How would you even make it _not_ return a singleton? I thought that was default.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#15> 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, security is important!
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#16Could 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…
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#17Could 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…
This can be done, for example, by testing it before the SQL call. In that case, it's safer than most pointer-dereferences done in C++.
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#18Could 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…
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#19 var Fiber = require('fibers');
function sleep(ms) {
var fiber = Fiber.current;
setTimeout(function() {
fiber.run();
}, ms);
Fiber.yield();
}
Fiber(function() {
console.log('wait... ' + new Date);
sleep(1000);
console.log('ok... ' + new Date);
}).run();
console.log('back in main');
It is used heavily in meteor[2]1: https://github.com/laverdet/node-fibers 2: https://github.com/meteor/meteor
Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell
#20What's wrong with async/await?
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.