I'd prefer that to page reloads, lost focus, scroll position and any input between clicking on a checkbox and receiving a response. Bonus points if I only have to download a db-diff next time, compared to downloading 5x db worth through POST /get-products?<filters>&page=<n> in every e-shopping session. Rarely a client-facing business database exceeds your average youtube cat video in size (assuming pics stored as urls).

What year was this comment written ?

Most web apps these days are single page applications which don't require page reloads for every UI interaction.

True. Only the fast ones do full page reloads now.

Sadly the current one. Most web apps that have a backend database do all of the aforementioned. See e.g. https://amazon.com

Also,

https://www.ebay.com/b/Digital-Cameras/31388/bn_779 -- try choosing a brand

https://www.bestbuy.com/site/video-games/video-games-accesso... -- only loses scroll, probably a winner

https://www.newegg.com/p/pl?N=50001157%20100007671%206013930... -- uses "Apply" button, out of competition, but still better

https://www.levi.com/US/en_US/sale/mens-sale/c/levi_clothing... -- a winner of the "wtf is going on after I click my size" category

Ten years ago your concern might be valid but in 2024, given that most people in the developed economies have ample amount of 4g/5g data plans with generous RAM/storage on their mobile phones, it makes more sense to just send them the whole DB once.

This is the same spirit as Electron vs native. Of course native uses less ram and is efficient but its not noticeable by the end user (because they dont care how its built). So we let developers write desktop apps in HTML/JS and end users do not notice usually until they open up task manager

We have abundance of data, memory, storage that continually drops in cost. It makes a lot of sense to simply download the DB once and then access it locally with optional syncing.

This is the future because we can't count on mobile phones to continuously maintain connectivity especially with limited data plans. Far better to simply allocate % of your fixed data plan and decide which local first app to install on your phone.

I live in a 4g/5g country (with 5g disabled on my phone because it seems to perform worse than 4g), with a 2gb/month data plan. I've usually stayed inside my data budget, but I'm cutting it a little close this month and I've blown past it a couple of times when I've forgotten to switch back to wifi. Sure, I live in a country where I can buy infinite data, but I don't see the point when I rarely use more than 2gb, and a 2gb plan is cheaper

I think their tool is designed for working professionals on laptops - seems like analysts doing traditional business insights reporting. Perhaps there's a world where that target audience is using their phones, but I doubt it's a use case they're too concerned with.

I would be worried about this approach for something that doesn't need to expose a SQL interface though! It's not the right fit for most webapps.

If it’s an app you use regularly that trade off could easily be worth it.

If it's an app, you're not in the browser anymore anyway, so you don have to worry about this browser wasm. You can store data locally anyway and don't have to pull it from the sever

> If it's an app, you're not in the browser anymore anyway

Webapps would beg to differ

Also all the code and data can be easily cached with e.g. Service Workers, so it will be downloaded only once.