
Ask HN: What are the real advantages of SPAs? - MarvelousWololo
I don&#x27;t really understand the reason behind Single Page Applications. I&#x27;m currently working on a code base so bloated with crap that I feel overwhelmed and I can&#x27;t help myself think stuff like: &quot;it&#x27;s such an overkill, we don&#x27;t need all these dependencies&quot;. Is it because it&#x27;s too expensive to send HTML from the server? What kind of problems SPAs are trying to solve? Does people actually bother about a full page reload? At this point I think we are just following the bandwagon and we forget what problems we are really trying to solve.
======
java_script
Soundcloud was built as a SPA so you can keep your music playing as you
navigate.

I wish MyFitnessPal was a SPA in places so I could click checkboxes and
paginate the food catalogue at the same time when adding food to my diary.

Nearly everywhere else, IMO, no. SPAs are absolutely harder to build and
people start with them by default because everyone wants to be Facebook, which
your average CRUD site is not. You can pull in those fancy javascript features
as you need them, and hell, even embed React in the one part of your site that
truly needs it. Which is what React begs people to do on their website, but
apparently people read that and say to themselves "That message is probably
for the plebeians building a Todo list app or something. _I 'M_ building
Todo++ Enhanced, so I'll probably need 40 layers of abstraction and about a
gig of dependences to implement a form."

~~~
MarvelousWololo
I couldn't put it better. I'd be happier if we stop thinking that every single
website on earth must be a SPA.

------
agarv
While there can be UX benefits to using SPAs, something I have not often seen
expressed, but which I believe is that the main advantages of SPAs are for
business rather than technical reasons.

1\. Clear separation of concerns for front-end and back-end teams. With SPAs,
the work is clearly divided into front-end and back-end parts, with the back-
end team working on the server side code and the front-end team working on the
static assets (HTML, JS, CSS). Both sides only communicate through a clearly
defined API (e.g. REST, GraphQL, SOAP) which allows both teams to work
independently of each other, and means that if there are bugs or problems,
there is less confusion on which team is causing them and thus which team
needs to fix them. Compare that with server side rendering using an MVC
framework such as Rails. The migration and model code "obviously" belongs to
the back-end team, and the static assets (JS, CSS) and views/templates belong
to the front-end team, but what about the controllers and routing? Both teams
are going to need to work on those parts of the codebase, and that's going to
increase the need for inter-team communication and confusion on which team
owns what. For example, I interviewed at a company where the front-end team
was US based and the back-end team was outsourced to India, and they were
moving to a SPA so the teams could work more independently. Previously they
had used JSP, which meant the front-end team had to write HTML and then send
it to the back-end team and then they had to coordinate how the back-end team
was going to re-write the HTML as a JSP template.

2\. Cheaper mobile and desktop apps. While it seems HN is very negative about
non-native apps, it's not hard to see the business case of quickly and cheaply
converting your website into a mobile or desktop app using something like
Electron, Cordova or a web view. Even if you do plan to make a native app, the
SPA and native app can reuse the same APIs, reducing the amount of work for
your back-end and QA teams.

3\. Flexibility in changing back-ends. While less common than the other two
cases, if you decide to change your back-end code (such as Twitter moving from
Ruby to Scala) if your app is an SPA you only need to recreate the APIs and
don't have to rewrite all your templating code (this is less of a problem if
you use a more "neutral" cross-platform template language like Handlebars).
For me personally, I'm moving all my personal projects to Elixir/Phoenix from
PHP, Rails or Java, and because I used server side rendering I had to convert
all my templating code to EEX.

------
dublin
I'm not trying to be a jerk, but the answer to this, like most things in
software development is, "It depends how you use them". They're wonderful if
thought out, designed, and used properly, and a bloody nightmare if not...

------
muzani
I've seen one major use for it. We had a "site" running on a tv (think Netflix
tv app).

It had to be run on one page for technical limitations of the hardware's
browser. It also had to do all the login, persistent connections at the same
time.

A lot of it was videos. Meaning we had to check whether users were still
watching, which profiles they were logged in to, and had to optimize the API
calls. Which is difficult on multiple pages.

There were plenty of overlays - we had videos on the background, navigation on
the foreground. Sometimes we'd have to play another app nested within the app.
And the only way of closing that app was through a command sent to the parent.

~~~
MarvelousWololo
I'm with you, contrary to 99% of other websites that's a fair use for a SPA.

------
BjoernKW
SPAs are particularly useful in scenarios where you need to combine the
characteristics of desktop apps (responsiveness, event-driven UI, complex
interactions) with those of web apps (links, drawing upon data various
sources, declarative UI, ease of software distribution and installation).

SPAs are usually associated with frameworks such as Angular and the MVVM
pattern.

While multi-page applications or frameworks like jQuery can provide similar
benefits, with features such as component architectures, pub/sub mechanisms
and dependency injection that come with SPA frameworks those usually allow you
do so in a more deliberate, comprehensible manner.

~~~
MarvelousWololo
I understand and I'm trying to troll you but if you need desktop features on
your software why can't you just build a desktop app?

~~~
BjoernKW
Because desktop apps lack several features of web applications:

\- links and open interfaces to other applications. Try exchanging data
between two arbitrary desktop apps, for instance. Often copying & pasting or
manually re-entering data is your only option in these cases. Yes, that's
mostly because vendors treat desktop apps as walled gardens and yes, there are
walled gardens on the web, too. The web however was designed with open
standards and data exchange in mind. This shows quite clearly in the
underlying protocols of the web, which is why when exchanging data between
desktop apps, nowadays often HTTP is used, too. ARexx on AmigaOS (and to a
limited extent AppleScript on macOS) was the only somewhat widely used
technology that allowed desktop apps to communicate with each other in a
manner similar to UNIX command-line applications. About the only more widely
used way of calling one desktop (or mobile) app from another today ironically
are customs URL schemes, which of course are quintessentially a web
technology, too.

\- ease of software distribution and installation. This one's particularly
relevant in enterprise environments. Rolling out a new version of a bespoke
in-house app to the entire staff and each and every desktop machine in the
company with all the individual installation issues that might occur on each
local machine is a huge undertaking. Besides, you'd probably still need some
sort of server application to synchronise to, which in case of a web
application already comes with the package. Browsers on the other hand today
are ubiquitous and other than old IE or firewall issues deploying a new
version of a web app to users in enterprise contexts by and large works like a
charm.

\- being able to declaratively define UIs. Desktop UI used to be programmed in
an imperative manner whereas HTML and CSS work declaratively, which allows for
faster development and immediate feedback to changes. A declarative style can
make the structure of a UI easier to grasp as well. Another huge advantage of
HTML - or rather browser engines - is that for the most part it abstracts over
device-specific peculiarities. Again, browser engines being ubiquitous is an
enormous benefit because you can expect a (largely) uniform and predictable
runtime environment on each potential target device. Pretty much what JRE
promised but never quite delivered (on the desktop, that is).

------
Zooper
The framework / tooling bloat is causing a bubble to form; it needs to be
simplified, now. It can be done cleanly, but SPA often is not. You are correct
in your assessment, even though the cargo-cultists will say otherwise. It
doesn't need to be thrown out, it needs improved standards, focusing on
simplicity, http >= 2, and domain-specific concerns, such as state management,
routing, etc. The innovation in the space is mostly over, time to give it an
injection of standard and boring. And, for the love of God, can we really not
do better than the virtual-DOM for updates? In-memory copies? Really?

~~~
MarvelousWololo
Oh, standard and boring. I pray every single day for it. And please let
ReactiveX and css-in-js die too, these are a real pain.

------
usgroup
Speed, interaction, service worker, local storage, PWA.

E.g wego.com built with polymer

~~~
malux85
Also if you're careful with design then the JSON API that the SPA uses can be
re-used for iOS / Android apps and third party integrations as you scale.

~~~
iKevinShah
This was one of the most important reason why I switched a site/app to PWA. It
is so convenient to have single "backend".

------
DATACOMMANDER
I’m about to finish my first web application—created to show off as a
portfolio piece—and it ended up being an SPA. Granted, it’s not very complex,
but I’m thinking about adding additional functionality to it, and if I do I’m
pretty sure I’ll stick with the SPA architecture. I like the responsiveness
and sense of intimacy, but more than that, I like having all of the
functionality easily accessible to the user at all times. The one thing I find
most annoying about using web applications is the sense of uncertainty that
lurks behind every click of a link/button. I find myself wondering:

\- Am I going to be taken to a new page with a different interface?

\- Will I have to open multiple tabs and/or navigate back and forth?

\- Is this going to take several seconds to load?

It’s not the end of the world, but I find it annoying.

~~~
tucaz
All of the points you mentioned to be true for web pages can also be true for
an SPA. Can't they?

~~~
DATACOMMANDER
They can, but it seems easier to avoid those pitfalls if you go with SPA.

~~~
romanovcode
In classic websites you also have layouts and controller-views so I don't see
how it's different from SPA in this regard.

