I have been building a web app product using Phoenix LiveView recently, it’s been very pleasant experiences for me. Since I was a long time Ruby (On Rails) developer since 2011 and then got my brain washed on functional programming (Clojure, ClojureScript) in 2014, so Elixir turns out a perfect fit for me (especially my brain). It has the dynamic language feeling but also comes with compiler helps to avoid silly bugs; it has powerful pattern matching; the syntax of the language is simple and concise. I often looking at the code I wrote and felt extremely satisfying, almost to the extent of seeing the code I wrote like an “art” piece (thanks to Jose on the language design). There are lots of things Elixir changed my brain in the good way that I will write about in a later post. In this one, I would just focus on the LiveView part.
If you haven’t heard LiveView yet, you can read more on here. Essentially, I think LiveView is trying to leverage three things: WebSocket, OTP and JS diffing/patching. Of course this is a dramatically simplified pillars of LiveView, but I think these are the keys if you want to understand what’s going behind the scene.
The first part and arguably the most important part is the web socket, it enables the long live communication to the server, so that any client side events can be “think” as they are happened directly in your Elixir code as well. Let this idea sink a bit for you before moving on. Because I think this is the fundamental difference not only technically but also can change the way you think about the programs.
For example, we want to switch a toggle button to change a user profile configuration.
Here is the traditional flow of simple client/server updates:
LiveView’s flow would be like:
Maybe the number of steps in the list can not justify the mental burden it applies to our brain. But here are couple things I would have to think of in the traditional client/server flow which I don’t need to in LiveView:
Please notice that there are lots of other nuances in between that I omitted, I also deliberately uses “callback” event here because that’s a more familiar term for client side engineers. But my point is by looking at this new flow, you will realize there is a huge mind shifting difference: LiveView enables you to think closer to the data source.
With LiveView, sometimes you almost feels like you are coding everything in one machine without the internet. Because it eliminated the events listening, the network call, the endpoint handles it, the data contracts design between client and server, the serialization of the data passing back and forth. By saving all these mental bandwidth, it enables you to think more closely to the data source.
It’s such a blessing to be not thinking all the data flows, endpoints in order to flip a switch. But there is a catch, not technically (though there indeed is, but not the major thing I want to focus on this article), but mentally about how you think about the your UI or UX.
I found out comparing to traditional client side UI frameworks like React or Svelte, the main impact it has over my mind is how I approach the UI/UX. With the power of seamlessly communication between client and server side, a lot of times I would easily falls into eagerly manipulating the data bits, being more obsessed with the data, sometimes by sacrificing the user experiences.
I think this is not an issue just applying to myself, people doing both design and coding were often impacted by this as well.
I found myself ended up asking different kind of questions using a client side framework vs LiveView. Because client side JavaScript, obviously, enables you to think more closely the the human being, cause it’s naturally, physically closer to the user. While your elixir function is ultimately lived inside a different process in a distant warm data-center.
When I tried to use Svelte (or any other client side framework, I will have another post on why I love Svelte so much) to replace some of the UI, I found out that it enables me to “sit” more closely with the user, thus it focus me to think more from the actual user perspective on how they use the product, how we should present the data using what transition or animation so that it’s more “accessible” to them.
Productivity is a double edge sword. Being able to do things extremely fast can enables us delivering features we can’t do yesterday, but sometimes it comes with an invisible cost or benefits to our brain, to the ways we are thinking about a problem.
I would admit that I’ve both overused client side frameworks and LiveView in the past. By overusing them, I would quickly found out the cons of the tools in a more tangible way.
I sill love LiveView (and Elixir) and Svelte. Using these tools just makes me happy.