Recently I was watching a YouTube clip of an interesting conversation between Lex Fridman and John Carmack, arguably the world’s best-known software engineer. The title of the clip is “Will JavaScript win?”. In this clip, Lex Fridman hypothesized that, long after humanity becomes extinct, after thousands of years, when an alien civilization comes to visit this planet, and when they inspect our systems, they would find that everything would be running on JavaScript. He continued that JavaScript still doesn’t get the respect it deserves, and asked Carmack; “Do you think that one day, everything will be written in JavaScript?”. 

As a company — SpringTree — that mainly deals with JavaScript technology, that type of statement should make me feel validated in our technology choices and confirm that we’re on the right track. Right? Well, not really. It actually made me think; “Are we maybe overdoing it?”. And with “we” I mean the collective we, the industry as a whole, not SpringTree specifically. 

There’s this quote that we regularly use within our company that goes; “To the man with a hammer, everything looks like a nail”. Meaning; if you know how to solve something one way (i.e. with a hammer), that doesn’t mean it’s always appropriate for other situations. Or, to phrase it differently: “Using tools for a purpose for which they were never intended”. 

JavaScript is everywhere these days. Not just in the browsers, or on the server (Node.js, Deno), but also in areas like machine learning, embedded devices, mobile apps, data science, gaming etc. Is this a good thing? You can argue that it allows developers to transition easier between different types of projects and that it enhances the portability of your code. While that’s true, I really like the answer that John Carmack gave to this question: “Much of programming is not the language itself. It’s the surrounding infrastructure and the libraries that you can get”. 

So in areas like gaming, where you need to be very efficient in how you utilize resources like GPU, CPU, and memory, a language like JavaScript won’t be a good fit. You simply do not get low-level access to these resources. John Carmack later talked about —while writing his software in C — for certain parts he chooses to write components in Assembly, a low-level programming language, for other parts, just to squeeze out the best performance. And that’s exactly how one should write software for gaming. 

We at SpringTree would not write machine learning software in JavaScript. Because Python has far better libraries and a strong community in this area of software development, compared to JavaScript. So, why don’t we write back-ends in a language like Go? They’re faster than Node.js in speed benchmarks. Well, yes, they are. But again, speed is just one consideration, tooling and infrastructure is another. For us, it makes more sense to choose Node.js for most back-end use cases. It’s very fast, there are a ton of libraries to pick from, and the big cloud providers offer excellent support, specifically for Node.js. If we were to build a back-end solution where speed was of the highest essence, of course, we would choose something like Go.

Source: https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go

At SpringTree we use a lot of JavaScript. Because it makes sense for our business needs and the problems we are solving. But we are trying to be aware of the “Man with a hammer”- syndrome. For search engines we prefer Java-based software (Elastic), for mobile, we choose Swift for Apple-only apps, or in some cases we choose Dart. But we’re not immune to the syndrome. It’s just so easy to stick with what you know. 

 But, in the long run, that’s not good for the product. Hopefully, when those aliens finally come, they’ll find that not everything runs on JavaScript. Because in the end, we were smarter than that.