Live data from Hacker News

Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

github.com

11–20 of 63 posts

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#11
post #2

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

In JS async/await returns a promise. In Python you have asyncio.ensure_future() to schedule coroutines. You can always call async code from sync code.

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#12

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

Thanks for the feedback.

"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

#13
post #8

Earlier 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.

I think the claim was: One async function (which of course returns a Promise under the hood) forces all surrounding functions to be also asynchronous (return a promise). Of course you could start an async operation from any function -> Just call the async function and ignore the result. But in order to do something with the result and return a transformed version of it the surrounding function has to be async (return a Promise, accept callbacks, etc) too.

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

#14

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

> The module pattern is pretty well known and you can use it to return a singleton.

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
Could 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, security is important!

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#16

Could 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.

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#17

Could 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 don't see the problem if userId is guaranteed to be just an id.

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

#18

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

[deleted]

Re: Show HN: Nsynjs – JS engine with stoppable threads and without callback hell

#19
Reminds me of `node-fibers`[1]

    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

#20
post #2

What'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.

Post reply on HN