throwawayblahhh

Single language is an advantage if you're trying to save money on hiring people that know both. We don't really share any code between our JS frontends and node backends, and I've never worked at a place that did. As far as I can tell that's a hopeful myth.

Working between languages is easy as long as you use a cross-language object format like gRPC.IMO single language is overrated and context switching cost is basically zero. Is it hard to switch between two verbal or written languages you know? People do it mid sentence, I don't see how it's any different with programming languages.

Node packages tend to be smaller but there's far, far more of them in an average project. And unlike Java they're not stored as zip on disk and class files when built, so in both cases they're using a lot more space. Java bytecode was designed to be compact like WASM, it takes way less space than even minified source and it's zip compressed for deployment into a jar on top of that.

Node dependancies being more fragmented is generally a bad thing. I constantly have to replace libraries when our code scanners find vulnerable npm packages that are no longer maintained. Since Java is far less fragmented I hardly ever have to do this with our Java codebases.

Node's standard libraries are terrible compared to Java and Python but I can't make a case for that besides saying they clearly are.

I agree with you on front vs backend being a bad comparison, but even our regular express apps take up more space and memory.

Java using lots of ram is also a myth. It might have been true many years ago, but Java generally uses about 1/3 the memory storing the same structures because there's a lot less overhead per object and field. The only reason most Java apps use lots of ram is because people configure the garbage collector to use as much RAM as possible so it collects less often. Node doesn't use as much ram because nobody really changes the GC defaults.

> I don't know, I feel like Node.js has a fairly full-featured and useful standard library?

IMO not really. We have many Java and JS projects where I work, I can't find a single Java project that has bigger dependencies than even our smallest JS project, or even an empty "create react app". One of our Java projects is 200k+ lines and still has smaller dependencies than create react app or a empty project created with angular cli.

In JS, it's normal to pull in 500+ libraries and this is only because the standard library is so lacking. Our Java projects, even massive ones, pull in less than 100.

In Java you also have Guava and Apache Commons. Those cover about 95% of data structure needs for a project not covered by the JVM. JS has nothing comparable.

People lament about how "big" the JVM is, but you trade complexity of the VM for complexity of your own app. In practice Java projects are smaller and use less space and memory because your dependencies aren't using 10 different libraries to pad whitespace.

This also makes it much easier to mentally transition between Java projects. If they were built in the last decade, they're probably using the standard library, Guava/Commons, hibernate, and some HTTP interface. I can move between Java projects at work no problem, but if it's Node or front-end 90% of the time I'm going to spend a few days learning a new framework to get anything done.

Small standard libraries are very harmful to the ecosystem. I hope to God they do it right with Deno, batteries included like Python and Java

I have seen too much come and go. I've mostly settled into Java on the back end and react front end. They have been around for a long time, and will continue to be. You can take a project many years old and easily modernize it.

I think all of us in the industry for a while have worked on "dead end" projects where many things were just unfixable because core libraries, languages, and frameworks are simply obsolete. These are, by far, the worst projects to work on.

Java is the perfect counter example. It's kinda verbose and has some annoying shortcomings, but all the tooling is top notch. It's one of the fastest languages out there and has the best debugging/build/monitoring/IDE tools of any language I've used. And it's rock solid stable, we have plenty of servers that run some hacky old stuff for years straight without a restart.

And the best part about Java is that I can find a library to do anything. I have never once ran into a technical roadblock in Java because I needed something unusual.

Most of these attributes are lacking in new languages. Rust has crappy IDE tools and debuggability, no good ORM, not many supported target architectures, no run time code generation. Golang has terrible package management, no generics, and a basic garbage collector that's fast except when it isn't. Node/JS threading support is a joke, the standard library is so small that most projects pull in over 100 megabytes of dependencies, and it's still a slow memory hog compared to Java/Go/Rust/C#.

Java doesn't have anything "terrible" about it compared to the glaring shortcomings in these newer languages. There's just been enough decades of use that everything has been smoothed over until it's at least decent.

I bounced between Perl, PHP, C# in my early days and I'm sticking with Java now. It's the easiest to work with. I'll pick up a new language when it's as good as Java, so maybe Go or Rust in another 5 years