This may be of general interest to some of you. Especially upcoming support for Numerical computing and ML in JS.
https://blog.sourcerer.io/why-is-a-java-guy-so-excited-about-node-js-and-javascript-7cfc423efb44
Have a feeling I am going to regret adding my $0.02 here, but I’ve watched some of these discussions with amusement and apparently have enough cough medicine in my system to bite…
As someone who spends a LOT of time working with node/js, I can’t disagree more. Node, in my experience, for most real products (as in, things that you need to maintain) is terrible. Javascript is just not a good language to maintain a project with once it scales to hundreds or thousands of modules. Even Node’s creator has said that – he’s trying to fix many issues with his Deno project which is typescript based. The lack of concurrency and single process event model is nice until you run into its limits, and then you’re dealing with scaling to multi-process architectures that again feel like half-baked add-on solutions. That’s because they were.
NPM being superior to maven is also laughable at best. More accessible? Sure. Nicer CLI? Ya. More options? Yep.
However, it’s nowhere near as stable or reliable, which is to say nothing about the packages you actually download. The quality of 3rd party java libraries is on average MUCH higher and much more stable than npm packages. Turns out that if you create a widely accessible package manager and make it easy for ‘3lite w3B h@xx0rs’ to build and published things, your platform quickly fills with junk. Beyond that, node_modules hell makes the old ‘classpath hell’ of java seem like a picnic, only you don’t even have the luxury of compile-time errors. Instead, you get to write thousands of unit tests to test code that would be automatically checked by a compiler in a statically-typed language.
There are tools now to help with scaling project size (lerna, yarn, bolt, typescript’s newer workspace support, etc), but again, they are immature, break CONSTANTLY with minor releases, and often flat-out fail to work on Windows.
The Java Guy complains a whole lot about Spring, EE, and a bunch of other Java framework monstrosities, and I do agree with him there. But those things are not Java, they are frameworks built on Java. If you choose to use a giant framework that is filled with magic annotations, reflection and code generation just to work, then yes, you’re probably going to feel like you don’t really know what’s happening. Because you don’t. So… just don’t use those terrible frameworks? Things like Spark (the web framework for Java and Kotlin, not the Apache data thing), Vert.x, Deft, Grizzly, Javalin, Ktor… there are a TON of performant frameworks that run on the JVM. Many of those I named off the top of my head are event-driven frameworks if that’s your thing. And unlike node, you get the very best ml/ai libraries – the ones the giants use. Not just javascript ports.
Java isn’t perfect and does have some issues: boilerplate is arguably one, but as it turns out, when you start maintaining a code base which has millions of lines of code, that boilerplate often serves a purpose and provides structure. It’s self-documenting in many ways js could never dream to be. Yes, it can go too far (see enterprise hello-world as a humorous demonstration), but a bad programmer will find ways to write even worse and less maintainable code in js.
I will say: Typescript has been a breath of fresh air in the javascript/node world, and we’ve moved essentially all our new front-end work to use it (including perspective). It definitely makes for a more maintainable code that can be reasoned about, refactored and maintained in ways JS could not dream of. You get to keep the good sides of of the JS language, while not suffering nearly as much from the bad sides. From a tooling angle - I am also looking forward to Yarn’s new PlugNPlay dependency management system which breaks from node_modules and actually looks to function much more like Maven/Ivy.
That all said, Javascript is a useful language for the purposes it was created for: small scripts, dom interaction, small utilities, prototyping, etc. But if you talk to engineers at places who moved to Node backends at scale (think Netflix, Walmart), they almost universally regret it and many teams are actively migrating to something else – typically Java/JVM, but Go is getting more popular too. Node has one notable benefit: server side rendering for purposes of SEO. Its story there is better than Java if you want to write single page applications that are served more statically to get better search engine optimization.
Once we get a full dom api and garbage collection for webassembly, I will be very surprised if javascript doesn’t slowly fall to obscurity. Even now, Typescript is quickly catching up and will probably become the default language of professional front-end developers within 5 years.
For all these reasons and more (I cut a bunch because my rant is already long), I wouldn’t pick Node for a long-term server project. If we could snap our fingers and instantly rewrite Ignition from scratch in any language we could, we’d almost certainly end up back on the JVM (Java or maybe Kotlin), or maybe something like Go, but it would almost certainly NOT be NodeJs.
15 Likes
Agreed TS is better than JS and NodeJS is not good for large projects like Netflix, Walmart, and is bad for maintenance, scale-ability etc. However for smaller applications I think NodeJS is still a good solution as you can get started and develop and test and deploy quickly, but it may quickly run to its limits beyond some size and complexity of the application.(A realization that may come after actually trying it out on a large application).
Must be some pretty good stuff. (-:
Not that I minded.
5 Likes
With so many likes I am sure you are not going to regret, it was worth it!
Hah,
No regrets I suppose, I stand by it all, but still probably wasn’t the right place to rant. Think this thread just happened to coincide with dealing with some node/npm ecosystem scaling issues of my own, and I guess Java Guy’s naive bliss (despite his apparent experience) irked me.
But if it helps one person think a bit before jumping into what might be an unfortunate platform choice, then I’m happy.
4 Likes
I am glad to see some reaction at least to this blog. Indeed the typed languages take care of 50% of bugs creeping in to the system. Bugs in JS due to its silent working with untyped code can be a nightmare to debug that I have experienced myself. Another thing I have experienced is dealing with its non sequential asynchronous nature for which we have to resort to promises and async/await functions can be mind boggling as compared to JAVA’s sequential threaded code, though it results in compact and cryptic code. JS’s simplicity could be a double edged sword! I haven’t come across the node_module hell problem so far as I haven’t developed large packages using Node/JS.
Even if JS can be replaced with TS in NodeJS it will improve it significantly. JS may be bad but the concept of single threaded server is not bad I guess. NodeJS definitely offers some advantages after all so many people using it are not all fools!
I personally like JS a lot.
- The async/await style makes it very easy to reason about async code (you can almost reason about it like synchronous code), it’s a huge improvement over callbacks, and certainly less error-prone than threading.
- Typing variables isn’t needed IMO, I tend to do most of my work in untyped environments like Python or JS, and rarely encounter type bugs (the simplest unit tests will catch these, and you need to test anyway)
- JS also has the advantage of not being controlled by a single entity, there are 3 big competing JS engines, all trying to implement the same standard (hello SQL), all trying to be completely backwards compatible (hello Python), and none can lure you into licensing or release-schedule changes (hello Java)
If you are able to use the latest and greatest JS features, it’s a very nice language to code in.
I agree however with the npm issue. The quality on npm isn’t that great, you often have to make small fixes when you want to use a library. One of the causes is that there are huge dependency chains, and a single change in a dependency deep down can have a huge consequence. And even when an npm package has a good quality, the freedom in JS often means many packages use a different style (like callbacks vs promises), and are hard to combine into a consistent code base.
2 Likes
Some of the core packages like express, net, http, socket.io, fs, os, mysql, mongodb are quite robust and stable in my opinion. I didn’t experience a quality issue or any other issues you mentioned, with these libraries. These libraries are good enough to write a normal web application on server side.