https://medium.com/@jmanrubia/escaping-the-spa-rabbit-hole-with-turbolinks-903f942bf52c
The author of this post has some views about the hardships of gonig the SPA route. I had to agree with maximum of his points.
I found myself agreeing to the entire article too.
When SPAs first started becoming popular I was genuinely interested in seeing where things were going because the promise for web apps that behaved like desktop apps was (and still is) an exciting idea. In reality they have completely failed to live up to the hype and in my opinion are a massive step back for the web.
I’m honestly struggling to think of one good example of a site that I frequently visit that is better for being a SPA. Twitter constantly loses my previous place if I click a tweet to read the comments. Reddit fails to even load any content a lot of the time and has a similar issue of losing comments loaded and history. Google (mobile web search) is the most offensive to me because - and what a surprise - going back to the search results after clicking one of them… loses my history and I have to go through the pages manually to find my place again.
5 Likes
I find myself in an odd position regarding SPAs. Personally, I don’t like them. I’ve previously built a substantial one, and the experience wasn’t great, the outcome even worse.
But, the way people are now talking about them, you’d think that Satan and Hitler got together to cook up the concept. As with most discussions on the web, they err towards extreme points of view and as the pendulum of popular opinion swings the other way, so in order to remain fair and logical, I unfortunately find myself defending SPAs despite my opinions.
In the end they have their place. Almost any criticism levelled against them can resolved with additional work, and if an SPA is truly required then that additional work can be justified as necessary. It comes down to choosing the right tool for the job.
Personally, I still find much of the conversation around JAMstack quite seductive, mainly because my big gripe with SPAs is removed (pre-rendered markup instead of client side rendering) whilst maintain many of the benefits of an SPA, however I’ve yet to work on a project where the additional complexity is worth it over a simple server-rendered app and our traffic is usually modest and not very ‘bursty’. Maybe one day I’ll have a crack at building one, just to see what all the fuss is about.
3 Likes
This is the root issue. 90% of the time an SPA is not required or even beneficial. In many cases they bring more problems than they solve. The exceptions are actual web tools that a person may keep open for hours at a time. Everything else is an open/check/close experience where they are totally out of place.
Nothing to do with Satan and Hitler, that we know of.
8 Likes
I was more referring to how some people are so opposed to them, even when they might be the best choice.
3 Likes
My skepticism in a nutshell! Everything they mentioned is pretty why I’ve never found cause to actually build with it.
1 Like
The only time an SPA made sense to me was when it made things easier or dropped the need for JS completely (like the Volt framework - which offered isomorphic Ruby).
The only decent SPA I know is the one that runs on this forum - Discourse 
(although I’d love it if it wasn’t an SPA, while retaining the same functionality and slickness).
2 Likes
In a fat-finger error I deleted an earlier response 
, but I’d brought up Notion.so as an example of an increasingly popular site that benefits from (or even requires?) an SPA. Doesn’t it just beg for React et al. plus GraphQL? Could a site/app like this be made without being an SPA?
Notion indeed is written in React. It my guess is that it has a Node backend with Apollo and makes heavy use of subscriptions. I think I read that they use Postgres.
Anyway @brightball seems to already have made the point when he suggests that SPA’s are usually unneeded but that…
The exceptions are actual web tools that a person may keep open for hours at a time. Everything else is an open/check/close experience where they are totally out of place.
Notion for one falls squarely in the web tools category.
1 Like
I wish it progressively enhanced. Every tab I bring up on Discourse takes a good 3-10 seconds to load. It’s a very bad example of a SPA because it takes soooo looong to load, which is every-single-thread! ‘Infinite scrolling’ in a thread is handled well though. 
2 Likes
I feel like the SPA features are less important to most apps than the Component-based development that these frameworks use. The only gripe I have with current Phoenix HTML capabilities is that while you can do layouts and nested layouts (good enough for most scenarios) it’s not the same level of abstraction to using components as in React/Vue/etc. Looks like Liveview is targeting those concerns, so I’ll be patient.
1 Like
SPA’s are a customer oriented solution. The user experience (if done right) is better. Not always better for the developers but clients/customers don’t care. Mobile applications have changed the expectations of consumers. They expect reactivity. SPA or SPA like functionality on the web is the closest thing we have to meeting that expectation. Bring in a react/vue dev and they will the the opposite opinion. “Escaping rails’s template engine rabbit hole using modern react”. There’s always a case to made and it usually depends on the project. I personally feel what elixir/phoenix brings to the table combined with a SPA functionality makes for both great customer facing and developer experience. Regardless of the framework, they are all trying to achieve the same type of user experience. There are plenty of options to choose from.
4 Likes
I personally like SPA apps, yes it has it’s problems but as always there are tools to make things easier (For example Next.js for React applications)
I’d prety much like the fact that your server and client are different projects, I think working that way make things clear in the development process and you can focus on fixing bugs specifically for a given client or server side
Just need to choose the right tools on development, and I also think the UX is much better on SPA apps, but that’s just my opinion
2 Likes
I too like the separation.
1 Like
Liveview is only one part of the component story: Handling state changes. Imho way more important for components in EEx is this change coming in elixir 1.9: https://github.com/elixir-lang/elixir/issues/8590
3 Likes
Almost 3 years ago it has been observed that the modern SPA ecosystem has slowly developed into a leviathan that embraces complexity much in the same way J2EE did (ultimately J2EE was disrupted by Spring which was then free to become a monstrosity of its own).
I think it would be more accurate to state that the UX seems more “native-like” with the implicit assumption that native is better. Depending on what you are trying to accomplish that assumption may not be valid:
HTTP 203: Web Vs Native (2015)
Mobile applications have changed the expectations of consumers. They expect reactivity.
Global mobile (e.g. KaiOS/JIOPhone) is what can break the viability of SPAs (unless you can afford to optimize every tiny aspect like Google and FaceBook) - if the page doesn’t load quickly enough, reactivity never comes into play.
In 2017 Netflix sped up its landing page by removing React (components notwithstanding; their SPA still remained React based).
Some people would like a lean web development movement. But that is still developer centric.
If your only tool is a hammer, every problem looks like a nail. (Law of the instrument).
I suspect many members of either camp are guilty of this - but I think the SPA camp may have gone overboard by trying to abstract away the Web by piling on complexity.
SPAs pushed progressive enhancement aside but the accrued complexity may invite disruption by an approach that is more capable of taking advantage of the strengths of the Web while at the same time being more aware of the constraints of global mobile technology.
3 Likes
The problem is the “if done right” part. If Google, Twitter and even Facebook can’t get it right with all of their talent then how are we supposed to?
I love the idea in theory. I’ve built a few SPAs myself with React and Vue but I don’t want to deal with all of the issues anymore. I actually really like Vue but using it in a SPA meant recreating everything the browser already provides (location, history, caching, e.t.c.) and everything the server app provides (routing, translation, validation, e.t.c.).
In my opinion the best use of React I’ve ever seen was the Facebook website feed. It used to be a server rendered page with each item being a React component. This give a reliable web page with interactive and dynamic components. I don’t really use it any more so I don’t know if it’s still like that but that was peak React. The mobile web version in comparison was terrible because that was a SPA and it would constantly hang and be stuck with stale data.
What I’m complaining about sounds like it can be fixed with competent developers but I’m going to argue that it can’t. The sheer complexity of a simple SPA that matches the the most basic server rendered site/app is terrifying. If none of the big companies can do it flawlessly there is a fundamental problem with the concept.
The evil side of me is hoping that these frameworks/companies keep on piling on more and more complexity to try and fix the technical problems the have dug themselves into. They’ll no longer be able to get anything done and have full teams fighting with the most basic pages. I’m just going to sit back and relax with server-rendered HTML with JS as needed.
3 Likes
This is where I completely disagree.
I think that SPAs are for developers. I have not met many customers who cares about if an app is SPA. SPAs are trying to solve a problem which no longer exists. Pure server side rendered pages are today so fast and predictable that the user experience is much better for the large majority of users out there.
SPAs are flaky, each implements their own behaviour and there is no standard on how to do things. They often have to re-invent things that has worked predictably in a browser for a long time. Things like back button, routing and what are links and what happens when you click on them, or right click on them. They don’t care about accessibility.
In my opinion they are the complete opposite of customer oriented. They are for developer pleasure and not much else 
12 Likes
I see your point. Agree to disagree. Today the popular frameworks are developer friendly. I believe that has to do with the insane amount of effort over last few years. You know how everyone complains about how it moves too fast. I don’t think server side rendered app are bad. I’ve always been a fan of sprinkle some js where needed. But I don’t think frameworks and libraries such as react or vue are bad either.
SPAs are flaky, each implements their own behaviour and there is no standard on how to do things. They often have to re-invent things that has worked predictably in a browser for a long time. Things like back button, routing and what are links and what happens when you click on them, or right click on them. They don’t care about accessibility.
I’m not sure I agree here. I mean does the back button not work on this forum? Is the routing “different” than it would be server side rendered? I’d argue very few people care about accessibility.
1 Like
Although we disagree I think we are pretty close, just on separate sides
Ok, back button seems to work. Forward button did not though 
Lost scroll position. And it is the consistency I am after. With SPAs there is always something that is broken (for my definition of broken )
There are lots of pretty good SPAs out there. I think though that they require much more effort to produce the same result than if they had picked a traditional technology.
4 Likes
