Yea man this benchmark is really really bad.

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.

Yea, that's why engineers are still very important for now (until models can do this type of longer term designs and stick to them).

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.

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.

Maybe someone should use AI to write the code for that...

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.

So they're talking about this becoming an issue when chunking TBs of data (I assume), not your 1kb random string...

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...

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?

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.

There is so much bullshit out there about how kids should be taught to read, and too many schools unfortunately still use wrong methods disproven by science.

What works is phonics, old, tried and true. If your school isn't teaching it, you need to do it yourself at home or your kids risk never being good readers.