That’s what Vampyre already does! It only goes one level deep, though.
tmbb
OvermindDL1
Exactly! And one level is fine as long as it’s all flattened, that is “Optimal” actually. Now you just need to autogenerate some unique ID’s to put in the DOM, and of course parse the DOM itself (Floki or so) at compile-time to be able to do that, and pass the requisite rebuilding information into generated javascript to be injected into the template, and done. 
1
tmbb
OvermindDL1
tmbb
But how is yours more optimized? Because you only update a certain ID instead of rebuilding the whole DOM
1
OvermindDL1
That is a big big one there but the dynamic data ID to DOM ID-list mapping also allows for extremely efficient in-place updates in the DOM without needing to construct elements at all unless necessary (creating new one for example of course). Mutating the DOM is surprisingly cheap, rebuilding the DOM is lag-hell.
0
tmbb
That’s not what the morphdom guys say 
But I believe you’re right… I should do what you say, but that requires doing pretty much what @dgmcguire wants to do. But Vampyre templates are still useful in these circumstances. They are very fast at rendering the HTML to strings.
It’s like I’ve told @dgmcguire: this requires an intermediate representation which I can compile to a highly optimized string representation while I simultaneously keep enough semantic information to add unique IDs for everything.
Writing an EEx engine that compiles into valid HTML poses some challenges, though. It would require (seemingly) arbitrary restrictionson what you can put in a template. Drab already does more or less that. I don’t know if the high complexity and unintuitive interface is worth it.
EDIT: The problem is that users expect to be able fo use normal EEx templates with no restrictions. That is possible with vampyre, but some restrictions are needed for something that compiles to a server-side DOM.
0
OvermindDL1
I’ve tested quite a bit and that’s how it always came out. ^.^;
Why do you think bucklescript-tea is so fast (it blows react away as just one example, faster than vuejs and all)? 
Observeable updating is even faster as it’s the same but without the iteration.
0
tmbb
Ok, I take it on faith that bucklescript-tea (just TEA from here on) is wicked fast. Bur how do I capitalize on that? TEA seems to be diffing a custom stripped-down VDOM. Is it still fast when it comes doen to patch it ino the real DOM?
How could I feed TEA the DOM fragments from the server in an efficient way? As JSON?
Should I render a webcomponent using TEA that is driven by messages from the server?
0
tmbb
Or are you just talking about reimplementing TEA on the server? If TEA is so fast I should youse it to handle the diffs on the client, right?