Live data from Hacker News

From Supabase to Clerk to Better Auth

blog.val.town

221–230 of 259 posts

Re: From Supabase to Clerk to Better Auth

#221
post #134

Earlier quoted context omitted.

Django, Rails etc handles this.

So... you just have to not build your web app in the most popular web app language? Somehow i think there will be big time debt from that decision

Those are both very popular languages for web backends, and both of those platforms are mature and robust.

Re: From Supabase to Clerk to Better Auth

#222

Earlier quoted context omitted.

I recently worked at a stupid startup where the entire logic of the app was basically delegated to several third-party services out there. It felt like an absolute piece of shit overall. Following the flow of things end-to-end was a nightmare. It was so stupid because the so-called co-founder PM at that company thought it would be cool to keep doing that. I am with you on this.

Thats because the goal of the start-up is to prove they have a viable business not build fancy tech.

At the same time, it also made things three times more complicated when it came to debugging. They found themselves swimming in the shit

Re: From Supabase to Clerk to Better Auth

#223
post #192

Earlier quoted context omitted.

I wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age. People not knowing what salt and pepper is... Vulnerabilities almost as if on purpose... Perhaps it is actually not THAT hard but just like error handling, people don't want to do the unsexy parts and want to delegate those tasks…

Your comment has a bit of an inexperienced smell. Business auth infinitely more complex than saving a user and salting/hashing his password. > There must be a behavioral pattern there... The pattern is that your comment is very far from reality.

My point is that people mess up things as basic as salt and pepper, or encryption at rest. People are not even trying...

If we deal with the intricacies of rbac, abac, acl mixed with scopes ,sso, saml, oidc, mfa, etc... I don't find these too conceptually, complex.

I mean, it should be avoidable complexity. Most of the complexity is technical debt, bad implementations etc. But by itself it is not THAT complex.

Re: From Supabase to Clerk to Better Auth

#224
post #192

Earlier quoted context omitted.

I wonder if it is not people being notoriously lazy or clueless at an astonishing degree. How often do you hear that password were saved in plaintext? Surprisingly high in this day and age. People not knowing what salt and pepper is... Vulnerabilities almost as if on purpose... Perhaps it is actually not THAT hard but just like error handling, people don't want to do the unsexy parts and want to delegate those tasks…

> want to delegate those tasks to someone else perhaps And this someone's name begins with "Cla" and ends with "ude". So we're going to have a lot more vulnerabilities in the auth code going forward.

Apparently a mythos loop will mitigate that. /jk

We will see I guess... It could also be an opportunity to audit systems in automated ways.

Re: From Supabase to Clerk to Better Auth

#225

Earlier quoted context omitted.

That's great for B2C, but B2B demands SSO.

Not really, we do B2B. E-mail & password is good enough for our customers. They really really dont care about what kinda auth we use.

Depends on your industry I guess. My personal experience is that small-to-medium companies ask for SSO, large and enterprise _require_ it.

Re: From Supabase to Clerk to Better Auth

#226

Earlier quoted context omitted.

This comment thread was a nudge to push out a quick experimental change to the val.town landing page, so thank you. Very open to feedback on that messaging if anyone has any. Most customers these days ask about using val town with claude code, so you could also think of us as a deployment platform for vibe coded apps

I wasn't trying to be negative. I think the changes you made to your landing page are more communicative than before, good luck with val.town.

Thanks! And btw I didn't perceive your comment as negative! More a helpful confirmation of what we've been thinking: "yeah, we have a messaging/positioning problem"

Re: From Supabase to Clerk to Better Auth

#227
Been using BetterAuth for half a year/one year now. It's exactly what I always wanted when using Clerk (and its free as a side effect). I was never a fan of the "we'll manage your user Table", always set up the Web hooks to sync everything to my own user table, but still loved the development experience clerk provided (most of it).

I will never go back. Lets see if in 3 years I have a different opinion, but I can't imagine so.

Re: From Supabase to Clerk to Better Auth

#229
For me, the real issue of switching auth providers hasn’t been touched: do thy all use the same hashing functions or how did they move the password hash column across providers? Running them in parallel and rehashing on first login?

Re: From Supabase to Clerk to Better Auth

#230
post #188

Earlier quoted context omitted.

Why pay someone to build a house? I’m sure you could do it yourself…but that doesn’t mean that is the best use of your time in all cases. The analogy is basic but apt; not everyone needs or wants to run (or create) every mechanism. I don’t do all of my own hosting either and it’s not because I couldn’t, it’s that it isn’t worthwhile in my cases. To expand a bit more: if a business is faced with a choice to save some…

This is such an absurd take. For starters, if I'm a "house builder" by trade, then yeah, I am going to build the house myself. Otherwise, why should the client pay me, and not the guy I'm subcontracting? Secondly, there is no such thing as a "house builder" profession. It consists of a lot of different trades people, some of them having legal power to sign off your house build (for example an electrician). Now, we co…

> For starters, if I'm a "house builder" by trade

You're not a house builder, you're a widget maker who needs a house to live in. Auth is almost never your startup's core competency or offering. Spending one of your very valuable five engineers on the auth tarpit while you lose deals because SSO is hard could be life and death for you.

Post reply on HN