“Duh, of course it’s not! Thanks a lot Captain Obvious!”

If that’s your response, we’re on the same page and you are free to skip the rest of the article.

Unfortunately, I have heard people drawing exactly that analogy recently and it just seems so horribly wrong that I considered it necessary to get things straight and clarify a few misunderstandings.

The main reason for this misunderstanding is probably the Browser-VM-analogy, as I like to call it. This analogy - we keep hearing quite often today – says that modern web browsers are like virtual machines in a way that they show many characteristics and features of an operating system on a very high and abstract level. Web browsers can execute and render arbitrarily complex applications and with the arrival of HTML5 even provide capabilities of local data storage and background worker jobs. This in fact comes very close to the services a general purpose application execution platform (aka a VM) provides and makes the Browser-VM-analogy absolutely valid. However, implicating that JavaScript is therefore the assembler language of these virtual machines, is the wrong conclusion and here is why:

• JavaScript is the lingua franca of the web and the least common denominator of programming languages. This is actually the exact opposite of assembler, which are highly optimized and architecture-specific sets of machine instructions.
• JavaScript might have its pitfalls and flaws, but – let’s be honest here – it is EASY! Gazillions of web developers know how to code in JavaScript and many of them do it considerably well. Not something that I would expect for assembler programming.
• JavaScript is a high-level language like other programming languages we are used to working with today. No one would be as crazy as comparing C# or Java to assembler just because of the fact that one could write complex code and applications with it.
• Also just like in C# or Java, tons of (application) frameworks exist that make dealing with problems in JavaScript easy and trivial. No one has to reinvent the wheel.
• Frameworks like GWT, which cross-compile into JavaScript, are there for a simple reason: Not because JavaScript is complex or hard to handle, but because some developers are often reluctant to leave their comfort zones (in that case Java programming). This is the wrong approach though: web developers should not be afraid of the web’s core technologies.
• If you are looking for web browsers’ assembler language then guess what: it is actual assembler! What do I mean by that? Just go and implement a native browser plugin (something like Flash-Player) purely in assembler. There you go.

The main reason why I consider this whole analogy such a big issue is that comparing JavaScript - a high-level, object oriented language – to something as cumbersome and complex as assembler, simply puts the wrong idea into people’s heads and creates unnecessary anxiety. JavaScript is not a complex and intimidating language like assembler (at least not more that other high-level languages like C# or Java are). So if you are a web developer using JavaScript to build your applications, everything’s fine. There’s really no need to fiddle with obscure cross-compiling technologies. Just keep what you’re doing, choose the right frameworks  and tools and you’ll be as productive as your random C# or Java developer.

[You might want to take a look at TypeScript though ;)]

Key Takeaways (TL/DR version)

• It’s perfectly valid comparing web browsers to virtual machines.
• However, this does not make JavaScript their assembler language.
• JavaScript is a high-level, object-oriented language like C# or Java and should never be mentioned in the same breath with assembler.
• There’s no need for cross-compiling frameworks and tools.