I completely agree with this content. Developing in the JavaScript/TypeScript ecosystem is too complex and creates many external dependencies. I'm looking forward to the videos about Go language and HTMX.
recently i was on WeAreDevelopers conference in Berlin and my assumption after 3 days was that "Go and HTMX" is the way to go! I'm a bit confused how did it come that we don't have something like Nuxt 3 but with Go under the hood. but yeah, my sentiment is typesafety and multi page app (MPA) instead of angular + java/node can be my next thing to learn and master.
@@coolmemeguy474 because the page is "static" but the "runner" of this static page in this case is nextjs or Bun, so the docker container has to run nodejs or bun and also nextjs stuff even if is not needed so thats gonna eat ram, in my job we had already the same problems with memory. I'm with you in the case that for a really simple web app, just use vanilla react with vite. NextJs almost always is overkill.
says the guy that was born 15 years ago lol. Back in the 90's dev's did EVERYTHING. What is this "full stack" crap lol. We did that and were just called engineers. We also ran our own servers (not cloud) which meant building the hardware, installing at a colocation and installing IIS or Apache servers and database servers, etc. BUt I am glad Railway is here - Azure and AWS are just wayyyyyy tooo much overkill for 99% of projects.
Just a minor correction: Goroutines aren't new threads. They're a chunk of memory with their own stack that's managed and scheduled by the Go runtime and not the underlying os. So they're even lighter weight than threads. Also, I agree, using Go has been refreshing. There's some weird stuff about it that I'm not a fan of but ultimately you just have less clutter.
@@dhanielr Yes, green threads are not actual threads however. They're managed by the runtime of the language. Goroutines are managed by the Go runtime which means they're green threads.
There not OS threads, it's just GO handles the scheduling and stack, a single Thread as such can have many Go Routines running, but there still executing in another thread. So from a coding point of view, it's still worth thinking about them as Threads, because you will still need to think about race conditions, and Mutexes (locks) etc. In the end calling them Threads is not really that bad a thing to do.. :)
@@keithjohnson6510 Yeah I was also wondering, if they aren't managed by the OS does that mean they still run in a single OS thread or does go runtime run with kernel privileges? But I guess you partially answered that.
@@keithjohnson6510 Goroutines are not by default executed in another OS thread. They are executed in the same thread as the the main one... usually. But also, it's important to be specific with the language. Saying that you can use the idea of threads to conceptualize Goroutines would be appropriate because of course you'll still have concurrency issues but at some point, depending on the level of abstraction you're working in, that intuition may fail you.
Absolutely love all the investigative work you have been putting into comparing the performance of all these JS frameworks, I wanted to do this one day, and you made a compact RUclips video with a complete comparison, thanks! Also, I have been learning A LOT from multiple JS developers trying to find a better/less complex alternative to this crazy ecosystem. Personally, I chose Elixir, but watching your videos about Go is bringing a lot of new perspectives to the table
I went down the rabbit hole weeks back (actually saw your video on Elixir too!), and my conclusion is Elixir is probably the way. Go community doesn’t like or recommend meta/mvc frameworks. They expect devs to choose and bring their own batteries. Very little convention, very pro-configuration. From what I read, this is totally ok for small, and highly specific apps (dev tooling, light API, cpu-intensive background tasks), but you’d never reach Rails level of dev productivity. I think Elixir-Phoenix is the only ecosystem right now that gives you Rails level convention with scalability of Go. Only gotcha is that Elixir prioritizes fault tolerance over memory usage. So if you got insane traffic, and got Cody-level concern with memory, might wanna consider Go. Primeagen actually has a video on this
I wish there would be more Rust-like languages but that are actually friendly to developers, easy to understand and with big set of libraries. Unfortunately it's either one or the other.
I feel somewhat trapped in Nextjs due to my sheer developer productivity. But, I recently did a Go REST API to work with invoices and PDFs and it was such an amazing experience. The backend part is a lot easier to make right, however I feel that the React component model is something I really like for UI. Best of both worlds for me would be a tRPC-like experience, but the backend is Go instead of TypeScript. And usual vite+react on the front, so we don't have to deal with Nextjs specific issues
Completely agree. I'm currently trying to build out a starter template with Tanstack Router/React frontend + Go backend using OpenAPI/Swagger to get some decent typesafety between both. The more I use Go the more I love it - amazing standard lib + simple language.
I assume you probably already looked at this, but one thing I ran into with NodeJS is the garbage collection not working as fast as I wanted it to. And I found out that the memory limit for Node can be quite high, and if the memory usage is not close to the limit, the garbage collector won't do much as GC can be expensive. This memory can be limited in node with --max-old-space-size and BUN_JSC_forceRAMSize for bun.
Personally, I'm learning Rust now to make it my main programming language since I want to move away from JS/TS (7 years) and I don't want to go back to C++ (15+ years) while still be able to write robust applications (not only) for the web.
Smart individuals manage their own VPS and run a full suite of apps for just $10/month. Stupid people use third-party cloud providers and end up paying $300/month. LOL
Completely true, everything you said. I’ve been a full time dev for 13 years now (and many more years part time before that) and it’s pretty nuts how difficult it still is.
really good video, just started learning Go and i'm also not going to abandon JS or React since that is what paying my bills but going to use Go for my personal projects
10:55 This is where I think Go community needs to take notice of InertiaJS. It would be awesome to combine the efficiency of Go and the ability to still develop your FE using modern client side frameworks and then connect them using InertiaJS. I think Laravel community showed this to be the case and that combining mature backend technology with modern client side libraries is great combo.
@@yonas6832 To offload some of the work to the client (if you think that's a good thing - see SSR), use powerful and battle-tested frameworks to build the front-end, tap into a larger pool of FE developers, and so that presentation is strictly separate from data. Look, I appreciate efforts to eliminate JS, but I haven't been convinced that HTMX is a workhorse, so far I can only say with confidence that it's a Primeagen-endorsed meme.
Inertiajs works with most languages and frameworks imcluding go, inertiajs is mostly just a spec so you just need to implement it.. ive only used it with latavel and ive had a much better exp over nextjs wish tech influencers would push it more
The difference in memory and CPU usage would've been even more drastic if you had a lots of traffic. You can try to load test both apps. I can assure you that the javascript graph will be increasing over time pretty much in linear fashion while go graph will be very stable over time.
I would love to see some HTMX experiments from you. Maybe a comparison? Build an app twice. Once with Next and once with Go and talk about what you like about each approach.
Until Static Hermes becomes a reality, and then gets widely adopted, it's going to be either sacrifice dev speed and experience or sacrifice performance.
Love your content, 100% agree with go over node for a lot of stuff. One thing to note - NodeJS does have a thread api. You can, in fact, allocate a pthread (outside of async runtime) and run your tasks in the thread manager - which just passes the execution to a C executor. The V8 JS runtime also supports this, they call it "workers". Partytown is a famous wrapper for the workers api.
Don't worry we'll welcome you back to JS ecosystem. We won't judge you. 8:55 as a sidenote, I would definitely love if I could create a single binary Nodejs deployments. Would absolutely be a killer feature.
At the start of the video you gave me a glass, as the video progressed you filled it with KoolAid, by the end of the video I guzzled it down like a man in the desert.
Yes! I just built my static portfolio in Go, with just one dependency to parse Markdown files. Not as feature rich as Next or Astro of course, but it does what it needs to do and it was a such a nice change. Plus, when I come back to it in a years time, I can just jump back in and it won't be out of date or running on deprecated packages.
I'm with you on this man. I started having this mindset shift after Remix: simplify, leverage the platform. I'm down for creating open source self-hostable solutions, just need to put the effort
My issue with Go for pet projects is that for almost anything AI-based you'll need Python. So now you have to deal with 3 programming languages: Python, Go and TypeScript. I don't have brain capacity to remember ever growing quirk lists of each one of them :( So it's totally reasonable to look for a way to discard either.
Thanks for the video! What you said is really important. Hopefully the industry and major contributors will realize this and we will move in the right direction. I look forward to following your progress in Go as well!
Would like to point out that JavaScript is also technically "concurrent" in that it can execute multiple promises on a SINGLE thread by swapping between them. Goroutines, on the other hand, can be concurrent OR parallel, meaning they can run together on the same thread OR on separate threads. The Go "scheduler" is crazy flexible.
Wow, I have been feeling the same way lately. I've spent more time trying to fight with the ecosystem than I think it would take to learn a new language at this point.
I think that Gleam + lustre may actually be able to bring the "less is more" in fullstack development with all the benefits of JS/TS frameworks. It will take some time for it to mature, but it seems it may be a good solution for uncompromised full-stack development.
@@WebDevCody yeah I too wouldn't use shiny new languages for production apps ofc, but I wanted to mention it because it seems like it gives a solution to all the pain points mentioned in the video with the benefits of a single language for both server and client.
At my first internship building an insurance agency web application I was SHOCKED at the complexity of the system to simply check that some values were in a certain valid range and update the UI with a save button if valid for example. We were using a Vite React 18 project for the front end anD Java on the backend. The complexity came from all the infrastructure around all this though. Endless JavaScript dependencies and serverless Google resources all done with Terraform. We had GitHub build processes, cloud functions, micro services, etc, etc. My idea from web development in college was insanely simple compared to this! I still wonder why we weren't just using our Java backend to run certain calculations? Like why have a python cloud function run heavy mathematical workloads when you could truly multithread the same task in Java on the server? I guess our lead thought if 16 people all decided to compute 100 scenarios at once it might be faster? IDK I'm still a bit of a noob and don't understand all these types of situations.
For me it really comes down to what of these 3 costs matter the most to me: Time, Compute, People. Do I need to get this done ASAP? Do I have budget concerns with a mature application? Can I hire enough people? There is no one tool that addresses all of these, but you can usually have a few in your toolbox that solves one really well and the others good enough.
Golang is amazing and especially for devs starting out like me who wants to learn more. I’m trying go for some of the projects and I already observe how less overhead I’ve about dependencies, build tools, I’m able to spend more time writing business logic
You can START with no dependencies. Linter, formatter, test suite, http server, types, packaging. Don't forget updates, Go is using v1 since March 2012 and will not go v2. Node is constantly upgrading
I understand every word you said, and I agree. It kind of applies to my situation. I'm a developer who used TypeScript for almost two years, and I found it frustrating, especially with the `try`, `catch`, and `throw` keywords and how slow ts is, along with all the build tools and compilers out there. Then I moved to Go, and I liked it for its errors as values, but I started hating how unsafe it is. For example, if you have a struct with non-optional fields and create an instance of it without providing values for those fields, it doesn't complain. That's one of the reasons that made me switch to Rust. It's my fourth time crashing while learning it, but I'm okay for now, still fighting the borrow checker, and I believe I'll master it soon.
coming from javascript and typescript, it's a bit hard to complain about go being unsafe. the main reason I'm not too interested in rust is because I want to be productive. I'm sure rust is a great language after you spend a lot of time mastering it. I just need to be able to ship a real app and not worry about "fighting the borrow checker"
@@WebDevCody go have GC, i think it's ok until it isn't... I'm using sveltekit, if I will have the same problem like you, i will switch to static in sveltekit and go with rust backend. I know will be a fight with borrow checker, but i want to run with best speed possible and safest mode for me. thx
I've been coding JS for over 20 years and am 100% ready for a sea change. I really like your channel and will continue watching no matter what tech you promote.
I came to a similar viewpoint recently. Using typescript and a jillion dependencies to make a basic lambda rest api work (not to mention weirdness with mocking in jest with es6) has been getting on my nerves for a while. It's only when I started playing with go and I was like "wow, getting things built with go is actually so much simpler!" No more bundlers, barely any dependencies, not fighting with the type system all the time. It's bloody glorious! If it ends up being more performant than my nodejs lambdas, that would just be icing on the cake.
Great video, I've got a couple of websites live using the multi stage build trick, you can also embed static files directly into your binary which is pretty cool, you can even generate static files from react and include that. Go is my favourite language for apis but for full stack elixir and phoenix is *chefs kiss*
I always hear great things about Phoenix. Any performance concerns since elixir is not the speediest of languages? My guess is that due to its exceptional concurrency, it can still handle large page loads
@@charlesbcraig For the majority of web applications, performance differences between languages are negligible. While some languages are undoubtedly faster, these slight improvements rarely matter in 99% of use cases. Most 'faster' languages don't offer the same web development experience as Elixir with Phoenix. Although Go, Rust, C, or Java can achieve higher performance, it's worth noting that most of the web runs on PHP, Ruby, and Node.js. There's a reason these dynamically typed languages are frequently preferred. In this space, Elixir is more performant while offering an equal, if not better, developer experience. It strikes a balance between performance and development ease, making it an excellent choice for web applications. And yes as mentioned the concurrency offered by BEAM is pretty much the gold standard in all software rivalled pretty much only by Go which I'd probably pick if I was strictly building a service/API although it takes a bit more to get up and running.
After doing a project in Java for the backend and C# for the frontend (weirdest stack ever, I know we could've used just C# but that's uni lol), I presented the idea to my friends to use Go for the backend and Nuxt for the frontend. In the end we are going Go+Next, but I myself would've loved to sprinkle some HTMX in there just to see less JS/React, at least I'm not going to look at it when working in the backend lol
"If you are trying to get the same performance by writing the same code why not just do that" This is what I love about Go. You just get decent performance without really doing any optimizations. I don't know what video I watched were someone made a Go implementation of the wc tool in Linux (I think it was Theo). Without doing anything in terms of optimizations it was just as fast.
this is a nice direction tbh. I have just spent a couple days trying to optimise running two concurrent long running processes in node without blocking. Yes it was a skill issue on my part, and it does make sense to me now, but I had that same thought as you in my head.. is there a simpler way to achieve this without the complexity? Added to that all the build webpack/grunt/rollup mess compared to the one binary you get from a GO compilation that you can slap into a Docker container and call it a day.. I definitely understand where you are coming from as a JS dev of 8 years now. Looking forward to the new content, will be diving into GO with you
Have you had the chance to look at Elixir and PheonixLive? Looks like a fascinating alternative to having a JS frontend framework + convex db, would love to hear your thoughts on it
I feel like the ecosystem just normalized that. Sometimes i saw nodejs applications using 1.5gb ram or more and people think this is normal or "it just works, i change the code so easily so if the infra is cost to much doesnt matter because i can pay for that" But now we have so many good alternatives with the same "easily code changes" that I don't see why starting a new project in the same way, with the same dependencies that everyone has been using since 2019, in the exact same way and having several same and other problems, apart from memory usage, cpu usage or complexity as you said.
This is SO refreshing. I was feeling so gaslighted and exhausted after a decade as a contractor JS dev and am learning Go myself right now. I can remember distinctly being a USER INTERFACE developer, and transitioning to a refactorer. I cannot for the life of me remember the last time I actually built UI on a consistent basis. And then there is the case of side projects. Dear god, just getting the damn ecosystem to not go nuclear before even writing a single line of code is so debilitating. There is only so much overcoming of ADHD that can mitigate the total defeat experienced by LINTING breaking your project. And build systems dear god Grunt, Gulp... was triggered at Webpack.... And what makes all of this worse is all of the damn hype and marketing around all of these damn ecosystems confusing the shit out of all of us during our early career. Again, THANK YOU for this video. I feel less crazy. I'm excited about Go and HTMX!
Exporting it gives you html files, you need to host those html files, hosting them means a web server is running, now we are back to where we started. I guess I could host in a cdn like netlify pages, but where’s the fun in that
Would vue/react be somewhat okay? Since it's javascript that runs client side, so you will still have the same performant railway graphs (i think, idk :p).
I've just been thinking about learning either Rust or Go as a 2nd language, so this comes at a really good time! Super excited to see some htmx and go content!
I was learning Rust early last year but the team behind it does not give me confidence. They imposed too many restrictions on users with their "trademark", "Approval Requirements", and anti "open-source" restrictions. They have since gone back on these things (somewhat) but it left me with a sour taste.
I am trying to move from Backend to Frontend. I am proficient with Go however I have always found it difficult get into html CS & JS. Hopefully this new Go series will help ease into frontend development.
Ive been doing quite a bit of batch processing and longer running processes and such lately. The problem with next js is that once you’re able to do some backend stuff it’s like why not just have an actual server. And if you’re going to have an actual server…. just use go I’ve been using river queue and it’s really nice But yeah I agree with you on the ecosystem I was just getting so exhausted every time I start a new project. Built in test runner is nice though now
I’ve been running into this problem as well… Apps are being built but memory is an issue I’m probably gonna take the same route as you and change up the language I’m using. Could be Go but I’m open to others. Great vid and thanks for the insight!
I 100% understand the frustration with the javascript ecosystem as it relates to needing different constantly changing dependencies for different tasks. Next is massively overkill for a single page static website, yes but it's a shame that there isn't a performant standard lib for accomplishing the most common tasks. If you do come back to JavaScript I'd love to see you try out Astro. It seems ideal for your second webapp that was eating up 300megs in next.
@@WebDevCody Not necessarily. Node is the common choice but Astro is backend agnostic. My team's current project is using django rest api to serve static pages generated by Astro. It's been a solid balance of performance and React like frontend development.
I love using go with air, & htmx but my workflow is so bad without hot re-loading, having to refresh the page each time I change my styling is a workflow killer, shame as there are so many good benefits building apps this way.
This is one of the reasons I like the serverless function paradigm. Code starts, code runs, code shuts down. One of the biggest drawbacks to production javascript is completely negated simply by not having a long running service.
I love this. The state of the JS industry is just rotten. I had a technical challenge a while back where I wrote the most performant solution out of all candidates, but got rejected cause I didn't want to import React Query for caching a 400 byte request and "didn't split up my components like they are expecting from their developers". No one cares about performance anymore, or about cutting off bloat, all they want to see is another React Developer (TM) who writes the same application with the same stack 1000 times over regardless of the requirements or whether it will actually improve the experience for whoever is using the product. I've been using Go for the last year and the entire performance and efficiency-first culture that has been built around the language is just refreshing.
I really really appreciate that you point out problems of JS even though you monetise it. I guess this is my first like button to your videos, since it encourages the idea of “good coding” or “efficient product building” Thank you! Btw I feel that js has the “quick start” thingy, which hooks newbies easily and then they use all the bs that they don’t actually need. I am a backend dev, I am not a webdev, but I always though that js is beautiful and easy to start pile of crap. Would prefer to use go 100% when designing simple things at work
The free HTMx book got me to get go-pilled. Templ is absolutely goated DX, very tsx-ish. Built in testing also a W. A fantastic simple language that's easy to get into. No more eslint, prettier, tsconfigs garbage ever. Just as easy to do e2e testing with playwright or cypress whatever. Great stuff
It's not about which language, guys. It's about the compiler/runtime. Same Javascript code can have different performances results on Bun, Deno, LLRT... And If I would to change my main language, I will choose Zig.
What about using nextjs as a hybrid? Doing the ssr ONLY when it matters for seo and then rendering the rest on client. Surely this has to be a way more optimal solution? I think this is when that framework really shines, I don't really use it for anything else.
![Who Wrote a Short Story That Seriously Disturbed a Teacher? | Dirty Laundry x Smosh [Full Episode]](http://i.ytimg.com/vi/bvHAy_rKoEI/mqdefault.jpg)
![GEEK TIMË [OFFICIAL AUDIO]](http://i.ytimg.com/vi/ry-6RvkH880/mqdefault.jpg)
"Goodbye JavaScript (for now)" - guy who'll literally be staring at JS code before lunch tomorrow
Nice one lol
Lmao 😂
Ha ha ha aglly😢😅@@gamemoves2415
@@habong17359Ben reported or ready 6 times over
@@gamemoves2415l😅😅😢😅😢😮😮😮
I completely agree with this content. Developing in the JavaScript/TypeScript ecosystem is too complex and creates many external dependencies. I'm looking forward to the videos about Go language and HTMX.
recently i was on WeAreDevelopers conference in Berlin and my assumption after 3 days was that "Go and HTMX" is the way to go! I'm a bit confused how did it come that we don't have something like Nuxt 3 but with Go under the hood. but yeah, my sentiment is typesafety and multi page app (MPA) instead of angular + java/node can be my next thing to learn and master.
Videos like this make me wish RUclips had a 'super like' button. 300MB+ to serve a static page is insane
I don't get it. Why use Node/Bun for a static page in the first place? Just serve the static files with Nginx, Apache, or something else.
@@coolmemeguy474 he could've used kubernetes and we would be clapping our hands as react developers
There is a super like button: "$ Thanks" :)
@@coolmemeguy474 because the page is "static" but the "runner" of this static page in this case is nextjs or Bun, so the docker container has to run nodejs or bun and also nextjs stuff even if is not needed so thats gonna eat ram, in my job we had already the same problems with memory. I'm with you in the case that for a really simple web app, just use vanilla react with vite. NextJs almost always is overkill.
But Apache is soo boring and old fashioned 😭@@coolmemeguy474
I understand your mindset change and am eager to see more Go+HTMX content w/ performance metrics
Devops used to be separate from programming, now we are supposed to do it all, without the second salary. I miss the old days.
prolly because they are a lot of us with 99 years of experience
u forgot to say, do it all in one day, possibly b4 lunch or at 3am on call.
You know, database administrator was also a separate job
says the guy that was born 15 years ago lol. Back in the 90's dev's did EVERYTHING. What is this "full stack" crap lol. We did that and were just called engineers. We also ran our own servers (not cloud) which meant building the hardware, installing at a colocation and installing IIS or Apache servers and database servers, etc. BUt I am glad Railway is here - Azure and AWS are just wayyyyyy tooo much overkill for 99% of projects.
@@BillionaireDegenApeClubgo to sleep old man
Just a minor correction: Goroutines aren't new threads. They're a chunk of memory with their own stack that's managed and scheduled by the Go runtime and not the underlying os. So they're even lighter weight than threads.
Also, I agree, using Go has been refreshing. There's some weird stuff about it that I'm not a fan of but ultimately you just have less clutter.
Its not too wrong say that. Goroutines its like green threads.
@@dhanielr Yes, green threads are not actual threads however. They're managed by the runtime of the language. Goroutines are managed by the Go runtime which means they're green threads.
There not OS threads, it's just GO handles the scheduling and stack, a single Thread as such can have many Go Routines running, but there still executing in another thread.
So from a coding point of view, it's still worth thinking about them as Threads, because you will still need to think about race conditions, and Mutexes (locks) etc.
In the end calling them Threads is not really that bad a thing to do.. :)
@@keithjohnson6510 Yeah I was also wondering, if they aren't managed by the OS does that mean they still run in a single OS thread or does go runtime run with kernel privileges? But I guess you partially answered that.
@@keithjohnson6510 Goroutines are not by default executed in another OS thread. They are executed in the same thread as the the main one... usually. But also, it's important to be specific with the language. Saying that you can use the idea of threads to conceptualize Goroutines would be appropriate because of course you'll still have concurrency issues but at some point, depending on the level of abstraction you're working in, that intuition may fail you.
Good job babe!!
If my wife aint this supportive i dont want her
Yeah if it's not like this I don't want it 😂
thanks babe!
@@WebDevCody wish you can call me that 🥵
@@cslearn3044 not in front of his wife lol
Absolutely love all the investigative work you have been putting into comparing the performance of all these JS frameworks, I wanted to do this one day, and you made a compact RUclips video with a complete comparison, thanks!
Also, I have been learning A LOT from multiple JS developers trying to find a better/less complex alternative to this crazy ecosystem. Personally, I chose Elixir, but watching your videos about Go is bringing a lot of new perspectives to the table
I went down the rabbit hole weeks back (actually saw your video on Elixir too!), and my conclusion is Elixir is probably the way.
Go community doesn’t like or recommend meta/mvc frameworks. They expect devs to choose and bring their own batteries. Very little convention, very pro-configuration.
From what I read, this is totally ok for small, and highly specific apps (dev tooling, light API, cpu-intensive background tasks), but you’d never reach Rails level of dev productivity.
I think Elixir-Phoenix is the only ecosystem right now that gives you Rails level convention with scalability of Go.
Only gotcha is that Elixir prioritizes fault tolerance over memory usage. So if you got insane traffic, and got Cody-level concern with memory, might wanna consider Go. Primeagen actually has a video on this
I’ve been wanting simplicity for like 10 years. Just because we can, doesn’t mean we need to chew up all these cpu cycles and memory bloat
I wish there would be more Rust-like languages but that are actually friendly to developers, easy to understand and with big set of libraries. Unfortunately it's either one or the other.
@@darekmistrz4364 they say google's carbon lang is good, its compatible with c++ code and has good memory management
I've done this shift myself Cody. IMO just Go for it. It'll work out great!
I feel somewhat trapped in Nextjs due to my sheer developer productivity. But, I recently did a Go REST API to work with invoices and PDFs and it was such an amazing experience. The backend part is a lot easier to make right, however I feel that the React component model is something I really like for UI. Best of both worlds for me would be a tRPC-like experience, but the backend is Go instead of TypeScript. And usual vite+react on the front, so we don't have to deal with Nextjs specific issues
Completely agree. I'm currently trying to build out a starter template with Tanstack Router/React frontend + Go backend using OpenAPI/Swagger to get some decent typesafety between both. The more I use Go the more I love it - amazing standard lib + simple language.
@@brandon-t7s cool template idea, what's your github?
@@brandon-t7s Where can I follow your progress for this?
We are so BACK
PHP is the obvious choice if you're being objective and rational.
I assume you probably already looked at this, but one thing I ran into with NodeJS is the garbage collection not working as fast as I wanted it to. And I found out that the memory limit for Node can be quite high, and if the memory usage is not close to the limit, the garbage collector won't do much as GC can be expensive. This memory can be limited in node with --max-old-space-size and BUN_JSC_forceRAMSize for bun.
Personally, I'm learning Rust now to make it my main programming language since I want to move away from JS/TS (7 years) and I don't want to go back to C++ (15+ years) while still be able to write robust applications (not only) for the web.
How would Cloud Providers make money if we all started using go, rust etc which consume less resources?
JS in backend was always a trap created and pushed down the throat by big Cloud Providers.
Smart individuals manage their own VPS and run a full suite of apps for just $10/month. Stupid people use third-party cloud providers and end up paying $300/month. LOL
@zlackbiro I'm new in this field and want to join the smart people here. Could you tell me more about that?
@@Gabriel-ch7sx +1
@@Gabriel-ch7sx Ubuntu linux, NginX, pm2, Coolify. Investigate all of that...
Completely true, everything you said. I’ve been a full time dev for 13 years now (and many more years part time before that) and it’s pretty nuts how difficult it still is.
Especially in dev Nextjs eats alot of memory
really good video, just started learning Go and i'm also not going to abandon JS or React since that is what paying my bills but going to use Go for my personal projects
Exactly the same but instead of React is React Native 😅
10:55 This is where I think Go community needs to take notice of InertiaJS. It would be awesome to combine the efficiency of Go and the ability to still develop your FE using modern client side frameworks and then connect them using InertiaJS. I think Laravel community showed this to be the case and that combining mature backend technology with modern client side libraries is great combo.
if it's not stdlib, good luck.
why should we we have go templ + htmx
@@yonas6832 To offload some of the work to the client (if you think that's a good thing - see SSR), use powerful and battle-tested frameworks to build the front-end, tap into a larger pool of FE developers, and so that presentation is strictly separate from data. Look, I appreciate efforts to eliminate JS, but I haven't been convinced that HTMX is a workhorse, so far I can only say with confidence that it's a Primeagen-endorsed meme.
Inertiajs works with most languages and frameworks imcluding go, inertiajs is mostly just a spec so you just need to implement it.. ive only used it with latavel and ive had a much better exp over nextjs wish tech influencers would push it more
The difference in memory and CPU usage would've been even more drastic if you had a lots of traffic. You can try to load test both apps. I can assure you that the javascript graph will be increasing over time pretty much in linear fashion while go graph will be very stable over time.
I have no traffic and it's already drastic 🤣
So excited!! I started learning Go for the exact same reasons and will for sure be following your videos getting stuck in to the language
Invaluable words of wisdom. Welcome to Go
Templ + htmx feels like very lean VueJS. I absolutely love it.
This is so true, I recently had eslint using 4GB of RAM to lint a simple TS project which is crazy, I love how simple and minimal Go is.
Damn, we're winning him around 😂
I'm a bit slow, but I learn eventually
I believe Go is a nice middle ground between complexity and control over your application to lower level.
I would love to see some HTMX experiments from you. Maybe a comparison? Build an app twice. Once with Next and once with Go and talk about what you like about each approach.
Until Static Hermes becomes a reality, and then gets widely adopted, it's going to be either sacrifice dev speed and experience or sacrifice performance.
Love your content, 100% agree with go over node for a lot of stuff. One thing to note - NodeJS does have a thread api. You can, in fact, allocate a pthread (outside of async runtime) and run your tasks in the thread manager - which just passes the execution to a C executor. The V8 JS runtime also supports this, they call it "workers". Partytown is a famous wrapper for the workers api.
I love this arc
Don't worry we'll welcome you back to JS ecosystem. We won't judge you. 8:55 as a sidenote, I would definitely love if I could create a single binary Nodejs deployments. Would absolutely be a killer feature.
At the start of the video you gave me a glass, as the video progressed you filled it with KoolAid, by the end of the video I guzzled it down like a man in the desert.
😆
Yes! I just built my static portfolio in Go, with just one dependency to parse Markdown files. Not as feature rich as Next or Astro of course, but it does what it needs to do and it was a such a nice change. Plus, when I come back to it in a years time, I can just jump back in and it won't be out of date or running on deprecated packages.
Your videos are great! I think we ALL learning so much from you. Thank you! 😊
It's encouraging to see modern devs discovering what we already knew in 1999.
I'm with you on this man. I started having this mindset shift after Remix: simplify, leverage the platform. I'm down for creating open source self-hostable solutions, just need to put the effort
My issue with Go for pet projects is that for almost anything AI-based you'll need Python.
So now you have to deal with 3 programming languages: Python, Go and TypeScript. I don't have brain capacity to remember ever growing quirk lists of each one of them :( So it's totally reasonable to look for a way to discard either.
Who cares about AI?
this is really super interesting!! thank you for sharing your thought process and fruits of your experience!
thank you sir !!! you spoke what i was thinking exactly ,
I agree brother. Great video!
Thanks for the video! What you said is really important. Hopefully the industry and major contributors will realize this and we will move in the right direction. I look forward to following your progress in Go as well!
I'm a simple man, I see a new Gopher I press Like.
Would like to point out that JavaScript is also technically "concurrent" in that it can execute multiple promises on a SINGLE thread by swapping between them. Goroutines, on the other hand, can be concurrent OR parallel, meaning they can run together on the same thread OR on separate threads. The Go "scheduler" is crazy flexible.
Remember K.I.S.S? Stop following the next shiny thing and stick to simplicity.
Wow, I have been feeling the same way lately. I've spent more time trying to fight with the ecosystem than I think it would take to learn a new language at this point.
I think that Gleam + lustre may actually be able to bring the "less is more" in fullstack development with all the benefits of JS/TS frameworks.
It will take some time for it to mature, but it seems it may be a good solution for uncompromised full-stack development.
Not sure about memory usage of Gleam yet tho. I will build and deploy a simple gleam + lustre project later on Railway and check.
i'm not interested in using "new" tech
@@WebDevCody yeah I too wouldn't use shiny new languages for production apps ofc, but I wanted to mention it because it seems like it gives a solution to all the pain points mentioned in the video with the benefits of a single language for both server and client.
I love the mindset and thought behind this decision.
At my first internship building an insurance agency web application I was SHOCKED at the complexity of the system to simply check that some values were in a certain valid range and update the UI with a save button if valid for example. We were using a Vite React 18 project for the front end anD Java on the backend. The complexity came from all the infrastructure around all this though. Endless JavaScript dependencies and serverless Google resources all done with Terraform. We had GitHub build processes, cloud functions, micro services, etc, etc. My idea from web development in college was insanely simple compared to this! I still wonder why we weren't just using our Java backend to run certain calculations? Like why have a python cloud function run heavy mathematical workloads when you could truly multithread the same task in Java on the server? I guess our lead thought if 16 people all decided to compute 100 scenarios at once it might be faster? IDK I'm still a bit of a noob and don't understand all these types of situations.
For me it really comes down to what of these 3 costs matter the most to me: Time, Compute, People. Do I need to get this done ASAP? Do I have budget concerns with a mature application? Can I hire enough people? There is no one tool that addresses all of these, but you can usually have a few in your toolbox that solves one really well and the others good enough.
Thanks for making this one. I’ll learn GO now more seriously now.
Golang is amazing and especially for devs starting out like me who wants to learn more.
I’m trying go for some of the projects and I already observe how less overhead I’ve about dependencies, build tools, I’m able to spend more time writing business logic
Do you have an equivalent comparison with python?
Looking forward for more content on go with performance metrics. Let's GO
You can START with no dependencies. Linter, formatter, test suite, http server, types, packaging. Don't forget updates, Go is using v1 since March 2012 and will not go v2. Node is constantly upgrading
I understand every word you said, and I agree. It kind of applies to my situation. I'm a developer who used TypeScript for almost two years, and I found it frustrating, especially with the `try`, `catch`, and `throw` keywords and how slow ts is, along with all the build tools and compilers out there. Then I moved to Go, and I liked it for its errors as values, but I started hating how unsafe it is. For example, if you have a struct with non-optional fields and create an instance of it without providing values for those fields, it doesn't complain. That's one of the reasons that made me switch to Rust. It's my fourth time crashing while learning it, but I'm okay for now, still fighting the borrow checker, and I believe I'll master it soon.
coming from javascript and typescript, it's a bit hard to complain about go being unsafe. the main reason I'm not too interested in rust is because I want to be productive. I'm sure rust is a great language after you spend a lot of time mastering it. I just need to be able to ship a real app and not worry about "fighting the borrow checker"
@@WebDevCody go have GC, i think it's ok until it isn't... I'm using sveltekit, if I will have the same problem like you, i will switch to static in sveltekit and go with rust backend. I know will be a fight with borrow checker, but i want to run with best speed possible and safest mode for me. thx
I've been coding JS for over 20 years and am 100% ready for a sea change. I really like your channel and will continue watching no matter what tech you promote.
I came to a similar viewpoint recently. Using typescript and a jillion dependencies to make a basic lambda rest api work (not to mention weirdness with mocking in jest with es6) has been getting on my nerves for a while. It's only when I started playing with go and I was like "wow, getting things built with go is actually so much simpler!" No more bundlers, barely any dependencies, not fighting with the type system all the time. It's bloody glorious! If it ends up being more performant than my nodejs lambdas, that would just be icing on the cake.
This video is perfect! I am tired to use nextjs and typescript ecosystem.
Way to GO! Let’s bring back some simplicity and power.
Great video, I've got a couple of websites live using the multi stage build trick, you can also embed static files directly into your binary which is pretty cool, you can even generate static files from react and include that.
Go is my favourite language for apis but for full stack elixir and phoenix is *chefs kiss*
I always hear great things about Phoenix. Any performance concerns since elixir is not the speediest of languages? My guess is that due to its exceptional concurrency, it can still handle large page loads
@@charlesbcraig For the majority of web applications, performance differences between languages are negligible. While some languages are undoubtedly faster, these slight improvements rarely matter in 99% of use cases.
Most 'faster' languages don't offer the same web development experience as Elixir with Phoenix. Although Go, Rust, C, or Java can achieve higher performance, it's worth noting that most of the web runs on PHP, Ruby, and Node.js. There's a reason these dynamically typed languages are frequently preferred.
In this space, Elixir is more performant while offering an equal, if not better, developer experience. It strikes a balance between performance and development ease, making it an excellent choice for web applications. And yes as mentioned the concurrency offered by BEAM is pretty much the gold standard in all software rivalled pretty much only by Go which I'd probably pick if I was strictly building a service/API although it takes a bit more to get up and running.
Definitely in for the go switch. Let's do it 💪
After doing a project in Java for the backend and C# for the frontend (weirdest stack ever, I know we could've used just C# but that's uni lol), I presented the idea to my friends to use Go for the backend and Nuxt for the frontend. In the end we are going Go+Next, but I myself would've loved to sprinkle some HTMX in there just to see less JS/React, at least I'm not going to look at it when working in the backend lol
We always go back to simplicity, it is the natural arc
Nice video thank you... I would like to see a comparsion of Dart vs Go.
this docker config is 🔥
"If you are trying to get the same performance by writing the same code why not just do that"
This is what I love about Go. You just get decent performance without really doing any optimizations. I don't know what video I watched were someone made a Go implementation of the wc tool in Linux (I think it was Theo). Without doing anything in terms of optimizations it was just as fast.
this is a nice direction tbh. I have just spent a couple days trying to optimise running two concurrent long running processes in node without blocking. Yes it was a skill issue on my part, and it does make sense to me now, but I had that same thought as you in my head.. is there a simpler way to achieve this without the complexity? Added to that all the build webpack/grunt/rollup mess compared to the one binary you get from a GO compilation that you can slap into a Docker container and call it a day.. I definitely understand where you are coming from as a JS dev of 8 years now. Looking forward to the new content, will be diving into GO with you
Have you had the chance to look at Elixir and PheonixLive? Looks like a fascinating alternative to having a JS frontend framework + convex db, would love to hear your thoughts on it
I’ve touched elixir / phoenix for a day, seemed ok, I don’t like the syntax too much. Also not a fan of dynamic typing
I feel like the ecosystem just normalized that.
Sometimes i saw nodejs applications using 1.5gb ram or more and people think this is normal or "it just works, i change the code so easily so if the infra is cost to much doesnt matter because i can pay for that"
But now we have so many good alternatives with the same "easily code changes" that I don't see why starting a new project in the same way, with the same dependencies that everyone has been using since 2019, in the exact same way and having several same and other problems, apart from memory usage, cpu usage or complexity as you said.
This is SO refreshing. I was feeling so gaslighted and exhausted after a decade as a contractor JS dev and am learning Go myself right now. I can remember distinctly being a USER INTERFACE developer, and transitioning to a refactorer. I cannot for the life of me remember the last time I actually built UI on a consistent basis.
And then there is the case of side projects. Dear god, just getting the damn ecosystem to not go nuclear before even writing a single line of code is so debilitating. There is only so much overcoming of ADHD that can mitigate the total defeat experienced by LINTING breaking your project. And build systems dear god Grunt, Gulp... was triggered at Webpack....
And what makes all of this worse is all of the damn hype and marketing around all of these damn ecosystems confusing the shit out of all of us during our early career.
Again, THANK YOU for this video. I feel less crazy.
I'm excited about Go and HTMX!
its be interesting to see a rust vs go vs bun comparison for that mailing list implementation
If its a simple static page, why don’t you just export it from nextjs instead of having next/node running in the background??
Exporting it gives you html files, you need to host those html files, hosting them means a web server is running, now we are back to where we started. I guess I could host in a cdn like netlify pages, but where’s the fun in that
@@WebDevCody or S3 bucket + CloudFront
Would vue/react be somewhat okay? Since it's javascript that runs client side, so you will still have the same performant railway graphs (i think, idk :p).
I've just been thinking about learning either Rust or Go as a 2nd language, so this comes at a really good time! Super excited to see some htmx and go content!
Same
I was learning Rust early last year but the team behind it does not give me confidence. They imposed too many restrictions on users with their "trademark", "Approval Requirements", and anti "open-source" restrictions. They have since gone back on these things (somewhat) but it left me with a sour taste.
I'm here for the "GO" saga.
this title makes me feel sad i was hoping for an react/nextjs course LOL. keep the great work Cody. Cheers from Brazil
But why do you need so much JS for simple pages like that, for what functionality exactly? Why don't you use simple, tiny pure custom JS scripts?
I am trying to move from Backend to Frontend. I am proficient with Go however I have always found it difficult get into html CS & JS. Hopefully this new Go series will help ease into frontend development.
I am also looking forward for go. Although my frontend would be in Vite React but I am excited to build and run backend
attractive, I'm on board
Ive been doing quite a bit of batch processing and longer running processes and such lately. The problem with next js is that once you’re able to do some backend stuff it’s like why not just have an actual server. And if you’re going to have an actual server…. just use go
I’ve been using river queue and it’s really nice
But yeah I agree with you on the ecosystem I was just getting so exhausted every time I start a new project. Built in test runner is nice though now
I’ve been running into this problem as well…
Apps are being built but memory is an issue
I’m probably gonna take the same route as you and change up the language I’m using. Could be Go but I’m open to others.
Great vid and thanks for the insight!
Elixir
elixir is dynamically typed, not interested
What if we transpiled the current projects into Go? So the end result should be the same, but no real 'shifts'.
I 100% understand the frustration with the javascript ecosystem as it relates to needing different constantly changing dependencies for different tasks. Next is massively overkill for a single page static website, yes but it's a shame that there isn't a performant standard lib for accomplishing the most common tasks.
If you do come back to JavaScript I'd love to see you try out Astro. It seems ideal for your second webapp that was eating up 300megs in next.
I would bet money astro has the exact same issue since it uses node to run the server
For static pages, I have successfully used nextjs' static export in the past. Just run "next build" and host the files however you like, without node.
@@WebDevCody Not necessarily. Node is the common choice but Astro is backend agnostic. My team's current project is using django rest api to serve static pages generated by Astro. It's been a solid balance of performance and React like frontend development.
I love using go with air, & htmx but my workflow is so bad without hot re-loading, having to refresh the page each time I change my styling is a workflow killer, shame as there are so many good benefits building apps this way.
This is one of the reasons I like the serverless function paradigm. Code starts, code runs, code shuts down. One of the biggest drawbacks to production javascript is completely negated simply by not having a long running service.
Amazing work
Can you also check Asp's Blazor?
Amazing that at least some people manage to remain rational despite all the web stack exposure. Maybe Dijkstra rule is not as universal as we feared.
Would be super interested in more videos around this
I mean, performance is a funny, the thing here sounded more like memory, which is also a performance metric :D
I love this. The state of the JS industry is just rotten. I had a technical challenge a while back where I wrote the most performant solution out of all candidates, but got rejected cause I didn't want to import React Query for caching a 400 byte request and "didn't split up my components like they are expecting from their developers".
No one cares about performance anymore, or about cutting off bloat, all they want to see is another React Developer (TM) who writes the same application with the same stack 1000 times over regardless of the requirements or whether it will actually improve the experience for whoever is using the product.
I've been using Go for the last year and the entire performance and efficiency-first culture that has been built around the language is just refreshing.
Enjoyed the session, Cody!
I really really appreciate that you point out problems of JS even though you monetise it. I guess this is my first like button to your videos, since it encourages the idea of “good coding” or “efficient product building”
Thank you!
Btw I feel that js has the “quick start” thingy, which hooks newbies easily and then they use all the bs that they don’t actually need. I am a backend dev, I am not a webdev, but I always though that js is beautiful and easy to start pile of crap. Would prefer to use go 100% when designing simple things at work
You can move hella fast using js for the entire stack, I can’t lie about that
The free HTMx book got me to get go-pilled. Templ is absolutely goated DX, very tsx-ish. Built in testing also a W. A fantastic simple language that's easy to get into. No more eslint, prettier, tsconfigs garbage ever. Just as easy to do e2e testing with playwright or cypress whatever. Great stuff
i am still learning go. Would definitely like to see some htmx + go videos
Moreover, this is will trully help being "green IT". We cannot afford anymore using 250MB of RAM just to display a single static page.
I am totally agree with you man.
It's not about which language, guys. It's about the compiler/runtime. Same Javascript code can have different performances results on Bun, Deno, LLRT... And If I would to change my main language, I will choose Zig.
Welcome to the native development crowd (Go, Rust, C, Zig) ❤
Can't wait to see shadcn/ui in Templ version
What about using nextjs as a hybrid? Doing the ssr ONLY when it matters for seo and then rendering the rest on client. Surely this has to be a way more optimal solution? I think this is when that framework really shines, I don't really use it for anything else.