Why I Stopped Using Backend Frameworks 

Thankful more people are saying this. The future is full stack, and these tools make it so much better

Oh shit, here we go again. 1-2 years and we will find that decoupled services are better.

Answer: because you are a frontender

Full stack is the only way to go with small teams

SvelteKit is great, and the idea of building fullstack apps with good SSR experience is definitely something worth giving a try. The thing is, the more bussiness logic you have, the less applicable the fullstack technologies are. Using such fullstack frameworks for something more complex than e-commerce sounds like a complete madness to me.

The only downside is when you want to go beyond web (like mobile, tv or whatever) Then you will have to maintain two separate “backends”. But if it’s only web I agree

I dont believe js should be used to on the server

Reason why I'm still writing separate backends for some apps is because I do more than just REST APIs that return data. When you need a stateful and persistent backend for usecases like websockets, server sent events, and CRON jobs, I feel like you'd still have to use it. Is this wrong? I know Vercel has those options but I still prefer to host on a VPS tbh. Also because sometimes of a requirement to write a different app that will consume that API.

What are the pros and cons of adapter static on s3? Does that mean im missing the full stack backend? I think you can do go on the frontend with wasm containers. When i worked on a ship, deff had to have everything cached to the server.

This is valid but only for pure landing pages

5:00 I agree. I'd say having fullstack devs where each has a distinct strength within the spectrum is the way to go. So for example, more of a back-end-like full-stacker vs more of a front-end/designer-like full-stacker.

I’m a fan of go+htmx atm but I totally agree full stack / monolith is the way to go unless and until there’s some pressing reason to change

what about realtime stuff? and dashboards etc?

I definitely understand the sentiment for coupling full stack. Especially for small teams and startups, next js + backend as as service (supabase etc) allows you to hit market very fast. I've written next JS app before which had a landing page, stripe checkout etc. It's a great DX experience I personally just don't enjoy writing JS/TS everywhere (but if I have had to pay the bills this way I would) I definitely prefer something like C# or Go on the back end. I need to give Go + HTMX a try sometime but haven't because I really enjoy component libraries like ShadCN because I suck at design. Also, to remedy your frustrations couldn't use an interface on the front end for type safety or consider using something like GRPC? Anyways great video keep building cool stuff

Yeah that is true. But if your hosting company doesn't support edge functions does it still work. Also should you use api folder in all cases when you use fullstack frameworks like nextjs?❤

tip: for hono you can export the type and instantiate a client which guarantees typesafety when calling your API. You can also add zod validators.

Basically you like monoliths is what I hear you saying fullstack. I definitely agree it is the productive way that people have always done fast and amazing things with for so long, its just hilarious we have gone full circle now. I personally prefer the more backend monoliths like Elixir/Phoenix or RoR.

Htmx needs a backend framework, the thumbnail is kinda confusing

Is rails, php. django etc full stack as well? I think so. I think the whole backend/fronted distinction might be a relatively recent concept

I haven't been this excited about the direction DX is starting to go since jQuery went stable and I thought I had super powers. (realized I had...)

what do you think of fastify microservices + trpc in a monorepo with frontend

I use grpc separate backend API and connect it to my sveltekit directly. Works quite well when API client gets generated and there is no duplication of code. And I can create more API endpoints on sveltekit that are needed only for web, making SvelteKit similar to BFF (backend-for-frontend) & frontend combo.

such an on point opinion.

Funnily enough I have been using Sveltekit and been stuck with the same pain of creating API endpoints everywhere and with very little Type Safety - having to still go through the fetch(endpoint, body) dance and custom validations everywhere. I think Astro Actions that just dropped may be a good solution, but I am starting to feel that Sveltekit is failing to address this issue. I would love to get your opinion on this - subscribing just in case.

The only reason I could have a separated backend is for strict security, e.g. I'm a bit scared of having backend envs around a metaframework

Would you care showing some examples of business logic in your JS full stack app and it working "really freaking well" like you said?

Hope there will be a good DX in go ecosystem in near future, maybe it will be htmx idk

I don't get it. Who needs more than a console as a front end? 😂

I prefer my backend and front end being agnostic from each. Even my db. Writing all the rules inside the db instead of the backend.

api client generation is the way to go

I'm on your side about using full stack frameworks but I prefer using backend languages in frontend instead of js/ts for backend. And it's possible through web assembly. My personal choice is leptos.

I'm using astro + grpc and had no problems with it. Feels productive and I dont have to write yucky JS on the server

By "full-stack" you mean "full-stack js" or "isometric."

I suppose if you have 1 client this is likely the most efficient approach.

You can just use a modular monolith design and use NATS for routing requests to the api running in the same app. It produces apps you can actually run a debugger on. It also makes it possible to hand roll request tracing. The event bus also functions as a storage layer so you can dump logs into it. Unless you have literally 100s of thousands of CONCURRENT users, this works fine. You still have too many levels of indirection for my taste(e.g. html renderer -> NATS -> logical endpoint -> ORM -> SQL - jesus), but it's way better than convoluted python javascript stacks with thousands of packages that run slower than your grandmother.

This is a good solution only for small teams and small projects, ideally for MVP. You need to be a backend dev to understand it. EDIT: I'm fullstack dev btw.

This is a problem I often see with inexperienced or front-end fullstack-wannabe developers who don't know much beyond dom manipulation and API integration. Most tend to think backend development is all about building apis. Now that they have API routers they call themselves full stack developers. An API is just an interface that allows other applications to communicate with the backend. It's not thee "backend". What we have are tools so pick the best one for the job. If you understand the history of software engineering, then you'll appreciate why all these technologies exist.

I prefer a separate backend because js can't solve problem perfectly Even just proxying the request, rust helps reduce the js server's response time from 100-200ms to around 1-20ms Htmx with pure rust is even faster, around micro seconds

Sveltekit is a game changer and the way to go forward. That or Go + HTMX (throw in templ). You don't need anything else. Let's retire the mess that React became and force all those "react devs" to learn proper CS/engineering practices.

but you'll always not have static data, some time you need to test it out with real data. Nextjs Server Action Doing Such Things, so you don't need to API call, they'll do for you.

You lost me at the backend devs writing CSS. 😂

Laravel is king

You should try Laravel 😊

Go is not good for prototype

Why would you use JS for the backend? Except as a junior trying to learn backend? JS is a horrible language for a backend language. Go, on the other hand, simple and powerful language

Typescript.. ewww..