Hacker News Reader

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered.

A lot of that is likely because of the way most REST APIs are laid out.

Suppose you're looking at a page that displays an invoice for an accounting system. With a traditional non-SPA app, you'd do a bunch of SQL queries and build a page from an HTML template.

With a REST API, you're doing one HTTP call per entity, at least, and then subsequent HTTP calls for aggregate entities.

When I've made SPAs before, I've often eschewed REST and just made a single Ajax call for "everything I need to display X to the user," not just out of efficiency, but also out of laziness -- it's easy to build. As long as you internally use your API only and don't publish keys for third parties, it's easy to maintain too.

There are some solutions to address the whole problem on a grander scale (GraphQL comes to mind), but overall, that's the cause of slow SPAs in my experience.

Yes, this has been my suspicion too. Calls out across a network like the Internet are always going to perform variably, and each new call you make represents a new roll of the dice on how fast you're going to get a response back. So passing the whole page over the wire in one call feels faster than breaking it up into X calls and then assembling the results of them all on the client end, with the page seeming slower as the value of X gets bigger.

If that's the case, shouldn't HTTP/2 have solved that issue? HTTP/2 is multiplexed, so if you make something like 10 HTTP calls, only a single TCP connection would be established. Additionally, according to section 9.1 of the HTTP/2 spec[0], connections are persistent so unless the server closed the connection, an already established connection will be available from when you first loaded the page.

[0]: https://httpwg.org/specs/rfc7540.html#rfc.section.9.1

Well, no.

For one, the most major http client library (Axios) doesn't have support for that kind of pipelining.

But also, you don't necessarily know what to pipeline until you get the first request through. Most web apps will make a REST request, look at the contents of the response, then make another REST request. Maybe you could keep the socket open through that, or you could even use websockets to bypass HTTP altogether and use jsonrpc, but still, you don't know what you need to fetch in the second round until you finish the first one, so either way you're looking at a waterfall of requests, one after another. Pipelining them would scarcely help.

What would help is having one API request that basically says, "here's who I am and here's the page the user wants. Give me everything for it." Then you're moving the controller back to the server, and leaving only the view on the client.

Axios doesn't control what protocol is used, the browser and the server will negotitate a suitable protocol and version, which the browser will transparently use for XHR (which Axios use under the hood). Don't confuse multiplexing with pipelining which was introduced in HTTP/1.1. Multiplexing is a much better solution than pipelining to counter head-of-line blocking, since large or slow responses will delay subsequent requests while multiplexing allows parallel response/request communication.

I do agree that waterfall-style requests are more prominent with a REST structure, and that something like GraphQL could solve that - but GraphQL seems largely incompatible with how many develop web apps today; smaller components that request their own data. I'm also unsure how compatible a dynamic query language like GraphQL is with denormalized databases like Cassandra or ScyllaDB where you can't model your data before you've established what queries your site/app will perform. I've yet to see a codebase where the REST waterfall problem is a huge problem though.

Note that I too dislike how slow websites are these days, and much prefer to both build and use an entirely server-side rendered one. None of the SPAs that I know of has been a success in terms of performance; Facebook, Google Mail, Reddit's redesign, Youtube, Twitch - most of them are dreadfully slow and sluggish.

Doesn't responsive UI just mean it works on different screen sizes and devices?

That's something slightly different: reponsive design (see https://en.wikipedia.org/wiki/Responsive_web_design).

I've started using Vue for some projects, and while it has some fantastic upsides, I find it very hard to optimise. With native code you can easily profile and work out where you need to speed things up or leverage cacheing.

With (e.g.) Vue, because you write so little code comparatively, it leaves you very little to do if the 'magic' that's making stuff happen under the hood is very slow.

I work with a largely native Javascript SPA (main dependency is d3) and find that Javascript can be pretty damn fast if you need it to be.

Time to first render isn't as important anymore. The expectation is more that people will open the app and leave it open for web applications and there is data to back this up. For informational sites the time to render is more important. That being said, there are also a lot of bad developers who basically invalidate any optimizations that the library makes due to their own ignorance.

> The expectation is more that people will open the app and leave it open for web applications and there is data to back this up.

I'm suspicious about this data. This sounds way too much like the same misguided thinking that makes people ignore performance, because obviously your app is so special it'll be the only thing user will have open on their computer. I can buy this expectation for work SaaS, in front of which you sit for 8 hours straight. Most of those used by genpop? Opened briefly and rarely.

> Even on a desktop PC with a fast connection, I spend so much time staring at progress bars and loading spinners as all the various bits and bobs of the interface get pulled down and rendered.

This means whoever wrote the app wrote it slow. React rendering performance is fantastic but that doesn't stop devs from abusing AJAX.

I think it's fair to say the browser has a ton of potential performance pitfalls in it, regardless of framework or lack thereof, and it's really easy to make a slow thing no matter what you do. There's definitely a ton of people who take relatively fast frameworks and do slow things with them.

I think Progressive Web Apps should help with this. The architecture there designates that you have an app shell that's only downloaded once - this should be your SPA framework and all the layout bits and blobs. Those get cached at the service worker layer. Everything else (i.e. the actual data that gets displayed) can be cached as needed or retrieved as needed, without having to redownload all the "app shell" bits.