
Ahead-of-time JavaScript compiler - apaprocki
https://github.com/tmikov/jscomp
======
ahmacleod
> It is not expected that the performance of compiled applications will ever
> rival 'v8'. JavaScript is an awful language for static compilation - it
> almost seems designed to foil any attempts at optimization, and so a JIT
> will always have a significant performance advantage.

For the compiler un-initiated such as myself, is there a simplified
explanation for why static compilation is inferior to JIT for languages like
javascript?

~~~
jestar_jokin
For one, "this" could refer to anything at any time, depending on who invoked
the enclosing function.

    
    
        function myFunc() {
            console.log(this);
        }
        
        var myObj = {};
        
        // this = window
        myFunc();
        // this = window
        myFunc.apply(null, []);
        // this = myObj
        myFunc.apply(myObj, []);
        
        myObj.myFunc = myFunc;
        // this = myObj
        myObj.myFunc();
        
        var tmpFunc = myObj.myFunc;
        // this = window
        tmpFunc();
    

Another issues is closures, where variables and properties available to nested
functions are dependent on the outer functions. Combined with the floating
"this", leads to highly dynamic behaviour which can only be assessed at
runtime.

~~~
userbinator
I'd guess the names of properties being possibly dynamically computed also
makes things difficult to optimise.

~~~
jestar_jokin
A clever compiler might be able to infer "structural typing", which is
basically "duck typing" done at compile time. So, if you add a property "bar"
to an object "foo", and you have some other code that calls "baz.bar", you can
infer that "foo" is of type "HasABar", and "baz" is of type "HasABar",
therefore it might be safe to use "foo" in place of "baz".

The tricky part would be consolidating every structural subtype into cohesive
classes.

------
marssaxman
Weird that the label specifies "ahead of time", which is implicit in
"compiler", but does not mention that it is a Javascript-to-C++ translator
rather than a normal machine-code-producing compiler.

~~~
ant6n
A compiler is a translator. It translates programs from one programming
language to another.

You always want to compile to the easiest target language that solves the
problem well and allows you to do the optimizations you want to do. By
compiling to C++, they can focus on static typing and closures etc., but don't
have to worry about generating machine code, and register allocation and
whatnot.

Back in school, I worked on a project to compile Matlab. We picked Fortran as
the target, because it was very similar in terms of operating on matrices. But
it's typed, and had a few very fast compilers available.

~~~
marssaxman
Of course. I've written a compiler myself which used C++ as its output
language. It just amused me that the authors made a point of specifying one
characteristic of the program which is generally assumed as the default, while
making no mention of another, far less common characteristic which effectively
defines the scope of their project.

------
z92

      Transition the runtime to C [from C++]
    

Wondering why? I thought C++ and C are comparable in speed.

~~~
azth
They are. Practically anything that can be done in C, can be done in C++. At
the same time, C++ offers ways to get better performance that are not
available in C (e.g. templates). Even GCC moved from C to C++ for safety. This
doesn't look like a very well thought out decision.

------
mtdewcmu
It was only a matter of time before someone did this. Did it really take this
long?

~~~
rubiquity
AFAIK browsers have been doing this internally for years. It just hasn't been
available as a standalone utility.

~~~
mtdewcmu
I don't think that's an accurate statement. If a browser implemented this, it
could be considered a crude form of JIT. But JIT techniques were more
sophisticated than this by the time browsers started using them on Javascript.

------
billylindeman
but does the output compile with emscripten?

