It’s not a matter of better or worse (in this particular case – there is such a thing as languages that are just plain bad). In my opinion, it’s just what you’re trying to do:

So Node uses a multiprocessing model where your program won’t be interrupted in unpredictable spots – there are very specific places where a function might pause waiting for something to happen, and give way to another function, but during ordinary (“synchronous”) operations you can be guaranteed that the program won’t be interrupted. That makes things hugely simpler because in general, you don’t have to mutex-protect your data structures, you don’t have as many weird subtle bugs that only crop up during certain thread interactions that are extremely difficult to debug. That’s the upside. The main downside is that because it’s a single-threaded model, which means (a) you can’t easily scale up your program to multiple CPUs and (b) if you have a long CPU-bound operation, it’ll happily block the whole rest of your program from executing no matter how many problems that causes. It’s excellent for network-I/O-bound workloads, because you’re probably not heavy on computation and it’s simpler to program and more robust than using multithreading in that case. Although, you do have to learn some new primitives and make sure to be careful with CPU-heavy operations. Then there are a lot of workloads where it’s awkward to try to use.

Java tried to do multithreading all the way from the ground up, to make everything thread-safe (which is actually pretty unusual for a full-featured runtime environment, because it’s a lot to take on). The upside is that if you need that, it’s gold; you can write your normal application and then run it on a 64-core processor and all of a sudden (relatively speaking) everything just works, which is great for massive-within-a-single-process scalability. The downside is that (a) you will get people who disagree vehemently with you on whether within-a-single-process scalability is worth the complexity cost you pay, and (b) if you’re just trying to write some code where you don’t care about threads, guess what? You have to care about threads. You need mutexes, you have subtle bugs and deadlocks, you have lots of extra testing headaches, or else: You can sort of close your eyes and run your Java application single-threaded, which defeats some of the purpose, and also God help you if later on you ever want to try to make it multi-threaded.

Neither one I would say is right or wrong. There’s a whole third way, which is actually what most environments do, which is that you say that a lot of things in the runtime aren’t thread-safe, and so if you want heavy scalability you do it with multiple processes, and if you need threads you need to take on the responsibility of tiptoeing around the non-thread-safe stuff. That’s sort of a mess, which is why both Java and Node take different more coherent approaches to it.

There isn’t one, java is excellent for async and multithreading and it does it properly unlike node that fakes it by running on a single clever event loop or stealthily launches a bunch of node instances in the background depending on implementation.