2

I've read a lot of things about interpretation, compilation, just-in-time compilation, etc. But I haven't found a clear explanation about why JS was created as an interpreted language and why there is still no ability to compile js code.

I have some thoughts, but I'm not sure about any of them:

  1. If the browser could execute (or just pass to OS) a binary code it would be a big vulnerability because any command could be injected into a binary code (e.g. delete all files from the file system). If it's true is it possible to teach the browser to validate somehow a binary code? And it's not a problem for a back-end side. Then, why NodeJS can't execute compiled JS (the same for PHP, Python, why they are interpreted)?
  2. Optimization isn't possible for binary code. Is it really true? Is optimized interpreted js faster than compiled (to binary) js?
  3. Different CPUs (architectures) need different binary codes. That means it's impossible to generate a universal binary code for any client. That's why WebAssembly modules use some intermediate code? And again why to not use compiled code for a back-end?

If anyone could explain some of the above or any other reasons I would be very grateful.

Alex Rypun
  • 101
  • 1
  • 8
  • Actually the V8 Javascript engine does compile code. It's just automatically compiled on the fly to a byte code that it can execute. For your reading pleasure: https://v8.dev/blog/background-compilation and https://github.com/thlorenz/v8-perf/blob/master/compiler.md. – jfriend00 Nov 07 '21 at 19:58
  • @jfriend00 the compilation is an implementation detail. OP is asking about why was JS conceptually made to be an interpreted language. And undoubtedly in the interpreted/compiled division, JS is strictly in the interpreted category. Even if there is a compilation step involved in some engines. – VLAZ Nov 07 '21 at 20:19
  • Questions about "why" some design decision was made 20 years ago are generally pointless here as none of us were in the room when the decision was being discussed. People can guess if they want or you can go ask Brendan Eich, but it's generally not a useful discussion. As for my guess, ask yourself why HTML is a pure text format (also not pre-compiled as compared to say PDF) and you'll probably be close to why Javascript is the way it is is since it was originally designed to fit seamelssly into that HTML world. Nodejs chooses to use the V8 engine so that's why it is what it is. – jfriend00 Nov 07 '21 at 20:38
  • 1
    @jfriend00 I don't necessarily disagree but I think there is a definitive answer here. Just not a very satisfying one. If it's interpreted, it's faster to develop code. You write it and you're done. No need to do extra steps. It was a likely consideration to onboard developers as fast as possible. Similar to the Java-likeness. – VLAZ Nov 07 '21 at 20:47
  • 1
    FYI, an interesting question might be why not pick an existing interpreted language of the day such as Python and integrate that? But, after looking it up, Python was only 4 years old when JS was released so probably even younger than that when the concept of JS was born and not yet with significant traction. Perl had been around a little bit longer and was in general use in that day so that could have been a consideration. Basic was the only other interpreted language in the top 10 for popularity in that day, but probably polluted by its association with Microsoft's Visual Basic. – jfriend00 Nov 08 '21 at 00:46

1 Answers1

5

Let's first say that unless you were in the design discussions for Javascript in its early days, none of us actually "know" why. The best we can do is try to infer why certain choices might have been made given the objectives they had and the choices they had.

If you look at the requirements for the original design of Javascript in web pages, you see things like this:

  1. Must run on lots of platforms.
  2. Must be easily embeddable in HTML pages.
  3. Must be simple to program.
  4. Is not initially an environment that feels the need to maximize execution performance.
  5. Not Java.

Let's look at these...

About #1, OK, run on lots of platforms means it cannot be compiled to native machine code - period. It could be compiled to a universal byte code like Java or webAssembly, but read on about the other requirements.

About #2, it wants to be embeddable in web pages so you can do things like:

<div onclick='alert("hi")'>Click me</div>

Then, it's pretty hard to have code that is compiled in advance fit in there. You'd probably have to compile your whole web page. That creates an entirely new paradigm and browser (that expects pre-compiled code and HTML). While the world could have eventually gone there, that certainly wasn't an easy way to go (requiring a redo of the browser).

About #3, "simple to program", it's generally believed that interpreted "scripts" are simpler for people to start with than languages that need a programming environment and compiler set up and some build tools. It's faster and simpler to do simple things.

About #4, "performance". In the early days of Javascript, it was an auxiliary language to help add some client-side logic to web pages. The initial target was far simpler than what Javascript is being used for today. I rather doubt it was envisioned that a pre-compiled language was needed for what its initial target was. So, keep it simple and go with the simpler way of reaching your target.

About #5: "not Java". Java was a known tool of the day. But, Java was not super simple, required pre-compiling, had IP encumbrances, etc... So, Javascript was born to be something that was familiar to both C and Java developers, but was far simpler for someone new to pick up. Easy to do simple things.

As for environments like nodejs, they could more practically have a pre-compile step, but the early designers of nodejs decided to use the open source V8 Javascript engine rather than make their own Javascript engine. Plus, in a server world, your code is generally loaded once at server startup where V8 compiles it to a combination of native code and byte code anyway so requiring developers to pre-compile it doesn't necessarily buy you a lot anyway. This is where it matters that Javascript is now actually compiled, it's just compiled upon loading rather than requiring pre-compiling by the developer.

And, nowadays, if you want the benefits of type checking in a pre-compile step, you can use TypeScript and precompile that to Javascript.

jfriend00
  • 683,504
  • 96
  • 985
  • 979