3 ms·

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 th

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.

kidstrack 9y ago
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.
Kiro 9y ago
> 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 9y ago
  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.
- BinaryIdiot 9y ago
  It is, I only meant that's a way it can be handled not that it wasn't common or anything.

kidstrack 9y ago

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.

Kiro 9y ago

> 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 9y ago
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.
BinaryIdiot 9y ago
It is, I only meant that's a way it can be handled not that it wasn't common or anything.