Not a subway rider, and I hate another form of lazy loading: webstore filters. You go to buypc.com, pc parts / ram, check 16GB box, it starts loading. Later you check 8GB (it starts loading), uncheck 16GB, it starts loading again, check “2x kits”. As you may have guessed already, it starts loading. You see the page and want to scroll it, but the second load finishes and the content changes. Then the third. If you want to filter a list by a handful of parameters, there will be almost the same amount of loads and re-renders, all insanely latent. A cherry on top - every time you check a box, load completion routine scrolls the page back to the top, so you miss a couple of clicks and check wrong checkboxes.
The irony is that a full category list in json format that could be instantly filtered at the client side would be smaller in size than a couple of jpegs they serve with each product card. And that would make their servers rpm literally an order of magnitude less.
Not OP, but I think the beef is that the act of applying a filter requires a reload of anything at all ("hey, server, please send me the list of only 16GB pairs this time"), when it's perfectly possible to just send the full list of items to the client initially and then have filtering apply instantly, client-side, on that already loaded list.
At least that's the beef I have, and was reminded of when reading the parent comment.
Rather than sending the full dataset (which could be fine if it's small), just do serverside filtering. And rendering for the most part.
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.
But it isn’t huge. I just checked how much data my local pc store fetches for the first page of RAM, 18 items total. It does too much ajax-in-json bs to estimate, but let’s assume each product uses 500 bytes, which is more than reasonable. It’s roughly 9kb total. The first RAM image on that page is 8kb. So the pictures on that page alone are roughly 18x bigger than that json. That means if there’s 18 pages of RAM, and there was 35 actually, the whole json is as big as one-two pages. Iow, unless a user changes just one filter and then buys immediately, it’s more effective.
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.
I've had a similar conversation with my lead before and my understanding is the web application does not reach out to the database server for search results. We query the elastic index instead where possible. Now I don't know much about elastic but my local development can take as much as 16GB RAM just for elastic.
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?
The reason that you store memory capacity for a power bank (and an adjustable chair) is because the alternative is storing entity value attributes in a joined table. Each approach has drawbacks and advantages, I'll use either of the two depending on the application.
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.
Also not OP but yes... like how many bytes are saved here vs just getting the whole list vs how many bytes of js-bloat have been initially loaded vs user experience.. often very much out of any reasonable proportion providing nil value.
Yeah. Also IMO the annoyance isn't really necessarily related to bytes transferred. It's other things that make that reload just really annoying when it happens. Bad UX
Why is it insanity? Web sites have no problem sending megabytes of largely worthless data and code as a matter of course anyway. Why can't some of it be useful?
I just don’t get it. There’s nothing that could beat an one-time json download per product category. Not even “apply filters”, which I see less and less often with years. Unless a store has thousands of products and vague categories, ofc (but not in my cases).
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.
A large reason why virtually all modern web stores suck as much as they do is the insane amount of bot bullshit they need to deal with.
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.
Not to defend the practice but I think the intent is to allow scraping (or API access) only by the price comparison site but not by competitors. (Why wouldn't the competitors then just scrape the price comparison site? Because that site also has anti-scraping measures in place...)
The irony is that a full category list in json format that could be instantly filtered at the client side would be smaller in size than a couple of jpegs they serve with each product card. And that would make their servers rpm literally an order of magnitude less.