This has been a non issue when using proper routing libraries that push history entries on the stack properly and render routes from the top of the component tree down.
You hate BAD react SPAs that break the fundamentals of how the web works. Good ones take care to not do that.
React fundamentally doesn't cause this issue either. You can use a different framework than react or even vanilla JS and still produce the same bugs.
This is such copium for AI haters. I stopped working almost any single line of code at the beginning of this year and I've shipped 3 production projects that would have taken months or years to build by hand in a matter of days.
Except none of them are open source so they don't show up in this article's metrics.
But it's fine. Keep your head in the sand. It doesn't change the once in a lifetime shift we are currently experiencing.
With my kids we did Le Robot from hugging face over the Christmas break, it was a fun project to put together the kit and get the follower arm to follow the leader. You can also train ML models with it etc https://huggingface.co/docs/lerobot/en/so101
Its top 100 or so subreddits are moderated by the same ~10 or so individuals who impose their ideological views on the subs and delete posts or ban anyone who dares challenge them.
A great example of how community moderation inevitably slides a platform to one side or the other of the political spectrum.
I honestly don't think mods on reddit should be allowed to moderate more than 1 or 2 of these top sub-reddits, this would at least force some semblance of diversity of thought on the platform.
I've been thinking about this and using Rust for my next backend. I think we still lack a true "all in one" web "batteries included" framework like Django or RoR for Rust.
Maybe someone should use AI to write the code for that...
Sugar free coke is not as bad as sugar-ful Coke but it's still bad. Many of the cheap sweeteners have been linked to cancer. They still fuck with the brain and hormones and make you want salty foods and/or more sweet tasting things.
So yea, how about drinking water as your primary source of hydration?
If you are poor, the last thing you need is Diabetes, Cancer, Hypertension, Cardiovascular disease, etc.
The problem also is there is a huge amount of fraud with SNAP with people claiming benefits for multiple people and then reselling their SNAP cards to just make cash. The people buying the endless cases of Mountain Dew often have just bought a 50% discounted SNAP card off some other person who isn't starving at all.
I worked on an internal tools team for a few years and we empowered engineers to fix user issues and do user support on internal support groups directly.
We also had PMs who helped drive long term vision and strategy who were also actively engaging directly with users.
We had a "User Research" team whose job it was to compile surveys and get broader trends, do user studies that went deep into specific areas (engineers were always invited to attend live and ask users more questions or watch raw recordings, or they could just consume the end reports).
Everyone was a team working together towards the same goal of making these tools the best for our internal audience.
It wasn't perfect and it always broke down when people wanted to become gatekeepers or this or that, or were vying for control or power over our teams or product. Thankfully our leadership over the long term tended to weed those folks out and get rid of them one way or another, so we've had a decent core group of mid-level and senior eng who have stuck around as a result for a good 3 years (a long time to keep a core group engaged and retained working on the same thing), which is great for having good institutional knowledge about how everything works...
So are photos that are edited via Photoshop not art? Are they not art if they were taken on a digital camera? What about electronic music?
You could argue all these things are not art because they used technology, just like AI music or images... no? Where does the spectrum of "true art" begin and end?
GraphQL was created to solve many different problems, not just overfetching.
These problemes at the time generally were:
1) Overfetching (yes) from the client from monolithic REST APIs, where you get the full response payload or nothing, even when you only want one field
2) The ability to define what to fetch from the CLIENT side, which is arguably much better since the client knows what it needs, the server does not until a client is actually implemented (so hard to fix with REST unless you hand-craft and manually update every single REST endpoint for every tiny feature in your app). As mobile devs were often enough not the same as backend devs at the time GraphQL was created, it made sense to empower frontend devs to define what to fetch themselves in the frontend code.
3) At the time GraphQL was invented, there was a hard pivot to NoSQL backends. A NoSQL backend typically represents things as Objects with edges between objects, not as tabular data. If your frontend language (JSON) is an object-with-nested-objects or objects-with-edges-between-objects, but your backend is tables-with-rows, there is a mismatch and a potentially expensive (at Facebook's scale) translation on the server side between the two. Modeling directly as Objects w/ relationships on the server side enables you to optimize for fetching from a NoSQL backend better.
4) GraphQL's edges/connections system (which I guess technically really belongs to Relay which optimizes really well for it) was built for infinitely-scrolling feed-style social media apps, because that's what it was optimized for (Facebook's original rewrite of their mobile apps from HTML5 to native iOS/Android coincided with the adoption of GraphQL for data fetching). Designing this type of API well is actually a hard problem and GraphQL nails it for infinitely scrolling feeds really well.
If you need traditional pagination (where you know the total row count and you want to paginate one page at a time) it's actually really annoying to use (and you should roll your own field definitions that take in page size and page number directly), but that's because it wasn't built for that.
5) The fragment system lets every UI component builder specify their own data needs, which can be merged together as one top-level query. This was important when you have hundreds of devs each making their own Facebook feed component types but you still want to ensure the app only fetches what it needs (in this regard Relay with its code generation is the best, Apollo is far behind)
There's many other optimizations we did on top of GraphQL such as sending the server query IDs instead of the full query body, etc, that really only mattered for low-end mobile network situations etc.
GraphQL is still an amazing example of good product infra API design. Its core API has hardly changed since day 1 and it is able to power pretty much any type of app.
The problems aren't with GraphQL, it's with your server infra serving GraphQL, which outside of Facebook/Meta I have yet to see anyone nail really well.
Yea man this benchmark is really really bad.