Live data from Hacker News

JavaScript is Eating the World

dev.to

321–323 of 323 posts

Re: JavaScript is Eating the World

#321
post #21

Earlier quoted context omitted.

Node is single threaded, in the sense that your code runs in a single thread. Your code assigns microtasks, to be executed later. Basically, if you write in Node JS, there's no concept of a thread. The thread API is not visible or accessible to the developer. This forces you to think from the ground up about asynchronous operations that would take some time to complete - file opening, network requests etc., and have…

> In Node, you are not supposed to block the event-loop that runs in that single thread and queues the tasks. well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?

>well, sure, but ten years ago it was already a given that one would just spawn one event loop per thread and have them communicate with messages, so why is it so hard for node ?

This is exactly how backend Node.js development is done. The tradeoff is that processes are used instead of threads, which uses more memory but is magnitudes easier to work with than traditional threads where mutable bits of memory are shared.

Sure, Rust solves these problems but Node still has a place in the world: it is established, easy to pick up, and can share code with the browser. A decent solution to modern web development complexity.

Re: JavaScript is Eating the World

#322

Earlier quoted context omitted.

It does: let's stop saying JS is great and be honest. The web is great. Despite JS.

and JS is one the major engines driving it forward.

No, JS is the one constraint we manage because it's the only stuff we got that is common to all browsers.

It's not driving anything, we keep hacking it to make it bearable. I mean, come on, the most popular projects in JS are all projects to avoid writing JS in the first place.

Re: JavaScript is Eating the World

#323

Earlier quoted context omitted.

If you are dealing with a single-threaded, non-concurrent problem, yes, that's true. Node isn't that. In my experience, the pitfalls of multi-threadedness are more around concurrency than they are parallelism, so that tradeoff strikes me as largely a false one.

I'd say the exact opposite. Race-conditions in parallelism are where the classic problems lie. We aren't going to agree here, but you sounded like you thought your position was axiomatic or something, and that's what I disagree with. Meanwhile I am content that we may have different preferences, that's not a problem.

Coming back to this, I'd really like to direct your attention to my reply. Am I missing something with regards to this?
Post reply on HN