The only requirement is curiosity. There's no "do this" with these tools. You have to learn them through constant experimentation.

The docs situation continues to be hilarious and bad, for the gem they have created.

It's the unfortunate situation where those who know, know, and those who do not, blasphemy the whole thing based on misunderstanding.

Super unfortunate, which could be solved by simply moving a little money over to Relay's docs, and working on some marketing materials.

Exactly! Once its working, it can be very healthy. And especially on the client. For a very, very, very long time. We started using GraphQL at the very beginning, back in 2015, and the way it has scaled over time -- across backend and frontend -- has worked amazingly well. Going on 10 years now and no slowing down.

We haven't been using it as long but it's definitely saved us from things that were "impossible" to associate in our microservice backend.

Love this so much! Coming from a Relay background I am happy to see its incredibly resilient and futuristic ideas start to spread outside of the GraphQL domain.

GraphQL FTW

Yes, exactly. In many cases you don't exactly need to involve the whole group but without a decider things stall out. And suddenly getting a decision about something looks like "collaboration", and gets struck down by the great confusion which is this authors take. It's a lack of decision making, simply put.

Articles like this are quite poisonous, because they take language and mutate it for purposes that aren't quite sincere, and then next thing you know something necessary and good is worthless.

Same - the leverage in using this tech is unbelievable for those who have a lot of experience. Folks are in denial.

Its easy to create a toy, but much harder to make something right! Like anything, so much weird polish stuff creeps in at the 90% mark.

> so much weird polish stuff creeps in at the 90% mark.

That is where the human in the loop needs to focus on for now :)

Our experience entirely. We replaced next.js with a simple router and everything in every sense got simpler, and FASTER. It was a remarkable education, replacing that crazy thing.

yeah RSC is totally unnecessary it turns out

It's a good idea in theory, the perf just needs to be better. Maybe with bun.

Bun unfortunately isn’t production ready for years for any serious application. Too many security problems.

Really? Do you have links to any good analysis on this?

I'd be shocked, given that the bun team has shown a ton of maturity in all their messaging as far as API compatibility, engineering chops, and attention to detail. Nothing I've seen suggests that they'd be sloppy on the security side.

The issue list is full of bugs with segfaults. At least used to be when I last time checked it. But that is what you get with C/C++/Zig et all. It takes a lot of time to get good enough fuzzing and testing process to eliminate all that. In Chrome, for example, you could get $20,000 bounty just for demonstration of memory issue without an actual exploit.

"1 more step function in performance bro, V8 was cool but just 1 more and we'll have enough to make CRUD apps in JS, bro I promise"

Or you can use React Query/Tanstack Query, not waste cycles and bandwidth on RSC, get an app with better UX (http://ilovessr.com), and a simpler mental model that's easier to maintain.

Yeah Vite+Reat+Tanstack SPA apps is definitely the way to go for a majority of web apps. I would still stick with nextjs for ecommerce or pages that need to load instantly when clicked from google however.

It was pretty clear from the beginning it wasn't necessary. It's funny how many junior developers will rant about how you must avoid shipping unnecessary code to the client all costs or you will die. Well, actually, I've been building React apps for over 10 years without any of this RSC shit and those apps made many millions of dollars, so it's actually not a problem.

We ship a multi megabyte package to our customers and preload massive amounts of data.

Nobody complains about it. In fact, they rave about how fast it is. They don’t care that the first page load is slow. Heck, they’re probably checked out between tasks anyways. But, once they’re in there, they want it to be fast.

This is entirely context dependent. Do that on a blog platform and you end up with blogspot.com infinite loading spinners.

Same. Our massive SPA app is so fast, SSR rendered and not even streaming, with great CWV scores, and -- omg -- even uses CSS-in-JS! All of this perf stuff is a f'ing lie. I'll never get over how they murdered that beautiful DX abstraction with FUD.

Yes forgot to also mention the CSS-in-JS! But these days apparently it will crawl your site to a halt and make your app unusable... funny, that

Everything was so hard. Everything! Backbone was kinda fun to write though, I'll admit. But not fun at scale to manage.