DEV Community

Derek Mercedes
Derek Mercedes

Posted on

The Benefits of a Single-Language Tech Stack (Or How to Learn to Stop Worrying and Love JavaScript)

One of the universal truths of software development is that anything that can be written in JavaScript, will eventually be written in JavaScript. The ubiquity of the language is impossible to understate. It's the core of all web development, of course, but with frameworks like Electronjs, it's steadily making ground in the space of desktop app development. And while it once needed other languages to supply it with the functionality of middle- and back-end, those angles are covered too. The question still remains, however: why would you choose a JS-based stack when you can supplement the frontend with technologies based in cleaner, more functional, prettier languages? Well, there's a few reasons, actually:

JavaScript is not going anywhere, because JavaScript is everywhere.

Since its inception in 1995, JavaScript has exploded in its adoption, and has become the primary way that most developers interact with the web. Its weaknesses (and there are many) are well known by this point, and JS is frequently mocked for some of the more archaic paradigms that remain at the core of the language. This seems counter to my case: if everyone knows that it's bad, then why would you use it more than you have to?
Because everyone knows not just that it is bad, they are also very familiar with how it is bad. This is a big deal.

Any problem you may have in building with JavaScript, a hundred (thousand? million?) developers have already had, have already complained about online, and have already had a discourse around. It makes chasing down bugs and figuring out tricky implementations a matter of googling skill more than algorithmic genius. That means more time spent actually making your project, and less time staring at the inspect screen wondering what went wrong.

I know what you're thinking: There are other single-language stacks out there. Python has Transcrypt, Java has GWT, and anyone who's been around web development recently has at least heard of Flutter. So you may be asking: why replace my middle and backend with JavaScript when I can replace my frontend with Dart, or Python, or Java. It's simple, really: Even if you're not coding in JavaScript, you're still coding in JavaScript. Aside from a handful of outliers, every framework that lets you code up a frontend in a language other than JS has a step where it compiles all of that beautiful code you've written straight into, you guessed it, JavaScript.

Other People Have Done the Work For You

If you're an experienced developer, you know that the best code is the code you never have to write (or code that only has to be written once and can be reused forever.) This is where npm comes in. At time of writing there are over 11 million packages on npm, with more added every single day. Some of them are for strange edge cases that no one needed a package for, but the fact remains: the code exists, it's easy to add to your project, and it's a lot faster to "npm install" it than it is to write it all yourself.

The sheer number of problems solved by other people shows just how ubiquitous JS really is. Even though they released in the same year, Python's package library (pip), only hosts about 450,000 packages. How can that be possible, though? Everyone loves Python. Hell, the person writing this article loves Python. Again, it's the difference of adoption. More people who use Python enjoy it, but even people who don't like JavaScript work in it at least occasionally. And developers who have problems tend to put effort into fixing them. And that's where all the npm packages come from.

JS is for Lovers (or Generalists, if you prefer)

The biggest reason to adopt a full-stack JS workflow is simply that it can handle most tasks with an acceptable amount of efficiency. Other languages tend to specialize (Python and ML tech are the most prevalent modern example of that), whereas JS can handle most things without issue and do it (relatively) quickly. And with new runtimes like Bun gaining prominence, it's not hard to see why that efficiency is likely to grow despite the lack of specialization. Most working developers have a vested interest in making JavaScript suck less. Even over the past five years JS has become significantly easier to work with, more functional, and more efficient. And it's only going to continue on this path, unless the entire internet explodes and we have no choice but to start from scratch. But in that case, we'll probably all be using Rust anyway.

Top comments (0)