When talking about AOT compilation, we generally tend to mean that the compiler produces a binary consisting of machine code at some unspecified time before the user attempts to run the application.
In the context of that blog post, there are two compilation steps: First emscripten would be used to produce JS. Then Mozilla's JS engine would compile that JS down to machine code at runtime.
They call the latter step with OdinMonkey AOT when they compile the entire thing at runtime, but before starting execution. But the way most people differentiate, this would still be considered JIT - it still depends on executing the compiler each time the application is started.
The point I was trying to get across is that by cross-compiling from C/C++ with Emscripten, static type information can be used to give native performance, that a program written directly in Javascript wouldn't. It's still AOT in that sense - it's not like JIT where only hot bits of code get converted to native to code, and only then when some heuristics have determined what actual types the code ends up dealing with at runtime.
I'm not sure how you claim to be the authority on 'CS speak', but it's a sufficiently blurred line here, for reasons I clearly explained and which you seem unable to understand.
Emscripten/asm.js can use static information to generate Javascript which can be compiled to native code, before the code in question is run, aka Ahead of Time.
Ahead of time compilation is used to describe the process of generating machine code at compilation time, in a form that can be executed directly by a processor without any additional transformation process.
Which clearly is not happening here, as the code is converted into JavaScript and relies on a JavaScript implementation to run. Regardless of the optimization processes used by the JavaScript engine.
