Differently from the traditional Multi-Page-Application, where the entire page needs to be reloaded whenever the user interacts with it, a Single Page Application does not require page reloading during use, it requests the markup and data independently and renders pages straight in the browser leading to better performance and a pleasant user experience.
Phoenix LiveView is a framework for building single-page flows on the web. It’s an Elixir library that you will include as a dependency in your Phoenix app, allowing you to build interactive, real-time LiveView flows as part of that Phoenix application. Now that you know a little bit about LiveView and SPAs we can finally start talking about how they differ.
The mechanisms might vary, but most current approaches to building SPAs force us to think in terms of interactions that initiate tiny requests and responses that independently change a page in some way. The hardest part of the whole process is splitting our development across the client and server. That split has some very serious consequences:
• By splitting our application development across the client and server boundary, we enable a whole class of potential security breaches, as a mistake in any single interaction leaves our whole page vulnerable.
• By splitting our teams across the client and server, we surrender to a slower and more complex development cycle.
• By splitting our design across the client and server, we commit to slower and more complex bug remediation cycles. By introducing a custom boundary between our browser and server, we dramatically complicate testing.
On the other hand, LiveView lets programmers rely on its infrastructure to handle all the state on the server-side, rather than forcing them to write their own custom code between the browser and server. As a result, it's no surprise that with LiveView you can create stunningly interactive and fast apps. (If you are curious to know more about how LiveView handles state, you should check my "State in LiveView" post, just click here!
Compared to the traditional SPA, these flows will have some characteristics that seem almost magical to many developers:
• The apps we build will be stunningly interactive.
• The apps we write will be shockingly resistant to failure.
• The programming model is simple but composes well to handle complexity.
• The programming model keeps our brain in one place, firmly on the server.
All of this means that SPAs built with LiveView will be able to easily meet the interactive demands of their users. Such SPAs will be pleasurable to write and easy to maintain, spurring development teams to new heights of productivity. Unlike many existing SPA frameworks, LiveView shields you from the details of distributed systems by providing some common infrastructure between the browser and the server. Your code, and your mind, will live in one place, on the server-side, and the infrastructure will manage the details. To conclude, LiveView meets all of the interactivity and real-time needs of your average single-page app, while being easy to build and maintain leading to a big change in the way we develop and think about our web apps.