Things I can think of:
- Single field validation
- Complex Async back-end process(Download, complex reports etc)
- Suggestion text field
- Multi step Wizard(kinda screen nav)
- Grid
- Continuous scrolling
- game
- accordion
One use case example: if I'm looking up resources to learn about cryptocurrencies, I want a web 2.0 style experience. If I'm on an exchange and trading those cryptos, I'd rather have a real-time single-page experience (I think poloniex does a decent job as an example). Even single page apps seem to have a lot of additional 'web 2.0 style' pages supporting them, so the entire thing can become blurred. Even with 'single page apps' you'll often have separate interfaces for user admin, splash pages, etc.
multi-page sites seem superior if you're more concerned with things like search engine traffic, maximum compatibility, smallest size, lowest maintenance, interacting with standard browser functionality (i.e. letting users bookmark pages in your app, browser extensions, etc).
Single page seems better if you're more interested in feeling like a desktop app, more interested in UI/UX, serving notifications, showing live feeds, letting the user 'sit back' while you deliver content.
Building single-page applications is my bread and butter, and I totally agree with this sentiment. If you're building something that's purely content and doesn't require too much interactivity (which is true for most websites on the web today), SPAs are not worth the hassle.
However, it's worth noting that most SPA frameworks support server-side rendering. For one of my clients, I built a server rendered React website that behaved less like a SPA and more like a regular server rendered website, i.e, navigating to a link within the website caused a full page reload. The performance numbers weren't too different from your average Django/Rails/PHP website, and making sure everything worked on Node as well as the browser wasn't as hard as we imagined.
The advantage was that we could write the whole thing with React, as opposed to using some kind of templating language to generate HTML and then using JS to inject the interactive bits. It's an interesting strategy that I wouldn't mind exploring again.
Why did we do it? Because we had to integrate with a bunch of legacy code and this was the only way we could do it sanely.
In my opinion most cases applying full SPA to CRUDs and content pages with normal hipertext navigation is overkill and comes from fad or desktop development experience. Such end ups with poor implementations failing with edge cases which normal browser navigation would support. E.g. try to change LinkedIn tab while you are offline - nothing happens, no error, no "You are offline" etc.
Too many sites' admin panels are like that. And don't get me started on single page econmerce or content sites.
Good:
- Excel Online
- Word Online
- Document processing application
- Complex administrator dashboard
Bad:
- Blog
- E-Commerce website
- Marketing website
- Something that requires heavy SEO
Seriously, though -- the company I'm working for is serving SPAs that interact with APIs directly, so you can serve everything except your API from a CDN. You don't need a server to render your pages, and perform your API actions; you can just use a SPA.
I'm not super knowledgeable about all this frontend stuff, so I can't really speak to if it's the only option, but it does seem like one thing that's pretty unique.
I want to know because I was thinking of doing this in a side project, but I fear my proprietary functionality could be exposed.
``` { "count": 1, "results": {...} } ```
Then if you want to perform an action on a particular invoice, you can access it using the /invoices/:invoice_id/action endpoint. For example, let's say you want to pay the invoice with id=1, then all you have to do is make a POST request to /invoices/1/pay/
and if you want to pass variables to your action, you can do it through the body of the request. For example, if you want to pay your invoice with a card on the account with id=4, all you have to do would be to make a POST request to /invoices/1/pay/ with the following body:
``` { "card_id": 4 } ```
If you're giving trust to a user to query the API, they could also maliciously leak data or execute queries inside a normal web app just as easily if you build something appropriately secure.
It needs some real architecting skills to build secure and limited API. Unfortunately often ease is prefered over security for some so I have witnesed Elasticsearch or MongoDB APIs exposed to SPAs without any additional layer.
There's web based terminal in that app, and the user would lose their session while navigating through the site, and there's also a radio stream going on that I didn't want to have to rebuffer.
I make SPA's all day for work, but they'd probably be ok with a different approach. Wasn't until I started to muck with my BBS's interface for fun from a user centric perspective that I realized that a SPA approach was the solution to most of the problems I saw. Not that this is a common use case, but just sharing my recent experience.
or if that's not a good basis for choosing what things would influence your decision.
The only pro SPA argument that has made any sense to me is performance. The idea is that you do not need to store any state information. This reduces server load and give the possibility to do caching, etc.
So I guess my answer to your question would be any time rendering the app server side will cause issues.
Some of the potential benefits with an SPA is the developer ergonomics and ui speed.
A single page application is a good choice where interactive graphics are generated server-side (typically from a simple and tiny JSON configuration file), but finely manipulated (through selections and transitions) in a web browser.
Applications built using modern data-driven libraries have access to class and id values across the entire graphical structure, allowing exceptionally fine-grain selections, which can be grouped according to user's needs. These are the basis for spectacular and visually liberating transformations.
For example, for timeline-based, event-driven applications, GUI events can be grouped according to whether dynamic (timeline-driven) or static (hover-over / property interrogation) mode, allowing -overall- a much greater event handling density.
Using modern programming techniques, literally thousands of model configuration variants can be derived from one generic tool visualization base. For application areas with many classification families, this implies many thousands of unique models, but also (often the only workable solution) open-source / community-driven provisioning.
Generated on the server and presented on the client in either SVG or WebGL forms, each and any of these can be instantly and automatically hooked up with the timeline, sharing consistency, styling and timing with all other animations.
Visualizations can be literal (structurally redundant or abstract, as with SVG) or figurative (ad-hoc, drama based as in WebGL).
A compelling aspect of domain-wide SPAs is their ability to act as an integration stack for (otherwise standalone) artificial and machine intelligence solutions.
They may also build on off-site synergies, such as timeline-synchronized video or the psychophysics of visual processing, adding other intriguing visual dimensions or feedback channels.
Configuration preferences can be aggregated to define menu preferences and indeed entire online environments, which in turn can be one-click shared with others, providing the basis for globally-available information exchange platforms.
The linchpin in all this? Intimate data/DOM bindings, a.k.a. 'ditch MVC'.
My feeling is that as mobile bottlenecks are eliminated, graphics-rich SPAs are set to be the next great driver of user expectations.
All that and not a single example? Clearly didn't read the question :-)