If you could AOT compile the templates into bytecode, which has to be parsed, why not just AOT compile the templates straight to JavaScript(like Angular 2/4)?

This is what I was going to ask as well. The only benefit I can see to this is that they are trying future proof for when WebAssembly or some other back end is more prevalent? Maybe they want to do Glimmer-Native?

Handlebars -> JS/TypeScript compiler -> Bytecode -> JS probably anyway -> HTML seems like a lot of work.

The bytecode representation is more compact than the compiled JavaScript. And this has an impact on execution speed.

See past discussion: https://news.ycombinator.com/item?id=14050625

I would assume because their VM/bytecode version is very fast at rendering updates and smaller in size than a "represent the bytecode as JS" version.

A few questions:

1. How does render time compare to the same thing without the AOT compiler?

2. How does render time compare to React or Inferno?

3. Are Glimmer templates type safe, or are they plain old strings?

4. How do I consume compiled templates? It seems like I need to transform my code to use compiled templates as opposed to raw templates?

> Once we have loaded the program we simply set the program counter to the handle and start executing the VM.

Seems like a perfect use case for WebAssembly once it's adopted. Instead of each framework creating their own bytecode implementation and VM to match it.

I'm baffled... why aren't they compiling to JS? They're cheating the runtime out of the ability to JIT the resulting code, which seems like a huge penalty.

I'm assuming that most of the runtime cost is in the actual DOM manipulation, so unless the JIT can inline and optimize those calls, doubly-interpreted code isn't going to slow down things much.

However, what they seem to be going for is a reduction of the time it takes to download and parse the code, so a specialized compressor makes sense. WebAssembly or the Binary AST proposal would change the calculation, but maybe it still works for them.