Baldur has written a wonderfully paced, deeply interesting post on the whole SPA/MPA (AKA normal website) debate with one critical conclusion: SPAs are fine; MPAs are fine; anything will suck if mismanaged.
It's a surprisingly simple premise, yet they do a very good job of explaining the underlying assumptions and overarching viewpoint. I'm not sure that I'm fully convinced, but I certainly sympathise with a number of the key points, and agree that in a better-managed industry a lot of the current headaches and pain points would be easier to address or remove outright.
The article also contains a wonderful section of real-world examples of idiotic business objectives that is just a joy (albeit a painful joy) to read through. My favourite is:
We need these five features for feature parity with a competitor, but the CEO wants the interface to look ‘clean.’ Can’t we hide the buttons and widgets using hovers? Oh, and make the hovers work on mobile somehow.
On the reality of SPAs:
SPAs are both amazing and horrible. Sometimes in the same project. The web is large; it contains multitudes.
When you look at performance, cross-platform and mobile support, reliability, and accessibility, nearly every Single-Page-App you can find in the wild is a failure on multiple fronts. Replacing those with even a mediocre Multi-Page-App is generally going to be a substantial win.
On the problematic tradeoff that a lot of front-end frameworks (particularly those used to make SPAs) fall into, that making their tooling infinitely scaleable also makes it impossibly hard to maintain and increasingly complex (therefore resulting in a never-ending burden on the teams using it):
Which, when they present it as ‘scale’, sounds like a good thing. But it’s absolutely a bad thing when you’re in an industry that’s as mismanaged as ours. We can’t handle complexity. Having no upper limit to it is extremely bad.
On how Basecamp use cooldown periods between sprints (or "cycles") to enable much higher levels of overall productivity and creativity (Baldur covers a good amount of evidence that a lack of breaks during business cycles directly causes project failures, and it honestly makes a huge amount of sense):
Therefore, after each six-week cycle, we schedule two weeks for cool-down. This is a period with no scheduled work where we can breathe, meet as needed, and consider what to do next.
During cool-down, programmers and designers on project teams are free to work on whatever they want. After working hard to ship their six-week projects, they enjoy having time that’s under their control. They use it to fix bugs, explore new ideas, or try out new technical possibilities.
On how poor management and an over-emphasis on higher-order control results in poorly performing teams and catastrophic websites:
It helps to just understand that the reason why Single-Page-Apps or Hybrid Apps suck isn’t that they suck as a concept. Technology implemented by a dysfunctional organisation is almost always going to suck.
The biggest hindrance to the web’s progress isn’t non-expert developers, tooling, libraries, Single-Page-Apps, or Multi-Page-Apps. It’s bad management.
On how the reduced scope of MPAs should be seen as a benefit, not a disadvantage:
As developers, we need to operate under the assumption that good management is the exception, not the norm. Multi-Page-Apps and hybrid frameworks let under-resourced, mismanaged developer teams deliver reliable and safe code. That should not be dismissed lightly.
