854 karma · joined May 20, 2013
Next I’m working on making reviewing large AI-generated PRs easier, but haven’t gotten there yet.
> We will not fare any better than Ukraine relying on tech like this.
Ukraine is faring amazing well, aren’t they?
Russia controls a fraction of the territory, has suffered a million casualties, and lost many many armored vehicles and combat aircraft.
Don’t use or pay for any AI features. But it’s really nice having a terminal with multi-cursor and keyboard shortcuts like an editor.
I still like using Next, though. Some nitpicks:
> Elements that could change need to be inside a client component, but data fetching cannot happen on the client components, even during SSR on the backend. This results in awkwardly small server components that only do data fetching and then have a client component that contains a mostly-static version of the page
That's one way to do it.
I like flipping it, though - most of the page is a server component, with awkwardly small client components that sprinkle in just enough JS for things that need interactivity (such as optimistic updates from the above quote).
> Since the App Router starts every page as a server component, with (ideally) small areas of interactivity, a navigation to a new page has to fetch the Next.js server, regardless of what data the client already has available!
This is true, and something that Remix v1/v2 did a lot better than Next.
It's because, as ugly as a long line of inline classes can be, it's easy to know exactly what styles are being applied to an element. Especially when there are more than 1 or 2 devs writing styles.
I can hear Sean Carrol saying, though, that:
1. We know general relativity isn’t complete, because it doesn’t take quantum mechanics into account.
2. We can’t say whether this is right because we don’t know the quantum theory of gravity.
But I don’t actually know what I’m talking about.
Now my read is they’re rebooting the Remix name to go their own way on the framework.
As a current Next and prior Remix dev, my rec is both are good in their own way. I wouldn’t hesitate to use react-router if it’s what you want to do.
In any case, I find it a nice article. Will it change how I write code? Maybe, maybe not. But it will change how I review code and talk about abstraction.
As far as I can tell, React let's you write HTML in both the right and wrong ways, like all frameworks (including plain JS).
Maybe it seems like React is worse in terms of HTML because of how popular it is? There are more users of it, so more potential examples of bad HTML?
My only quibble is that it’s certainly possible to choose React (or any popular solution to a problem) without considering other options too much, and still care about craft.
Obviously others will have different experiences than me.
Point is, you can find crime and bad things in any city. San Francisco has work to do, but isn't the hell-hole people or the news make it out to be.
Both choices are reasonable ones to make. Flow has some really cool stuff, and works great for a lot of people.
There’s no denying, though, that there’s TS has done something right (even if you personally dislike it)
What I should've said: GraphQL isn't the only option for type safety and preventing over fetching. There's a nice REST pattern which Remix happens to do.
What I meant (and probably poorly communicated) is that you don't necessarily need GraphQL and its challenges to get type safety and prevent overfetching. There's a nice REST pattern that can do that, which happens to be what Remxi uses.
My thinking here was kind of half-baked.
Thinking through it some more: - Maybe it's more that I've seen teams reach for GraphQL when another option would've been simpler. - You can get many of GraphQL's benefits with other, simpler solutions. - But when you do need GraphQL, of course go for that.
Maybe thinking through what I was thinking a bit more:
GraphQL isn't the only option for preventing overfetching, and has some downsides. For example, the pattern Remix uses.
GraphQL from a Remix loader is doable. Works great if you have an existing GraphQL you want to consume.
If you don't, though, I prefer avoiding the extra HTTP request.