Programming Phoenix LiveView

The days of the traditional request-response web application are long gone, but you don’t have to wade through oceans of JavaScript to build the interactive applications today’s users crave. The innovative Phoenix LiveView library empowers you to build applications that are fast and highly interactive, without sacrificing reliability. This definitive guide to LiveView isn’t a reference manual. Learn to think in LiveView. Write your code layer by layer, the way the experts do. Explore techniques with experienced teachers to get the best possible performance.

Instead of settling for traditional manuals and tutorials, get insights that can only be learned from experience. Start with the Elixir language techniques that effortlessly marry your client templates and server-side handlers. Design your systems with the right layers in the right places so that your code is easier to understand, change, and support. Explore features like multi-part uploads and learn how to comprehensively test your live views. Roll into advanced techniques to tie your code to other services through the powerful publish-subscribe interface.

LiveView brings the most important programming techniques from the popular Elm and JavaScript React frameworks to Elixir. You’ll experience firsthand how to harness that power by working side by side with some of the first LiveView users. You will write your programs to change data on the server, and you’ll see how LiveView efficiently detects those changes and reflects them on the web page. Start from scratch, use built-in generators, and craft reusable components. Your single-purpose reducers will transform server data that your renderers can turn into efficient client-side diffs.

Don’t settle for knowing how things work. To get the most out of LiveView, you need to know why they work that way. Co-authored by one of the most prolific authors and teachers in all of Elixir, this book is your perfect guide to one of the most important new frameworks of our generation.

@ Pragmantic Programmer

Intro

Steven Nunez: Welcome to the GOTO Book Club. I'm Steven Nunez, and today I'm thrilled to talk about a book that captures the excitement and joy when programming Phoenix LiveView. Programming Phoenix LiveView. That's the book. I'm joined today by its co-authors, Bruce Tate and Sophie DeBenedetto, and I wanna just dive right into it. Bruce, can you tell us a little bit about yourself?

Bruce Tate: Yes. I am the founder of a company that teaches Elixir developers to code LiveView and OTP, and then some of Elixir itself, and I've also been involved in the Elixir publisher... Edit. I have also been involved in the Elixir publishing community for a good long while. I was the original editor of the Elixir source line of books at the Pragmatic Bookshelf. So, I've been involved with Elixir since before version 1.0, and I'm excited to talk about this topic today.

Steven Nunez: That's so cool. Again, just like so many great Elixir books that you've been not only a part of, but have written, which we'll get into in a little bit. Sophie, how about you?

Sophie DeBenedetto: Thank you for introducing us and hanging out here today. I'm Sophie DeBenedetto. I am also the co-author, along with Bruce Tate, of the Programming Phoenix LiveView book, out in beta now Pragmatic Bookshelf. A little bit about sort of my programming background, I'm a staff engineer now at GitHub, where, you know, before you ask, we don't use any Elixir or BEAM languages, sadly, or should I say, yet, you know. Always holding out a tiny spark of hope. My introduction to sort of the Elixir publishing world came through Bruce, when I came on to co-author this book with him, and Bruce, you mentioned that you were formerly the Elixir series editor at Pragmatic Bookshelf. I am the new Elixir series editor at Pragmatic Bookshelf, which means that my job is to help people who want to write books about Elixir for Pragmatic Bookshelf. So, if you have an idea for a book, and you wanna talk about it, you should reach out to me on Twitter. I think our contact information will be available. If you're listening to this recording, I'm here to hear your idea, and to help you get that proposal submitted to our proposals committee if that's something you're interested in doing.

What else? Along with Steven and Bruce, and a couple of other fabulous people, including Lars Wikman and Alex Koutmos, we co-host the "Beam Radio" podcast. Steven Nunez is showing the "Beam Radio" T-shirt, and it's a very handsome T-shirt at that, courtesy, I believe, of Bruce and Maggie, who help produce the show. So, check out the podcast if you haven't yet, or if you like what you hear today if you wanna just listen to us hang out and talk about all things BEAM. What else? I like to write about Elixir. I like to write Elixir. Wish I could do it a little bit more in my professional life, but that's one of the reasons why I've been having such a wonderful time working on this book with Bruce.

Steven Nunez: Chances are, if you're looking for something related to how to solve a problem in Elixir or Phoenix, you're gonna run into Sophie's work out there on the blogosphere. The book is just an extension of that awesome writing.

Sophie DeBenedetto: Thank you.

Building a Case for LiveView

Steven Nunez: So, you guys are directly involved with Pragmatic Bookshelf's Elixir line, as you mentioned, and you kind of decide what goes out. This book is important to put out. Not only that, I'll let the readers know, it's a bear. It's a huge book. Like, it's a massive book, incredibly comprehensive, talking about Elixir, Phoenix, LiveView, and design, which we'll get into, but for listeners that are new to Elixir and Phoenix, what is LiveView? And, kind of, what problems does it solve? What domain does it sort of exist in? I'll toss that over to Sophie DeBenedetto to start.

Sophie DeBenedetto: Cool. So, if you are brand new to LiveView, and you've maybe not heard much about it before, which was the audience I was, speaking of GOTO, I gave some LiveView talks at GOTO Copenhagen, and I asked for, like, a show of hands who's worked in LiveView before, and one or two people raise their hands each time, so it's very cool to see that there is some broader interest in the functional programming community. If you are tuning in and you don't really know anything about LiveView, but you're just a little curious, you're not alone among other functional programmers.

So, what is LiveView? It is a real-time web development framework that is incorporated into the Phoenix web development framework, which is Elixir's web development framework. How many times will I say web development framework? It's kind of the Rails of Elixir, or, the Rails of functional programming, and I think one of the cases that I tried to make in my recent talks at GOTO Copenhagen is that LiveView makes functional programming relevant to web development, because up until, I think, even more recent versions of LiveView, which makes it such a compelling choice for teams, companies, organizations, we didn't have a go-to web dev framework beyond Phoenix, which it is just an extension of that, that would sort of let functional developers build web apps that take advantage of a lot of the features of functional programming.

So, it's written in Elixir. It's written on top of OTP, so as far as functional languages go, you get the benefits of it being, working with immutable data structures, and you get all the other benefits that you might be used to just in terms of modeling the world with a functional framework. I think the actor model is very much the principle of LiveView. A LiveView is a process, and it passes messages. And because it's built on top of OTP, you get all the benefits of OTP without having to understand how that works. So, instead of, like, Rails magic, which abstracts away a lot of the internals of how a web application or a web server works in an object-oriented language, you get this kind of OTP magic. You get massive amounts of concurrency for free. You get fault tolerance for free. A LiveView is a process that backs your webpage. So, if it crashes, it just starts back up again, and there's lots of kind of niceties around making that a seamless experience for your user.

So, in short, it is a functional web development framework that is built on top of Elixir and OTP, to bring real-time web development to functional programmers, and everyone else. What it lets us do, and why I think it's taking off so much within the Elixir community, and we're starting to see it take off outside of the Elixir community, is that you're building single-page applications with a pure server-side framework. 

It allows you to build single-page web applications with a purely server-side mindset, which isn't to say that JavaScript won't be running, or that you won't write any JavaScript, but if you're used to the complexity, and kind of the added overhead of something like React, where you're coordinating your API, and your front end code, and your backend team, and your front end team in dealing with onerous release cycles because of that, and you're dealing with a lot of cumbersome tests because of that, you're gonna pretty much write almost exclusively server-side code. You're gonna keep the mindset of, you are developers, your team, firmly on the server side, you're gonna execute a purely Elixir test suite, and you're gonna get all the benefits of a highly interactive, real-time, single-page app, without, I used to say without JavaScript, but there's plenty of JavaScript in LiveView. You just don't have to write the boring parts. You don't have to write any JavaScript at all unless you want to or need to add in something extra special and fancy, which LiveView lets you do pretty seamlessly.

Steven Nunez: Bruce Tate, how about you? Why is this important? Why should people think LiveView is relevant?

Bruce Tate: I could say everything that Sophie said, but that'd be a little bit less interesting. So, let's go back to when José first started writing a web application, or a web application server, and that wasn't Phoenix. That was a little framework called Dynamo. And it was his first take on what web development should be. And, unsurprisingly, there's, the use cases in Elixir were still evolving. The abstractions and design patterns were still evolving, and that wasn't exactly what he wanted it to be. So, when he went looking for a solution to how to build web applications in Elixir, he started with a web server application...what? Lego, framework, toolkit, or something like that. And essentially, what this thing was, was a common data element, called a Plug.Conn, a connection, and functions that worked on it. And every single one of those functions accepted a connection and returned a connection. And so, you could think about Phoenix as one long, beautiful function. And with that abstraction, Chris McCord found it, and they worked together to build the Phoenix framework.

Recommended talk: The Power & Performance of Phoenix LiveView • Geoffrey Lessel • GOTO 2021

The thing that made that interesting to functional developers is that we had functional composition, in a functional language, and it was really beautiful. And LiveView just extends that model to, rather than having a request-response framework, LiveView supports a single-page framework, so that we go through this one long chain of plugs, we get to a point where we say, "Hey, this is a LiveView," and then Phoenix loads the page, returns the page, and there's a little bit of pre-written JavaScript on that page that says, "Establish a connection on a straight HTTP socket." And then, from that point on, we're doing one of three things. We're establishing data, we're transforming that data, maybe from a button click on the page, or maybe somebody fills out a form and we need to validate that. Maybe it's some type of a slider or a link. And then the last thing is we're rendering whatever's in the socket. So, that old single-page application were this kind of weird, entangled mass of code and state, and the state came from all different places. We kind of put that stuff together, in a process. And then we accessed it, just like Sophie said, with the actor-based model, so that you're either establishing state, changing state based on clicks, and rendering state. So, maybe, in the socket, we have a list of users, we have a button that says remove a user, and then all that button does is remove a user from the list. And then, in another dimension, we just render that page whenever the state changes. So, it's a beautiful way to build web applications.

Steven Nunez: LiveView feels like an inevitability if you look at the OTP framework. Even in "Programming Erlang," by Joe Armstrong, talks about abstracting away interacting with a web socket, and it's an actor model. It's all OTP. And when you look and dive into the internals of LiveView, you get the same kind of feeling, that it's like we're just interacting with a central state, and then how we render it is a bit different.

Potential Drawbacks of LiveView

Steven Nunez: I wanna talk a little bit about some of the concerns that someone might have coming into LiveView. One of them, or working with a SPA in general, is sort of, like, SEO concerns. And in addition to that, Sophie DeBenedetto mentioned that you're not gonna have to write any JavaScript. I don't know exactly what you said, but how does LiveView allow for those things, SEO, and sort of that big concern of, like, not showing up in Google, and then also, like, okay, if you have to use a library that's been around forever, how do you do that in LiveView?

Sophie DeBenedetto: You wanna start with this one, Bruce Tate? I'll take it. Okay. So, SEO is something that you mentioned, and I think it was one of the biggest concerns that Chris McCord and the team addressed, even at the very beginning, kind of baked into the very nature of the LiveView paradigm, because of course, without SEO, absolutely no one will use your web development framework for your single-page apps. So, the beauty of LiveView, exactly as Bruce described, is that it starts out like a regular HTTP GET request, and it begins by rendering a static webpage. So, your LiveView template will first render as static HTML. Then, that little bit of LiveView JavaScript that's embedded on the page for you for free will kind of kick in and open that persistent bidirectional web socket communication, so that SEO is gonna run on that first static render. So, SEO is not at all a concern for LiveView. There are many concerns that one may have when working with a single-page web application, and I think that these are considerations that are not at all specific to LiveView. As I said, they're very many considerations that I think anyone building web apps today may have and may share, and I think LiveView has, like, an ideal solution for all of them.

So, not to sort of, like, flog my GOTO talks too much, but I did give a talk at GOTO Copenhagen at the beginning of October, talking about really exactly this topic, sort of laying out this list of sort of these main and common concerns when it comes to single-page web apps, and then I kind of went through each category and talked about the solution that LiveView has for each one. I'm not gonna try to recap my entire talk right now, but I'll give maybe just a little bit of a taste of it. So, I consider, sort of, this list that I'll recite right now to be some of these common concerns. There are questions about security. How do you secure your single-page apps? Certainly questions around state recovery. What happens if the app crashes or if the connection is lost? That's something that JavaScript web frameworks have a lot of answers for. What about file uploads? File uploading in your single-page app can be notorious, if not difficult, maybe just kind of laden with toil. There are questions around code organization that I know we're very eager to hear from Bruce on. Especially if you have ever worked with a dense, nested, gnarly React app, I think the question of code organization may resonate with you.

Questions around integrating JavaScript. I mentioned earlier that you don't have to write JavaScript. That doesn't mean that you don't get to write JavaScript. LiveView has a solution for that as well. Then there are also questions about efficient data transfer. And maybe I'll just go into a little bit more detail on just this one because this is a question I would get a lot. And Steven, this is a question you and I would get from our students when we taught our LiveView workshop, which is now sadly out of date because LiveView has changed so much since we first gave it a year or two ago. But one of the main things that people would ask me when learning LiveView was, "What if I have a lot of data that I'm trying to communicate between the client and the server?" We know that  LiveView is backed by a process on the backend. We know that it's connected to the client over this persistent web socket connection. So, let's say you're building some sort of Spotify-type web app, and you've got a bazillion songs to send down to the client, or to make available to the user in some way, and to allow them to interact with. LiveView always strove to minimize data transfer, and make that communication as efficient as possible, which it did from the outset, and still does, when it comes to rendering the smallest possible page divs when the state of your page has changed. But if you have, like I said, a bazillion songs, you have a bazillion songs. It doesn't solve that problem.

LiveView has solved that problem since a couple of months ago, I think, at this point, with the streams feature set in LiveView, which allows you to manage really large datasets in your LiveView by detaching it from the server and storing it primarily client-side. And if it kind of makes you shiver a little bit to say you're gonna manage a huge amount of data client-side, LiveView does it for you, and this is the beauty of LiveView. This is something we haven't talked about yet. LiveView is a declarative framework. You will never have to tell LiveView how to do something, and this is no different. You don't have to tell LiveView how to manage your 1000 Taylor Swift songs that you are trying to display to the user to take them on a walkthrough of the Eras Tour, because the LiveView framework contains all the code that manages that data client-side, and exposes to you, the developer, a sleek API for you to do things like update data in that data set, which was called a stream, add something to it, clear it out, bulk edit, remove, and so on. So, LiveView handles the hard parts of that for you, and you kind of just are focused on what you care about as an application developer.

Steven Nunez: I love it. There's so much power in the framework, and it keeps getting better. I'll just mention this. I wanna move on to some of the things in the book, but, anywhere that Elixir can run, LiveView can run. We've seen it in embedded systems, which is cool, with the Nerves Project. And then, LiveView native. That exists. We'll have it on mobile. It's great. 

Recommended talk: Genetic Algorithms in Elixir • Sean Moriarity & Bruce Tate • GOTO 2023

Crossroads of Web Dev and Design Patterns

Steven Nunez: Bruce, I wanted to ask you a question. So, you wrote "Designing Elixir Systems with OTP." I have it here. Bruce, you need to sign this for me. I need it. This is, like, I go to sleep with this every night. It's all about the design for me. This new book, though, is as much about design as it is about web development. I know you cover a lot of this in your training, but can you talk about the value of sort of focusing on patterns? A lot of books that are covering a framework are just trying to teach you enough to, "This is kind of how it works. Here's your map function. Here's your render function." You guys go the extra mile, and I want to understand what the thinking is behind that.

Bruce Tate: That's interesting. I've heard it said, by, actually, specifically, by a man named Melvin Cedeno, at a conference that we had, called Lonestar Elixir, in 2020, that Elixir is reduce. And what it meant was that Elixir is two different things and one of them is how do you compose functions? And with Elixir, that does mean reduce. How do you take something like that plug connection, and do a little bit of work to it, and return another connection? Whether that little bit of work is fetching a session, or managing some small bit of security, or actually taking us from the actual flow of plugs, and into the router, where we actually start to make decisions in the framework. So, at one level, Elixir is about reduce.

And at another level, Elixir is all about what it is in every functional language. It's this ability to manage uncertainty. It's dealing with the worst word in a programmer's language, which is "maybe," right? "Maybe" is difficult for programmers, and that's where we come from. We come from simple abstractions and simple pipes in Elixir, and simple composition in Haskell, to the place where we have to deal with the real complex features, like monads, and the composition. But the way that we think about layering applications in LiveView determines how beautiful the applications that we build, how easy they will be to maintain, and whether we are fighting the framework along the way. It essentially means that we're going to start with some data, and LiveView has graciously defined that for us, and then we're going to think through ways to transform that data and test within that realm. And then we're going to put layers on top, some of which are managed by the framework, like our dependencies that handle the complex parts of our application, so that we don't have to write them, and the lifecycle management, which is managed by supervision, but some of those are exposed in additional layers in our application. Like, we have a boundary layer, where we'll handle things like, oh, I don't know, external interfaces to a database, or managing user uncertainty in the form of user input, and we go through things like schemaless changesets in forms, so that we map those abstractions, all the way from the backend, we apply user data, manage that uncertainty with the right data structures, whether it's a changeset or a tagged tuple or an exception, and then we're able to consume those beautiful boundaries in our application. And that, rather than a list of features, separates the good concepts, the good training, the good books from the bad ones.

Steven Nunez: I think you're right. I think taking the time to build something that is extendable... Because the truth is, we write these books and we do these courses, and folks are gonna, like, copy-paste stuff, you know? You don't want that on your conscience.

Bruce Tate: Thanks for that. You've kept me up all night.

Steven Nunez: No, and it's really...

Sophie DeBenedetto: I'll add that, I have said this before, and I mean it. I have learned so much from you, Bruce, from working on this book, not just about LiveView, which I think we've both been learning as we go, but, especially about how to architect and design Elixir applications and OTP applications, a callback to your previous book. And I think that's what sets this book apart from the LiveView documentation, and another shout out to Chris McCord and to the LiveView team is excellent. It's not just, "Here's a function. Here's what it does." There's lots of good narrative stuff in there about how to do uploads, how to set up your forms, and so on.

But, the book goes beyond that, to talk about how you should be designing your LiveView applications. And a LiveView application isn't just a LiveView. It's a Phoenix application. So, it goes all the way from the design of your database tables, right? Up through to that front end, with your LiveView and your template, that thing that the user sees. So, that's really where Bruce's expertise and opinions around how to architect these applications, things like, and this may sound familiar to readers of his previous book, but things like separating the core from the boundary of your application, things like building out really elegant functions to query your database, with, like, this sleek pipeline of these single-purpose reducer functions, and sort of applying that same type of design and that same type of thinking that you see elsewhere in the Phoenix app to the actual design and architecture of the LiveView itself to the way we think about the different types of LiveView components and layer them to build these elegant UIs. I've become a better programmer, just more broadly, from reading this book. Like, never mind learning, reading, and writing this book with Bruce Tate.

Bruce Tate: I would agree with that. I'm kind of in the same boat. One of the things that was fun to see was that, as the book evolved, we started to see the composition strategies in LiveView itself change. A good example was the LiveView components. They went from these stateless components to function components that protected us from problems in type, with problems with HTML structure and surfaced this functionality in beautiful ways. Because of the abstractions in the Elixir language itself. So, for example, we have these beautiful ~H sigils, that allow us to specify quickly the data type for the LiveView components. And these sigils are exposed, in turn, with a little line that says "use Phoenix.Component." And that "use Phoenix.Component" backs up to a macro. And there are also some very elegant abstractions in the way that we manage forms, that take advantage of Elixir protocols. But all of these things kind of layer on top of each other. And so, the opportunity to kind of explore that with Sophie, and kind of have this relationship, through a book, with the team that works on Phoenix, and works on the Elixir language itself, has been a fabulous thing.

Steven Nunez: I think Sophie DeBenedetto called out the documentation, which is really incredible and good. What I love about this book is that it is building an application in action. And I'm kind of, like, hearkening to another book series, but seeing it in motion, essentially, right? Let's build a thing, let's ideate, let's design, and kind of, like, go through it. It does add a good amount on top of the documentation, which is already really incredible. 

Code Generation in LiveView

Steven Nunez: One thing that I want to talk about is, in your book, there's a lot of generated code. So, one thing that I like about Phoenix, and the way that it sort of started to shape up its generation strategy is, it...there's a lot of taking advantage of Elixir macros, which happens, but when you are, you're running a generator, it's essentially dumping a bunch of code in your project. This is interesting because it allows you to change and manipulate things, get into it, and see how things work. This book dedicates part one to code generation. Can you guys talk a little bit about the benefits of using generated code as a way of showing how things work, looking at conventions, and sort of what the thinking was behind that?

Bruce Tate: It's funny. You could see both Sophie and me break into shakes and cold sweats, because the code generation that makes things so elegant and beautiful for the user, it's a difficult thing to manage when a framework is underway and under development. We thought it was worth this cost, just to serve, to better serve the Phoenix community, and I think I'd make that decision again. But the idea that we can learn from experts, like Chris McCord and the rest of the LiveView team, by reading that, kind of, really excellent, proven opinions, was a fantastic thing to me. And I'll turn it over to Sophie.

Sophie DeBenedetto: I mean, I feel like you certainly probably have more to say on the generators. Maybe we can drag it out of you. But, yes, there was a lot of churn in writing the book on the generator portion of things, and that's kind of where most of our efforts kind of focused as we've had to put out newer and newer releases. So, I just wanna thank our readers for their patience. I feel like what often happens is that we'll release a new version of the book, and then a day later, like, a flood of comments will come in, saying, you know, this, that, and the other thing is out of date because that's how quickly the LiveView has been moving. So, just know that we're working on it, and eventually, this book will be sealed and printed, but we do appreciate the patience of our readers and all the feedback, certainly, that you guys have been putting in.

I mean, generators, I think, are part of the compelling story of not just LiveView, but Phoenix in general. They are opinionated, I think, but not too opinionated. They generate what you need for your web app to kind of take away the boilerplate and the toil, which is one of the sort of biggest themes you'll see running through both Phoenix and LiveView. You see it often in LiveView when we say, or when I say a lot that the framework handles the hard parts. You don't have to write the tedious details of, let's say, client-server communication over a web socket. Another way that the framework handles the hard parts with Phoenix and LiveView is with these generators. You could generate an entire functioning LiveView application with just one line of a command that you're gonna execute, to tell that generator what to do, and that's not a novel feature for a web framework. I think Rails also has a long history of generators, but you do get a fully functional, highly interactive single-page web application, backed with all of the power of OTP, all the concurrency and the fault tolerance, and all of that real-time capability that is embedded in a Phoenix app, with a pub-sub server, provides to you. And you can do that with, as I said, just one line, and then hit enter, and then you've generated it. So, what we try to do in the book is use the generators, because you'll use them as a developer. After all, they are that good. Then we try to walk you through what was generated so that you do get an understanding of how the app is architected because the generators put out code that is architected correctly.

Bruce Tate: I think that one of the things that tends to happen with a generation-type setup is that there are some strong opinions and that these opinions might vary based on the mechanism that you choose to expose your interface, right? Like, so, a lot of Phoenix is exposed in, effectively, the functions of the framework themselves. And then there are also places where we want to kind of add convenience for the users, and so we expose these ideas with things like macros, whether they're in the "use Phoenix," Phoenix.LiveView, or "use Phoenix.Component." And, we also see opinions expressed in the generators themselves. So, it's a cool thing to see the balance between macro code, which generates compiled code, at compile time, and code generation code, which generates code one time, when you process the generator, and then hand the keys of this new Ferrari to the customer. And the decisions between putting something in a macro or a library or a framework in the generator, it's a really difficult one to make and get right over time, and I think that the LiveView, and overall, the Phoenix team, has done an excellent job of keeping this balance. And what that allows is for a framework that has the right level of backward compatibility, and can provide some insulation between the customer and the framework developers, in slowing down how quickly you have to act on things like deprecation. And it's a wonderful thing to watch.

Recommended talk: The Soul of Erlang and Elixir • Sasa Juric • GOTO 2019

LiveView’s Evolution: Milestones

Steven Nunez: I feel like I should give you guys a trigger warning. Next, we're gonna talk about some of the changes that have happened in the framework over time. So, Sophie, I know the first version, the first production application that you put out with LiveView was on, I think, 0.10. So, you are a super-duper early adopter, which is great. While working on this book, my interest in the project exploded, right? More people started paying attention, because there's something special here, as far as, like, what you can get, how you can become more productive as a developer, how you can put more things out into the world. Exciting. So, what are some of the changes that have happened while you guys are working on this project?

Bruce Tate: I think that one of the things that was the most exciting, and also generated the most heartburn for Sophie and me, was the idea of what a component is. That started with this API for stateful components and stateless components, and everything in that whole component system changed from the early versions of our book to the later ones. And they started changing through a third-party framework, called Surface, which was just some beautiful code that gives us a lot of the capabilities that are in the components right now. But if you think about it, there was an input control, and to the Phoenix, for the overall Phoenix surface area, that's one function. But in our application, we might have several hundreds of input controls, and then you kind of spread that out across the forks and branches that we have to keep in the project, all the way, as we take the user from one chapter through the last. It turned into kind of a pretty big endeavor to keep the book up-to-date. But what I wanna say about the users, what they're seeing in LiveView is just light years beyond what they were before. This kind of beautiful interface, that's more of an HTML style, makes templates that are easy to read. And this strategy of allowing some type checking and some HTML structure that's actually on the page is going to make much more reliable applications as we move forward. So, that's been one of the things that I've kind of had a love-hate relationship with them, but they're by far better now than when we started the book.

Sophie DeBenedetto:  If anything, I think my experience has been, every time that I identify something that I wish LiveView could do, it then will do, within, like, a matter of days or weeks. Certainly, from the perspective of trying to keep this book up-to-date, that can be a little bit stressful, but from the perspective of a web developer who wants to use this framework, it's been pretty thrilling. So, for example, we talked a little bit about streams earlier, streams in LiveView, and how it lets you manage large data sets efficiently. That solved one of the biggest blockers, I would say, to LiveView adoption that I would encounter. Uploads, I remember, Steven Nunez, you were playing around with some complicated kind of bespoke. How do I get file uploads in my LiveView app, which you could do? It was certainly possible...

Steven Nunez: Where's my trigger warning? Okay?

Sophie DeBenedetto: ...for you to write that code. I know, right?

Steven Nunez: I sunk a weekend in that.

Sophie DeBenedetto: A couple of days later, and this was an experience I've had as well, you know, the new version is released, live uploads are supported, and it's super easy to do. I had that experience with, I don't even remember. I gave a whole talk at Elixir Conf one year and I don't even remember what aspect of LiveView was about. All I remember is that, like, by the time the last words left my mouth, like, there was a new version of LiveView that meant this whole fancy, crazy workaround that this whole talk was about was, like, unnecessary.

Steven Nunez: I think you had a caveat at the beginning, that was, like, hey, just, like, pretend this talk came out 72 hours ago.

Sophie DeBenedetto: Exactly. And it was still fun. It was still a fun thing.

Steven Nunez: It was great. It was great.

Sophie DeBenedetto: And then another example with streams, I think, Bruce, you, and I talked a little bit about this briefly. I don't remember exactly the details, but there was a certain feature, and you had suggested, oh, we'll wanna use streams here as well. Maybe something to do with updating a group of products in our, sort of, product catalog at a time. And I said something like, oh, we won't wanna use streams for that yet, because they don't have a bulk update option, so it's kind of not the right fit for that kind of interaction. Now, of course, you can bulk update items in your LiveView stream, so, actually, that's, like, a reminder to myself that we can update the book in that section as well. And so, I think the reason for that is the incredibly strong dialogue between the LiveView team, Chris McCord, and the Elixir community. There are strong connections there. There are strong relationships there. The people building LiveView use LiveView. The people building LiveView talk to and listen to the Elixir community, talk to and listen to their users, and they know what the pain points are. They know what the blockers are, and they're working, like, frankly, tirelessly to address all of them, and to make LiveView, I've said this before, I'll say it again, not just a compelling web framework for folks that are in the Elixir community, who are already using Phoenix. I think it's the most compelling web framework that exists today.

Steve Nunez: It's really exciting. It does so many things right. I'll shout out one of my favorite features that came out in this sort of, like, period. Verified routes. Like, just the big, the focus on developer ergonomics, where you don't have to say something.path, and then pass in conn and a bunch of other arguments. You just say the route, and the compiler will check it for you. It's really beautiful, and again, really thoughtful, and just a sign of sort of what the development team behind this, their focus is. It's on making it easier and better to work in this framework and this ecosystem.

Bruce Tate: Funny story. I was working with a professional class in "Programming LiveView," which is one of the Groxio classes that we do. And one of the users took a look at some code, and I said, can you change that ID to a product? And they said, "No. You can't. This is a verified route now." And I said, "Well, try it." And he dropped it in there, and this is, like, a seven-year expert Elixir developer, and he said, "How did they do that?" And then we kind of dove into the protocol, and looked at how that happened, to trace it from the sigil forward, is a cool use of technology, and a dramatic simplification that makes everybody's life better, every day, in LiveView.

Writing a Game With LiveView

Steven Nunez: I couldn't agree more. Like, working with this is just, it's delightful. It feels really good. Everything from putting the markup on the page, to testing the story, is just great. I wanna talk a little bit about the app that you built in the book. So, you did not write a chat application, so thank you for that, for not writing another chat application with Phoenix and LiveView, and all the things. I've got all the chat applications I can use, or I could need. You guys went with a game, which I found interesting. Can you talk a little bit about why you went with a game to kind of show off LiveView and some of the additional features that being on the BEAM and using OTP offers?

Bruce Tate: A couple of points here. There's the game and the dashboard, and Sophie pushed hard on making a live interactive dashboard, with professional features. And that was wonderful and beautifully executed. I also, pushed hard on the game aspect, because I think that one of the things that you need to be able to see in LiveView is Elixir is reduce. And how easy is it to see it when you press the right key, and then the box moves one square to the right? It's just, it becomes easy to see, and transformative, when people can see the way that components are layered to that, the way the attributes kind of get checked and passed on down, and the way that we could kind of group and manage complex ideas through one giant reduce cycle.

Steven Nunez: I love that the application sort of lets you dive into some of the, I guess, more, not advanced features, but lets you dive deep on things like pub-sub, and presence, rendering graphics. It's a good problem domain, and it's not just a matter of implementing game logic and rendering it. You get to use an application like you actually would build one in production. So, I think it's cool.

Bruce Tate: LiveView works on rendered text. And that rendered text isn't limited to just HTML. It handles SVG, beautifully, and we're starting to see more of that now, but I believe that the book has a particularly good treatment of that.

Recommended talk: Idioms for Building Fault-tolerant Applications with Elixir • José Valim • YOW! 2021

What Would People Get From the Book in 3 Years?

Steven Nunez: Great. Well, I have one last question for you guys, and you can keep it short if you'd like. You spent all this time investing in writing and rewriting this book over at least a year, again, on a boat, three months, Sophie? Three years.

Sophie DeBenedetto: Easily, yeah. Three years.

Steven Nunez: Three years. What do you want folks to get out of this book, spending the time with this book? Again, it's a beast. At the current beta, it's about 400 pages. I'll start with Sophie DeBenedetto. What do you want folks to get out of this book?

Sophie DeBenedetto: That's a really good question. Is it weird to say that I haven't thought about it, like, that before? I've more just been thinking about what I offer to people, not so much what I want them to get out of it. But I think that what I want them to get out of it is an understanding of what OTP and what a functional paradigm brings to web development, and the way that it empowers you as a developer, and empowers your team, to be productive, to build apps that elegantly meet the needs of, I'll say, modern web users that require and expect a lot of interaction and, kind of, real-time functionality today. We're offering you all the things in this book. We're offering you how to build a LiveView application. We're offering you a look under the hood, a lot of the time, about how it works so that you can understand what's going on. But what I want you to get out of it is this deeper understanding of what functional development and what OTP gives you as a web developer.

Steven Nunez: How about you, Bruce?

Bruce Tate: I would say two things. I would say that the first thing is that beautiful applications first have to depend on beautiful technology with beautiful abstractions. But second, they depend more on beautiful design than any punch list of features. I think that that's super important. The second thing is that I believe that every good course, every good book, and every good conference talk that I've ever done has talked about design and abstractions because those are the hard things to read from the pages of internet documentation. I think that when I can communicate those things well, I'm happy with the product. And this book certainly qualifies in that area.

Steven Nunez: Awesome. This book will help you fall in love with LiveView. If this was interesting at all, pick up the book, for sure. Give it a read. It covers the base technology and shows you what amazing things you can do with it, so please pick this book up. If people wanna hear more about you guys, where can they find you on the internet? Bruce?

Bruce Tate: I'm on LinkedIn. But I'm also on Twitter, I guess, the application previously known as Twitter. I'm @redrapids there.

Steven Nunez: Awesome. How about you, Sophie?

Sophie DeBenedetto: I think Twitter's probably the best way. My Twitter handle is @sm_debenedetto, my last name. And another shout-out, if you're interested in writing something for PragProg about Elixir, I wanna hear about it.

Steven Nunez: Awesome. Well, thanks everyone for tuning in. We've got a lot of this. Pick up this book. It's great. Thanks, Bruce, and thanks Sophie, for spending some time chatting with us about all things LiveView.

Bruce Tate: Thank you, Steven.

Sophie DeBenedetto: Thank you.

Steven Nunez: My pleasure. Any time I get to hang out with my friends, it's a good day, you know?

Sophie DeBenedetto: Yes.