
Ask HN: What are some use cases for single-page apps? - sharemywin
Besides screen navigation<p>Things I can think of:<p>- Single field validation<p>- Complex Async back-end process(Download, complex reports etc)<p>- Suggestion text field<p>- Multi step Wizard(kinda screen nav)<p>- Grid<p>- Continuous scrolling<p>- game<p>- accordion
======
newman8r
I think it's an interesting question.

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.

~~~
GeneralMaximus
> 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).

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.

------
imhoguy
I think the single client-side state and navigation control is the most
prominent cause to chose SPA. Every time you want to avoid full
page/javascript reload for some reasons. Such reason may be heavely
interactive website/app like whiteboard, chats (Slack,SkypeWeb), music apps
with online playback (Soundcloud, Spotify), text editors, spreadsheets, real-
time updating stuff.

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.

------
twobyfour
If you have a single "view" and you're moving stuff around in it, that makes
sense for a single page app. If you have multiple views or multiple objects
that each take over the entire page when you look at them in detail, that
should not be a SPA and you'll just infuriate users like me by hijacking the
browser's navigation facilities and slowing down page loading by trying to go
the SPA route.

Too many sites' admin panels are like that. And don't get me started on single
page econmerce or content sites.

~~~
TomMarius
SPA that slows down page loading is an extremely poorly done SPA. If done
right, things should be considerably faster. Not saying that there is a lot of
good SPAs.

~~~
twobyfour
Client side rendering of an entire page is almost always slower than server
side rendering.

~~~
TomMarius
SPA doesn't imply initial client side render. The first render should of
course be done by the server, ideally cached and reused. After that, you can
leverage caching and preloading to significantly improve the user experience,
page loads can be near-instant.

------
romanovcode
SPA stands for Singe Page APPLICATION therefore

Good:

\- Excel Online

\- Word Online

\- Email

\- Document processing application

\- Complex administrator dashboard

Bad:

\- Blog

\- E-Commerce website

\- Marketing website

\- Something that requires heavy SEO

------
zck
If you're tired of writing HTML that isn't inside Javascript.

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.

~~~
applecrazy
Doesn't that run into the issue of exposing all your business logic in the
JavaScript? Somebody can also build a malicious client to query your internal
APIs, maybe even leak some data?

I want to know because I was thinking of doing this in a side project, but I
fear my proprietary functionality could be exposed.

~~~
noodle
Some will have to be in the JS, but that isn't really any different from non-
SPA web apps. They still serve up JS files that have business logic. JS and
business logic are, to some degree, inseparable.

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.

~~~
imhoguy
This is about separation of layers and defined interface contracts which
applies both to SPA and traditional server-side rendered pages. Remember
mangling with query params back in the time? `.php?param=...`. Now regarding
"JS business logic" in SPA, I think it should be only presentation logic
(formating, handling input, navigation etc.) and at most some data aggregation
from various sources.

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.

------
chairmanmow
I was tweaking my monolithic BBS software's web interface and decided it
needed to be rewritten single page app because there were elements that really
needed to persist in memory for the experience I wanted.

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.

------
relaunched
Single page apps are primarily a design / experience choice. The limitation is
one's ability to define an experience within a single-page app.

~~~
sharemywin
Let me rephrase when might a SPA be a good design choice given various
functional choices the user might need to accomplish.

or if that's not a good basis for choosing what things would influence your
decision.

------
jklein11
All of the things you mentioned can be achieved with server side rendering and
embedded javascript.

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.

------
jbergens
An SPA is generally a good choice for applications with a lot of user
interaction, if you're only creating a web site a server based solution may be
the best.

Some of the potential benefits with an SPA is the developer ergonomics and ui
speed.

------
wetware
The field of application for SPAs is VAST - and (thanks, perhaps, to an
ongoing obsession with the fragmented, resource-starved visual poverty of the
mobile web) miserably underexploited.

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 :-)

------
kehers
Electron apps. (Cross platform apps that can be built with HTML, CSS, JS
really).

------
mbrock
Anything that would be improved by offline support.

------
Sevii
Microsoft Outlook email client

