This may be of general interest to some of you. Especially upcoming support for Numerical computing and ML in JS.
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…
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.
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.
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.
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.
With so many likes I am sure you are not going to regret, it was worth it!
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.
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.
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.