Another approach to this is just building a static site (Gatsby or w.e)…if the content is not something that needs to be immediately published - you could do something quite simple via an API that writes a JSON file to a storage bucket - and on a regular basis like every evening it kicks off a build, deploying and SEOing the newly added content… of course this also has scaling issues if you are building 100k + pages(unless done incrementally) - but if you want really good SEO - you cant beat serving static content. This is also not a bad idea until you DO reach scaling issues, and then you re-engineer when you actually have users actively publishing content all the time…
harmon25
dorgan
In my particular case, the content is user generated, akin to reddit, so it is immediatly published.
For other cases, your solution may work, but it adds another moving part to the stack.
The reason you can have, say, gatsby, next.js, nuxt, sapper, etc, and don’t suffer from the disconnect between what the backend knows about the markup and what the frontend knows about what to enhance, is because both the browser and node can evaluate the same code(more or less, but you get the idea). With this stack it doesn’t matter if you build an SPA or not, because the client always receives all it needs to show content to the user or crawlers.
But this isn’t the case with Phoenix, so despite having an excellent templating engine, if you want to avoid the disconnect you need to spin up a node server and let it handle the frontend. You can mix them of course, but at some point you think “this would be SO MUCH EASIER(and maybe cheaper) if I could just do everthing in js”, so that’s why I think we see MPA or SPA, and not much in between(maybe github is one of those rare specimen that take the in-between route).
For some stuff, it doesn’t really matter who knows what. A dropdown or an image cropper, for instance, can be built with whatever frontend tool you want.
When you have content that needs a roundtrip to the server to perform some action and reflect the results in the client, however, it does matter and drives the way you design everything. It can be a page navigation to not lose state on some layout pieces(like a chat miniwindow), it can be a change on how certain pieces of content are displayed.
So coming back to the topic of Phoenix LiveView vs SPA, I believe this is where I think LiveView shines, because it allows you add behavior to the markup not without the need to write js, but without the need to spin an additional server to handle the frontend and without having your presentation pieces split between clientside libraries and backend templates. And I believe it’s for this very reason LiveView is coupled to the DOM and it’s not just a data diffing/syncing library. Most people don’t have the scale of github or twitter, and Phoenix channels have already proved to scale very well, so I believe LiveView can take you quite far. If you do reach a really big scale, I would say you’re making enough money to hire a bigger team and maintain more complex stacks.
I hope this makes my stance more clear. I’m not in the SPA or anti SPA team, because I understand both approaches have their places and I’ve already tried both extremes(FWIW, most of the user facing content of my project is phoenix templates intertwined with js enhancements, and the backoffice is mostly handled by js alone). But when you want to sit in the middle ground and keep your stack small, there’s a lot of dragons to tame. You can’t have the cake and eat it too, I guess. It’s a very very wide topic and there’s a lot of factors to have in mind.
I’m not using LiveView because I have some concerns about memory usage with potentially infinite data sets in the client(infinite scrolls), but it does solve real problems for a wide variety of use cases.
1
lud
dorgan
https://sveltematerialui.com/ for instance. Also Svelte-prosemirror, Sapper, you can check https://madewithsvelte.com/ and find a whole lot of bindings for other libraries. Before Svelte 2 it wasn’t popular enough and it was lacking on community-made bindings and libraries in general.
2
harmon25
Yea would not do this unless it was the only type of content. I am pretty impressed with the JAM stack ideas though. They are doing a good job of replacing the usage of systems like WordPress/Drupal - which imo are a stain on the web and we would be better off without. They did serve a purpose, but are now a liability. There is a huge amount of web development done in that space, the public site that is not an app but maybe needs some sort of CMS functionality - and is better off not being dynamic in that it just adds a larger attack surface - and running costs. The future of most static/marketing sites with any cms requirements are better served with something like netlifycms
You are right about this - at least our current state of Phoenix + JS integration is not helping to tame the dragons…The difficult position the phoenix team was in when deciding what to do in regards to static asset management and the stumbling with brunch as the initial bundler is I believe what led us down this path, and did not leave a positive impression of the JS community with the phoenix team…
The migration to webpack has been good - but I think something to bridge the divide more cleanly like what the guys behind asset_import have done would be a step in the right direction…
I think we have somewhat concluded this discussion and it is clear there is room for LiveView and SPAs and even fully static sites. Factors such as the team building it, the users/target market, the requirements of the UI; its the age old answer of ‘it depends’…
1
AstonJ
React does indeed look like the best atm, at least from the various sites I’ve seen using it. Some do feel a little too similar (bit like when Bootstrap took off) so it’s good to see more UI kits coming out. I will definitely check it out at some point but I want to see how I get on with Svelte first. I like that it’s the newest of the bunch and that we may be able to help shape the direction it may go in by providing feedback etc.
I’m enjoying seeing the Svelte portal grow on Devtalk too, could be worth keeping an eye on for anyone interested in Svelte 
0
50kudos
Just read ALL comments on this thread, I was “yes” “yes” multiple times. It’s quite many good points if I have to quote. I had done a project using phoenix channel with SPA 3 years ago. Currently I am on a project that produces worst case of leex diff, client patch (via live_patch) tooks 7 seconds! And then I switched view layer to Elm and just push pure data (push_event/3) down, and it now takes ~ 1 second! (Bonus: 7MB memory for components diff tracking is now 0.9MB)
Compared to low level phoenix channel + SPA, liveview + SPA is a lot easier. (Server + Client) side routing for free!, push_event/this.handleEvent for free..
So I agree with many points in this thread, liveview without presentation/view layer is still super solid (again, push_event, this.handleEvent, routing (live_patch, handle_param etc). I kinda think all those phx- stuff should be js API. Keep those form stuff since it goes to server anyway. Finally yeah, there’s still room for liveview + SPA indeed, basically liveview + virualdom lib + vanillajs lib + custom element should work well together. Not re-inventing lots of thing on their own virtual[king]dom; the web platform today has many borders (no micro frontend thanks!)
3
marciol
This is one of the more clarifying threads about this subject I have seen, and in general, you summarized very well the possibilities that are open to getting full advantage of Phoenix LiveView when doing SPAs.
1
adamu
Sorry for the thread resurrect from a perpetual LV-newbie, but I’ve been thinking about this topic. Specifically in relation to this observation from the HTMX thread:
Managing the UI state on the server seems fine if there is a single server, but what do you do if you want to scale an app to have multiple server nodes? The client could disconnect and reconnect to a different server. Would its UI get reset (unless perhaps Erlang distribution is used to synchronise between server nodes)? Or would you simply have to force the client to do a full reload in this case?
If you are managing the state on the client with stateless connections, it shouldn’t matter which node the background API requests hit, as it will all be managed on the client.
1
LostKobrakai
Yes the UI would by default reset. But that only matters for stuff that the server doesn’t know about. All the information that lives on the server should render the absolute same no matter which app server you hit. That’s most of the value you get from LV – not needing to jump through hoops to bring stuff you need the server for anyways onto the client in a way it can be updated and react to user input.
Then there’s forms, which by definition pose temp. client side state. LV has means to submit current form values on reconnect, so the server can respond in a way that take those form values into account.
Another given form of client side state is the URL. So things like tabs or modals could change the url, so on reconnect the server will know based on the URL what to do. Another common example of that is search forms or pagination.
You might also have additional client side state that a developer brings into the picture. For those you can use connect_params, which the LV js client can receive and – just like the form recovery – send up on reconnect for the server to account for.
Lastly you might have state, which both the client and the server want to have a say in and that’s where things get more complicated given the nature of dealing with distributed state.
So far for the theory. In practise you still sometimes needs to get your hands a bit dirty to separate purely client side state from purely server side state due to how morphdom works. It wholesale replaces dom nodes without ids and also removes all client side changes unless they’re made in a way for LV to recognise them. If LV would use different means of updating the DOM client side that complexity could be improved upon, but I doubt that’ll happen.
4