6 ms·

Introducing Bundle Compiler

49 points by jashkenas 9y ago

nathancahill 9y ago
> 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 9y ago
  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 9y ago
    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.
bcherny 9y ago
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?
steveadoo 9y ago
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)?
- killercup 9y ago
  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.
- rubiquity 9y ago
  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.
- zimbatm 9y ago
  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 https://news.ycombinator.com/item?id=14050625

49 points by jashkenas 9y ago

> 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 9y ago
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 9y ago
  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.

bcherny 9y ago

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?

steveadoo 9y ago

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

killercup 9y ago
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.
rubiquity 9y ago
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.
zimbatm 9y ago
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 https://news.ycombinator.com/item?id=14050625