
Ask HN: Why Spas (Single Page Applications) Are So Popular? - cnst
Why SPAs — Single Page Applications — are so popular nowadays?<p>When I try to login to my bank to see my transactions or make a payment, it&#x27;s a multi-minute affair, because it&#x27;s all an SPA, and the individual parts take ages to load, and you mostly can&#x27;t even use the bookmarks or URL autocompletion to navigate to the appropriate sections of the site.  Usability is a mess, backwards&#x2F;forwards buttons often don&#x27;t work, bugs are everywhere (probably because noone really understands how the whole thing works and what are the limitations).<p>Before SPA, it was a very quick task; now it takes ages to see it finish loading the various pages.<p>Same with Reddit — the newest redesign is extremely slow, and especially unusable on mobile, although desktop experience itself isn&#x27;t any better.<p>A good counterexample to SPA — Hacker News — not an SPA.  It&#x27;s very quick to load (unless you&#x27;re shadowbanned).  Straight HTML.  URLs work.  Forwards&#x2F;Backwards navigation buttons work perfectly.  There&#x27;s no need for any sort of a progress bar, because the actual page loads up immediately.  (One way to ruin it would be to convert it to SPA.)<p>Why are they teaching SPAs in bootcamps?  Why is there so much demand when it decreases usability, SEO, and probably conversion rates, too, compared to the plain old server-side HTML-based rendering, with a little bit of auxiliary JavaScript like here on HN?<p>I could understand SPAs being used for webmail and webchat (although both are also possible without SPA), but why has it taken over for things like online banking, where all data is static (it&#x27;s usually cached at a time you login)?<p>Has anyone ever thought how much energy is wasted daily on all these megabyte-sized SPAs when the same information could be presented in kilobyte-sized straight HTML?  Wouldn&#x27;t the most immediate action we can take against global warming is to tune-down SPAs a bit?
======
tboyd47
Possible reasons: Javascript developers are cheap/plentiful, you want to leave
options open on the back-end, or someone on the team just is very pro-SPA.

Ruby on Rails is still pretty popular for bootcamps.

------
the_hoser
This isn't really a problem with SPAs. SPAs can be fast (and if done right,
can be _very_ fast). SPAs can be bookmarked. SPAs can have full support for
forward/backward controls.

These problems aren't unique to SPAs, either. Many server-side rendered
applications have the exact same problems.

The problem is just that these applications are being designed poorly. Nothing
else.

------
photawe
SPAs, if done right, can be very fast, and the user experience can be waaay
better. It may load a bit slower, but after that it should be smooth sailing.
But yeah, only if done right.

Seems your bank is pretty much the opposite of that.

------
PaulHoule
I wrote a famous Javascript in '97, went onto make some very complex GWT and
Silverlight apps where I had to figure out how to do complex choreography with
the server despite asynchronous communications long before most people
understood there was a problem...

Despite that (or because of that?) I was a hater on SPAs throughout most of
the 2010. I know agencies that did PHP/ColdFusion/ASP work before 2005 or Ruby
on Rails work 2005-2010 who found their customers were asking for SPAs and
they just couldn't sell the traditional sites anymore.

I think it's a situation that people blundered into. Web forms weren't
originally designed to make complex applications. At the beginning you
typically made a web form and then had the form POST to a cgi-script at a
different URL. (e.g. Back them you had a static HTML page and a separate Perl
script in your cgi-script directory)

If you wanted to validate the form you were in trouble because doing that on
the back end required the script to be able to display different pages
depending on the content of the form, and ultimately that requires a back-end
framework that separates HTML content from the exact URLs it is served as at.

Ruby on Rails was an example of the kind of framework that addresses that --
what you get when you think systematically about these issues. Around the same
time Microsoft was coming out with ASP.NET which had some brilliant ideas but
didn't understand that you might need to display a different page at the same
URL, then they got ASP.NET MVC that threw out all the good things from
ASP.NET. On top of that there were many frameworks and apps that did very bad
things keeping session state on the server that led to major bugs.

The SPA answers many of those issues by having (medium term) persistent state
on the front end rather than having to have something that manages that state
cooperatively between the front end and back end.

I did a lot of home automation and related work recently and that got me
looking at cross-platform GUI frameworks and I found that these were uniformly
awful. For instance if you are working in Python you can use tkinter or GWT
but the Python side isn't really documented so you have to look at the Python
docs, source code, and the tk or C or C++ docs to guess what you're supposed
to do. I kinda liked JavaFX but it is being phased out...

I got back into programming React-style SPAs for work, and I finally got over
my hate for SPAs and (particularly) Electron.

Yes, it's annoying to install 20 crapplets on your machine that are all 30 -
32 MB in size, but just try using any other x-platform gui framework and
Electron, React-Native and other web derived things look good.

