Ask HN: How difficult would it be to produce a “synchronous” fork of Node.js? | Hacker News Reader

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

2 pointsdools10 comments

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?

View on HN

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.

So the v8 runtime can be executed directly to run nodejs code instead of calling node on the command line?

like if I had some node code I could execute with:

node mynode.js

can I do:

v8cgi node.js

also?

Like https://www.squarefree.com/shell/ maybe?

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

Hmm well not really. I just mean something where you can run all normal node code but like this:

node --sync mynode.js

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

If blocking the event loop means the event loop isn't the event loop then why do people say "don't block the event loop" and how would you describe synchronous versions of functions like readFileSync and so on?

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.

If I have a bunch of node code, can I execute it in C# from the command line on a linux box without changing the code at all?

Also the async/await stuff doesn't really make node synchronous, because you still have to wrap your await in an asynchronous function.

I use sync versions of library methods and sync-request to make things synchronous, but I'm just wondering what the process would be to "disable" the asynchronous behaviour of nodejs and make everything blocking by default.

> If I have a bunch of node code, can I execute it in C# from the command line on a linux box without changing the code at all?

No, C# is a different language. The syntax should be familiar to someone who has written JavaScript (especially TypeScript), Java, or any C-like language.

> Also the async/await stuff doesn't really make node synchronous, because you still have to wrap your await in an asynchronous function.

No, you don't[1].

But even when you did, what's the difference to you? You can just wrap all the way up to the top level. The node CLI doesn't care if it's executing a top-level async function or not. You could have async/await syntax available to every line of code you write.

> I'm just wondering what the process would be to "disable" the asynchronous behaviour of nodejs and make everything blocking by default

Part of the reason Node has asynchronous* behavior is because it's part of the ECMAScript standard.

So to answer your question, to disable the asynchronous code, you would have to either:

A) Stop using any libraries that use callbacks or return promises

B) Stop using JavaScript

That's why I suggested C#. It doesn't make sense to say, "How hard would it be to change this fundamental design decision in this language?"

If you don't like it, just use another language. Or use the built-in syntactical sugar (async/await) that make it feel like a synchronous language.

1. https://pprathameshmore.medium.com/top-level-await-support-i...

* I am aware that JavaScript is single-threaded and blocking, but I'm using "asynchronous" as shorthand for "programming in an asynchronous style".

Okay so top level await now let’s you stick await in front of anything you want to block… so what about a change to the runtime that just defaulted to that?

Also Google Apps Script has a blocking v8 runtime so I’m pretty sure that what I’m asking for isn’t some sort of oxymoron or logical impossibility

Reply on news.ycombinator.com