Btw, I truly appreciate you talking about the developing process, not just "oh this is great because x doesn't have it", you go through the whole logical process and it is something I truly miss in other channels.
using http requests to hit your DB is pretty inefficient. Like, connect to db once on start? or do it for every single time you need to access data? Lol
1) Wanting to use something else than node and its flaws, js is forced frontend side, not backend side. 2) Wanting decoupling, people are just going full circle, you know what is battle tested, monolithic and way more productive if one doesn't care about separation of concerns? Rails, Laravel, Django, Phoenix etc, although those could still bring benefits by being used as backends with a js framework alongside since they are way more mature and useful/complete by themselves than anything node related where you'd have to duck tape half a dozen libraries for basic things. 3) Those /api routes style "backend for frontend" are often deployed in a serverless fashion, which brings many limitations, it's nice as a backend for frontend or for simple endpoints where bringing a separate server would be too much, like if you just want to send an email from your landing page. So yeah nice for basic tutorial like crud apps and when you'll not use the API for something else. But for building apps I don't think it's suited, and it's not like this concept of backend for frontend was new either.
nice video man in the mobile app case I think that go could be a good option specially if we are creating a native app with koltin/swift or maybe a flutter thing if its a react native app maybe trpc can be a good fit
Ben sorry i just thought of a question. Have you had issues with database latency? If your app is in the cloud but is in the same datacenter for azure/amazon/google/ect....i don't think it would ever been an issue but if your database isn't collocated with your app (which of course will never be the case with planetscale, neon, cockroachdb), unless your data needs are very minimal, then i would think there would be latency issues?
Actually when you use next Js or sveltekit or other You're using the development servers of this runtime, so I'm using sveltekit and bun. It's like using the responsiveness of svelte plus the speed of golang.
Thanks Ben, can i have your opinion on this: I have a production site where i have seperated BE and FE. That way i can create new MVP FE with any new tech that comes out, and without redoing everything again, or breaking my current code. I love SvelteKIT but i dont know why, it feels to wired to have both BE and FE all mixed up in the same app. As you said at the biginning im really trying to give myself excuses to have separate codes, but i think in my way of thinking i might be correct. One unique backend + differente FE in svelte/React/JS/ native Apps, etc.
In your case I think it makes perfect sense to have sveltekit and a separate backend, because its already built. Having a "frontend cloud" is super useful even without connecting it to a DB
Have you had any experience with HTMX? Lately it's been blowing up my feed, and it seems quite interesting. Perhaps instead of sveltekit, a combination of svelte+htmx+golang backend would be better - but I have not tested it yet.
I would better look into HTMx then. Htmx is a completely different paradigm: it enables you to have a backend respond with HMTL instead of JSON, so using both Svelte and Htmx wouldn't make much sense
@@computerfan1079 but it's hard to ignore the possibilities of svelte+skeleton design system, I'll have to dig in hard to find best use case scenario of this combo, because surely if htmx is used as intended, the efficiency and production speed skyrockets, but then again with svelte you hardly have any limitations but it takes longer. I need to play with htmx to see where it shines in real apps.
i'm sure that go will outperforme backend on node at any day of week. nodejs people are usually impressed by 400 concurrent connections, but backend in c (yes, in c) can manage 400000 (not a typo) concurrent connections, it's on a completely different level. you probably don't need this performance, but those cpu cycles are going to accumulate into the cost of owning that backend. also svelte is not something i would use. if i'm not mistaken they have deleted documentation in russian, well, i'm actually in ukraine, but i wouldn't use some sort of discriminating software, whoever they discriminate. maybe you don't understand this sentiment, and hopefully you won't, because you need to be discriminated to really understand what it is. ideally i would use some "agnostic" software that can be relied on. i guess i'll stick to vue, maybe not ideal, but stuff works, you know.
I want to ask you one thing as I was thinking of some serious project and I am nooobie but even if I am a solo dev : let's say I am a solo developer trying to build a startup or something which is highly scalable. And In there Once I finished the frontend part for the mvp , isn't most thing what should be done is on backend : why do I need to consider frontend now ? that's already done for what I am serving : now just push the backend to its limit that comes with my skills and expertise and as application grows, team might grow too : now why I want a full stack framework , it's just better to make things seperate for team and collaboration , right? I might be wrong , but isn't that what it is ?
A lot of the benefit of doing fullstack is that your fe/be are tightly coupled, which lets you move faster. For me I would just do everything in a fullstack JS framework, then when its needed break everything out into a full separate backend
I don't know much about building mobile apps but I've heard maybe you can use a web app as a mobile app, or build a mobile app with JavaScript. For instance I've heard capacitorjs is like the electron of mobile. I've also heard of TWAs which are like extensions of PWAs but I dont know much about that either. I wonder if a go backend is still justifiable for mobile vs building with web(site) technologies
I was in this exact conundrum but I decided to stick with golang because concurrency is easier, especially with bg jobs, it's easier to deploy and uses less memory so I can use a tiny instance and save money...plus the dev experience is better with the integrated toolchain.
with LLM on the rise and now added to all websites and MVP at one form or another ... can't say performance and websocket is an option anymore, also each CPU cycle matters a lot all the computing should be saved for the inference
Would you be able to do a comparison of something like firebase/supabase vs using these tools like vercel, planetscale etc. My initial thoughts is that for a MVP/startup the BAAS is fine, I mean who wants to implement auth and all the other boring shit
1. why you all complicate with databases on other servers? you can take a cheap vps and install any database... 2. Rust it's blazing fast, i don't see why i can use GO... to replace TS...if i want to...
I don't think Rich Harris is a no js person. I think he is saying that MOST websites should STILL work without js. Most, not all. And by still, he means that js is nice to have but it shouldn't be an absolute necessity for people to still use a website. Js should enhance an already working website, as it says on the svelte tag line, cybernetically enhanced.
in my opinion, if not choice sveltekit for backend and have to have another language for backend, so i will choice rust like axum rather than golang. If use golang for backend, i will choice sveltekit too. not Golang.
I already thought at the last video was for a nonsense. This already destroyed the advantages of Go. Better throw Svelte in the garbage can and look for a better stack for Go.
The argument for a go backend never made sense for the reasons listed, but I thought I might be pleasantly surprised haha. I used to go out of my way and build complexity into my apps to squeeze out that extra performance, but not for these types of apps anymore. If you need speed for a specific task, add a message queue, write a consumer in Go/Rust, and let that crunch the data asynchronously at bare metal speeds
@@Xe054 hey maybe @bmdavis419 will make one! I’m sure you could find some videos on RabbitMQ that would show this process in action. It’s possible to replicate a queue in a db, but it may add an extra step of checking for race conditions if your running multiple consumers in parallel.
At around 10:10 you mention about the pricing of planetscale being really cheap but that is not the case for enterprise scale. The thing is that "row reads" in planetscale is not equivalent to "row returns". Meaning that when the database return you x number of rows, the number of rows read is significantly larger because the database have to scan through the table to check for conditions and constraints. Therefore, I agree that planetscale scales really well for small to somewhat large apps, but the number of rows read can be a huge bottleneck for any application bigger than that. Something like cockroachdb or tidb would be cheaper at that scale
True, but my point was that if I get to the point where I care about enterprise pricing then I have a successful app with product market fit so I really don’t care and can eat the cost or pay someone to migrate it
If everyone migrates their app after it reaches certain row reads because planetscale has a weird pricing structure, do they really have a sustainable business model? The paid plans support the free plans. For side projects, choose planetscale all day. If you're making decisions at a company, are they the right choice?
As someone more on the junior end of the scale, hearing the thought processes that led to your decisions is immensely insightful. Awesome stuff as always 👏🏻
This is a really, really great video! I love how candid you are and your assessment of the pros and cons here. It helped me think about this topic more accurately, I think. I appreciate it :-) Modern web development is getting crazy, and I think the transition to these "meta frameworks" (SvelteKit for Svelte, Next.js for React, Nuxt for Vue, etc etc) is.... nice in some ways, but confusing in others. Or atleast I have found it to be. The combination of the backend and frontend together just makes things confusing to me. Heck, your "Apparently I don't understand Svelte..." video is good proof right! I related a lot to that video. I dunno, call it a skill issue I suppose, but I think it gets confusing for people (or atleast me) when you start putting the FE and BE code in the same repo. At the same time, I see the reasons why they are doing it. End-to-end type safety is huge and just such a productivity boost. I almost wish SvelteKit would have put more emphasis on generating API specs though, eg Swagger/OpenAPI like you mentioned. Like, they could have set it up such that the FE makes requests down to the BE in a **very** well documented way, and then allow *you to choose* on a Per-endpoint level the "Backend functionality provider" you wanted. So eg maybe some endpoints went down to a Go server; and the rest were fielded by your standard SvelteKit server; and there was a nice file that clearly defined that for you! I think that would have been awesome. And you could still keep the backend stuff SvelteKit is able to do for you now with page.server.ts; but it just wouldn't be required. And my hope would be, with the API specs, you'd still have the seamless End-to-end typing. Basically I guess, I want all the niceness of SvelteKit, but without the requirement to run Node on my backend lol. Also I find it funny, for you it seems like your darling language is Go, for me it is Rust 🦀. Man, do I love me some Rust. If you ever want to rewrite your App again (always a productive thing right 😂), give Rust a shot if you haven't already!
Yea I’ve thought about giving rust a real shot, it honestly where I am right now Go/TS just makes 100x more sense. Although I do need to make more go content, it’s been lacking lately
Sveltekit endpoints can be open to third party calls, so you can basically make it an api and use it on your mobile apps, might not be better that a go backend, but it stills eliminates more uses cases for a separate backend
Are any sizable production apps using sveltekit as their true application server instead of a BFF? At first glance that seems like a terrible idea. For a tutorial todo list it's fine, but if you're building a company having a standalone API seems infinitely more scalable and maintainable.
Depends what you mean by sizable, some VC backed startups that follow trends, will rewrite everything in a year and write 10 blog posts about it ? sure. Complex apps by sizable (or not even for that matter, just reasonable ones) companies ? Probably not, right tool for the right job. Those frontend frameworks can be a productivity boost over vanilla JS as long as you use them as frontend frameworks and don't drink their marketing cool aid which isn't really in developer's interest, as we've seen lately with Vercel making NextJS 13.4 a completely new framework and releasing their /app directory as stable while everyone is still complaining about things constantly breaking. As you said tutorial like apps or even marketing ones it's likely not a problem, and it's perfect since that's 95% of what is portrayed on youtube, but you probably already know that even vanilla JS would nicely handle these use cases and in a way less complex manner.
I'm actually a developer who uses Svelte (not Svelte Kit) with Golang. I use Golang in the backend for performance reasons so I don't need as much resources as I scale.
We rewrote our React front end into SvelteKit in a couple months and haven't looked back. Our backend is custom NodeJS and it works perfect for our data analytics product. I've been wanting to do parts in GoLang. There's parts where I want to use Elixir on the backend. Svelte has a few quirks and limits at the moment tho for someone used to the horsepower of C# and ASP net/Razor/Blazor type component models and component APIs. In all, SvelteKit (without its backend) is a wonderful tool. I had been a front end dev from '96 to '07 then a backend engineer, and scalability architect since. Then last year I discovered Svelte and fell in love with web development again.
@@tuananhdo1870 Our front end was built in React for its first 2 years and we had many React devs working on it. We did an early prototype of something and used Svelte because the thing we were trying to learn, the tutorials were in Svelte. We were originally going to learn it then carry the skill over into React. The team fell in love and all made the choice to switch it over. As the CTO, I didn't take the decision lightly but they were doing things in days that in React was taking much longer. In just a few weeks they already had 80% of the entire app re-coded up from scratch using Svelte, nothing copy and pasted from React. So I greenlit the project. So we switched. All my React devs are now Svelte devs and rue the day they leave the company and might have to go back, LOL. It's not completely because of React that things were less productive, we also changed the architecture. But even so, it's clear as day, things that took a week or more regularly in React (among the dozens of different devs that worked on it, they all basically were equally productive)... takes hours or about a day in Svelte for the same people. For us, it was a clear winner to switch over. We were an early stage startup and time to delivery was felt.
Imagine you can write your backend in any language you want inside of your app without having to create a separate standalone server. Idk why that's not possible yet. Where I can just go inside the /api folder of my Next js app and put my golang files in there for the server and just have a config file that tells Next that Go is gonna be the language of choice. That would be cool
I appreciate Go and a clear sepperation between fe & be and SQL is nicer to handle & test in a seperate go backend. I like to see my svelte app as a seperate thing that's just fetching data and not wired up with the backend unnecesserly complicated (even if it is abstracted away quite fancy) If i build a neutral well-structured api that can be used for enything I feel more productive in the FE. There are less things in my mind when I don't have to deal with backend related things anymore. Everything is well documented in swagger. And it's not my concerene at this point. It's just fetch & display, fetch & display, form & submitt, ... IMO The tech-stack should depend primarily on the nature of your data and how it is consumed. I also learned to appreciate SQL because depending on what you do, you get quite complicated ralations very fast even in simple apps. And with baas solutions you end up solving issues at a higher level which are terrible to handle there. The most horrifying thing to me is that customers enter data for a long time and later you realize that some transaction didn't work properly. But at this point payments were made based on that data and there is no way to know what data is wrong. (thats more of a terrible UX than +10ms response time) Properly testing business-logic and the repos is very important to me. If the app is just for consuming data and you don't have to be concerned about creating it (like getting it reliable from SEC), i can see why a different stack with baas is beneficial. jm2c
This feels like a cope. Performance and Scale absolutely matter, especially in a business context. Also, you forgot the case when you have multiple large services that need to be accessed by the same front end. Are you going to just connect directly to multiple databases? The few videos I’ve seen of yours have been interesting. This one seems just outright wrong.
i can see your point but i argue that in development it's all about compromises in a way that ,yes sveltekit can do everything and you don't need a separate backend to link it to ,BUT the use case for golang is not to be a monolithic app backend but its is to have multiple microservices that works together efficiently and reliably while consuming less resources . sveltekit for backend is great and fast when it WORKS but it's still in the end of the day another js/node framework a GOOD one but still it's chained by that limitation of js. every framework/language is designed for a purpose, some do things better than others and there is no perfect framework /language and our job is to use the better tool for the job for the use case . i see a bright future for sveltekit as reliable front-end framework , i used it for its simplicity and my hatred for react ecosystem.
Hi Ben I have a setup with go microservices and just graphql BE on Sveltekit to use them as DataSource. This is also a flexible approach I can use Kafka or grpc between services below the FE server layer, while still maintaining one centralised schema to stitch them on my Sveltekit backend. Some people go as far as having Gateway there to stich them more properly. I still use normal GQL server though it works. I know this is some kind of a rant ,but it's still a way to have solid Contract that centralises microservices next to your UI. And than having whatever you want below.
"I'm a guy with a hammer in search for nail". lol. Sounds easy, but my heartfelt respect for having such a mature mindset that you went and dropped Golang after experiencing it didn't make sense in practice for your project. That's a tough one for sure👍
Golang is better for compute heavy workloads on a separate server. This would decouple the scalability of compute heavy from compute light workloads, while taking advantage of performant Golang. In this scenario, Golang is probably the right tool for the job. For authentication, admin stuff... a fullstack JavaScript framework makes more sense. Basically any backend that directly deals with UI.
Always was wondering about such frontend dumbs. They can't get that frontend is just a user interface while the vast majority of work is being done on a server side, beyond user's eyes and access. It's like ppl who think the market they go everyday to buy groceries make them just there without fields, animals, plants, storages, trucks, etc etc
It's kinda funny to get to your videos about sveltekit and go as a back-end cuz I was doing a Remix app and I wanted to create a Rust back-end for almost the same reasons that you said (perf, scale, WS, standalone, etc). I'm still currently asking myself if I should keep Remix or use plain React with Vite. Nice videos tho ! I like how randomly you have the same problem than me and make videos about it haha, it'll be easier for me to make a choice.
you are basically comparing monolith vs microservices architecture: 1) monolith: the sveltekit backend would do everything or 2) microservices: your sveltekit handle only frontend related things (SSR, SEO), but call to others microservices (others backend) for everything else, the others backend might be a golang, java, c#, (or evens other nodejs). Your current choice is monolith over micro service, and it might be more appropriate for your (simple) applications. But it is not means that Sveltekit + Golang backend microservices is a bad choice for larger applications. (If your SvelteKit backend try to talk to Dgraph database, or PocketBase, which are written in Golang then.. voilà you have a Golang backend 😅 no need for pros and cons)
With something like HTMX and web components you can pretty much stay in the back end language you like. I built an HTMX-like library called HTMF (a fraction of the size) and it is amazing how dynamic you can make your apps with very little work (my apps are mostly just offline-first apps in JS built in ServiceWorker).
If you are building any application that will hit more than 1000 users, and that is relied upon by companies, you will not use a full stack framework. If you make your frontend reliant on a backend that is so tightly nit together you will incur costs that are very big for not a lot. You would go from hosting your frontend application (note how I didn't say homepage or that, the application can take some time to load, zero loadtime is futile) on static storage-which is very cheap-to now needing to flash out a serverless instance, or a container just so the user can reduce 0.5 loadtime seconds off of an app they are already paying and takes a login to even view. Also, if you now need to make the api accessible to a mobile app you can kiss goodbye to ever being able to invite someone else to help you, as they would need to also understand the frontend (it is what defines your api requirements, rather than a spec sheet). There are very little upsides for not a lot of gain, whilst the downsides make it so scaling of any kind is incredibly expensive.
what about HTMX. do the same job without billion line of node module and build pack and hours of googling for cli commands, just html attributes (even http requests)
I honestly don't see Go as a good general backend language. It gives you incredible performance but requires too much work for some basic operations (like CRUD). Here in the company I'm currently working we have a microservices architecture and our backend stack is split between Laravel/NestJS for most of the operations and Go for specific flows that are required to be highly performant. We use Kafka for the internal communication between services.
Actually Go does not require much work for basic CRUD. Your problem is that you are making microservices that increase complexity ten fold since you need to also solve problems like data consistency, tracing, metrics, load-balancing, service-discovery, etc...
![State of Play | September 24, 2024 [ENGLISH]](http://i.ytimg.com/vi/fVs0suPHAX8/mqdefault.jpg)
Btw, I truly appreciate you talking about the developing process, not just "oh this is great because x doesn't have it", you go through the whole logical process and it is something I truly miss in other channels.
I try to make sure I go through my entire thought process and make sure the "why" behind everything I think is clear
I'm glad you're addressing it.
Before I watched your videos, I simply assumed that Go would not be handling most calls, just data processing.
Thats probably how I'm gonna handle this in the real world, background workers in go then the CRUD I/O in sveltekit
Great presentation, very mature and reasonable. Thank you for your thoughts and experience! I'm looking forward to watching more of your videos.
i love the way you communicate, you look like you're going to be successful, just keep on doing what you do, i'll support your journey by subscribing
I was waiting for this video since the last one. Glad to see it. 👏
using http requests to hit your DB is pretty inefficient. Like, connect to db once on start? or do it for every single time you need to access data? Lol
1) Wanting to use something else than node and its flaws, js is forced frontend side, not backend side.
2) Wanting decoupling, people are just going full circle, you know what is battle tested, monolithic and way more productive if one doesn't care about separation of concerns? Rails, Laravel, Django, Phoenix etc, although those could still bring benefits by being used as backends with a js framework alongside since they are way more mature and useful/complete by themselves than anything node related where you'd have to duck tape half a dozen libraries for basic things.
3) Those /api routes style "backend for frontend" are often deployed in a serverless fashion, which brings many limitations, it's nice as a backend for frontend or for simple endpoints where bringing a separate server would be too much, like if you just want to send an email from your landing page.
So yeah nice for basic tutorial like crud apps and when you'll not use the API for something else. But for building apps I don't think it's suited, and it's not like this concept of backend for frontend was new either.
nice video man
in the mobile app case I think that go could be a good option specially if we are creating a native app with koltin/swift or maybe a flutter thing
if its a react native app maybe trpc can be a good fit
Ben sorry i just thought of a question. Have you had issues with database latency? If your app is in the cloud but is in the same datacenter for azure/amazon/google/ect....i don't think it would ever been an issue but if your database isn't collocated with your app (which of course will never be the case with planetscale, neon, cockroachdb), unless your data needs are very minimal, then i would think there would be latency issues?
start with this, and scale with Go 👌
Actually GoLang doesn't really have many web socket libraries compared to other languages. Gorilla is basically abandoned.
Well gorille still works just fine and you only really need one library for doing websockets not many.
@@KManAbout well project is not maintained anymore so future is uncertain
@@Cyber_Lanka there's already another library for websockets
I love writing form validation once for server and client.
Actually when you use next Js or sveltekit or other You're using the development servers of this runtime, so I'm using sveltekit and bun. It's like using the responsiveness of svelte plus the speed of golang.
Thanks Ben, can i have your opinion on this: I have a production site where i have seperated BE and FE. That way i can create new MVP FE with any new tech that comes out, and without redoing everything again, or breaking my current code. I love SvelteKIT but i dont know why, it feels to wired to have both BE and FE all mixed up in the same app. As you said at the biginning im really trying to give myself excuses to have separate codes, but i think in my way of thinking i might be correct. One unique backend + differente FE in svelte/React/JS/ native Apps, etc.
In your case I think it makes perfect sense to have sveltekit and a separate backend, because its already built. Having a "frontend cloud" is super useful even without connecting it to a DB
Have you had any experience with HTMX? Lately it's been blowing up my feed, and it seems quite interesting. Perhaps instead of sveltekit, a combination of svelte+htmx+golang backend would be better - but I have not tested it yet.
I would better look into HTMx then. Htmx is a completely different paradigm: it enables you to have a backend respond with HMTL instead of JSON, so using both Svelte and Htmx wouldn't make much sense
@@computerfan1079 but it's hard to ignore the possibilities of svelte+skeleton design system, I'll have to dig in hard to find best use case scenario of this combo, because surely if htmx is used as intended, the efficiency and production speed skyrockets, but then again with svelte you hardly have any limitations but it takes longer.
I need to play with htmx to see where it shines in real apps.
htmx + svelte seems pretty pointless. I thinks htmx is great middle ground between html and frameworks. Really nice for some smaller sites
have you approached it from a HTMX perspective ?
Not yet, but I will be playing with it soon!
i'm sure that go will outperforme backend on node at any day of week. nodejs people are usually impressed by 400 concurrent connections, but backend in c (yes, in c) can manage 400000 (not a typo) concurrent connections, it's on a completely different level. you probably don't need this performance, but those cpu cycles are going to accumulate into the cost of owning that backend.
also svelte is not something i would use. if i'm not mistaken they have deleted documentation in russian, well, i'm actually in ukraine, but i wouldn't use some sort of discriminating software, whoever they discriminate. maybe you don't understand this sentiment, and hopefully you won't, because you need to be discriminated to really understand what it is.
ideally i would use some "agnostic" software that can be relied on. i guess i'll stick to vue, maybe not ideal, but stuff works, you know.
I want to ask you one thing as I was thinking of some serious project and I am nooobie
but even if I am a solo dev :
let's say I am a solo developer trying to build a startup or something which is highly scalable.
And In there Once I finished the frontend part for the mvp , isn't most thing what should be done is on backend : why do I need to consider frontend now ? that's already done for what I am serving : now just push the backend to its limit that comes with my skills and expertise
and as application grows, team might grow too : now why I want a full stack framework , it's just better to make things seperate for team and collaboration , right?
I might be wrong , but isn't that what it is ?
A lot of the benefit of doing fullstack is that your fe/be are tightly coupled, which lets you move faster. For me I would just do everything in a fullstack JS framework, then when its needed break everything out into a full separate backend
I don't know much about building mobile apps but I've heard maybe you can use a web app as a mobile app, or build a mobile app with JavaScript. For instance I've heard capacitorjs is like the electron of mobile. I've also heard of TWAs which are like extensions of PWAs but I dont know much about that either. I wonder if a go backend is still justifiable for mobile vs building with web(site) technologies
Maybe SvelteKit without a backend is enough, but what about mobile apps that need a backend too, or smart devices???
I was in this exact conundrum but I decided to stick with golang because concurrency is easier, especially with bg jobs, it's easier to deploy and uses less memory so I can use a tiny instance and save money...plus the dev experience is better with the integrated toolchain.
with LLM on the rise and now added to all websites and MVP at one form or another ... can't say performance and websocket is an option anymore, also each CPU cycle matters a lot all the computing should be saved for the inference
I am also on the hype of html form but still need js for input validation tho
TCP not TLS
Would you be able to do a comparison of something like firebase/supabase vs using these tools like vercel, planetscale etc.
My initial thoughts is that for a MVP/startup the BAAS is fine, I mean who wants to implement auth and all the other boring shit
Auth is boring?
1. why you all complicate with databases on other servers? you can take a cheap vps and install any database... 2. Rust it's blazing fast, i don't see why i can use GO... to replace TS...if i want to...
I don't think Rich Harris is a no js person. I think he is saying that MOST websites should STILL work without js. Most, not all. And by still, he means that js is nice to have but it shouldn't be an absolute necessity for people to still use a website. Js should enhance an already working website, as it says on the svelte tag line, cybernetically enhanced.
This is disappointing. I subscribed for the 'Go' content..
You can call yourself lucky because Go, although useful, is just hideous
in my opinion, if not choice sveltekit for backend and have to have another language for backend, so i will choice rust like axum rather than golang. If use golang for backend, i will choice sveltekit too. not Golang.
I already thought at the last video was for a nonsense. This already destroyed the advantages of Go. Better throw Svelte in the garbage can and look for a better stack for Go.
The argument for a go backend never made sense for the reasons listed, but I thought I might be pleasantly surprised haha. I used to go out of my way and build complexity into my apps to squeeze out that extra performance, but not for these types of apps anymore. If you need speed for a specific task, add a message queue, write a consumer in Go/Rust, and let that crunch the data asynchronously at bare metal speeds
Exactly how I’m gonna be handling it in the future
I'm a junior dev and this sounds like a very smart idea. Are there any good videos that cover this programming concept?
@@Xe054 hey maybe @bmdavis419 will make one! I’m sure you could find some videos on RabbitMQ that would show this process in action. It’s possible to replicate a queue in a db, but it may add an extra step of checking for race conditions if your running multiple consumers in parallel.
@@charlesbcraig yeah. this really covers the "websocket" part since it scales with multiple servers/clients
At around 10:10 you mention about the pricing of planetscale being really cheap but that is not the case for enterprise scale. The thing is that "row reads" in planetscale is not equivalent to "row returns". Meaning that when the database return you x number of rows, the number of rows read is significantly larger because the database have to scan through the table to check for conditions and constraints.
Therefore, I agree that planetscale scales really well for small to somewhat large apps, but the number of rows read can be a huge bottleneck for any application bigger than that. Something like cockroachdb or tidb would be cheaper at that scale
True, but my point was that if I get to the point where I care about enterprise pricing then I have a successful app with product market fit so I really don’t care and can eat the cost or pay someone to migrate it
If everyone migrates their app after it reaches certain row reads because planetscale has a weird pricing structure, do they really have a sustainable business model? The paid plans support the free plans. For side projects, choose planetscale all day. If you're making decisions at a company, are they the right choice?
@@bmdavis419 depends on the type of the app. You can have a LOT of traffic and not a lot of income from it.
As someone more on the junior end of the scale, hearing the thought processes that led to your decisions is immensely insightful. Awesome stuff as always 👏🏻
This is a really, really great video! I love how candid you are and your assessment of the pros and cons here. It helped me think about this topic more accurately, I think. I appreciate it :-)
Modern web development is getting crazy, and I think the transition to these "meta frameworks" (SvelteKit for Svelte, Next.js for React, Nuxt for Vue, etc etc) is.... nice in some ways, but confusing in others. Or atleast I have found it to be. The combination of the backend and frontend together just makes things confusing to me. Heck, your "Apparently I don't understand Svelte..." video is good proof right! I related a lot to that video. I dunno, call it a skill issue I suppose, but I think it gets confusing for people (or atleast me) when you start putting the FE and BE code in the same repo.
At the same time, I see the reasons why they are doing it. End-to-end type safety is huge and just such a productivity boost. I almost wish SvelteKit would have put more emphasis on generating API specs though, eg Swagger/OpenAPI like you mentioned. Like, they could have set it up such that the FE makes requests down to the BE in a **very** well documented way, and then allow *you to choose* on a Per-endpoint level the "Backend functionality provider" you wanted. So eg maybe some endpoints went down to a Go server; and the rest were fielded by your standard SvelteKit server; and there was a nice file that clearly defined that for you! I think that would have been awesome. And you could still keep the backend stuff SvelteKit is able to do for you now with page.server.ts; but it just wouldn't be required. And my hope would be, with the API specs, you'd still have the seamless End-to-end typing.
Basically I guess, I want all the niceness of SvelteKit, but without the requirement to run Node on my backend lol.
Also I find it funny, for you it seems like your darling language is Go, for me it is Rust 🦀. Man, do I love me some Rust. If you ever want to rewrite your App again (always a productive thing right 😂), give Rust a shot if you haven't already!
Yea I’ve thought about giving rust a real shot, it honestly where I am right now Go/TS just makes 100x more sense. Although I do need to make more go content, it’s been lacking lately
Sveltekit endpoints can be open to third party calls, so you can basically make it an api and use it on your mobile apps, might not be better that a go backend, but it stills eliminates more uses cases for a separate backend
Are any sizable production apps using sveltekit as their true application server instead of a BFF? At first glance that seems like a terrible idea. For a tutorial todo list it's fine, but if you're building a company having a standalone API seems infinitely more scalable and maintainable.
Cal.com is just a next app I’m pretty sure which is the same concept
@@bmdavis419 interesting, good to know 🙌
Depends what you mean by sizable, some VC backed startups that follow trends, will rewrite everything in a year and write 10 blog posts about it ? sure. Complex apps by sizable (or not even for that matter, just reasonable ones) companies ? Probably not, right tool for the right job. Those frontend frameworks can be a productivity boost over vanilla JS as long as you use them as frontend frameworks and don't drink their marketing cool aid which isn't really in developer's interest, as we've seen lately with Vercel making NextJS 13.4 a completely new framework and releasing their /app directory as stable while everyone is still complaining about things constantly breaking.
As you said tutorial like apps or even marketing ones it's likely not a problem, and it's perfect since that's 95% of what is portrayed on youtube, but you probably already know that even vanilla JS would nicely handle these use cases and in a way less complex manner.
I'm actually a developer who uses Svelte (not Svelte Kit) with Golang. I use Golang in the backend for performance reasons so I don't need as much resources as I scale.
golang is still my boy
PocketBase is a great example of Svelte + Go
thinking of using it in all my future side projects
We rewrote our React front end into SvelteKit in a couple months and haven't looked back. Our backend is custom NodeJS and it works perfect for our data analytics product. I've been wanting to do parts in GoLang. There's parts where I want to use Elixir on the backend.
Svelte has a few quirks and limits at the moment tho for someone used to the horsepower of C# and ASP net/Razor/Blazor type component models and component APIs.
In all, SvelteKit (without its backend) is a wonderful tool. I had been a front end dev from '96 to '07 then a backend engineer, and scalability architect since. Then last year I discovered Svelte and fell in love with web development again.
curious, what's your reasoning for choosing elixir vs go on different backend parts?
How many years of experience you have with Reactjs. Do you use reactjs with typescript?
@@tuananhdo1870 Our front end was built in React for its first 2 years and we had many React devs working on it.
We did an early prototype of something and used Svelte because the thing we were trying to learn, the tutorials were in Svelte. We were originally going to learn it then carry the skill over into React.
The team fell in love and all made the choice to switch it over. As the CTO, I didn't take the decision lightly but they were doing things in days that in React was taking much longer. In just a few weeks they already had 80% of the entire app re-coded up from scratch using Svelte, nothing copy and pasted from React. So I greenlit the project.
So we switched. All my React devs are now Svelte devs and rue the day they leave the company and might have to go back, LOL.
It's not completely because of React that things were less productive, we also changed the architecture. But even so, it's clear as day, things that took a week or more regularly in React (among the dozens of different devs that worked on it, they all basically were equally productive)... takes hours or about a day in Svelte for the same people. For us, it was a clear winner to switch over.
We were an early stage startup and time to delivery was felt.
The only logical separate Go backend to Sveltekit is Pocketbase.
I would also mention that security is an advantage in having a complete separate Golang backend.
Imagine you can write your backend in any language you want inside of your app without having to create a separate standalone server. Idk why that's not possible yet. Where I can just go inside the /api folder of my Next js app and put my golang files in there for the server and just have a config file that tells Next that Go is gonna be the language of choice. That would be cool
That would be a big security risk though.
WASM might be what gets you there. Looks to have a bright future outside of the browser and on the back end.
I appreciate Go and a clear sepperation between fe & be and SQL is nicer to handle & test in a seperate go backend.
I like to see my svelte app as a seperate thing that's just fetching data and not wired up with the backend unnecesserly complicated (even if it is abstracted away quite fancy)
If i build a neutral well-structured api that can be used for enything I feel more productive in the FE.
There are less things in my mind when I don't have to deal with backend related things anymore.
Everything is well documented in swagger. And it's not my concerene at this point. It's just fetch & display, fetch & display, form & submitt, ...
IMO The tech-stack should depend primarily on the nature of your data and how it is consumed.
I also learned to appreciate SQL because depending on what you do, you get quite complicated ralations very fast even in simple apps.
And with baas solutions you end up solving issues at a higher level which are terrible to handle there.
The most horrifying thing to me is that customers enter data for a long time and later you realize that some transaction didn't work properly.
But at this point payments were made based on that data and there is no way to know what data is wrong. (thats more of a terrible UX than +10ms response time)
Properly testing business-logic and the repos is very important to me.
If the app is just for consuming data and you don't have to be concerned about creating it (like getting it reliable from SEC), i can see why a different stack with baas is beneficial.
jm2c
This feels like a cope. Performance and Scale absolutely matter, especially in a business context.
Also, you forgot the case when you have multiple large services that need to be accessed by the same front end. Are you going to just connect directly to multiple databases?
The few videos I’ve seen of yours have been interesting. This one seems just outright wrong.
Man but golang is ideal solution, because you have separate API, use in frontend, use in mobile etc
i can see your point but i argue that in development it's all about compromises in a way that ,yes sveltekit can do everything and you don't need a separate backend to link it to ,BUT the use case for golang is not to be a monolithic app backend but its is to have multiple microservices that works together efficiently and reliably while consuming less resources . sveltekit for backend is great and fast when it WORKS but it's still in the end of the day another js/node framework a GOOD one but still it's chained by that limitation of js.
every framework/language is designed for a purpose, some do things better than others and there is no perfect framework /language and our job is to use the better tool for the job for the use case . i see a bright future for sveltekit as reliable front-end framework , i used it for its simplicity and my hatred for react ecosystem.
If you need mobile app you will need a separate backend I suppose, go will be a great api
Decoupled Frontend and backends are best
Hi Ben I have a setup with go microservices and just graphql BE on Sveltekit to use them as DataSource. This is also a flexible approach I can use Kafka or grpc between services below the FE server layer, while still maintaining one centralised schema to stitch them on my Sveltekit backend. Some people go as far as having Gateway there to stich them more properly. I still use normal GQL server though it works. I know this is some kind of a rant ,but it's still a way to have solid Contract that centralises microservices next to your UI. And than having whatever you want below.
You look much better now than you did back in November. Thanks for the videos!
Really appreciate you making this video after I've seen the previous ones I was wondering what's the motivation for the go backend. Great insights!
A sveltekit + drizzle orm video would be awesome
I never subscribe to people. So when i do its for good reason. Really appreciate your honesty with tooling in the beginning. Earned a sub
"I'm a guy with a hammer in search for nail". lol. Sounds easy, but my heartfelt respect for having such a mature mindset that you went and dropped Golang after experiencing it didn't make sense in practice for your project. That's a tough one for sure👍
Hey Ben thanks for the video . I have one question which GO framework you use for backend ?
He uses Fiber, he's mentioned it in his earlier videos.
@@ishaanmalhotra3008 Thanks 👍
Tried it. Not mature enough for a real
API. Compare it with something like NestJS and you’ll find it really badly wanting.
Golang is better for compute heavy workloads on a separate server. This would decouple the scalability of compute heavy from compute light workloads, while taking advantage of performant Golang. In this scenario, Golang is probably the right tool for the job.
For authentication, admin stuff... a fullstack JavaScript framework makes more sense. Basically any backend that directly deals with UI.
Well this aged horribly, hasn't it. Real infrastructure plumbing and knowing how hardware works (ooh hypervisors scary!!!) wins out.
Always was wondering about such frontend dumbs. They can't get that frontend is just a user interface while the vast majority of work is being done on a server side, beyond user's eyes and access. It's like ppl who think the market they go everyday to buy groceries make them just there without fields, animals, plants, storages, trucks, etc etc
You do know you can just use Svelte alone and build pages that you can serve from your Go backend, right? 🤷
It's kinda funny to get to your videos about sveltekit and go as a back-end cuz I was doing a Remix app and I wanted to create a Rust back-end for almost the same reasons that you said (perf, scale, WS, standalone, etc). I'm still currently asking myself if I should keep Remix or use plain React with Vite.
Nice videos tho ! I like how randomly you have the same problem than me and make videos about it haha, it'll be easier for me to make a choice.
you are basically comparing monolith vs microservices architecture: 1) monolith: the sveltekit backend would do everything or 2) microservices: your sveltekit handle only frontend related things (SSR, SEO), but call to others microservices (others backend) for everything else, the others backend might be a golang, java, c#, (or evens other nodejs).
Your current choice is monolith over micro service, and it might be more appropriate for your (simple) applications. But it is not means that Sveltekit + Golang backend microservices is a bad choice for larger applications.
(If your SvelteKit backend try to talk to Dgraph database, or PocketBase, which are written in Golang then.. voilà you have a Golang backend 😅 no need for pros and cons)
1000% agree
You look like you will be one of my favorite creators
nice video
it’s great that you can call out your own biases!
yeah but fun is something
and i enjoy writing go more than ts
This just makes me not wanna use svelte to be honest
drizzle looks like sqlalchemy lol
first 😳
With something like HTMX and web components you can pretty much stay in the back end language you like. I built an HTMX-like library called HTMF (a fraction of the size) and it is amazing how dynamic you can make your apps with very little work (my apps are mostly just offline-first apps in JS built in ServiceWorker).
If you are building any application that will hit more than 1000 users, and that is relied upon by companies, you will not use a full stack framework.
If you make your frontend reliant on a backend that is so tightly nit together you will incur costs that are very big for not a lot. You would go from hosting your frontend application (note how I didn't say homepage or that, the application can take some time to load, zero loadtime is futile) on static storage-which is very cheap-to now needing to flash out a serverless instance, or a container just so the user can reduce 0.5 loadtime seconds off of an app they are already paying and takes a login to even view.
Also, if you now need to make the api accessible to a mobile app you can kiss goodbye to ever being able to invite someone else to help you, as they would need to also understand the frontend (it is what defines your api requirements, rather than a spec sheet).
There are very little upsides for not a lot of gain, whilst the downsides make it so scaling of any kind is incredibly expensive.
what about HTMX. do the same job without billion line of node module and build pack and hours of googling for cli commands, just html attributes (even http requests)
“Why are you using two backends when you can use one?”
Clearly, some people have never heard of BFF and distributed systems.
I think it's safe to assume vercel and plantscale have investor money behind them
and their pricing model won't last.
Ben, have you messed around with chatgpt generating sveltekit code for you? Also thanks for your great tutorial content!
ngl I cant believe I watched the first 3 minutes to find out this was a todo app.
this is great for MVP and BETA apps not for production
Yes, more advenced content on drizzle OEM, joins, relations, triggers will be super helpful 🎉
I mean, we are just building MPA's at this point
outstanding video! so much useful information
Sounds like you need htmx. 😉
Very wise by recognizing it and sharing it with us !
Have you tried PHP? ;-)
Go + htmx?
I honestly don't see Go as a good general backend language. It gives you incredible performance but requires too much work for some basic operations (like CRUD). Here in the company I'm currently working we have a microservices architecture and our backend stack is split between Laravel/NestJS for most of the operations and Go for specific flows that are required to be highly performant. We use Kafka for the internal communication between services.
Actually Go does not require much work for basic CRUD. Your problem is that you are making microservices that increase complexity ten fold since you need to also solve problems like data consistency, tracing, metrics, load-balancing, service-discovery, etc...
Great!
14:25 Super Duper
GOodbye Lang 😢
Extremely useful stuff Ben, thank you!
Bro you have been posting out really amazing content, love it 💖..!!
btw have you explored svelte + sst ?