HACKER Q&A
📣 dools

How difficult would it be to produce a “synchronous” fork of Node.js?


There are times you want asynchronous behaviour, and times you don't.

Is there some part of the Node.js "event loop" where you could make a relatively small change that would mean all function calls were blocking rather than non-blocking?

Such that, if you wanted to run a node script from the command line, for example, you would only be able to achieve "concurrency" by starting more than one process?

  👤 tannhaeuser Accepted Answer ✓
You can just opt to use synchronous variants of I/O functions such as fs.readFileSync(). Or you could use alternate Server-side JavaScript (SSJS) runtimes implementing the sync parts of CommonJs (= the Node.js API) such as teajs/v8cgi, narwhal, Helma. Though I'm not sure those latter ones are still being maintained after Node.js became the dominant SSJS platform ten years ago, when those projects contributed to CommonJs, and made Node.js even possible through the CommonJs module convention. And I should add that JavaScript and v8 lack any mechanism for shared memory access/multithreading, like the JVM has.
👤 cratermoon
Like https://www.squarefree.com/shell/ maybe?

Or one of thses? https://developer.mozilla.org/en-US/docs/Web/JavaScript/Shel...

👤 outsomnia
> Is there some part of the Node.js "event loop" where you could make a relatively small change that would mean all function calls were blocking rather than non-blocking?

It's no longer an event loop then, is it. Blocking means that your thread is dead to the world.

You're better advised to learn more about how to use the event loop to get the behavior that you want.

👤 smt88
Modern Node is easy to write 100% synchronously using either async/await or the "___Sync()" version of standard library methods.

If you want truly synchronous Node, I'd suggest just switching entirely to C#. It's honestly a lot easier to write and deploy anyway.