3 ms·

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

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?

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?