
Introducing Bundle Compiler - jashkenas
https://github.com/glimmerjs/glimmer-vm/pull/631
======
steveadoo
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)?

~~~
rubiquity
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.

------
bcherny
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?

------
nathancahill
> 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.

~~~
zzalpha
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.

~~~
yorwba
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.

