Since my previous question was closed (https://stackoverflow.com/q/62354455/1173166), I thought this would be a better place to ask the question.


JavaScript we designed specifically for browsers. It wasn't pulled off the shelf. So what were the reasons behind making it a scripting language rather than a compiled language?

With the introduction of WebAssembly, it's proof that compiled languages for the web is possible. But why wasn't it designed like that to begin with?

What benefits does a scripting language have over compiled languages in the domain of the web?

Proponents of compiled languages believe JavaScript is a terrible language that should never have been adopted, so I wonder, was the choice to make JavaScript scripted an arbitrary choice, or was it a choice to appeal to developers who can't handle a "real" language like C? Or some other reason?

What prevented a WebAssebly-like system from being implemented on the web to begin with?

  • 2
  • 3
    What's wrong with the answer you accepted on Stack Overflow? Commented Jun 19, 2020 at 20:32
  • Scripting languages are lightweight and accessible to a much larger audience than full-featured languages such as Java. It was a conscious choice by the designers. Not every programming task in a web browser requires the overhead of compilation. I'm also grateful for JavaScript--it's how I got started in software, by viewing and tinkering with the code I found online.
    – Dan Wilson
    Commented Jun 19, 2020 at 20:35
  • Is there a better place to ask questions about programming language design? The old question was closed with only one answer. I would like to see other answers from different people, especially since the original answer did not post any citations.
    – Croolsby
    Commented Jun 19, 2020 at 21:29
  • 1
    JavaScript was thrown together in a couple of weeks by a single person just so that Netscape could tick off a box on their marketing checklist. There really wasn't a lot of time for finding an optimal design. But then the other browsers also implemented JS to achieve feature parity, and JS became an unavoidable part of the web. Pre-WASM, there were plugins like Java applets, Flash, ActiveX, Silverlight, but they were either slow, proprietary, or entirely insecure.
    – amon
    Commented Jun 20, 2020 at 7:25

4 Answers 4


JavaScript was originally used for tiny things. Often, your entire script would be inlined in your HTML onclick attribute. A large use of JavaScript would be two or three functions in the HTML header. I remember thinking why would anyone ever want to use the ability to put a script in a separate file. It makes zero sense to precompile something that small.

Now if you actually wanted to do something substantial, everyone knew it was ridiculous to use JavaScript for that. You use a Java applet or Flash.


Tooling and ease of use.

The way the web was done at the time was in a text editor. That is, JavaScript was not feed into a tool that would spit some binary format, because that is not how you develop for the web. Instead, if you develop for the web, you pick a text editor, any text editor, and you type. No special tool required. Well, we have minifier and other stuff now, but, back then? No.

Because of this, any binary format was not going to be popular※.

We can kick the question up to why is HTML not compiled? Well, because it was never meant to be a programming languages (and, despite being a declarative way to tell the computer what to do, the consensus is that it isn't), it is for documents instead. Why compile that? You don't need a compiler, you need a document viewer. Part of the popularity of HTML on its beginning was that it was simple to implement a viewer, and viewers were made for different platforms. A binary format would have been an obstacle.

HTML, was, of course, based on SGML, which also was text based. Why was SGML text based? It was meant to remain readable, independently of the technology, long term. Thus, it could not depend on a particular machine code or binary format that would require an specialized interpreter that might become unavailable as technology changes.

※: Except Flash, right?

If you wanted to play simple animations on the web, Flash would give you an smaller file size (and thus faster to load) and higher quality than the alternatives. Because it was vectorial. In addition to that, Flash popularity also derives from the fact that the player was free, and the tools to produce it were easy to use. Then eventually ActionScript was added to it.

Yet, despite entire sites made in Flash, it could never replace HTML and Javascript. Not only in that producing HTML was cheaper (no need to license specialized tools), but also simpler. If you wanted to generate dynamic text (HTML and Javascript) on the server it was trivial to do, while generating dynamic Flash on a server was virtually unheard of. Thus, for any enterprise web application that wanted to hit a database or a mail server, Flash was just not an option. This kept Flash confined to client-side interactive content.

Please notice that if Flash didn't have animation, just ActionScript and access to the DOM (it could not access the DOM, at least not directly, but imagine it could), then it would not have been popular. And that is what a binary format JavaScript would have been back then.

Ironically, this also meant that you would not use JavaScript for complex client-side interactions. Thus JavaScript code was relatively small, and thus the cost-benefit of a binary format was not in its favor.

I also want to mention that an interpreted language, as JavaScript used to be, has some benefits. For once, it is easier to implement a security model.

Plus, it would be easier to make it tolerant to mistakes… Alright, that needs some context…

Let us say, I am an sloppy JavaScript programmer, who would not be bothered to validate/check my code. And my site works on Browser A, but not Browser B, because Browser B is more strict with JavaScript code. What is the client perception? That Browser A is better! For market share there was, and still is, an incentive to make the browser tolerant to bad HTML and bad JavaScript. Up to the point that this tolerance has been codified and standardized, and what was sloppy back then is correct now.

This is also why competing browsers approached some level of parity on non-standard behaviors and features. Emphasis on "some".

On the other hand, if the browser was strict, as in the failed XHTML, any small programming mistake (say, a missing ;) would mean a failure to render the page or run its code.

Well, it is easier to implement a tolerant interpreter than a tolerant ahead of time compiler. Well, it is easier to implement a interpreter than any other kind of compiler, period. However, the incentive to make it tolerant would translate into an incentive to not go into the effort of using something else than an interpreter.

Which finally brings up to why we ended up compiling JavaScript (as in, not just running it in an interpreter) anyway?

Speed, of course.

In the decade of 2000, interest in large client-side web applications (as opposed to, you know, desktop apps, which require installation) was growing. And as large JavaScript applications (notably google's) began to appear, the performance issues of JavaScript engines also began to appear.

Around this time Ajax was coined, Apple decided to not put Flash on the iPhone, and a lot of standardization effort of web technologies began around this time.

So Google decided to make a better and faster JavaScript engine. Which, by the way, some people argued it was not possible, because JavaScript was a dynamically typed language with some unique challenges. V8 showed it was possible. It would also eventually power Node.js and bring JavaScript to the servers.

It is this same desire for large client-side web applications that would spark NaCl, asm.js and eventually WebAssembly.


There is no such thing as a "compiled language". Compilation is a property of the compiler (duh!), not the language. Therefore, the term "compiled language" is not even wrong, it is non-sensical. Which makes the answer to your question trivial: you cannot adopt something that doesn't exist.

Some people define "compiled language" to mean "a language for which compilers exist". If you define it in that sense, then the premise of your question is wrong: every existing implementation of JavaScript has at least one compiler, some even have more than one. So, the web has adopted a compiled language, namely JavaScript.

  • 1
    While I usually agree with this sentiment, in this precise context it is irrelevant: any method used for scripting web pages would need a defined method for transferring the code to the end user - either as text source code or using some kind of predefined bytecode or other virtual machine instruction set. As I interpret the question, it is why the former was chosen rather than the latter.
    – occipita
    Commented Jun 20, 2020 at 6:22
  • In that case, the answer is trivial: before LiveScript/JavaScript, the language of the browser was JVM byte code, and that was a failure. Commented Jun 20, 2020 at 8:42
  • @RobertHarvey: HotJava was the first browser that allowed client-side scripting, even before LiveScript / JavaScript. (Depending on how you define it. HotJava 1.0 was released after Navigator 2.02, but development releases were available before Netscape was even founded.) HotJava was itself written in Java, and client-side scriptability via Applets was fully builtin, as was extendability, with extensions also written in Java. Also, why does it matter if something is shipped with the browser or as a plugin? Commented Jun 20, 2020 at 14:40
  • The bytecode format is part of the Java specification, so I would argue Java is ahead-of-time compiled by definition. Any language where a bytecode or object code or binary format is part of the specification is IMHO a compiled language by definition.
    – JacquesB
    Commented Jun 22, 2020 at 9:51
  • @JacquesB: The byte code format is actually part of the JVM specification. Java does not depend on the JVM nor vice versa. It is perfectly possible (as was demonstrated by e.g. GCJ) to have a Java implementation that does not use a JVM. Commented Jun 22, 2020 at 10:48

The premise of your question is wrong. An ahead-of-time compiled language was introduced in browsers at the same time as JavaScript. Netscape 2.0 was the first browser which supported JavaScript and it introduced support for Java Applets at the same time. But for various reasons Java applets fell out of use.

JavaScript was specifically positioned at the time as the scripting complement to the more powerful Java. It was expected that Java would be used for more complex stuff, while JavaScript would be used for scripting the applets and as "glue" for integrating the Java applets with the HTML and perhaps other plug-ins.

Java did not live up to its expectations (on the client side), and JavaScript gradually took over as the sole programming language in browsers.

The reason for the rise of JavaScript compared to Java was mostly due to Microsoft. They considered Java a strategic threat and therefore introduced powerful browser features like "dynamic HTML" (today known as the DOM) and AJAX which could be utilized from JavaScript but not Java. This over time made JavaScript much more useful than Java.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.