Why not some type of VDOM solution? I imagine it would be faster than comparing HTML strings, but tbh I have no clue what the performance difference would be.
And what’s the problem with polluting the DOM with custom attributes?
(I am a bit out of my depth here, so these are honest questions!)
I really hope @chrismccord works with you on LiveView. You’ve definitely pioneered and popularized this entire concept within this community.
Morphdom can patch a string representing a DOM into an existing DOM as fast as a VDOM solution (look at their github page here, where they explain how it’s possible: GitHub - patrick-steele-idem/morphdom: Fast and lightweight DOM diffing/patching (no virtual DOM needed) · GitHub). Yes, it has to parse the string into a DOM and diff both DOM trees, but if you’re sending a VDOM from the server you’re not actually sending a JS object representing a VDOM. You’re sending a string representation of a VDOM, which has to be parsed into a VDOM in a way that’s probably slower than the browser parsing a string into a real DOM (this is the thing at which browsers are faster).
As I said above, you’re not comparing HTML strings. You’re parsing the HTML into a DOM and comparing DOMs. Comparing the DOMs is not necessarily slower than using a VDOM.
It’s not that much of a problem, honestly… It’s just something I’d like to avoid if it was I implementing a solution. There was a time when Drab used to pollute your webpage with custom <span> elements, and that would cause some real trouble, but adding attributes is probably very safe and won’t cause problems.
Interesting! Sending HTML strings does strike me as a cleaner approach, all else being equal. It’s probably easier to test/debug/extend than any VDOM-type solution that starts on the server-side. Will definitely look into morphdom!
I also feel I must explain the rationale between my solution above (the one which sends only a list of strings into the browser). Having a VDOM computed on the server allows you to send minimal HTML DOM diffs, which the Javascript in the browser can apply to the DOM.
Browsers need the DOM because that’s important for interactivity and to actually render the HTML into pixels on your monitor. But the server doesn’t care about the DOM at all. The BEAM (and by extension Erlang and Elixir) is very efficient at sending bytes through a socket. Dealing with nested structures with backreferences like a DOM is definitely not something for which it is optimized. The main reason why Phoenix templates are so fast is that they do the least amount of work possible besides sending bytes through a socket (see here, for example: https://www.bignerdranch.com/blog/elixir-and-io-lists-part-2-io-lists-in-phoenix/).
My solution (which @chrismccord and @josevalim probably had in mind) intelligently divides work between the client and the server:
That all makes perfect sense. I also imagine that your solution is much easier to implement, as it would require additional client-side code instead of significant changes to server-side rendering.
Honestly, the only reason I dislike this whole LiveView/Drab-like approach is that I just recently converted a ‘regular’ Phoenix app, views and templates, to an JSON API-based approach with the usual Rube Goldberg client-side React implementation ;-). I’d much rather have stuck with Phoenix’ server-side rendering…
You can optimize data transfer even further at the cost of more memory and CPU cycles on both the server and the client by keeping the dynamic list of strings in memory. When you generate a new dynamic list of strings, you compare the new list and the old one. If strings are the same, you can just send a placeholder instead of the string (null, the integre 0, etc). If you have long strings, this saves some space (a lot of space in some cases, even!).
Then, because you’re also keeping the dynamic list of strings in memory on the client, you can reconstruct the placeholders.
At which step you’re trading CPU and memory for data transfer. Depending on your solution, this might be the wrong choice. For example, while the overhead of keeping part of a webpage in memory is low on the client, if you have millions of users, you now have to keep millions of dynamic lists in memory, which might kill your servers… So it’s not a decision to make lightly.
Trading CPU usage for Network transfers is usually the right choice (the network is very slow), but it might transform an IO bound task (at which Elixir excels) into a CPU-bound task (at which Elixir does not excel)
I don’t think of moving code from the server to the client as “easier to implement” xD The complexity is still there, (someone, maybe you, will have to maintain and debug it); you’re just moving complexity around. In this case, you’re building on top of the morphdom JS package, which has some complexity on its own.
The advantages of moving complexity around are that now you’re spending CPU cycles on the client instead of the server and you’re playing on the browser and the server’s strengths: the server dumps dumb bytes into a socket and the client builds and handles a “smart” DOM
This is the approach I suggested but it doesn’t work with nesting (for example, form_for). So when using LiveView someone would need to reduce the amount of nesting that happens in templates (it is doable though). So different tools will make different trade-offs here and that’s totally fine IMO. Hard to say which one is the best without benchmarking and looking at example applications.
Me too! The repo is out, although very early on: GitHub - beam-telemetry/telemetry: Dynamic dispatching library for metrics and instrumentations. · GitHub - We are considering already integrating it with Ecto 3.0 though.
