If I understand correctly your beef is with the fact that they don’t have an “Apply filters” button and not lazy loading?
Also they’re probably not trying to save bandwidth but database servers.
Also they’re probably not trying to save bandwidth but database servers.
At least that's the beef I have, and was reminded of when reading the parent comment.
You'd think it shouldn't be possible. I have fewer than three thousand styles and fewer than thirty thousand style plus color options but strange legacy ERP decisions mean you have weird "data points" like memory capacity of zero for a power bank. Well, duh. It is a power bank. Why do we need to store data for it to say it's memory capacity is zero?
However, I hope that you weren't really storing the integer 0 for the memory capacity of a power bank. It should be null. Most databases handle such sparse matrices very well, it really is not an issue.
It drives me nuts how much completely useless JS is written. 90% or more of web apps could easily be serverside rendered with maybe a few small scripts added.
Instead we have this shit, people writing hundreds or even thousands of lines of JS to make this dumb ass auto-refreshing search/filter page whose only purpose is to make a bunch of pointless requests and computation while I'm in the process of building my query.
Just have the filters be a form and the search button submits it. The backend executes the query, builds the page and returns it. Easy peasy, no pointless requests, no sending megabytes of pointless data in response to every request. No complex JS(which by the way is an absolute shit-tier language for anything beyond 100 LOC) logic.
I may be biased due to my personal experience, personally I find that the vast majority of JS I'm forced to deal with shouldn't exist. It's either a result of bad application design, bad API design, JS that just does things html and CSS do better, or dumb ass requirements like "we need this filter page to update the results every time the user does anything". No you don't, you just need a way to build a query and a way to submit it. And paginate it.
"But page loads take too long that's why we use SPAs" they take too long because you're sending megabytes of pointless JS that shouldn't exist. Remove the JS and they're fast. Plus SPAs are frequently slow as shit anyway, because most web developers just kind of suck and write shitty code. Like sending a huge Json document with every request rather than handling it in the backend.
As a consumer, this all feels like being between two fires. One side creates the stupidest UX possible, where one change can fix that, while the other side claims it’s all bs anyway and we must go medieval. Can’t we just listen to a user for once?
> sending the full dataset (*which could be fine if it's small*)
In the specific case of search/filter pages, I prefer the server-side rendered experience as a user. If I want to just check the box for RAM and search instantly, I can do that. But if I want to build a more complex query I don't need it to keep updating over and over.
I don't necessarily hate the auto-updating pages if they are implemented well. I just don't think they're any better, so why waste dev hours on it? It costs money to maintain that code, and the more of these pointless little JS applications you bake into your website the more expensive it is to build and maintain.
If there is something beyond Hanlons Razor, I’d like to understand by which metric it works and how. E.g. how fetching 30 rows 10 times through different params compares to fetching 200-300 rows once, assuming various sorts of caching, etc. If everyone does it, it’s either a common methodic or a common ui-fad incompetence. But then even a shallow search should yield at least some results. It doesn’t.
Most storefronts are designed more or less as an obstacle course to make any sort of scraping or automated retrieval more obvious, this includes having beyond useless filters, having no working search function, having nebulous item names, paginating with 4 items at a time, etc.