Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Easier said than done. When you have to load a number of components, each with possibly multiple rows within them, it can take awhile to pull all the data and it is better to break them into a bunch of smaller backend calls that can be cached as needed than trying to return a single json object containing all the data needed to be displayed on a user generated app.


That seems like a good excuse for when there are multiple lists of things, but when it becomes the standard behavior for pagination of a single table of 10 rows, it's ridiculous.

> can be cached as needed

For requests of < 30kb, client side caching has very few benefits. If it's a slow database query, then hopefully the server side is caching something to lessen load.

> trying to return a single JSON object

Certainly there are some cases where JSON might make sense to return to a browser, but the cases that I'm frustrated by should never be serialized as JSON when sent to the client, and should be sent as tables or other HTML. Having JSON transformed by JS as the only method is displaying data feels like the fundamental architectural error that is degrading the web for users.

All these years later, huge advances in compute and bandwidth, and in many ways that good 'ol 28.8k modem in a Penguin box was as responsive.


Both caching and json I’m referring to as coming from the backend, not going to the browser from the frontend. I’m saying you break out large data objects (from the backend) into multiple calls and then render them as they respond so you can then see which ones are slowest and should be cached (on the backend.) I get what you’re saying about loading screens for a few rows but I didn’t think that’s what we’re talking about.


It's like all of these posters have never worked on a large-scale app, acting like the decision to lazy load content is made just because we don't have anything better to do.


Sure, there's lot of code to write, but is the end goal writing code, or making a web app that's great for users?


Not sure I get what your comment is saying, but:

> making a web app that's great for users

That's what the goal is, and that's what SPAs enable. You can't build a modern web app without it being a SPA. The two are basically synonymous, I don't understand how there is even a discussion around this. No user wants to navigate to another page and lose their context. That's why the industry moved to SPAs. If you ever tried to manage complex UI state in the jQuery/Backbone/Knockout/etc days you would see that a React SPA is a huge improvement. It actually enables devs to build complex apps without getting bogged down in bugs.


> The two are basically synonymous, I don't understand how there is even a discussion around this.

This erroneous belief is the very source of the problem. Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables.

I have never, literally never, thought that a good experience came from a SPA. Give me HN and it's 2000s dead simple tech any day. Or compare the absolute shit-show of new Reddit in an SPA to old Reddit.

Managing complex UI state is the problem.


As a counter point: were I to write a hacker news clone it would be an SPA. You wouldn’t know from using it, because I’d break it down into routes using e.g. react router (but that’s really just for organizational reasons) and it’s simple HTML and plain text so there’s really no need to have loading screens. An SPA doesn’t have to be bloated and show loading screens and the aforementioned grey boxes.

I’ll also add that Reddit’s problem doesn’t stem from being an SPA, it still loads state, etc from url navigation just as much as it keeps the state as you browse (depending on where you go on the site.) Reddit’s problems stem from (for some reason I can’t fathom) being the worst UI implementation I’ve had the displeasure of using recently and constantly adding features (before bugs from the last round of useless features are fixed) in an effort to converge towards some kind of weird Facebook clone.


> Here's a user, telling you that I'm sick of lag from weird multistage loads in apps that gain nothing from keeping local state in browser JavaScript variables.

You do realize the alternative is the same amount (or more) of waiting with a blank screen, right?

> Or compare the absolute shit-show of new Reddit in an SPA to old Reddit.

You are conflating bad design / UX with SPAs. You can build a SPA that is exactly the same as the old Reddit. Reddit is trying to monetize their site, many of their shitty UX decisions are done with that goal in mind.

> Managing complex UI state is the problem.

...What? Unless you are talking about stripping web apps of their functionality, you can't avoid this. You will have complex UI state. It's just a question of whether you use some shitty, convoluted approach of the olden days, or you use a modern solution that makes this faster and easier.

Anyways, you do realize you are in the minority, right? Most users have an expectation of how modern web apps should function. Redirecting a user for simple tasks doesn't cut it. If SPAs didn't provide a better experience, and in turn, better conversions, companies would not adopt them.


    > You are conflating bad design / UX with SPAs. 
Not really. Bad UX is what is really synonymous with SPAs.


A wildly erroneous assertion, and one that is backed up with zero facts on your part.


Oh la ..

>> You can't build a modern web app without it being a SPA.

Lots of people can

>> I don't understand how there is even a discussion around this.

This is the difference that makes the difference


> lots of people can

Let’s see some links.


It's funny. A few years ago I proposed myself to make a list of nicely working SPAs. So far, this is my list:

1. twitter.com

That's it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: