Auth Has Been 'Solved' Five Times. It Keeps Getting Solved Again.

Authentication has been solved more times than almost any problem in web development.

I've implemented auth with Passport.js, Devise, JWT rolled by hand (don't do this), NextAuth, Auth0, Clerk, and Supabase Auth. Each of these was, at the time I reached for it, the obvious solution for my constraints. Each of them also had specific failure modes that I discovered after committing to them.

The pattern is consistent: auth libraries solve the constraints that existed when they were designed. When the constraints change, the gap opens again.

Better Auth from better-auth/skills — 43.3K installs — is the latest entrant in this cycle. The interesting question isn't whether it's better than what came before. It's what constraints it's solving that previous solutions didn't cover.

What Previous Solutions Missed

NextAuth solved the problem of adding social login to a Next.js app quickly. It's excellent at that. It's less excellent when you need it to work in a non-Next.js context, or when you need fine-grained session management, or when you want to understand and own the code running your auth layer.

Auth0 and Clerk solved the problem of outsourcing auth complexity. You pay them, they handle it, you don't think about it. That works until you have a compliance requirement that their data handling doesn't satisfy, or until their pricing scales with your user count in a way that's painful, or until you need to move off for reasons that are hard to anticipate at the start.

Supabase Auth solved the problem of auth for apps already built on Supabase. It integrates cleanly with the Supabase ecosystem and almost nowhere else.

Better Auth's pitch is different: framework-agnostic, TypeScript-first, self-hostable, with the full implementation visible and modifiable. The constraints it's optimizing for — developer ownership, TypeScript type safety end-to-end, no vendor dependency, no per-user pricing — weren't the primary design goals of any of those previous solutions.

The Framework-Agnostic Constraint

This one matters more than it might seem.

The JavaScript ecosystem has fragmented significantly in the last three years. The "obvious" choice of Next.js has been joined by SvelteKit, Astro, Remix, Nuxt, Qwik, and a handful of others that all have real communities. NextAuth works well in its native environment. Outside Next.js, there are wrappers and adapters that work to varying degrees.

Framework-agnostic auth means the same implementation, the same mental model, and the same TypeScript types regardless of which framework you're using. For teams maintaining multiple apps or migrating between frameworks, that consistency has compound value. You don't relearn auth every time you start a new project.

43K installs in a short window suggests this constraint is real and widespread — enough developers hit the framework-specific friction point to generate meaningful demand for a solution that doesn't have it.

The TypeScript-First Distinction

There's a meaningful difference between "supports TypeScript" and "TypeScript-first."

"Supports TypeScript" means types are available, usually via a @types/ package maintained separately from the library. The types may lag behind the implementation. Edge cases may not be typed. The runtime behavior and the types can diverge.

"TypeScript-first" means the types are part of the design. The session object type is inferred from your configuration. Adding a custom field to the session is reflected in the types automatically. The compiler catches auth errors at build time rather than at runtime.

For developers building serious TypeScript applications, this distinction is not cosmetic. Auth errors that surface at runtime in production are expensive. Auth errors that surface at compile time are free. Better Auth's TypeScript-first design moves that boundary.

What the Auth Market Is Actually Telling Us

The recurring pattern of auth solutions isn't a sign that the problem is fundamentally hard in some irreducible way.

It's a sign that the developer constraints around auth keep changing — with frameworks, compliance requirements, pricing models, performance requirements, and the degree of ownership developers want over their auth implementation.

Each new auth solution isn't replacing its predecessors because the predecessors were badly made. It's appearing because the space of valid constraints has expanded, and a new combination of constraints wasn't addressed.

The honest takeaway from 43K installs isn't "Better Auth is the final solution." It's that the auth market is growing to reflect a more diverse ecosystem of projects and developer preferences. There will probably be another entrant in two years with slightly different constraints again.

The question to ask when evaluating auth isn't "which one is best" — it's "which one was designed for the constraints I actually have."

---

Part of the Better Auth skill — framework-agnostic, TypeScript-first authentication built to be owned.