54) ElixirConf US 2018 – Closing Keynote – Chris McCord

Awesome keynote Chris!

Loved hearing about LiveView… and this bit made the hairs on the back of my neck stand up

38982×450 132 KB

“Challenge the status quo of what is possible”

“We have this platform that can advance the state of the art”

“The future is ours to build”

Although we’ve seen similar patterns before (i.e. drab) LiveView still totally blew me away and I’ve rewatched the video 3 times now. Now tomorrow morning I get to write tons of React form validation code and repeating the same/similar code in my changeset validations on the server and dealing with all the plumbing… while thinking how much easier it would be with LiveView with no perceptible performance degradation.

The way it was presented it seems like you could make LiveView “components” (stateful and stateless (not needing a GenServer?)) and hook them together like a React component tree. It seems weird to say but maybe we could have “JSX-like” syntax inside the EEx LiveView components which could call other LiveView module’s render functions with props (assigns) and children. All the data would be accessible server-side so less need all the JSON/GQL requests. It seems like that should work… and it could be the right choice for many (not all of course) project types.

Unbelievably incredible job @chrismccord just can’t wait until it is released for experimentation!!

You can probably get something pretty similar to LiveView reuseable widgets right now by:

1. Setting up a channel
2. Hooking up some JS to events in your forms (maybe using custom attributes)
3. Rerender the form on the server
4. Send the HTML back to the client and diff it with the JS morphdom library.
5. (Bonus) have a deterministic ID for the resource so that different cliente can edit it, and you have a (bad) collaborative realtime resource editor (with last-write-wins semantics, which is what makes it bad)

Hmmm… interesting thanks @tmbb. Definitely your ideas would work while we wait for LiveView.

Since I have already invested several months learning and building a working React-based system (and have no offline requirements) I think I will look into channels to more efficiently do async field validations… at least those that are more complex than simple regexes. I haven’t had a need for phoenix channels to this point and this seems like a good opportunity to learn it finally!

From the talk, I believe that “my” ideas are basically the same as the ones behind LiveView (although I’ve certainly had them independently). The main advantage of LiveView over something custom like what I describe here is the existence of a widely accepted pattern which user can follow. But by all means experiment with these kinds of solutions yourself!

This really looks great and I’m excited to try it out. My biggest question is about how this will affect Drab? Will the projects consolidate?

Similarly, how does this relate to the Texas Server-side Virtual DOM library? The ElixirConf video was pretty good on that.

All these server-side implementations of client-side js apps are appearing quickly. Shows how well put together phoenix is.

Fantastic video, really excited about this, can’t wait for it to be released. Great work!

Imagine the following sequence of events (imagine a non-trivial latency):

1. Client sends an input field
2. The server validates the input field and sends the form back to the client
3. The client edits (and sends) the new input field
4. The client receives the 1st diff from the server

In step 5, the client must be smart enough not to undo the changes in the input field (there are many ways of dealing with latency, you just can’t paste the diff from the server while ignoring that it’s an input tag that might have been changed), preserve caret position and all that. This requires some level of “smartness” on the client. I think that if you’re having such a smart client, you should move most of the diffing work there.

But yeah, if you version your diffs with a monotonic sequence, use operational transformations or a CRDT or something like that you can achieve the same results. It just seems simpler to let the client do most of the job.

In fact, I don’t know if morphdom handles the sequence of steps above gracefully. The tests we’ve seen in the video show almost no latency, which allows us to ignore the fact that the client-server connection is actually a distributed system. I’d like to see a demo with realistic worst-case latencies (~ 300-500ms)

Yes, Texas does the diffing on the server, Phoenix does it on the client. I believe the diffing of input tags could be done on both sides though - it is just a matter of sending enough information to the client, structured or not, for it to happen.

Dan, Chris and I also had a conversation between their talks and I think it is possible to at least reduce the amount of data LiveView currently sends to the client. Today it sends the whole template but they can likely extract the static parts out during compilation time. There are many possible optimizations available on both projects.