Comment by dkarl | Hacker News Reader

Comment by dkarl | Hacker News Reader

I think this article is unfair to SPAs. SPAs are a lot more effort, but they are better. For a long time they have been the only way to "make it feel like an app." (I think the author says "make it feel like an app" because they know we all resent app fatigue, all the apps we have to download that should just be web sites, but I think we also all know that when something really is an application, it's rare for a "web app" to match the experience of a local native application, and an SPA is the only way to make a sincere attempt.)

The comparison of bloated SPAs with lean web sites is bogus. If someone takes the effort to make their web site lean, they'd do the same with an SPA. If someone makes a slow, bloated SPA with megabytes of Javascript, they'd make a slow, bloated web site with megabytes of Javascript. I think we've all seen enough of the web to know this is true.

I click on articles like these because I've seen the effort that goes into a good SPA, and I'm interested in anything that would allow people to deliver an equivalent experience with less effort. All I see here is a tiny bit of cosmetic polish. Polish is appreciated, but this doesn't seem like something that would tip the balance between building an SPA or not. Am I missing something?

“But they are better”

By what measure?

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.

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.

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.

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.

> 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.

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-...

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..

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

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?

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

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.

> 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.

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.

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.

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.

Reply on news.ycombinator.com