The Disadvantages of Single Page Applications (2014)
adamsilver.io
The Disadvantages of Single Page Applications (2014)
1–10 of 105 posts
Re: The Disadvantages of Single Page Applications (2014)
#2Finally some love for the anti-SPA crowd. Subjective here, but there's something nice about Post Redirect Get and Plain Ol' Hyperlinks from a User Experience. Whenever I interact with a regular web application, I am relieved. Not every "forms over data" or ecommerce experience has to be Gmail. Even in mobile.. SPA just isn't that much nicer. Also, I think maintaining these SPAs is ridiculously more difficult.
I don't think the SPA juice is worth the squeeze.
Re: The Disadvantages of Single Page Applications (2014)
#3Other points of note:
The whole history API exists to help the SPA experience (but others too).
The site still needs to be able to render something like:
www.foo.com/customers/10 even if www.foo.com is a SPA and via clicks can go to /customers/10. This may require more server work, so you're not exactly making life much easier for yourself.
You still need to handle cases where a web crawler comes in without good javascript and has to index your site.
Re: The Disadvantages of Single Page Applications (2014)
#4I think this article is overly negative, some of the cases are not _always_ a disadvantage.
Take "fast back" as an example. If your app is interactive and updates live, the "back" page can already be up and running with the latest data, instead of first loading a cached version and then having it update with JS later.
Also, personally I'm not so sure users care about things like the "stop" button working. And "fast back" depends on the situation.
Having said that: if these kinds of articles reduce the risk of things like blogger.com being a SPA, keep writing :)
Re: The Disadvantages of Single Page Applications (2014)
#5This seems to be aimed at Single Page Websites and not Applications.
The aim isn't to "mimic the browser using Javascript" but to create an immersive application that feels like you're no longer in a browser at all.
Re: The Disadvantages of Single Page Applications (2014)
#6In general, it depends: there are many different use cases where SPA is fine and others where they are not. It's especially good for long-running consoles that don't need much navigation (given using the appropriate JS framework which doesn't leak resources on most browsers). SPA doesn't make much sense (apart from in-web app search live results searching) for static pages that need to be SEO crawlable and can be served up fast from static CDNs. Perhaps the core engineering tradeoff is whether to breaking the stateless RESTful contract by managing state with session cookies and/or JavaScript, and doing so in a way that may or may not be sharable to other users, history-friendly, SEO-friendly, etc.
Ruby's turbolinks is a clever hack and mostly works approach to make nav-based (browser history- and crawler SEO-compatible) almost as responsive as SPA... it replaces assets, title, meta and body on-the-fly and updates the url location with javascript to save a whole page update. It's basically a hybrid of client+server coordinated fragment caching. There are some gotchas and workarounds for onLoad() and other JS hooks, but it mostly works pretty well.
Re: The Disadvantages of Single Page Applications (2014)
#7This seems to be aimed at Single Page Websites and not Applications. The aim isn't to "mimic the browser using Javascript" but to create an immersive application that feels like you're no longer in a browser at all.
I'd say that ~98% (statistic pulled out of the thin air) of Single Page Applications are - in fact - Single Page Websites in your terminology. At least that's what I usually see when various companies are using Angular (or Ember, or React-with-routing, or any other library/framework) to power their web applications.
Honorable mention for the application that you probably have in mind can go towards (IMO) React UI Builder which was posted to HN a few days ago (https://github.com/ipselon/react-ui-builder).
Re: The Disadvantages of Single Page Applications (2014)
#8The main disadvantages mentioned in this article relate to the fact that many SPA today don't replicate the traditional routing mechanism. Which, in my humble opinion, is the wrong thing to judge it on. You can easily have a single-page-application on a... Single Page. The actual url can just preserve the current state of the app, instead of a location.
Re: The Disadvantages of Single Page Applications (2014)
#9This seems to be aimed at Single Page Websites and not Applications. The aim isn't to "mimic the browser using Javascript" but to create an immersive application that feels like you're no longer in a browser at all.
What are some examples of applications that succeed in this?
The only one I can think of that is successful is Google Maps. Though lately I seem have all sorts of problems navigating it, so maybe it's no longer a success.
"Feeling like you're no longer in a browser" isn't really a customer goal or a product goal. It could be a means to an end, depending on the application, but I don't see that many people executing it effectively.
The more common case by far seems to be people who want too much control, without realizing that they are actually degrading the experience (i.e. by messing up navigation, hyperlinks, copy-paste, accessibility, latency, etc.)
Re: The Disadvantages of Single Page Applications (2014)
#10How about the fact that in case you use API keys for the back end, the API key has to appear in the client as well. e.g. If there are third party clients using your API server and you want to issue keys for them. (They could just as easily use the one that is used by the main website)