[pcloadletter_]

The "zippy" client stuff comes at a cost: my browser has to download ~150kb of javascript to make this website work. Not as bloated as many sites but more JS than is truly needed for this sort of thing. Likely framework bloat.

Edit: I should say of course you can have zippy client-side stuff without the bloat (for example: just filter the JSON object and update the DOM yourself without a framework!). So it doesn't _really_ come at a cost, just typically the most expedient way a reactive UI is put together uses a framework like React.

[jotaen]

150K worth of JS doesn’t seem too bad in my eyes, considering the level of interactivity here (not just for the filtering, but also for the input dialog). Almost half of the 150K is actual data, which is embedded into the JS file directly.

To put things into perspective: the preview images are around 20–60K each, so if you scroll the entire list, you end up downloading ~5M. If at all, this is where I’d start to look at in terms of optimising bandwidth.

[pcloadletter_]

I did not realize half the payload was the data itself!

[misterrpink]

yea this will become a problem at scale but nothing that can't be fixed

[misterrpink]

Wait I don't see a payload coming in on page load. OP might just have hardcoded json objects into client side

[bazil376]

This is kind of correct, but hardcoded sounds a bit worse than it actually is. Basically a cron job updates the JSON file and injects it as a JS object into the bundle