Hey, author of Better Auth here. I created Better Auth because I couldn’t find any other auth library that goes beyond simple login with OAuth. Even then, the only properly maintained ones were NextAuth (Auth.js) and Lucia (which is now deprecated). I’m not sure where the idea of "too many auth libraries" is coming from.
They're probably including libraries tied to hosted offerings, and there are a lot of them (Cognito, Firebase, Auth0, Clerk, FusionAuth, Kinde, Descope, WorkOS, and many many more)
Does anyone have experience with https://lucia-auth.com ? OP says that it's deprecated, but it seems like it just changed from a library to a short guide on how to implement auth yourself.
I'm planning to migrate our authentication and session management from auth0 to this to save costs and make things simpler.
I am currently self hosting former gotrue, now supabase auth and am having a hard time implementing oath and will probably try to switch to better auth. The docs look super comprehensive.
As someone developing with both Nuxt and Next, I find these "full-stack" JavaScript libraries and frameworks really confusing and difficult to grok. I understand the benefit of only having one ecosystem to worry about (JS/TS in Node and browser) but I'm not convinced that having backend and frontend in the same codebase is actually a good idea. It might be due to being a more "old school" full stack developer, but th…
I am a big fan of Gleam language's Lustre[0], and due to its functional nature, the full stack experience is much better.
Instead of becoming this mishmash of backend and frontend, there's a clear delineation between the two. They share common functionality via functions (like model and views), which is much easier to do when they're pure.
You basically get the advantages of those magic frameworks without all the magic.
As someone developing with both Nuxt and Next, I find these "full-stack" JavaScript libraries and frameworks really confusing and difficult to grok. I understand the benefit of only having one ecosystem to worry about (JS/TS in Node and browser) but I'm not convinced that having backend and frontend in the same codebase is actually a good idea. It might be due to being a more "old school" full stack developer, but th…
I don’t think the issue lies in using the same language to write the client & server. IME projects become brittle & hard to refactor when you use a full stack framework because you wind up writing a ton of controller code or a sprawling service layer to support different features for each page. This isn’t exclusive to using a framework, I’ve done the same thing with API endpoints in the past.
Making a general purpose API as if it were its own product seems to lead to better, more sustainable outcomes.
As someone developing with both Nuxt and Next, I find these "full-stack" JavaScript libraries and frameworks really confusing and difficult to grok. I understand the benefit of only having one ecosystem to worry about (JS/TS in Node and browser) but I'm not convinced that having backend and frontend in the same codebase is actually a good idea. It might be due to being a more "old school" full stack developer, but th…
As someone developing with both Nuxt and Next, I find these "full-stack" JavaScript libraries and frameworks really confusing and difficult to grok. I understand the benefit of only having one ecosystem to worry about (JS/TS in Node and browser) but I'm not convinced that having backend and frontend in the same codebase is actually a good idea. It might be due to being a more "old school" full stack developer, but th…
I've worked on a wide range of projects that use a number of different approaches to this. At the end of the day, you usually want at least some parts of it to some extent. If you don't want every page the user sees to be full of loading spinners at first, whatever is serving the initial HTML needs to know at least something about what the UI components are like and how to lay them out. In fact, the closer the initial load to the final result, the better. On the other hand, you also want interactivity, especially in this day and age. Very few web applications are just static data you look at and don't interact with. So you also need some frontend stuff that adds all of that magic. So all these frameworks are essentially trying to solve this problem, how do you get both of those things without just duplicating and syncing all of that code between the frontend and the backend. I do agree that many of the solutions we see today are immature, but when it's done right, it's wonderful.
As someone developing with both Nuxt and Next, I find these "full-stack" JavaScript libraries and frameworks really confusing and difficult to grok. I understand the benefit of only having one ecosystem to worry about (JS/TS in Node and browser) but I'm not convinced that having backend and frontend in the same codebase is actually a good idea. It might be due to being a more "old school" full stack developer, but th…
In my opinion the only real point of those frameworks is so that developers can focus on coding while the experts figure out how to do code splitting, search engine optimization and what to render where (browser, server) and when.
Since http protocols and browsers change and especially google never ceases to push new optimizations, it is extremely difficult to keep up and do the right thing.
How are people able to just spin up Google login using these libs? When I tried it doing it directly my site had to be reviewed multiple times by some Google rep and I had to change the privacy policy, not have any beta features etc etc. What am I missing? I find it really strange that I must fully launch my product before I can enable the most common login mechanic. It feels like a catch 22.