Why is client-side web still using an interpreted language? [closed]

Question

To my knowledge JavaScript is the only language that will execute on the client side after the HTML file has been retrieved from the server. As far as I know JavaScript is by no means compiled in anyway and thus it is an interpreted language.

With Web becoming more and more popular, so much so that some say mobile and desktop applications will soon cease to exist.

We see new technologies like WebGL, that makes use of JS.

When I develop for WebGL I have to optimize so much more to achieve a reasonable performance benchmark, then what I would have to for PC or Console.

So why do we still use an interpreted client side language? Is it a security issue, hardware (cross platform) issue or is it simply because it's difficult to introduce such a large change into the web architecture? I know web developers have headaches over even the smallest and simplest changes, like using CSS 3, simply because not everyone has their browser up to date.

Am I correct in thinking that interperated languages are slower then compiled ones? Am I making sense or are my assumptions completely incorrect? I am by no means a JS/web expert, please educate me.

Answer 1

To my knowledge JavaScript is the only language that will execute on the client side after the HTML file has been retrieved from the server.

This is wrong. At least in HTML 4.01, the <script> element has a type attribute that allows you to specify any language you want. The HTML 4.01 specification itself has examples in VBScript and Tcl.

Older versions of Internet Explorer, for example, support VBScript as an alternative scripting language to ECMAScript. There are versions of Chrome that support Dart as an alternative scripting language. There was a project that added support for PHP, Perl, Python, Ruby, Tcl and others to Firefox.

You can also use any language that has a compiler that outputs ECMAScript, and almost every language nowadays has that, e.g. there are compilers that can compile C, C++, Java, Scala, Ruby, C♯, F♯, and many many others to ECMAScript. There are also languages that were explicitly designed to be supersets of ECMAScript (e.g. TypeScript), semantically close to ECMAScript (e.g. CoffeeScript), or easily compilable to ECMAScript (e.g. Dart).

As far as I know JavaScript is by no means compiled in anyway and thus it is an interpreted language.

This is wrong. All currently existing in-browser ECMAScript execution engines have at least one compiler. Many have several compilers. At least one has no interpreter whatsoever:

• V8 is purely compiled, there is never any interpretation going on, it always compiles ECMAScript source code to binary native machine code. The original version had a single compiler, the current version has two.
• SpiderMonkey always compiles ECMAScript to SpiderMonkey bytecode. This bytecode is then first interpreted a couple of times to collect statistics, and then the "hot" parts are compiled to binary native machine code by one of several compilers.
• Nitro always compiles ECMAScript to Nitro bytecode. This bytecode is then first interpreted a couple of times to collect statistics, and then the "hot" parts are compiled to binary native machine code by another compiler.
• Chakra always compiles ECMAScript to Chakra bytecode. This bytecode is then first interpreted a couple of times to collect statistics, and then the "hot" parts are compiled to binary native machine code by another compiler.

In fact, the terms "interpreted language" and "compiled language" don't even make sense. Languages aren't interpreted or compiled. Languages just are. Compilation and interpretation aren't traits of a language, they are traits of a compiler or interpreter (duh!) A language is a set of mathematical rules and restrictions. Nothing more. The concept of "language" and the concept of "interpretation" live on two completely different levels of abstraction. If English were a typed language, the term "interpreted language" would be a type error.

Every language can be implemented by an interpreter and every language can be implemented by a compiler. There are interpreters for C and C++, there are compilers for ECMAScript, PHP, Python, and Ruby.

Am I correct in thinking that interperated languages are slower then compiled ones?

No. First off, like I explained above, there simply is no such thing as an interpreted or compiled language. There are only interpreted or compiled implementations of languages. Secondly, it doesn't make sense to say that a language is slower than another language. All you can say is that some particular program when executed by a particular version of a particular implementation in a particular environment on a particular machine runs faster than a different program executed by a different version of a different implementation in a different environment on a potentially different machine.

In general, the performance of typical programs on a particular implementation is mostly a function of how much money, resources, effort, brainpower, research, engineering, and manpower was expended on it, not on any particular trait of the language. The Oracle HotSpot JVM is fast not because it is a compiled implementation, not because Java is statically typed (in fact, that's completely irrelevant because the HotSpot JVM executes JVM bytecode, it doesn't even know anything about Java!), but because Oracle and Sun have poured massive amounts of resources into it. Ironically, Java was actually pretty slow until Sun bought a Smalltalk(!!!) company and their VM technology. Yes, that's right: HotSpot JVM is actually just a slightly modified Smalltalk VM, i.e. a VM for a dynamic language.

In fact, the VM HotSpot is based on, was open-sourced and is also the VM V8 is based on (which is not surprising since V8 was developed by some of the same people who developed the HotSpot JVM and the Smalltalk VM it was based upon).

Note that there are two attempts on getting a new language accepted by the browser vendors:

asm.js is a language that is a syntactic and semantic subset of ECMAScript (meaning any asm.js program is also a semantically identical ECMAScript program, and a browser that doesn't know anything about asm.js will simply think it is ECMAScript and execute it as ECMAScript and it will just work) with certain restrictions that make it a good target for compilers (e.g. it is relatively easy to create a compiler that compiles C to asm.js) and at the same time a good source for native code generation (i.e. its semantics are relatively close to the semantics of modern mainstream general-purpose CPUs).

Likewise, WebAssembly is a (binary) language that has basically the same goals as asm.js, except there is no requirement that it be a proper subset of ECMAScript. It is its own independent language, inspired by asm.js, LLVM bitcode, ANDF, CIL, JVM bytecode, Pascal P-Code, and others.

Asm.js already has some browser support, and because of the fact that it is just a subset of ECMAScript even works in browsers without support … just slower. WebAssembly is gaining traction, although it is still in the experimentation and prototyping phase.