Why We Use Phoenix Without LiveView<br>| HanziHero

Close menu

Product

FEATURES

Mnemonics

Spaced repetition

Optimal learning order

Chinese characters

Vocabulary words

Character components

Pinyin

COMPARE

Chinese WaniKani

Heisig's Remembering the Hanzi alternative

Anki alternative

COURSE

Traditional

Simplified

Pricing

Docs

Community

Sign up

Existing customer?

Log in

Why We Use Phoenix Without LiveView

Kevin

\\

September 24, 2023

HanziHero is a Chinese character learning web application that leverages the powers of mnemonics and spaced repetition to help you learn thousands of Chinese characters!<br>It is written in Elixir using the Phoenix Framework. Earlier versions of the application used Phoenix LiveView before switching over to using a combination of small composable JavaScript libraries:<br>Mithril - for complex interactions<br>StimulusJS - for simple interactions<br>HTMX - for SPA-like navigation, lazy loading, form enhancements<br>In this article, we will go over why we choose to go with this approach instead of using LiveView.<br>Stateful vs stateless<br>LiveView works by holding a stateful websocket connection. This means anytime you do a deployment, you will need a strategy to persist and restore that state. This can be done via encoding that information in the URL params or hash params, or saving the state in Redis or Postgres.<br>Failing to do so will result in a jarring user experience during deployment, as the LiveView will “reset” as through the user has visited the page for the first time once more. For our quiz component, we saved the quiz session state in Postgres and it worked well enough.

However, we still ran into some rough edges as we needed to evolve the state table schema and data within it during migrations.<br>In comparison, rolling deployments are trivial for traditional stateless applications. Simply have the reverse proxy route all new requests to the newer version of the app. Since there are no stateful websocket connections, there is no need to worry about draining old connections.<br>In short, one pays for LiveView in the form of deployment complexity.<br>Stability<br>LiveView has not reached 1.0 yet, so it is subject to frequent changes. For example, in the past year the recommended templating language scroll-to#scroll" data-scroll-to-behavior-value="smooth">changed from LEEX to HEEX. The HEEX is great and a huge improvement, but it was a bit of effort to make the changes to our existing templates. We could have kept the LEEX templates and still be supported, but most tutorials used HEEX, even before Phoenix 1.7 came out.<br>Related to the previous point, we also ran into an issue where a status code sent by the Caddy reverse proxy when doing rolling deploys would result in the Phoenix LiveView application completely breaking.<br>All of this is to be expected, and I think for many they are willing to accept paper cuts to stay close to the cutting edge.<br>Our JavaScript libraries are all more stable, but still not as much as we would like. Mithril being the shining example, which has had the same API more or less unchanged for over half a decade now.<br>Latency considerations<br>Most changes in Phoenix LiveView requires a server-round trip to process. Therefore, it is suggested that LiveView should only be used for interactions that would need a server round-trip anyway, like fetching extra data or updating a form.<br>The main interactive widget on our site is our quiz page. There users are quizzed on items they previously learned, and they type in the answer to be graded.<br>We initially thought using LiveView would be fine for this, since we wanted to do a round-trip anyway to update the user data when they answer a question.<br>Unfortunately, the visible delay from hitting ENTER and the input turning red or green resulted in a degraded experience.

Given that the quiz widget is what our users interact with the majority of the time on our site, we felt that using a custom built JavaScript client was necessary, so used Mithril instead.<br>However, we think most websites don’t have latency requirements like this. For standard form updates and lazy loading data, LiveView is not going to be any slower than any SPA - in fact it may be faster.<br>Easier to understand and change<br>Phoenix LiveView is pretty magical in what it can do. It does state change tracking to send down incremental updates over a websocket to update the client DOM.<br>Unfortunately, we personally think it is harder to understand and tinker with than the traditional MVC model. I don’t think this is anything inherit in the Phoenix LiveView model per se, but depends on the person. I’m sure there are others that think the opposite!<br>For example, if we hit an issue with HTMX AJAX-powered SPA-like navigation, looking through the HTMX code is usually pretty simple. After all, it is a single file with no transpiler. And I can easily reason about how things are working because it is just a thin layer on top of traditional stateless HTTP requests, which can be...