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

AI makes it easy to generate a lot of code and PRs, so Prism makes it easy to track which PRs needs your attention. Eventually I'd like to make a great code review UI as part of this, too, but baby steps.

Free while in beta. Give it a shot, and let me know what you think.

Comments URL: https://news.ycombinator.com/item?id=47806464

Points: 1

# Comments: 0

Give it a try, it's completely free right now.

Concept - make it easy to share updates, and let clients see them without any friction (no signup required for clients). Clients can also react with emoji and comment.

Goals - my day job is making web apps, but I've never shipped a product on my own. With this I wanted to create something that I could actually build, ship, and support end-to-end. So it is pretty simple (maybe too simple?).

Tech stack - NextJS... don't hate me. Next has an annoying amount of magic, but I really like using it. Let's me use React to generate plain HTML, and sprinkle in client-side JS for interactive bits. - Sqlite / Turso. Local dev without needing docker is really nice. - WorkOS authkit, instead of rolling my own auth. - Polar for billing, although billing isn't currently active.

Challenges - The classic problem of getting people to try it out. - Building something completely end-to-end was new for me. For example, setting up the webhooks and coordinating auth and billing isn't hard, but took a bit of thought. - I can't design.

Learnings - Maybe don't even build in billing, or possibly even auth, until people are trying it out.

Comments URL: https://news.ycombinator.com/item?id=46704671

Points: 2

# Comments: 0

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