
Show HN: Nsynjs – JS engine with stoppable threads and without callback hell - kidstrack
https://github.com/amaksr/nsynjs
======
wwwigham
So it stringifies the function you give it, splits it into its component bits
of execution, then interprets the contents alongside a state machine (with
judicious use of bits concatenated together and eval'd). Interesting, for
sure. AFAIK there's no preemption mechanism (or resource management), so all
it does is make your code execute asynchronously - very asynchronously - the
every-line-interwoven-randomly kind of asynchronously.

I do love me some metaprogramming, but is there a real scenario where you'd
want something as dangerous as this compared to a generator (or a system of
generators)? They have very clear atomicity guarantees (things between yields
will happen synchronously), unlike what this ends up decomposing your code
into. I suppose that's just the cooperative vs supervised threading debate,
though?

------
BinaryIdiot
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:

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.

~~~
Kiro
> 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.

~~~
svckr
One way is to delete entries from `require.cache`.

Either way you _might_ get a separate instance if npm decided that your module
and another module require different version of a given module. These would
both be singletons though. Just singletons of instances of different versions
of the same module.

------
drinchev
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](https://github.com/laverdet/node-
fibers) 2:
[https://github.com/meteor/meteor](https://github.com/meteor/meteor)

------
Neverbolt
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!

~~~
kidstrack
I agree with you. It's just for illustration purposes I intentionally
oversimplified it to pseudo-code.

~~~
Kudos
That's the wrong thing to be oversimplifying, tbh.

------
modarts
What's wrong with async/await?

~~~
q3k
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).

~~~
cdata
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.

~~~
Jim99
As someone who has been around for a long time and manages teams using many
different languages (C,C++,C#,Java,Python,JavaScript) my JavaScript/Web teams
are the most problematic in terms of cost/performance/gating
bugs/upgrades/multi-platform support. The JavaScript critiques that you see
are just an expression of the time and resources being wasted.

~~~
cdata
Where in the stack did you spend your time before you became a manager?

------
vbezhenar
I'm using ES6 async/await and I can't be happier, async programming is almost
sane now. The only drawback is that you have to remember that it's all syntax
sugar about Promises and they are just a bit more than syntax sugar about
callbacks, so you have to understand how each async thing works or you'll be
mad. But when you know those things, you can be asynchronously productive.

------
Can_Not
Sightly 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.

------
forgottenacc57
The JavaScript callback hell thing is pretty much solved now isn't it?

~~~
k__
yes. I also never had it in the first place.

~~~
coldtea
Having to manually handle callbacks (and error callbacks) is the hell in
itself.

~~~
k__
Fair enough :D

------
nialv7
I can't quite see the need of this now we have async/await.

~~~
meirelles
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.

~~~
z3t4
async/await doesn't change the fact that we have two types of functions, async
and sync.

------
tobyhinloopen
How is this an improvement over `await` and `async`?

