Quote:
Originally Posted by Katsunami
And if this wasn't enough (with regard to TypeScript):
A browser obviously cannot execute it, because it's not Javascript. Therefore Microsoft supplies a compiler, to translate typescript into Javascript. However... that compiler is written in TypeScript.
As there's no way to execute that compiler, you're stuck with a chicken and egg situation. So what do you do? Write a Node.JS package (thus, in Javascript) that can run the compiler.
Are you still with me?
|
It's worse than you know.
JavaScript is a "batteries not included" language, with only primitives. To do anything it it, you need to use libraries. There are an enormous number, and the ones that are popular went through a Darwinian selection process.
JavaScript was first written for Netscape Navigator
2. Creator Brendan Eich commented "If it hadn't been JavaScript, you would have gotten something much worse later!" The first fun part was the name. Eich wanted to call it LiveScript, but someone in Netscape marketing decided to name it JavaScript, to capitalize on the popularity of the then new Java language created by Dr. James Gosling at Sun Microsystems. (I have lost count of the number of times I've had to explain to people that Java and JavaScript are two different languages, whose only similarity is "Java" in the name...
)
Another problem is that it was made an ECMA standard rather before it was mature enough to
be standardized, and Eich has described arm-wrestling sessions at ECMA standards meetings to get agreement from stakeholders on just what will go into the next ECMAscript standards update.
Meanwhile, it's appearing in all sorts of places that have nothing to do with the web or browsers. Adobe PDF viewer, for instance, embeds an ECMAscript variant called ActionScript (turned off by default, thank $DEITY), that can be used to add interactivity to PDFs.
Coffeescript and Typescript are syntactic sugar. They are supersets of JavaScript designed to add desirable features, like types, and as you mentioned, they compile
to standard JavaScript. Needing a compiler to do that shouldn't come as a surprise. You need a compiler for C/C++. The difference there is that compilation is to object code.
But the whole process is a matter of "What's old is new again." When Bjarne Stroustrup created C++, the original implementation was on Unix. C++ code was "compiled" to standard C by the cfront translator, and the C was compiled to Assembler by cc, assembled to object code by as, and linked into an executable binary by ld. (You could halt the process after the compilation to assembler stage, and go in and hand-optimize the assembler code before assembling and linking.)
C++ compiling to native code came rather later. I asked about that at a Unix user group meeting where Bjarne was a speaker, and he said we already had a portable intermediate language called C, and it made sense in the early days to just compile to it while other things caught up.
Another milestone was GCC, which separated the front-end language translator from the backend code generator. The front end translator compiles to an intermediate format the back end code generator turns into object code for the target system. This makes it possible for GCC to compile Ada, C, C++, Fortran, Objective-C, Objective C++, and Go for whatever target architectures are supported.
Increasingly, we are seeing
JavaScript as the intermediate form that will be compiled to object code, and one of the things the latest ECMAscript standards revision did was add support for that. It's a pretty fair bet that down the road,
everything will compile to JavaScript as an intermediate step.
And browsers already do compile JavaScript to native code. In the ongoing quest for speed, all of the major browsers have implemented JIT compilation for JavaScript to native code for faster execution. Mozilla got bit by that a while back. They had a JIT JavaScript compiler, and it produced fast native code, but overall performance still lagged. The issue was that were were many times when it was fastest overall to just interpret the JavaScript instead of compiling and executing, but their JavaScript engine wasn't smart enough about when that was, and was adding the overhead of compilation when it should have just interpreted.
______
Dennis