Why Elixir? Phoenix & LiveView are unmatched for Modern Web Apps

RisingStack's services:

Search

Node.js Experts

Learn more at risingstack.com

Sign up to our newsletter!

In this article:

Let’s face it: In the JavaScript world, we still don’t have a killer app. 

We’ve previously written about Redwood and Blitz, two technologies that seemed promising at the time, but they’re still not really there, and we do not see them taking the community by storm. (You can read about them here: RedwoodJS vs. BlitzJS: The Future of Fullstack JavaScript Meta-Frameworks)

On the other hand, Next.js has become the de-facto standard for full-stack development, but it’s still far from becoming a kind of “React on Rails”, and compared to other frameworks, a Next.js project is definitely not smooth sailing either.

In our meta-framework post, we briefly mentioned Elixir’s killer app, Phoenix, and LiveView. If you felt it was foreshadowing what was to come, you were right.

Because of Phoenix and LiveView

Phoenix is basically Rails for Elixir, but unlike Rails, it scales really well. And just like Rails, it comes with a powerful code generator: you simply define your data model, and a full-stack CRUD feature is generated for you with migrations, models, basic business logic, templates, components, and forms. It uses Ecto, which provides migrations, query builder model definitions, and validations for those models… and forms too! You can create forms based on your Ecto models, and Phoenix handles the form validation for you automatically, so you don’t need to repeat the same thing in multiple places. 

But Phoenix provides much more: Do you need authentication? Just run `phx gen.auth`, and you have everything from registration through login to email validation and forgotten password. You need to notify a subset of clients of events? Use Phoenix.Channel. Need to see who’s online? Phoenix.Presence tells you exactly that. And the list goes on.

To explain why LiveView is awesome, we’ll need to dig a bit deeper into why it’s superior to SPAs first. But long story short, the speed and simplicity provided by Phoenix and LiveView are just unimaginable after working on SPAs for almost a decade. How fast, you ask? Look at this video where a live twitter clone gets implemented in 17 minutes.

So just to answer my own question: Why Elixir? Because of Phoenix LiveView.

What’s wrong with the Web today?

We used to build backends for web pages. They were simple but weren’t really interactive.

Rails architecture

Then came mobile apps, and we loved the interactivity. We wanted to have the same in the browser, so we started building web Single-Page Apps (SPAs). 

SPA structure

While the architecture of a SPA does not seem that much different from a simple set of pages, the Client-Server separation made everything a lot more complicated. Previously, we had one system that simply generated HTML strings, and we added some JavaScript to it here and there. Now instead, we have a backend API and a frontend app that are essentially two different systems with their own states, their own validations, and their own storage (think LocalStorage and IndexedDB).

We started to not only deliver HTML with CSS and some JavaScript logic for DOM manipulation to the browser but also a whole framework with a complex application. Inevitably, load times became slower and slower as the amount of code we sent over the wire kept growing. This is not a problem for applications that we open and use throughout the day, like webmail clients, instant messaging platforms, or to-do apps, but we use these frameworks for literally everything. 

And why? Because we have to. 

Take, for example, a simple listing site, which sounds like a good target for a simple web page: it has to be SEO friendly, listings have to be loaded quickly, and at first glance, it seems pretty static. Still, it needs interactive filters, navigation, and loading animations, so even though the majority of the content could be easily generated on the server, we end up needing to write a full-fledged web app for that too. So we needed to figure out how to render JavaScript on the server side. Or at least we thought. 

Next structure

So we started to do just that and started using Next.js, Nuxt, and SvelteKit. But rendering JavaScript on the backend is ridiculously resource-heavy. While in the olden days, we simply needed to replace variables in an HTML string template, now we need to run JS on the server as a browser would so we can generate the same thing. So while we have the possibility to use SSR, we should only rely on it when we can easily cache the generated pages on a CDN. 

Well, if it changes so rarely, we can statically generate it, can’t we? But for now, most frameworks handle SSG in an “all or nothing” manner, so if the data behind one-page changes, we need to regenerate the whole site. So in those cases, we better rely on Incremental Static Regeneration (ISR), where the page only gets generated when it’s requested for the first time and gets cached for a given period of time. If the page gets accessed after its TTL has expired, the stale page gets served to the user, but a new version is generated in the background. So we’re juggling with SSR, SSG, and ISR, which makes it even more difficult to reason about our system. Mind you: this whole complexity is there so we can have some interactivity while forgoing the need to show our users a loading bar when they first navigate to our page.

Web development really got out of hand in the last decade.

LiveView to the rescue

The whole problem arose because our toolset is binary: A site is either interactive or simple. No middle ground, while the majority of the apps we build could do with some sparkle form validation, navigation, and filtering and could leave the other parts static. 

LiveView

The idea behind LiveView is fairly simple: You create templates that get rendered into HTML strings, then ship them with minuscule JavaScript that latches on to form controls and links. The JS lib also builds a WebSocket connection between the client and the server. Through that connection, interactions get streamed to the server. You update the state on the backend as you would do with react, and the diff between the old state and the new state gets sent to the frontend through the socket. Then the LiveView JS lib applies said diff to the DOM. 

And that’s it. When the user navigates to our page, LiveView replaces the variables in the template just like any other simple template engine would do instead of mimicking a browser on the server. It’s fast, interactive, and simple, just as we needed. And all this using ~1000 lines of JavaScript (88Kb without gzip and minification).

Why we’ll help you learn Elixir

So if you’re a startup or working on side projects and you build web apps, you should definitely start learning Elixir, Phoenix, and LiveView. It might take a couple of weeks to get productive, but the fact that with them, one person can achieve what 3-5 other engineers can do in the same amount of time with other tools starts to pay dividends quickly. Not to mention that they make web development fun again.

To help you with your journey, we’ll start writing tutorials specifically for you, JavaScript developers, starting with a how-to-get-started guide and a cheat sheet.

Share this post

Twitter
Facebook
LinkedIn
Reddit

Node.js
Experts

Learn more at risingstack.com

Node.js Experts