Working with JavaScript is easier than ever before. The ecosystem is continuously expanding, and the entry bar is lowering.

But is this actually a good thing?

Disclaimer: I’m not a full-time JavaScript developer, only a few projects I’m working on are JS-based (React/React-Native, VideoJS, some browser stuff). And I’m often not very happy when I have to deal with it and its ecosystem, so be prepared a little ranting. This is my opinion, you don’t have to agree with me, I don’t want to evangelize you away from JS.

A brief history

JavaScript was born in 1995 at Netscape Communications in an attempt to turn the web into a full-blown application platform. Even a server-side JavaScript environment (Livewire) was created.

Its development took 10 days. In comparison, it took Sun Microsystems 5 years for Java to become a public 1.0.

JavaScript contains many great features and concepts. But the rushed development is showing on the edges, and we have to deal with its shortcomings to this day.

Jump forward to today

JavaScript, or ECMAScript, has become omnipresent. Thanks to Node.js, it’s no longer just a web platform for feature-rich web applications, you can now build your complete stack with it.

Multi-platform desktop apps, many CLI tools are built with it, even Microcontrollers support it, and so much more.

Getting better

The most widely used version (at time of writing this article), ECMAScript 6, tried to fix some of the issues JavaScript had since it was born. It’s a good step in the right direction. But the existence of compile-to-JS-languages and WebAssembly shows that the community yearns for more.

Facebook created Flow to deal with missing type-system, Microsoft created a whole language around the concept called TypeScript that compiles down to JavaScript to make it safer, typed, and better scalable with teams, thanks to really nice tooling support.

Getting more complicated

Due to its nature of rapid evolving, JavaScript seems to suffer under the constant need to improve its ecosystem. Every few months, a new great and shiny framework emerges that promises to be better/faster/smaller etc. than before.

But even worse than all the new frameworks is the constant change in project tooling. Every single project seems to use a different build system / packager, and even if you look at a single project, it might switch its build system with the next release.

Remember Grunt?
Or Gulp?
Maybe you’re using Webpack.
Or what seems to be the flavor of the month, Rollup.

Let’s see what you will be using in 3–6 months.

It sometimes feels we have more work keeping our build-/packager-system alive during a project than working on new features.

I know how alluring it can be to switch or build your own tooling to get the last little bit of optimization quite right. But as developers, we shouldn’t be needing to care so much about the finer details.

Being a full-time Java developer, I can tell you that Maven or Gradle aren’t the best build systems ever built for every edge-case. But what do we want from them? We want a consistent, maintainable build system, so we can maintain our code, not the build system itself.

Everything’s broken

Move fast and break things. Unless you are breaking stuff, you are not moving fast enough.
– Mark Zuckerberg

In my opinion, this quote is misunderstood most of the time.

Yes, moving fast is essential in today’s business environment. And some stuff will obviously break in the process.

But breaking it isn’t supposed to be the end of it… you need to fix it, too! Or you just end up with a broken system.

For your own little projects that might be ok. But building something with multiple people or some enterprisy stuff shouldn’t be in a constant state of being broken just for the sake of being fast.

Every time we update React-Native it’s hell because being fast is more important than being maintainable. Instead of fixing broken stuff, it’s more important to release new features, with their own set of new bugs. And most of the time it won’t reach 1.0 quality, instead, it will be replaced with another component or system.

Lower bar === lower quality?

Everyone who wants to enter the field of software development should be able to do so. Nobody should be forced to understand C/C++ in detail, or know how to write assembler first.

JavaScript is a simple and easy-to-grasp language with a fast way of seeing results, and it can be applied to almost anything. But it’s also a language with many flaws and pitfalls.

Writing functional and maintainable code is hard, it’s an art form you’ll need a lot of practice for, even better a mentor guiding you in the right direction. But with JavaScript, so much can be jumped over with its vast package system.

Everything you might need is already available as an NPM package. Actually, that’s a great feature of the ecosystem many other languages are missing.

And everybody can easily create and publish an NPM package for others to use!

Code duplication and reinventing the wheel can lead to so many problems, but as the left-pad fiasco showed that depending on external dependencies for everything might not have been the best idea. A few lines of code for a trivial function broke so many builds.

There are high-quality packages you can be sure about being around in the long-run. But the dependency graphs are getting longer every day. Are you using React-Native? So you now have 620 dependencies, with ~17 different licensing models. Are you sure all of these dependencies are future-proof?

Conclusion

The history of PHP and its ecosystem should have been a lesson for JavaScript. But it seems we might end up with something similar…

PHP is also a simple language, that runs almost anywhere, with lots of beginner-friendly content. You can build great products with it, but you could also build a big pile of shit. To make it more usable, Facebook created a dialect Hack of its own.

This kind of reminds me of all the compiles-to-JS languages or addons like Flow. A language should be great, or at least good enough without the need for a lot of tooling and other stuff to make it productive and useful. It feels weird how much code is written around a language to fix its shortcomings so you can use the language everywhere.

JavaScript has its usefulness, but not for every single problem there is. Know when to use it, but even better, know when NOT to use it.

It’s not a one size fits all solution. So stop treating it like one.