ahuth

https://prismstudio.dev. A GitHub and GitLab PR inbox and review UI. Built it to help me tame GitHub notification fatigue and see which PRs really need my attention.

Next I’m working on making reviewing large AI-generated PRs easier, but haven’t gotten there yet.

Warp, although it’s not open source.

Thanks for posting. It is heart warming/breaking to watch.

Probably right. But,

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.

Unlike many comments here, I love Warp.

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.

Good write up, and the author certainly seems to really know their stuff.

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.

Probably referring to the collaboration tools. Zed has a bunch of stuff around remote pair programming with people.

Can't agree that Tailwind is popular because it forces you to setup a centralized config file (although I guess that is nice).

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.

Cool article!

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.

Could be. Although people sometimes accuse my own blog posts of being AI-generated (they're not, just my shitting writing).

What was Remix got merged into react-router, since Remix eventually was mostly a wrapper around RR + a server.

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.

Jekyll is fine. So is React. And Astro. Some folks like different things than others.

What did React ever do to you?

That's one of the points of the article

Obviously this TypeScript one: https://huth.me/conway4/

I don't know. Sure, examples could be nice. But an article can be imperfect and still be interesting or useful. Also, it's easy to say come up with examples, but I find it hard sometimes.

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.

You're right that there's certainly bad HTML produced by React apps out there. But there's good HTML, too!

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?

This is a very underrated comment.

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.

As I said, everyone's experience has been different. Sorry you've had a bad experience in SF. This just hasn't been my experience (no gaslighting involved...)

SF certainly has its challenges. But in my 9 years of working in the financial district I never saw something like this.

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.

What bad coding practices does TS allow, and why are they bad?

TS made the choice to be “just JS” + types, and lean into JS-isms.

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)

Yep, this was mostly a random thought.

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.

Definitely an apple to oranges comparison.

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.

touché

Good point.

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.

Hey, nice connection to conway's law! I didn't think about that.

True!

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.

Nope, I wrote it myself (although maybe poorly!).

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.

That's pretty sweet. Nice job!