SW engineering, engineering management and the business of software

subscribe for more
stuff like this:

The Business Case For LiveView Is Strong Enough To Change How You Staff Your Dev Team

This is part two of a short series titled “The Sublime Developer Efficiency of Elixir, Phoenix and LiveView”. You can find part one here.

To recap the initial thoughts on Elixir:

  • It’s quirky
  • There’s a learning curve
  • Taking the time to climb that curve can result in elegant solutions
  • The endgame is high developer efficiency

The above is a succinct summary of my experience using Elixir. My overall impressions of the language, tooling and broader ecosystem are quite positive.

Phoenix

The Phoenix web framework is (as far as I can tell) the crown jewel of the aforementioned broader Elixir ecosytem.

It’s an opinionated web framework, with a bit of magic and convention in it. Just like Elixir was strongly influenced by Ruby, Phoenix’s ancestral roots point to Ruby on Rails.

It’s a great framework. Like Elixir itself, it is quirky & has a learning curve & elegant & you can be quite productive with it. If you are coming from an environment where everything is explicit, the magic and convention steepens the learning curve a bit, but that’s part of the productivity tradeoff.

It is based on the classic MVC paradigm. Elixir’s template language, Eex, essentially compiles down elixir code. It’s fast enough. You can scale vertically, horizontally with a load balancer or with any fancy cluster management solution. The Ecto ORM and Postgres integration quite well done. Ecto itself is, you guessed it quirky, learning curve, etc.

The thing about Phoenix however, is that it’s just an opinionated MVC web framework. Plain old Phoenix isn’t enough for me to radically adjust how I think about creating new web apps or change how I staff up engineering teams.

Ruby on Rails was a tremendous productivity booster during a good chunk of it’s early life. You could make reasonable and often convincing business cases for developing Rails. However, it is 2021; many other web app ecosystems have caught up or surpassed its vermillion tracks.

Phoenix LiveView

LiveView is a relatively new extension to Phoenix. The first release, 0.1.0, was published in August of 2019 and I believe work started in 2018.

Spoiler: LiveView is more than enough for me to consider transitioning a large amount of work to the Elixir/Phoenix platform.

The way it works is tremendously clever. There’s some liveview javascript you include in your html. Then you defined your live view templates like you always do, but with a special .leex suffix (LiveView Eex).

Your typical template will look like this

<html>
    <head>
        <meta charset="utf-8"/>
        <%= live_title_tag assigns[:page_title]%>
    <head>
    <body>
        <h1>
            User Details
        </h1>
        <ul>
            <li>
                username:<%= @user.name %>
            </li>
            <li>
                email:<%= @user.email %>
            </li>
        </ul>
    </body>
</html>

What Liveview does (conceptually) is takes all those embedded elixir tags, and creates a map like so:

{
    0: "User Details Page",
    1: "Jane Doe",
    2: "jane.doe@example.com"
}

When the page is sent to the browser for the first time, those elixir tags are filled in server side. you will see the right values even if javascript is turned off.

The magic happens next. LiveView sets up a websocket to the server. The client can send events like phx-click="checkbox_toggle", phx-capture-click="close", phx_change: "validate", phx_submit: "save", etc.

The server can then do any backend processing, such as change a users email, save it to a database and email a notification. Maybe calculate a new estimate of shipping time for updated contents of a shopping cart. Anything a server needs to do really.

Then, instead of a 302 redirect to reload the entire page to refresh the content (email, cart, whatever), LiveView will send just the data over the websocket like so:

{
    0: "User Details Page",
    1: "Jane Doe",
    2: "janes_work_email@example.com"
}

There’s a bit of javascript logic that rerenders just that part of the DOM with new values. in this case, the <li> with the updated email.

What you get is the speed, responsiveness and UX performance exceeding that of a React/Vue/javascript front end framework against a server API, but you haven’t written a line of javascript.

This is a magical feeling.

Other similar-in-spirit technologies are Livewire for PHP/Laravel and Hotwire for Ruby on Rails. Livewire uses AJAX instead of WebSockets and Hotwire sends little bits of HTML over the socket instead of tiny chunks of data. Conceptually, all three are all quite similar, share the same strengths and the provide a kindred developer experience.

A lot of productivity gains of the Elixir/Phoenix/LiveView stack1 is based on the fact that you can build modern browser experiences without having to write any javascript whatsover.

Phoenix does have a webpack dependency, but it comes preconfigured and the javascript glue code that makes LiveView work is all written for you and included with the framework.

LiveView’s primary advantages:

  • You aren’t required to write any javascript whatsoever.
  • User experience is as fast or faster than React/Vue/etc.
  • Reduced bandwidth. You are only sending tiny data deltas.
  • Works when javascript is off. (fall back mode will just work like a normal Phoenix app essentially)

Hours per feature

I can’t stress how important the first point above is. The way to faster development cadence is rarely “add more developers”. Usually, it’s make them write less code to do good work.

CI/CD makes developers faster, because more of the testing and deployment is automated, drastically reducing human error, reducing code review time, human time on keyboard per deploy, and importantly reducing risk.

Good Project Management improves feature velocity because developers are typically better coordinated with design, product, marketing, etc. They end up writing the more important bits first.

Good Customer Development or User research improves developer productivity because they build features that people use instead of stuff that doesn’t move the needle on business goals.

LiveView makes it so you don’t have to write javascript.2 A poor metaphor: This is a like saying a car repair shop doesn’t need to paint or do body work anymore. All there customers are totally satisfied with having a running enginer.

Obviously, you still have to do HTML and CSS. LiveView is amazing, but it’s not a miracle. All logic is written in elixir and executed on the server. There is no javascript logic required whatsoever.

If you do need some fancy Javascript functionality, there are hooks built-in to the framework that allow arbitrary javascript to send events to LiveView and vice versa.

Sublime Developer Efficiency

LiveView, like the rest of the broader ecosystem, continued the streak: Quirky, Learning Curve, Elegant, High Feature Velocity.

Again, Elixir and Phoenix are quite good, but the productivity gains of LiveView are great enough for me to strongly favor it for all new projects and seriously consider rewriting certain existing projects in that stack. The business case for using LiveView is that strong. It changes the total headcount and makeup engineers I need for a given web app team.3

So that title up at the top? that part-cheesy, part-aggrandizing line about Sublime Developer Efficiency? That’s LiveView. After you get past the quirks and the curve, it’s pleasant to work with and there’s a strong business case to be made that you or your team are going to be really productive with it.


Author’s Note:

This post is the second of a two part series. You can find the first part here.

Lastly, I do live code streaming about Elixir, Phoenix, and LiveView on twitch.tv. You should follow me there.


Footnotes:

  1. This stack now has an acronym: PETAL coined by Patrick Thompson. Phoenix, Elixir, Tailwind, Alpine, Liveview. If you are not familiar with it, TailwindCSS is also amazing.
  2. It’s not my intention to dump on javascript, but there are real pains in that ecosystem: giant node_modules, dependency hell (leftpad), reliance on node and npm with almost no alternatives, etc.
  3. You probably need somewhere between a fifth to a third of your current front end team. Maybe even less because the HTML you generate will be significantly simpler in terms of complexity. Convert them to full stack, or just run a leaner eng team. I’m hearing that good Ruby/js developers can get productive in about 2 weeks and competent in about 3 months. After that, retention is high.


in lieu of comments, you should follow me on twitter at twitter/amattn and on twitch.tv at twitch.tv/amattn. I'm happy to chat about content here anytime.


the fine print:
aboutarchivemastodontwittertwitchconsulting or speaking inquiries
© matt nunogawa 2010 - 2023 / all rights reserved