The Argument Against JS:
…(skipped for brevity)…
- NPM is such a good and bad experience. Compared to some other package systems its kind of messy. The other issue is that they have this
“microservice” where instead of writing a one line piece of code they instead pull from NPM to get the same thing done. There was an issue a few months ago where one developer removed his package that thousands of people depended on, and it caused a “dependency hell” per se.
- Too many kludges to make it imitate OO
- Poor unittesting tools.
The arguments above use Python as a language reference point. That’s great! I have used Python for years and love it as well; so I will focus on comparing JS with Python.
1. (Terrible) Language Tricks
Python has it’s share of weirdness that people use and had a rather large set of breaking changes with Python 3. Let’s read from the official sources about Python 3:
There are more changes than in a typical release, and more that are important for all Python users. Nevertheless, after digesting the changes, you’ll find that Python really hasn’t changed all that much – by and large, we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft.
Python had (still has) a big problem with Python 2.7 -> Python 3 upgrades. Even now, years later, many projects still rely on 2.7 and haven’t upgraded. That situation would never work on the world wide web!
Your argument is against how people have used NPM, not against NPM itself. And the issues you cited are definitely problems, but they are problems for every package manager that reaches the nexus of popularity and ease-of-use. RubyGems had the exact same problem with excessive “micro-gems” 10 years ago.
And that NPM “left-pad” issue that broke everything earlier this year … yeah that could still happen on NPM, PyPi, RubyGems, INSERT_PACKAGE_MANAGER. Nothing special/bad about NPM made it happen. Just that a guy decided to be a jerk and remove a package that everyone depended on.
Patently false. Microsoft, Google, Facebook, Walmart, Mozilla, etc. have poured so much time, effort, and money into the JS ecosystem (specifically Node.js, NPM, and JS Engine implementations) that it has become one of the most stable platforms you can be on. And don’t forget the JS language guarantee that language features can’t be removed until most websites stop using them. Even among browsers, the consistency of good implementation of JS features is at an all time high.
Any instability in Node.js specifically has been largely mitigated with the new release process (Stable and Current distributions). The only “instability” to speak of is the massive volume of updates that V8 goes through to keep up with ECMAScript features, and those only matter to the native library maintainers not using node-gyp (which most use afaik). And even then, Google and Microsoft now work closely with Node.js maintainers to help with API changes in their JS engines.
5. Not OOP
Everything in JS is an object. It just doesn’t use Classical OO. Your argument sounds more like you mean Classical OO vs. Prototypal OO. JS is the latter, and it is just as Object-oriented as Classical; but fundamentally different because Prototypes are objects as well and can be changed at runtime. To help people wrap their heads around prototypes, ES6 even introduced the keyword
class (although I’m not a big fan of it). In some ways, prototypes are a more true and powerful kind of OOP. Classes were introduced after OOP landed and primarily to help with static-type checking, not to enable better OOP design.
6. No Unit Testing
10 years ago, who would have thought this about JS:
- Most widely used programming language on earth
- One of the fastest scripting languages ever
- Largest package ecosystem ever (npm)
- Popular as a server backend language