Hi Guys!
I just watched this.javascript where in one part, Evan Vue talks about the path between Vue 2 and 3.
In one part, he talks about them looking into the way svelte and angular ivy are doing AOT compilation of templates for better performance and smaller footprint, but because of Vue.js supports a render function in addition to templates, they can’t optimize in the same way as those frameworks that only uses templates can.
Link to the video: https://youtu.be/DFF9eOlTWzY?t=1301
Don’t know if this is something that does not affect aurelia since it’s not using a vdom, but I was just curious about how the AOT compiler in aurelia will be done with components that uses templates vs render function. Will there be a difference?
PS: The video is a good watch and it’s cool to see Justin from lit-element/lit-html showing the some of the ways the components are done on that framework.
Espesially the way the the scoped css is done with the tagged-template-litteral and shadow dom combined with constructable stylesheets.
Hey 
I get the impression some things are being mixed up in that video.
The difference has very little to do with the presence/absence of a render function, but rather (at least in vNext) with the presence/absence of the JIT package and I’m getting the impression Vue does not have this separation or distinction.
Example: you’ve got a CMS or an in-app editor that provides raw html to Aurelia and you want to put into au-compose. Of course that html needs to be parsed (we can just let the browser do it because we don’t violate the spec ) and then analyzed and searched for custom elements/attributes/bindings, and finally compiled into low-level instructions that the runtime renderer can use.
This is a JIT process. By that I mean it’s done by the template compiler, expression parser and attribute pattern interpreter which are comparatively slow/bulky processes compared to rendering. These components live in the jit package.
AOT will use JIT at “build time” to do all of this… Ahead Of Time. It will do this for whatever it can find in your app. So that inherently limits it to whatever is statically known at build time.
If you don’t need to dynamically feed stuff into the framework from the server or from user input, then that means all the information Aurelia will get at runtime is already known at build time. Then, AOT can pre-optimize it all (whether render is being used or not). Even if you dynamically compose strings and feed it into render and such, as long as the information at some point originates from a static origin, it can be traced and analyzed upfront.
So to reiterate, AOT simply stops at server access and at user input (and external libraries). But render has nothing to do with whether AOT can do its job or not. It’s all about information being statically available upfront or not.
1 Like
Hi @fkleuver! Thanks for clearing that up