The Wonderful Consequences of JavaScript as the Virtual Machine Language of the Web

Back in the late 90's, when the <blink> tag was still a thing and JavaScript was mostly used to alert(“something”), I briefly worked with an external consultant who made his living doing Smalltalk. I was a Progress programmer at the time, there was no internet as we know it today and it wasn’t even all that easy to find job listings, let alone find a new job doing new tech. This is back in the days when you’d look up job postings in the New York Times or some local paper. If you didn’t use technology X at your day job, it was non-trivial thing to pick it up on your own.

Although I loved my day to day life as a Progress guy, I also managed to find some time to envy “Chris.” He was working with some exotic programming language, flying around the country doing interesting things for interesting companies. Never mind that I was also flying around the country doing interesting things — I definitely had a bad case of the the-grass-is-always-greener’s. He moved on and I did that Progress stuff for a long time after. Then, BizTalk and eventually SharePoint and life went on in its interesting and fun way. But, I’ve always felt like I missed out on something. The Smalltalk world seemed to exotic, unusual, powerful and … completely out of reach. Progress was exotic and unusual but not at all in the same was as Smalltalk. Everyone had heard of Smalltalk while practically no one had heard of Progress.

JavaScript has obviously gone way past the alert(“something”) that it was when I first came into contact with it. It’s been that way for years by now, even if it still feels new to a Johnny-come-lately such as myself. I didn’t do “real” JS development until three or four years ago and resisted Angular for a full year for no good reason at all. I generally viewed JavaScript as a secondary tool, useful for adding some pizazz to ASP.NET driven web apps and SharePoint. I started to take a real interest, however, after I finally saw the light in regards to Angular. It was around that time that I took the plunge and started learning TypeScript.

I’m relatively slow to adopt new stuff so it’s not exactly my usual thing to jump on something so new. I did adopt TS relatively early and I have a great time working with it. I enjoy it for the obvious value it brings — strong typing, classes, interfaces and the natural way in which it allows you to follow standard standard software design patterns. But I also have a growing appreciation for meta fact of its existence. It’s a full blown solid language in and of itself that compiles down to JavaScript. It’s darn close to JavaScript. You can hardly start reading about TypeScript without learning that TypeScript is supposedly just JavaScript plus “extra.” But in the end, it’s really and truly a different language. Let’s put in a pin in that notion for just a moment.

Back to a bit of history. As I experienced it, the first real “write once, run everywhere” thing for the web took the form of Java Applets. Applets promised this interesting capability where you could write some application and not worry so much about desktop OS, whether or not they had the right TCP/IP driver installed and a million other details that stood between you, your app and your customer. Applets didn’t work out. I don’t know why. However, JavaScript did — eventually. I think that when Google released Chrome with it’s “always-updated” nature, the die was cast. Others followed suit (or Google followed them, it doesn’t really matter) and these days, we can mostly assume that every browser we care to target is going to be able to run our JavaScript solution.

Back to TypeScript — the meta fact that so interests me is that no browser on the planet can actually run TypeScript. And yet, it doesn’t matter since it compiles down to JavaScript and any browser that I care about can run that.

There’s a some debate these days about TypeScript and questions on the various message boards along the lines of “should I learn TypeScript?” I personally think the answer is “yes” and I generally argue in favor of that. That said, I’ve come to think that this question is actually kind of limiting and and overly tactical. The tactical question is a good one, but if you take a step back and think more broadly, the question isn’t “should I learn TypeScript?” but rather, “should I learn [X] language that can reasonably transpile down to JavaScript?”

JavaScript has become a kind of machine language for the web. It’s pervasive. You can rely on it being everywhere and rely upon it working for all of the primary use cases of a your typical application. (Let me just make the obvious point that in the end, it’s running in a secured box, with many, many restrictions — it’s not the end all and be all of technical solutioning by any means). Given this fact, it’s a great target for transpilation — taking TypeScript, for instance — and compiling it down to JavaScript. Well, if you can do TypeScript, you can do Smalltalk. And indeed, there is at least one Smalltalk transpiler out there. Indeed (again!) — there are actually many transpilers for many languages already. Here’s just one list: https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js.

This is what I mean by the “wonderful consequence.” JavaScript is pervasive and sufficiently powerful enough that you can transpile a heck of a lot of programming languages down to it and they will run in your target environments with no fuss. That, in turn, means you have far more interesting choices from which to pick and choose your programming language. If you’re like me and you care a lot more about the art and craftsmanship side of this career rather than any specific end result, you could hardly be happier.

It’s not going to be perfect. These other languages may or not be good on their own merits. They may be great languages, but lousy candidates for transpilation. The transpiler writers may not be good at it. After all, not everyone has the resources of Microsoft at their disposal. If you’re in a pure JavaScript shop or a TypeScript shop, you still have potential cultural hurdles to overcome. That said, it’s never been easier to branch out. Task runners like gulp and grunt, .map files to support runtime debugging and vibrant online communities knock down many of the barriers that we faced 15+years ago or even three or four years ago. It’s certainly not perfect, but it’s pretty darn good and we have good reason to think it’s going to get even better.

These are exciting times and freeing times. The programming world has never been more oystery than it is today :). Let’s enjoy and take advantage of these wonderful consequences ;).

</end>

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!