Ask HN: Why Spas (Single Page Applications) Are So Popular? | Hacker News Reader

Ask HN: Why Spas (Single Page Applications) Are So Popular?

4 pointscnst4 comments

Why SPAs — Single Page Applications — are so popular nowadays?

When I try to login to my bank to see my transactions or make a payment, it's a multi-minute affair, because it's all an SPA, and the individual parts take ages to load, and you mostly can't even use the bookmarks or URL autocompletion to navigate to the appropriate sections of the site. Usability is a mess, backwards/forwards buttons often don't work, bugs are everywhere (probably because noone really understands how the whole thing works and what are the limitations).

Before SPA, it was a very quick task; now it takes ages to see it finish loading the various pages.

Same with Reddit — the newest redesign is extremely slow, and especially unusable on mobile, although desktop experience itself isn't any better.

A good counterexample to SPA — Hacker News — not an SPA. It's very quick to load (unless you're shadowbanned). Straight HTML. URLs work. Forwards/Backwards navigation buttons work perfectly. There'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.)

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?

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's usually cached at a time you login)?

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't the most immediate action we can take against global warming is to tune-down SPAs a bit?

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.

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.

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.

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.

Reply on news.ycombinator.com