Hacker News Reader

> Ship your users an app including a copy of the data ahead of time

I did exactly that with a hobby project (https://www.acceleratul.ro/). The funny thing is that I had to add a short (~50ms) artificial delay with a spinner before showing search results, because people completely missed the fact that the page had refreshed

Yeah, I did the same with https://james.darpinian.com/decoder/. It's an underused technique for sure. It's enraging when I have to repeatedly wait multiple seconds to load a bloated results page containing 10 additional rows from a database query (e.g. paginated product listings) when I could have easily downloaded the complete query results or even the entire database in less time.

Nice helpful project, I think I may have used it once while in Romania. Yeah, for small static data it absolutely makes sense to embed it in the app itself. But imagine your app was world wide or it needed to account for dynamic data, not sure it would make sense to ship a few dozen MBs all at once.

This is cool. What techniques did you use to include a copy of the data?

I believe this entire technique is known as SSR - Server-Side Rendering. It's built in to Vue and React and you can find examples on their respective sites.

that's confusing, I've only ever heard SSR/server side rendering to mean actually rendering html and serving that, as opposed to SPAs

Well, the idea is that you render the first pass of the SPA and serve that HTML to the client. Rather than just injecting the data into the SPA source code, you inject the data and render the page, and then serve that page. Then whatever changes the user makes to the page after that initial load gets handled by the SPA. This way the user avoids having to wait for the SPA and all its dependencies to load before the page can even appear, and the developer doesn't have to differentiate between what happens on the client side and server side (remember using PHP to inject variables into JS source code?) because they can just bake it into their SPA.

that's pretty neat, I didn't know that react could do that. Shame no one ever seems to make use of it

it's just a bunch of JSON bundled inside the rest of the JS assets with webpack

"unless you screw things up elsewhere, that's going to be less than 1ms of delay"

Are you using an iPhone?

In my experience SPA performance falls apart on cheaper Android devices, which are far more common among regular users but tend not to be in the pockets of developers, who spend way more money on their devices.

I think the question is whether developers actually care if users with cheap devices can't use their SPAs. If you're trying to sell them something, you probably want customers with deep enough pockets to afford a somewhat modern phone. If you don't want to sell them something and you just want to provide information (e.g. restaurant website, digital flyer, event RSVP, etc) you could serve a simple static page, or forego the website entirely and post your information on social media which can then be consumed by optimized native apps.

If you don't want to sell them something and you don't want to tell them something, why are you building a complex SPA at all?

> forego the website entirely and post your information on social media which can then be consumed by optimized native apps

...and force the user to install the "optimized native app" for the social media site du jour? Or simply let them put up with Facebook's "yes-this-is-a-public-page-but-I'm-still-going-to-ask-you-to-log-in-or-sign-up-just-because-I-can" shenanigans? Great UX, that!

Cheap phone, cheap UX?

Are we really going to assume that your average user doesn't already have FB installed and already signed in? They have over one billion users, you know. It's not exactly rare to find Facebook on any arbitrary person's device.

Even assuming all of those accounts are still active (and none of them are duplicates), that still leaves around 7 billion people without a Facebook account. Personally, I do have a Facebook account, but I only use it on my private desktop PC, not on my work laptop and also not on my phone.

I agree with you, I'm only logged into my work FB account on my personal device, however I'm also a power user (and I'm guessing you are too) so I don't think our experiences can extrapolate out to the population as a whole. Sure 7B people don't have FB, but are you trying to invite 7B people to your event or business? Not really; you're probably trying to target a very specific kind of person, or a group of people you already know. In that case you can just do some surveying / focus group'ing to figure out what people already use and push your content on the platforms that cover the majority of users (which in most cases, I'm guessing, would include FB).

A few years ago while working on a big redesign of a high traffic web app used by people on a variety of devices–where maintaining conversion rates was critical to the project–I bought my team a handful of the cheapest current-gen Android devices I could find on Amazon to test with.

It's definitely a worthwhile exercise if your audience isn't just tech company employees with brand new flagship devices.

> that's going to be less than 1ms of delay

That doesn't jive with my experience. If you are using something like React to do client-only rendering, you're gonna be waiting a lot for blocking critical path JS to run, as well as the actual paint time (which alone can easily be in the hundreds of milliseconds).

> Ship your users an app including a copy of the data ahead of time

That's not really feasible though, is it? Most SPAs in the wild fetch data on demand, so you still get the network latency no matter what (on top of the delay due to no streaming each time). This is why you get those skeleton placeholders on sites like Facebook.

>which alone can easily be in the hundreds of milliseconds

This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though.

Plus, if your application is so complex that paints are on the order of magnitude of network latency, it's probably very important to have a framework to handle interactivity, else everything will end up as some kind of a mess if you try to re-load the whole HTML page to change some small DOM subtree.

Overall, I don't really see the situation where an SPA is performing worse than a server-rendered application, given that some in-browser interactivity is required.

> This actual paint time is surely not any different than if you rendered the exact same application from pre-hydrated HTML though.

Well, it's different in different ways, depending on which goalpost you're standing on. If by that you mean do SSR, then run React on top, then you've just incurred the same TTFP as plain HTML, plus the cost of React hydration, plus potentially a second repaint (or even third and fourth repaints, depending on how your data trickles in). In the wild, this pattern gets particularly egregious when people decide that it's ok to have loading icons and widgets pushing each other down as data comes in.

If you mean to compare to client-side rendering without SSR, then you're still looking at the cost of at least two repaints (the initial TTFP repaint, plus any repaints from data fetching after that).

>Well, it's different in different ways

You misunderstand - I mean that literally. Arriving to the same initial application state from any means, surely the HTML painter isn't going to be slower or faster. Other parts of the stack will of course be, but I really didn't understand how the painter would induce latency.

I personally see extremely limited value in SSR, I prefer to let the client machine deal with assembling related data objects into a nice UI, so you won't catch me out here arguing for it. I load an HTML page that displays an animated spinner inside #root, and then once my bundle loads it lays the application out.

In single-page apps, navigating between pages is hard to get right. https://vector-of-bool.github.io/ implements its own JavaScript-powered page turning. However if you press End on a long page, then navigate to a short page and back to the long page, the browser's scroll position gets truncated.

In the "Instant Multi-Page App", navigating between pages "just works".

Misses the point on so many levels.

Fastest experience will always be without a special framework. Fastest will always be if there is nothing except the content served in a single minimal request/response. So, this means no JS (excepct issuing requests), no browser framework, pure content. Browser sends the simplest request and receives simplest content. User reads it or looks at it. Fast as hell. It can't be faster than that because JPG can not be compressed further, gzipped HTML can not be compressed further. With later HTTP implementations, the connection can already be open and re-used.

To explain this with an analogy. Bloatware comes when you decide that your true content is not enough to be appreciated as is, and needs to be beautified, made interactive, .... Just like make-up. Without make-up you only need to show your face. When you decide to use make-up to cover the true content (your true face), you need huge ammount of overhead - you need to buy the make-up, you need to learn how to apply the make-up, clean the make-up, re-apply the make-up. You need robust make-up. You need waterproof make-up. Then you need special cleaner because water will not be able to clean it. Then you start needing a make-up framework, to help you clean, apply and re-apply the make-up consistently and easily. So reinventing make-up frameworks will do nothing in alleviating overhead. Dropping the framework is the best way to go.

I hope this analogy makes things clear what I meant.