Great idea with the static JSON file. Also I like the filtering is nice and zippy because it's all happening client-side (according to lack of activity in my network tab).
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.
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.
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
No matter how much people want to proclaim RSS is "dead" there is actually no way to kill it. It is decentralized. No one owns it. If we keep publishing RSS feeds, it still lives.
Its death can be from sites deciding it’s no longer worth supporting, when they do a redesign. I can see this happening if a bunch of young front end devs are put in change of the full redesign.
I’m currently on a project where the front end has all the control and none of them seem to know anything about computers or tech in general. It seems like they all went to an 8 week boot camp and got a job. It has been very frustrating.
On behalf of front-end devs, I'm sorry. I'm not an amazing FE dev, cut my teeth on Rails projects and weird PHP, but the lack of simple thinking in the frontend world hurts my soul. I need to switch...
I’m sure there are FE devs who aren’t like this, it’s just been my experience over the last 3 years. I don’t mean to be disparaging, I’m just frustrated.
To add to the issues, the FE team has a dedicated QA team, we don’t have any QA for the backend, we just need to do it ourselves. But the QA team doesn’t know what they are even looking at (they’ve never spoken to us). They make sure the UI does UI things, but don’t understand the goal of what it should accomplish, so we (the backend devs) end up needing to do a significant amount of the FE QA, as what they are looking to release is just bad.
No, don't apologize, you're right. Frontend should be a junior's intro to backend, and I will advocate for this forever. Senior FE devs should be the competent ones who really like FE.
These days there are too many information published as newsletter and will require some tools to reverse publish it as RSS. RSS is not dead, but half way there sadly.
The JS ecosystem of 2024 does not represent what's on the web right now. What is out there is by-and-large codebases that were started in the mid 2010s. Sure, frameworks have been doing a great job correcting mistakes over the past couple years, but the JS-heavy junk of the 2010s is still largely out there ruining access for folks.
>Many websites advertise deals on laptops that seemingly have good specs for a great price, but buyer beware on these products: it might not be the deal you think it is. The build quality on many of these machines is subpar, if not outright awful. Bad hinges, plastic casing, and cheap components mean there is a good chance these machines were designed to fail - right after that 1 year warranty expires, of course.
I have called this the enshittification of consumer products. It's not just computers, it's everything
