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

Points: 1

# Comments: 0

I’m Bereket, founder of Better Auth. Our team spends a huge amount of time on GitHub every day. Like anyone who’s spent enough time there, I’ve always wished for a much better GitHub experience.

I’ve asked a lot of people to do something about it, but it seems like no one is really tackling GitHub directly.

A couple of weeks ago, I saw a tweet from Mitchell (HashiCorp) complaining about the repo main page. That became the trigger. I decided to start hacking on a prototype to see how far I could push an alternative interface using GitHub’s APIs.

Within a week, I genuinely started using it as my default, same with the rest of our team. After fixing a few rough edges, I decided to put it out there.

A few things we’re trying to achieve:

- UI/UX rethink* – A redesigned repo home, PR review flow, and overview pages focused on signal over noise. Faster navigation and clearer structure.

- Keyboard-first workflow: ⌘K-driven command center, ⌘/ for global search, ⌘I opens “Ghost,” an AI assistant, and more.

- Better AI integration: Context-aware AI that understands the repo, the PR you’re viewing, and the diff you’re looking at.

- New concepts: Prompt Requests, self-healing CI, auto-merge with automatic conflict resolution, etc.

It’s a simple Next.js server talking to the GitHub API, with heavy caching and local state management.

We’re considering optional git hosting (in collaboration with teams building alternative backends), but for now, the experiment is: how much can we improve without replacing GitHub

This is ambitious and very early. The goal is to explore what a more modern code collaboration experience could look like, and make it something we can all collaborate on.

I’d love your feedback on what you think should be improved about GitHub overall.

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

Points: 38

# Comments: 48

A couple of weeks ago, I started hacking on a project to improve GitHub, mostly because I was tired of the current experience (like many others) and no one seemed to be doing much about it.

It’s still very early and pretty ambitious, but I hope you like it. It’s open source as well.

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

Points: 11

# Comments: 3

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

Points: 3

# Comments: 0

We started Better Auth with the vision of making high-quality auth (with simple abstractions, great docs, extensive set of features...) and make it accessible to everyone . It didn’t start as a commercial venture, at first it was a purely oss project I created. The reason it evolved into a commercial venture is that we saw new ways to make owning your auth even more accessible and scalable for companies.

The reason we’re bringing Auth.js under Better Auth is that the Auth.js team is moving on, and we don’t want the project to be abandoned, that would hurt trust in open-source auth as a whole. We’ve already seen that happen at smaller scaller with Lucia. If that weren’t the case, we’d actually benefit from Auth.js being deprecated, since we’re effectively the next most people would go for and we wouldn't have to take this risk and responsibilities.

No, and actually if you really really wanna override the core database calls, we have a way to do so. You just need to write a hook or custom plugin to override the `internalAdapter`.

> Auth.js did everything we need regarding authentication

I don’t think this is true. Any sufficiently complex project has had to add a lot of customization and logic on top of NextAuth to make it even somewhat complete. I was one of those people, which is exactly why I started Better Auth.

> auth in JS is in a sorry state

That’s been the case long before we started Better Auth, it’s the reason we built it in the first place. I hope we’ll be able to change that narrative. But I think what we already have is something other ecosystems can only wish for. Some references:

- https://www.youtube.com/watch?v=dNY4FKXwTsM - https://www.reddit.com/r/golang/comments/1le9q65/is_there_a_...

There are already many companies with lots of users and revenue using Better Auth from simple auth setups to organizations, billing and what not.

If your question is more about whether we should allow database adapters to be written directly by developers (some people ask that) that’s just not realistic at the scale of what we handle. No one is realistically going to write hundreds of queries manually

2. The features we offer through plugins don’t exist in NextAuth, so that shouldn’t be a problem. You can use the core library for almost all of NextAuth’s features, and we provide most plugins first-party. Of course, you can choose not to use a plugin, write your own, copy and modify one, or only use the first-party ones we provide. We handle the database so you can own your auth without writing the logic yourself.

3. Auth.js hasn’t been actively maintained for a while. Our main reason for bringing it under Better Auth was to avoid a sudden deprecation, as that would directly harm the open-source auth ecosystem by eroding trust. Something we’ve already seen happen on a smaller scale with Lucia Auth.

2. Yeah, you’d need to migrate to Better Auth and move your user table to your main schema. We have a migration guide for Supabase.

3. It’s just additional features built on top of the framework, not a 3rd party auth service. You’ll still use the framework, and when you need those features, you can connect it to the infra to enable them.

- We don’t use JWTs directly, and sessions always require state (it’s not stateless). And yeah, both the client and server handles automatic session refresh.

- Yes, we support both multiple sessions or having different organizations open in different tab: https://www.better-auth.com/docs/plugins/multi-session

- Yes, that’s possible, you just need to set the `prompt` parameter to `select_account`