5 ms·

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 s

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.

RamRodification 3y ago
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.
- throwbadubadu 3y ago
  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.
  - RamRodification 3y ago
    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
- mcny 3y ago
  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?
  - dotancohen 3y ago
    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.
- zanellato19 3y ago
  Then the server send you 2k products every time because you might want one? This is insanity.
  - JohnFen 3y ago
    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?
    - sharlos201068 3y ago
      Because the application files are cached and aren't sent on every request.
- sfn42 3y ago
  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.
  - wruza 3y ago
    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?
wruza 3y ago
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.
- marginalia_nu 3y ago
  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.
  - wkat4242 3y ago
    Why stop bots though. Price comparison sites are amazingly useful.
    - marginalia_nu 3y ago
      Competitors use them to ever so slightly undercut your prices, get a higher position on said comparison sites, and run you out of business.
      - yunwal 3y ago
        If you aren’t on comparison sites at all because of your anti-scraping measures, is that better?
        3y ago

RamRodification 3y ago

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.

throwbadubadu 3y ago
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.
- RamRodification 3y ago
  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
mcny 3y ago
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?
- dotancohen 3y ago
  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.
zanellato19 3y ago
Then the server send you 2k products every time because you might want one? This is insanity.
- JohnFen 3y ago
  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?
  - sharlos201068 3y ago
    Because the application files are cached and aren't sent on every request.
sfn42 3y ago
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.
- wruza 3y ago
  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?

wruza 3y ago

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.

marginalia_nu 3y ago
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.
- wkat4242 3y ago
  Why stop bots though. Price comparison sites are amazingly useful.
  - marginalia_nu 3y ago
    Competitors use them to ever so slightly undercut your prices, get a higher position on said comparison sites, and run you out of business.
    - yunwal 3y ago
      If you aren’t on comparison sites at all because of your anti-scraping measures, is that better?
      - 3y ago