[lightblade]

Well, Glimmer actually compiles opcodes to just numbers. So it wouldn't be `a(e,"id","bar")`, it's actually [1,'id','bar']. Opcodes' wire format is an array. I haven't see it being a tree yet. If this is the case, stream parsing is definitely possible.

[ibdknox]

You could do even better than this if you wanted. Since there are only between 100-200 dom attributes, you can pack that into the opcode itself. Assuming 6 bits for the opcode (64 ops) and 8 bits for the dom attribute (256 attrs), you still have another 18bits to play with in a 32 bit int. If you wanted to allow arbitrary attributes, you could dictionary encode them and then use the full 26 bits for a total of 67M possible attribute names. Alternatively, you can reduce that entire op down to just the opcode by dictionary encoding the operand and packing that in as well. How many programs have more than 262,000 static strings? :)

Compared to the string encoding above we went from 14 chars (1-4 bytes each, we'll just say 2) at 28 bytes to 4 bytes for our 32 bit int.

[curveship]

Yeah, I was just looking at the Glimmer opcodes format. I'm a bit surprised it's an array of arrays, rather than a flattened array. It looks like it goes `[[1,"id","bar"],[2,<other param>],...]` rather than `[1,"id","bar",2,<other param>,...]`. Wonder why? Monomorphism, or faster dispatch by not having to pass a pc index around? Interesting.

The `a(e,"id","bar")` format is what other frameworks produce. It sounds like in Glimmer it would be `[1,"id","bar"]`. So that's only a single char savings.

[chadhietala1]

Yea this is sort of a relic of the initial VM architecture we landed originally in Ember 2.10. That architecture was more like Clojure e.g. read -> compile -> execute. So the nested arrays are seen as sub expressions. You are correct this can be linearized.

[wycats]

Also, this particular format is the "wire format", which is the compact representation that we compile templates into to send to the client.

The client then compiles that representation into flat opcodes, in part by specializing the template based on runtime information (like the exact identity of the components in question).

The runtime opcodes are binary (128-bits apiece at the moment) and optimized for reasonably fast iteration. The wire format is, as chadhietala1 said, not as flat or compact as it could be, but still much more compact than our earlier representations (or the representations of competing rendering engines).

We plan to improve the wire format representation in the near future.

[swsieber]

Ah, but you can pass it as json and have it render much faster. (If I've understood this thread correctly. Please correct me if I'm wrong)