Behind the scenes, widely unnoticed, there's an interesting development going on. The role Javascript plays in the computer industry is starting to change. The first time I got aware of the new role was when I learned about GWT. The heart of GWT is a cross-compiler translating Java code to Javascript.
Then I learned about Dart.
Dart is a language with two target platforms: the Java Virtual Machine (aka JVM) and the browser. It "compiles" to Javascript. I put the word "compile" in quotes because "compiling" usually means translating a language to a faster language.
I suppose anybody who's interested in this article already knows there are basically two different approaches to executing a computer program written in a high-level language. The computer itself can execute machine code only. But humans find it difficult to work on the machine code level. It's easier to work with an "assembler language". Those languages are a direct representation of the machine codes, but instead of jotting down numbers, assembler programmers use words and abbreviations (aka mnemonics) that can be memorized more easily. If you're an Java expert who has never seen assembler code, disassemble a class by calling javap -p -c myClass.class on the command line or by dragging and dropping a class in the Eclipse editor window. The byte code you are shown it not an assembler language, but it looks and feels very much alike.
As I mentioned, assembler languages are a human-readable representation of the code that can't be executed directly. It has to be translated to real machine code. The same applies to higher level languages like C++: They are converted to machine code. This process is called "compiling" (except for assembler languages, where it's called "assembling" for some reason lost in history).
The second approach is to write a program that analyzes the code at run time. Each statement of the language corresponds to a function written in machine code. The machine code is called each time a statement occurs. It isn't stored or cache, but the analysis takes place every time the higher level languages statement is executed - even if it's within a loop and has been used hundreds of times before.
You can see the difference nicely in BASIC. Many BASIC dialects can be executed either in an interpreter or compiled to native machine code. The same applies to Java byte code: it can be interpreted, or it can be (partially) compiled by the Hot Spot Compiler. The latter version is tremendously faster (typically 10 to 1000 times). Add the -Xint switch to disable the hot spot compiler.
Even when we talk about compiling Java, we mean converting a program to Java byte code which is another representation of the same program that can be executed far more efficiently. The Java source code we know is basically a long string. In theory, it can be interpreted, but the creators of Java chose another approach. They don't compile Java code to machine code directly, but to an intermediate version optimized for execution. The byte code is an intermediate language. It still has to be interpreted at run time, but it's designed to be interpreted very efficiently. Byte code can even be read by humans - granted, we can read it only just, but we can decipher it if we really try. There's even been a language - Forth - that tried to make the paradigm the JVM byte code is based on (stack oriented programming) popular amongst humans.
However, compiling a language to Javascript means converting a human-readable text to another human-readable text. Javascript was by no means optimized for computers when it was introduced. It still isn't. If it were, it would look completely different. For example, I suppose it would be statically typed. The dynamic (even slightly anarchic) type system Javascript supports is optimized for human laziness, not for a machine's rigidness. And of course Javascript is a classical interpreter language. You can do better if efficiency - more precisely: run time efficiency - is your primary concern.
So it's obvious Ceylon, Dart and GWT don't use Javascript because it's fast. They compile to Javascript because it's the only language that can be used in the browser.
Nonetheless, today we hear astonishing stories. Modern browsers run Javascript programs almost as fast as equivalent C programs, some evangelists claim. Honestly, I don't believe that (even if I have to admit I never bothered to write a benchmark). But what I can say is that Javascript has become blazingly fast. Forget about the C comparison. But I'll give you this much: Javascript almost caught up with Java. Sometimes it's even faster (see this article). Even if Javascript were ten times slower than Java, I'd still call it blazingly fast.
There are two reasons why I believe Javascript to be fast. First, I have seen impressive demos, like Quake 2, an equalizer and a live Fourier analysis. Each of them running flawlessly in Javascript. Which is to say: today, Javascript is fast enough for most applications. The second reason has to do with my work. The alternative to executing Javascript code is to send a request to the server. That's an extra 20 - 500 ms delay. Even if Javascript was very slow: in my daily life, it has to compete with the 20+ ms delay, and that's an easy play for Javascript.
Let's return back to the languages based on Javascript. I already mentioned GWT and Dart. But there's more - Kotlin and Ceylon, just to name two. That's four languages I know of being cross-compiled to native Javascript code. And people tell me the cross-compilers optimize in ways almost no human being would think of. The compilers generate code that's more efficient than code a human being would write.
That's why I'm pretty sure Javascript has a great future. Maybe it's not because it's an interesting language in its own right - which it is - but because it's going to be used as sort of an assembler language more advanced languages compile to.
Calling an interpreted language an assembler language sounds ridiculous to me. But maybe it's the way it is. Times, they are changing!
I'm very curious about the future of Javascript. Will it see a great future because it is an interesting language, will it see a great future because there is no alternative, will it be reduced to play the role of an assembler language or will it be replaced by something new?
Further reading
JavaScript is Web Assembly Language and that's OK." by Scott Hanselmann