Nope, no DOM representation at all, literally the data, think of the assigns in the template, if any part of it changes then you just do one of two things (depending on library design), like serialize it out to something the javascript side can handle, so if something like @title (assign[:title]) changes then you just send a json patch of like {"title":"newtitle"} (and the json patch formats for updating parts of a string or arrays or so is quite good), or you can generate a set of commands to modify based on pre-baked information at compile time of the data to ID mappings and send those json commands across (a refined/enhanced version of Drab’s style).
OvermindDL1
tmbb
OvermindDL1
Eh, kind of for the first method, except where it just encodes what it needs to know to rebuild the parts that each data access, and not at all for the second method.
tmbb
Refining drab seems hard… I think Drab is already operating near the limit that its mode allows. It could be improved by merging it with morphdom (send the parts of the dom you need to update as literal html and let morphdom diff them), but IDK.
OvermindDL1
Oh not at all, there are many opportunities for efficiency enhancements! A lot of what I said above for example.
Oh that would be much worse! Right now say you have something like <span class="blah">Value: <% @stuff %></span> in a deep DOM tree and the @stuff value changes via a commander, right now it sends a tiny little bit of javascript that directly edits the span’s text element. Compare that to if using morphdom where you’d have to send the entire DOM tree over down to whatever marked point as a string and let it iterate over the entire thing to find the specific difference to update just that one point, which is both incredible worse in both speed and network bandwidth both!
tmbb
No you don’t. You can simply tell morphdom to replace the contents of that specific span tag. In this case there is no advantage compared to ussing span.innerHTML = ..., but in other cases there might be an advantage. Morphdom can patch any element of the DOM, it doesn’t have to patch from the root.
tmbb
I’m not making use of that in Vampyre, of course. With Vampyre, I’d have to ask morphdom to generate the whole DOM from the root and then diff it. Which, as you say, is very inefficient. But my main target was to send as little data through the network as possible, and I think I’ve succeeded with that. Maybe it was not the best target, though.
OvermindDL1
But if you already have the direct element then why not set it directly then so you don’t incur the cost of parsing the string, performing the diff, etc… when you can just set the new value immediately?
Uh, wouldn’t this send just about the ‘most’ amount of data through the network as possible though? o.O
tmbb
No, because I cache the static html fragments on the client and only send the dynamic fragments from the server. That’s the while point of yhe UndeadView project! Vampyre is just a spinoff which doesn’t implement the transport layer (which hasn’t been written yet) and which (as a side effect of optimizing for data transmission) is very fast
You can see how it’s supposed to work by re-reading the first post in this thread 
tmbb
I’ve been playing with some ideas to make Vampyre more efficient on the client side. Vampyre doesn’t actually have a client yet, but any client I can think of with the current architecture wouldn’t be very efficient… I can implement a much more efficient client if I restrict Vampyre’s semantics such that it operates on a VDOM instead of raw binaries (this is more or less the same as what @dgmcguire is doing).
The problem is that it will break compatibility with Phoenix.HTML in minor ways. This means that Vampyre won’t be a drop-in replacement for Phoenix.HTML anymore. I don’t find this to be a deal breaker in practice, because the tag() function in practice, except to implement other widgets, and even in that case I don’t like the current API that much. Aside from teh tag function, I believe I can maintain compatibility. In particular, I can maintain compatibility with the form_for/4 function, which in my opinion is the whole reason to use Phoenix.HTML instead of rolling your own HTML in the templates.
So, I have some questions for the audience:
-
Would you use Vampyre at all? Or with Phoenix.LiveView doing pretty much the same thing would you prefer to use Phoenix.LiveView anyway?
-
Would you use Vampyre even if it broke compatibility with Phoenix.HTML if it were faster on the client and more efficient regarding data transmission over the network?
I’m assuming that Vampyre will be more efficient because my architecture allows me to do things that are simply not possible with the way LiveView is shaping up. In particular, I’m willing to implement all widgets as macros to get the highest amount of optimizations possible.