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 this new wave of of SSR-led full-stack frameworks is tricky.

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.

100% agree with how confusing it all feels. Smudging data and code back together feels like a massive step backwards. I can't but be reminded of the disaster that was ASP.NET Webforms.

It took me a while to grok that in SSR frameworks, you shouldn't treat the SSR backend as a data backend. The best mental model is that the "SPA" just now has a client-server boundary in the middle of it. You should have a normal data API servicing the SSR backend.

With this approach, this does mean that client-server auth can now either live in the SSR backend or as normal on the data api. Arguably doing it on the SSR backend makes the most sense since that is now your server boundary. In this context the resurgence of auth in the SSR space make sense.

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.

[0]: https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...

I started a side-project in SvelteKit a while ago, and so far I still like it a lot. When I saw what projects using it look like, it somehow just intuitively 'made sense' to me. For me it's also just the right amount of 'magic' so that it's still quite flexible, but takes care of the parts that would be tedious otherwise.

(I've never worked with Nuxt or Next though, so I can't directly compare them.)

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.

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.

Ok, but how is that related to this auth library?