Phoenix LiveView vs SPA

There are a few being worked on (mostly in proof of concept / toy stages). I think Surface is one that is somewhat influenced by Vue. The bundling aspect is very important though. Without that, it’s a step back in time. Modern UIs are loading assets only as needed, sometimes even using Google Analytics and some simple data science to predict the user’s next page and loading those resources.

One thing that I personally feel is a mistake (one that React makes) is the whole “CSS in JS” concept. The respective languages should be as “pure” as possible. The LAST thing I want to do, is write some kind of Elixir / CSS / JS / HTML Frankenstein syntax.

No, definitely not. In-fact, the communication / protocol layer would actually need to be built up a bit to essentially expose an API (not just hooks). As I mentioned, you could even add a model layer (eg. using JS’s new proxy logic for reactivity) and / or a caching layer (eg. Apollo). But as I mentioned, it’d be important to be completely unopinionated / decoupled from the presentation layer. The current presentation layer could (should) be broken out as the “default” (but easily replaceable).

Per above, if these two things were done, I think the community would solve a lot (if not all) of the other issues. Currently, LiveView feels mutually exclusive. With some key tweaks, LiveView can be “incrementally adoptable” in ways that cater to the needs of the project and team’s comfort level with various technologies.

For me personally, I often work in Vue (Nuxt) for the UI. With a LiveVue™ adapter, we could make the UI even more “dumb”, but leverage routing, hydration, and complex UI components (eg. the dropdown example from above).

3 Likes