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

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

Full stack is the only way to go with small teams

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

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.

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

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.

This is valid but only for pure landing pages

Htmx needs a backend framework, the thumbnail is kinda confusing

I agree with you completely. I did NestJs + Angular in my project, now I regret it..... I should have done MPA in PHP or NodeJs and not complicate everything

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.

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.

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.

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?❤

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

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

such an on point opinion.

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...)

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

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.

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

api client generation is the way to go

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.

Laravel is king

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

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.

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.

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.

To solve the problem you have that is lack of expressiveness in the contract (between BE and FE), you are advocating for just getting rid of the contract and have everything into one giant tangled ball, where the alternative is having a working contract, a working process between teams. This will work only up to the point where the app is small enough to fit the inner workings in everyone's brains. The moment it grows bigger, nobody will have full context of anything, and development will slow to a crawl, everyone stepping on others' feet. In my experience, the complexity accumulates quite fast. If you just do this, I guess it would end up an unmaintainable mess by the 1 year or 2 year mark.

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

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

what about realtime stuff? and dashboards etc?

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.

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.

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

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

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

You lost me at the backend devs writing CSS. 😂

Go is not good for prototype

You should try Laravel 😊

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..