Performance, developer experience, user experience

I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off.

Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry about the server disagreeing with the client is the ultimate developer experience. Build a competent app that can serve full pages in .1 seconds and no one will care that your site isn't an SPA. They want a fast reliable site.

▲

unchar1 4 days ago | parent | next [-]

We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages.

By every performance metric, the new app was faster.

But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site.

I'm not sure if this is a universal experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.

▲

bob1029 4 days ago | parent | next [-]

SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency.

My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.

▲

nfw2 3 days ago | parent [-]

Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.

▲

gizzlon 3 days ago | parent [-]

> should have no perceivable latency between the action and the feedback that the action was received.

Huh, according to who? I think a small delay is totally fine.

Often better than the SPA's that tried to fix this non-problem and introduced much worse problems.

Edit: For example HN: I press update and there's a small delay.. So what? Most sites and SPA's have a much worse user experience than this.

▲

nfw2 2 days ago | parent | next [-]

Because past delays of about 100ms, users lose the sensation of directly manipulating the page. The feel of a page is part of it's aesthetic.

Also, immediate feedback reduces anxiety and mistakes (for example duplicate submissions).

https://www.researchgate.net/publication/391230228_Cognitive...

https://www.nngroup.com/articles/response-times-3-important-...

▲

gizzlon 2 days ago | parent [-]

Looked at the first one, and that's in a game setting? And they test 600 ms??

edit: The second one is more useful IMO. It's hard to get under 100 ms with a roundtrip, but < 300 ms should be doable, right? So you do lose the sense that you are directly manipulating data. In most cases I think that's a good trade-off. Exceptions would be things like Google docs, but that's also because it's a well made app I trust to actually sync my data without loss. Unlike most SPAs..

	▲	nfw2 a day ago \| parent [-]
		300ms for network latency both ways, with server potentially doing its own network calls for data to fulfill the request, interpolating the html, and then browser rerendering client seems like a stretch

▲

2 days ago | parent | prev [-]

[deleted]

▲

nfw2 2 days ago | parent | prev [-]

I am curious to identify what your users are perceiving that isn't be being captured by your metric. If it is accurate and not just rhetoric that MOST of your users are asking for a rollback for purely performance reasons, that is a very extreme outcome.

Are your p90 metrics testing:

- navigation after first load?

- users who are going to the app after it is cached on their browser?

Are your actions going through server actions or rest apis? Do you have metrics on those?

▲

jeremy8883 3 days ago | parent | prev [-]

the back button does work, if you use any basic routing library. opening in a new tab does work, with any basic routing library...

▲

romanovcode 4 days ago | parent | prev [-]

Developer experience - Yes, in most cases.

Performance - No, in most cases.

User experience - No, in most cases.

What are you talking about. Majority of SPAs have abysmal performance compared to regular HTML rendered websites and that reflects poorly on user experiences.

▲

elktown 4 days ago | parent | next [-]

> Developer experience - Yes, in most cases.

I think if people remembered how productive you could be before the SPA frontend/backend split they'd reconsider. Being able to take a feature from A to Z without either context-switching between ecosystems or, even worse, involving other people, was incredibly productive and satisfying. Not to mention a much more streamlined dev env without a bloated js ecosystem of bundlers/compilers and whatnot.

▲

christophilus 4 days ago | parent [-]

I write an SPA for my day job. I write Postgres queries myself. I create endpoints and background workers and cron jobs myself, and I build out the UI myself. It’s all typescript with static types end-to-end. It’s a fantastic developer experience. Much, much better than I ever had in Rails or ASP.NET.

Also, I love components for UI as opposed to templates. And I don’t think I could ever really go back to the way I did things in my MPA days.

	▲	elktown 4 days ago \| parent [-]
		If there's no clear backend/frontend split wrt to language and roles in your particular project my point doesn't really apply for you. But it seems that you're lucky that you can use js on the backend to get closer to that. I would still prefer to not have to do a SPA unless obviously required for the job, but at least you got some of the fundamentals in place to be individually productive.

▲

nfw2 3 days ago | parent | prev [-]

Performance - For pages that have different content for every user, the best performance will be reached by caching the app code on the client, only loading the data needed to render, and rendering once on the client. Rendering on an aws machine that is weaker than my 15 year old macbook is not a recipe for good performance.

User Experience - Every single user action should have no perceptible latency between the action and the feedback that that the action was received. This can't be done gracefully without javascript. Moreover, SPAs enable a better ux by enabling developers to build complex features that wouldn't be possible on traditional webpage.