JS devs really are spoiled with great developer tools that enhance the experience. It becomes hard to move away from that into a dev world that's more raw, lower level, verbose, etc.
24:00 I wanted to try this for myself - it took me 10 minutes to make a basic kanban board in html+css - it took another 10 minutes to make a typescript API that generates A kanban board from a config and has an API to add more nodes at runtime - it took 5 minutes to add drag/drop using sortablejs So 25 minutes in total, and I have full control over the design and logic so no risk of needing to fork/vendor/contribute to a third party package later down the line I agree that the modern js ecosystem is undervalued by outsiders, but I think you overvalue the benefit of frameworks and third-party libraries.
Also this was from scratch after exclusively using tailwind+jsx for the last 2 months. So if I used my stack of choice it would probably take just 15 minutes ;)
yeah, I don't doubt it. There are existing vanilla javascript libraries out there that also achieve that a react module provides (often react modules just import the javascript libraries anyway). Like I said in the video, it could all just be bias talking.
@@WebDevCody Mhm, Embla is a good example of this. Best carousel library out there. (It's also what shadui uses). I'm a bit bummed that a lot of the innovation going on these days is tied to specific frameworks like react so it's understandable why you stick to it, going vanilla definitely requires more experimentation to get great DX
That won't solve all the problems for sure. And I like the final take, as an independent developer you need to use the tools that make you faster for the product you are using.
Good job babe!!!!….but also howwww embarrassing LOL I’m kidding! Glad you learned and owned up to it and circled back :) one of the best character traits is being receptive to learning and growing and changing your way of doing things :) also, you’re allowed to change your mind don’t let anyone except me tell you otherwise 😊😂 love you!
Feels like a lot of issues were related to templ/htmx. I’d really encourage you to try Go with a react or svelte front-end. You can also share types with protocol buffers between back and front-end.
As for the state in HTMX vs React/Vue, you might have solved that problem by updating the URL to reflect the state. With HTMX, any state change should be reflected in the URL via slugs and params. Also too, then the user has better UX when changing web pages and going back. This is a major problem in many frontend data based solutions. Edit: Of course you can do this with frontend frameworks. But let's not pretend that devs often don't forget/care/agree to do it since the frameworks lean harder into not using the URL outside of page routing.
Yep, I wish more devs would understand this. This is such an annoying problem most modern web apps have. Client side JavaScript state should be a last resort for things like this. It doesn’t matter what framework you use, the majority of view states can, and should, be represented in the URL. If it can’t then you likely have a design problem. Browsers are designed to work with state in the url. It makes everything so much simpler, both for the devs and for the user.
the problem lies deeper Java and c# have similar issues. Go and Rust are compiled languages, they can make heavy use of the stack an are optimizing memory deallocation at compile time.
Thanks for sharing the journey, I'm facing a simliar problem - trying to find a language and stack that fits with my way of working. I appreciate you going through the thought process and what you tried, great video
If you use parseInt() in JS, it returns NaN, and then you need to be checking it with isNaN, or you WILL have some kind of insane bug in JS at runtime, in production. Handling your errors at the source is better programming. It would be nice if stuff magically handled the errors, but it doesn't and can't, it's part of writing program logic. Just because JS devs often don't pay attention to these kinds of things doesn't make JS better, it makes it worse. Handling errors are part of programming the logic of your application.
@WebDevCody and thats fine. Those are not comparable. But you know more now. Btw I'm working with many different langs at work and switching doesn't take longer than 15min.
I think go works amazing for things like REST services, microservices, CLI apps, even scripting etc. since don't need to jump into UI templating and the back and forth with your editor not knowing where to jump to. But I agree with you on basically any other language solution for templating/UI. I've yet to encounter anything that comes close to the dev experience you get in the JS ecosystem with JSX. Sure its less performance but theres a reason so many people develop with it - because its that easy and productive.
Hello Cody! I've been using and learning golang too, and i wanted to add that in regards to 5:05 in the video (the ParseInt convertion being too verbose) i've been using strconv.Atoi() to use string to integer conversion. Example: scoreQuery := req.URL.Query().Get("score") score, err := strconv.Atoi(scoreQuery) You will still need to handle the error in case the provided Alphabetic letter or character is not valid, but i find Atoi to be more simpler because it defaults to the values of ParseInt that i mostly need in my apps. Hope it helps in case u didnt know and plan to return to use golang in the future 🤣!
If you want the performance of go with the familiarity of TS/JS then c# is going to probably be your best choice. With that said I still try to just do everything as a monolith in Next.js. Only go n-tier when I absolutely need too
exactly. While I love C#, for most cases (unless you already know you are creating for tens of thousands of users), start with Next.js, then maybe just proxy some more demanding requests into a faster backed in C# or Go. At some point you can just fully proxy everything except maybe authentication straight to the faster backend, and you should be fine. For me, I will always start with C# backend and JS frontend - I just hate working in JS so much by comparison. Even with TS - it's so easy to break the types in TS, plus it comes with all the JS bullshit like type coersion, truthy values etc. Let that live just in the browser :)
I appreciate your honesty i almost got influenced in starting developing in go thanks to you, really liked the first video. It's a relief to know that you published a valuable opinion based on actual experience before i jumped into this.
I've gotten influenced though I've always wanted to learn a simpler, faster language compared to JS, Python. It's certainly... interesting to learn the Go way but the journey is cool.
Web components would DEFINITELY help your frustration with inline js in htmx and weird ids everywhere. The disconnect between event listeners and html is a big pain point for me, but web components make it extremely clear where the behaviour is defined
Try new things is really essential for a programmer. Even if you go back to what you were doing before, you learn something new and appreciate the traits of the previous technology more. It wasn't a waste of time. It's about the journey, as they say. Great video.
Thanks for your transparency. I think we can take a page from natural selection and apply it to code-life: "live where suffering is sustainable and thriving is ample." Keep learning though. Who knows where weird ideas and insights will drop while learning other languages.
Regarding being able to create components right in the handler, I don't know about fiber, but echo allows you to return an HTML response from a string using context.HTML(code int, html string). It's a string so you don't get any syntax highlighting, etc., but it works in a pinch.
Welcome back.. What I been hearing from you this entire video is that the JS eco system has had time to mature and evolve into what it is today. It's had a ton of extremely smart companies / individuals innovate over that time. And it has been the base language for the browser since the beginning.
@@sama7496 agreed, though i would love some easy integration whereby i could kick off goroutines from the nextjs endpoint when i have something more intense to do. i hate workers api. sharing the orm would be sick as well, so maybe something like a prisma schema generating both a ts ang go client, which some tech that easily allows me to inline go in my nextjs endpoints when needed. this is what i dream of
I don't doubt it, but like I said at this point I'm starting to see more value in just having a single monolithic self contained application in a single language
I think if you cant save to DB its still better to handle the error rather than panic. Panic should be reserved for when the system reached an unrecoverable internal state. An error on failed db write can be retried, ignored and maybe the write is pushed to some queue to retry later or simply respond with a system error. I dont think you want to panic there. Edit: cody literally says this in the next sentence lol 😂😂😂 fml
It's great that you're exploring. It gives us a good POV too. I tried Go and I agree that for an individual project or a small team, it's overkill for two languages.
This is exactly me. I've tried other languages and massively respect some of the strengths that they have over js, but mental comfortability is key with me. My brain just clicks with js. I'm much more productive with it because I enjoy it.
As much as I love Go, I agree with your take. Tried htmx and templ and results in terrible UX (and DX too). But I do think backend performance and static type is really important. That’s why I still use Go + React but no NextJS
@@blessdarah1256 What sucks with Laravel after being in the typescript land for a bit is the intellisense, esp. for Models(read DB columns). Some guy just came up with Laravext, which brings file routing like nextjs, and another guy developed a custom composer command to generate types from barryvdh/ide-helper plugin. I'll be back once those two ideas get smoothed out coz Laravel is just a beast
Hey Cody, regadring the interpolation - I think this pain is mostly related to not using a logging library, e.g. uber-go/zap, which might simplify writing logs by removing the need to do an interpolation in the first place.
I got the same issue with my lsp go to definition that just keep me opening the generated templ go files. I solved this issue by hijacking in neovim my lsp go definition to look if the result file is a templ generated file to instead open the original file but I know this solution is not as easy as pressing a button. But I don’t know how you could easily solve that without that kind of middleware since go lsp to definition is made to open golang file and templ file are not go files… Anyway I understand your decision, nobody here is here to say to don’t quit golang. You didn’t feel confortable, that’s right. I feel confortable in Golang, I always find C sprintf good. I have created my own micro framework with tools to helps like form validation. I hope your future project to success ❤
i'm tending towards using Go in the backend next or plain react in the front. i usually prototype my features in next, there i get to basically ship something to get feedback, if it becomes important, i just extract the backend stuff in a golang api, i keep next just for whats its for (front + bff)
Complex software that uses this stack is the open core Gitea project and its open source fork Forgejo. I don't like this stack either, it's making the UX bar low and making the UI development slow, but yeah that's a real world example.
Good call mate! I have tried HTMX as well and honestly I didn't like it, it just didn't click for me. The issue with state is spot on, like not having the various components have a shared state is so weird, and the concept of HTM is probably that all your state should derive from your server, but for something like a loading button or some dynamic text it really sounds silly. And the introduction of some random vanilla JS scripts makes so much weirder. Don't feel bad about being a NextJS developer, you are a very good one so no shame from me 👍
always learning, great stuff! the easiest way to integrate js frontend and non-js backend is to generate client sdk from backend's openapi definition or grpc protobuffers
I am using astro with htmx. I do use react component when it is nedded. Dailsy ui helps me to write astro server components . productivity increased 2x as i am writting less js compared to my previous Next js project. I develop my apis using c# which i am familiar with.
Btw about error handling in Go. Yeah it's verbose. But instead of panicking you can just return errors in your route handlers. Whatever library you use usually have top error handler and it will return 500 to the end user. So no need to panic errors actually. But yeah at the end, you need verbosely return error in every function under handler so it goes up. In that sense js is easier cuz if you use async functions and something throws you don't need to push error up in the tree.
We definitely not angry I went on that journey to and it really allowed me to appreciate JavaScript, my main language are JavaScript ,C++, and csharp. I use JavaScript for web, c++ for memory projects, and csharp for game modding. I tried to replace JavaScript with go, and was not a good experience
Appreciate you gave it a good go, most people dont even try it without expressing their opinions and if they do it then i doubt they would invest 2 weeks :)
my problem with go is that it's too simple. their vision of simplicity is too extreme. you have to reinvent the wheel every time you use it. i much prefer rust. a lot of typescript developers would enjoy rust if they tried it. i've been building all of my side projects with leptos for close to a year now. it's a simpler version of next.js with a lot of the same capabilities. it has signals like solid js, different rendering modes, progressive enhancement, colocated server functions, islands, and the bundles aren't bad at all.
I never understood these holy wars that developers get into when it comes to languages, frameworks, and tech stacks. These are not your identify as an engineer. They are just tools and each of those tools have tradeoffs. Pick the tools that have the tradeoffs you need for the project you are working on.
Right but when you hear people saying how awesome something is, you kind of want to try it, but then you find it’s actually not that great so basically you learn everyone just sucks
you sound a bit picky 😅 experience talking I suppose, after 10y into something difficult to get out, you became really confi in your stack. understandable. I agree on many point, and it is maybe a specificity of Htmx, to use Tmpl in Go... sound very weird to me, first I would never think to use Go for something else than the backend... having this htmx frontend stuff incorporate in it feel wrong and over complicated. Htmx / Go is probably not the right tech stack. I don't think I will give it a try. If I need to build a frontend I simply use JS/react and it work very well with my Go backend. I will give a look at your JS content, good continuation 👍
This feels more like a comparison of go vs next, I mean did you try hono or so? it lets you write straight jsx. if you find htmx limiting, I'm on team alpine. you mention it too, have you tried it properly? seems to me there are plenty of things in between htmx - next
Maybe i dont understand because im a backend developer, but, in my mind, frontend and backend is always separated. What is all of these templates? Why not use your frontend and leave the backend only to go?
Literally after watching your video about performance in JS I decided to give it a try with GO and I'm enjoying it a lot so far. So thank you anyway hah😀!
a few libraries and tools seems wonderful and revolutionary at first glance, but over the time you realize one day you realize that everything becomes ugly at the highest levels, with the added complexity intrinsic that comes with real problems maybe this is how the life works, there's no way around, let's embrace complexity as a requirement to win.
today i implemented a pick, extend, omit for a custom code generator that can create types from other types. you can only really do this in ts all fully typed and checked. cant beat it.
look, it's not that hard, if you're building sites or web apps, stick to php or js go is for servers and networking (think consul, docker, kubernetes) if you are building drivers, games, audio, cad, trading systems, then other languages are for you
Haters gonna hate and never ship :) If you like next and TS on the backend, just do it. Most of the apps we, as developers, are building are simple web apps that TS on the backend can easily handle, and if you know it, it gives you tons of productivity.
The problem is that HTMX is like AJAX made easy, but Alpine is like a client-side interactions made easy. In the case of the kanban, in alpinejs there is a way you can achieve that drag-and-drop functionality like many others, i see has chrome devtools extension, even theres a plugin Alpine-AJAX.
If you still demand low memory usage, with C# AOT, you can try blazor which is a readable frontend framework. It has a great comunity and tooling for components like sort, tables, counter, etc.
It was fun and informative to see someone else explore go and htmx. I heard good things about it too but when I watched you try it and said nah from the first video. Not because of a specific reason, it just didn’t look appealing to me. Strange looking syntax maybe 🤷🏻♂️. Thank you for trying those things for us. I’m glad I picked react and next… made me realize how good we have it on this side. The videos were really helpful to bring that to light.
Pretty much same for me, I tried htmx + Templ, it's good and for sure in the right direction. But it's not at the same level of polish as Next.js, the tooling around Templ and htmx is not quite there. The lack of good autocomplete and small things makes it very hard to work with, especially when refactoring or updating the code. I find Go itself an excellent language, but for now, I think I would only use it if I need performance. I'll build a robust API with it and consume it in React/Next. Or building a performant CLI, a special service or something like that. For productivity stuff I think nothing beats TypeScript/Next.js/Convex or some stack like that.
How dare you! 😂 Its really hard to give up the smooth route transitions and client-side states. For personal projects though, I use HTMX and a compiled language like Rust since I'm the only one to use it and no one would complain that the UI/UX sucks :D Can you do nextjs and go backend instead?
Mane you need to use neovim/LazyVim distro and read the keymaps lol. Add lazygit and some other typescript stuff. It’s weird seeing you use the mouse lol. e to open and close the menu, w to switch windows, gg to do git stuff, ft to open floating terminal, at the min. ask AI to write the configs to add in whatever vscode shortcuts you like
For backends, I still prefer using something other than JavaScript, like Kotlin, .NET, Java, or even Swift now. I initially loved Go, but once you have to write a lot of it, including integration tests and other necessary components for a robust API, it stops being enjoyable.
Enjoyed this series! I always felt like the React + Next ecosystem is too strong for Go + HMTX, despite the performance wins. I'd love to write a dedicated API in Go, but I think it's JS for HTML/CSS. Your Go complaints are where I've found Swift to shine. Flexible importing, interpolation, not verbose (actually, I think a lot of times it's too terse), etc.
I can’t wait to primagen reacting to this haha
Primeagen used to write C#, so he’s obviously a dummy since it’s the best language and he left it.
JS devs really are spoiled with great developer tools that enhance the experience. It becomes hard to move away from that into a dev world that's more raw, lower level, verbose, etc.
You could rename this video title to: 10 years of js vs 2 weeks of go
24:00 I wanted to try this for myself
- it took me 10 minutes to make a basic kanban board in html+css
- it took another 10 minutes to make a typescript API that generates A kanban board from a config and has an API to add more nodes at runtime
- it took 5 minutes to add drag/drop using sortablejs
So 25 minutes in total, and I have full control over the design and logic so no risk of needing to fork/vendor/contribute to a third party package later down the line
I agree that the modern js ecosystem is undervalued by outsiders, but I think you overvalue the benefit of frameworks and third-party libraries.
Also this was from scratch after exclusively using tailwind+jsx for the last 2 months. So if I used my stack of choice it would probably take just 15 minutes ;)
yeah, I don't doubt it. There are existing vanilla javascript libraries out there that also achieve that a react module provides (often react modules just import the javascript libraries anyway). Like I said in the video, it could all just be bias talking.
@@WebDevCody Mhm, Embla is a good example of this. Best carousel library out there. (It's also what shadui uses).
I'm a bit bummed that a lot of the innovation going on these days is tied to specific frameworks like react so it's understandable why you stick to it, going vanilla definitely requires more experimentation to get great DX
Welcome back to the dark side 😜
Let’s go!
can't escape nextjs
its time for cody to actually come to the real dark side: rust and do even html in rust macros.
"The light is dark, the dark is dimly lit." - MacBird, a Kennedy-centered McBeth parody by Barbara Garson (1966)
The love-hate relationship with JS is the one thing that makes us JS devs
This is the most mature video I have seen from you in my opinion, not talking techwise but being mature in general and being honest.
Thanks man...
I grow up so fast don't I
@@WebDevCody I struggle when going back on what I say most of the time, that's what I mean, congrats again
The easy way out would be to keep going with that one for a few more days and start adding javascript back to the main content without anyone noticing
Instead of the button and the hx-include, you should use a normal HTML and a submit button . In that case it will post everything inside the form.
That won't solve all the problems for sure. And I like the final take, as an independent developer you need to use the tools that make you faster for the product you are using.
Good job babe!!!!….but also howwww embarrassing LOL I’m kidding! Glad you learned and owned up to it and circled back :) one of the best character traits is being receptive to learning and growing and changing your way of doing things :) also, you’re allowed to change your mind don’t let anyone except me tell you otherwise 😊😂 love you!
thanks babe! love you!
It's weird how she always responds like that on every video. Share your affection at home, it's weird in the comment section.
@@damonguzman go be miserable somewhere else.
@@damonguzman just scroll past if you don't like it
wholesome couple, love it
Feels like a lot of issues were related to templ/htmx. I’d really encourage you to try Go with a react or svelte front-end. You can also share types with protocol buffers between back and front-end.
I don’t need to try go again to agree it’s good for a rest api
As for the state in HTMX vs React/Vue, you might have solved that problem by updating the URL to reflect the state. With HTMX, any state change should be reflected in the URL via slugs and params. Also too, then the user has better UX when changing web pages and going back. This is a major problem in many frontend data based solutions.
Edit: Of course you can do this with frontend frameworks. But let's not pretend that devs often don't forget/care/agree to do it since the frameworks lean harder into not using the URL outside of page routing.
You can do all that with React and Next with the gazillion other DX perks.
Yep, I wish more devs would understand this.
This is such an annoying problem most modern web apps have. Client side JavaScript state should be a last resort for things like this. It doesn’t matter what framework you use, the majority of view states can, and should, be represented in the URL. If it can’t then you likely have a design problem.
Browsers are designed to work with state in the url. It makes everything so much simpler, both for the devs and for the user.
@@harrybarden5438 yup
1 Million subscribers is programmed for this man.
I got to give the people what they want
anthony it's been a while. I used to regularly watch your content.
Let's hope bunjs, nodejs etc. Are able to solve those memory issues
the problem lies deeper Java and c# have similar issues. Go and Rust are compiled languages, they can make heavy use of the stack an are optimizing memory deallocation at compile time.
Thanks for sharing the journey, I'm facing a simliar problem - trying to find a language and stack that fits with my way of working. I appreciate you going through the thought process and what you tried, great video
If you use parseInt() in JS, it returns NaN, and then you need to be checking it with isNaN, or you WILL have some kind of insane bug in JS at runtime, in production. Handling your errors at the source is better programming. It would be nice if stuff magically handled the errors, but it doesn't and can't, it's part of writing program logic. Just because JS devs often don't pay attention to these kinds of things doesn't make JS better, it makes it worse. Handling errors are part of programming the logic of your application.
Why not solid start? Would like to see it
it's friday I'm in love with javascript again.
Dont be so attached to things. Learn to let go.
I let go of go, and I’m ok with that
@WebDevCody and thats fine. Those are not comparable. But you know more now. Btw I'm working with many different langs at work and switching doesn't take longer than 15min.
@@TheJubeiam weird flex
@@TheJubeiam That's not as impressive as you think it is. 15minutes is a really long time vs 0 context switch time.
I think go works amazing for things like REST services, microservices, CLI apps, even scripting etc. since don't need to jump into UI templating and the back and forth with your editor not knowing where to jump to. But I agree with you on basically any other language solution for templating/UI. I've yet to encounter anything that comes close to the dev experience you get in the JS ecosystem with JSX. Sure its less performance but theres a reason so many people develop with it - because its that easy and productive.
Hello darkness my old friend...
Hello Cody! I've been using and learning golang too, and i wanted to add that in regards to 5:05 in the video (the ParseInt convertion being too verbose) i've been using strconv.Atoi() to use string to integer conversion. Example:
scoreQuery := req.URL.Query().Get("score")
score, err := strconv.Atoi(scoreQuery)
You will still need to handle the error in case the provided Alphabetic letter or character is not valid, but i find Atoi to be more simpler because it defaults to the values of ParseInt that i mostly need in my apps. Hope it helps in case u didnt know and plan to return to use golang in the future 🤣!
If you want the performance of go with the familiarity of TS/JS then c# is going to probably be your best choice. With that said I still try to just do everything as a monolith in Next.js. Only go n-tier when I absolutely need too
exactly. While I love C#, for most cases (unless you already know you are creating for tens of thousands of users), start with Next.js, then maybe just proxy some more demanding requests into a faster backed in C# or Go. At some point you can just fully proxy everything except maybe authentication straight to the faster backend, and you should be fine.
For me, I will always start with C# backend and JS frontend - I just hate working in JS so much by comparison. Even with TS - it's so easy to break the types in TS, plus it comes with all the JS bullshit like type coersion, truthy values etc. Let that live just in the browser :)
I appreciate your honesty
i almost got influenced in starting developing in go thanks to you, really liked the first video.
It's a relief to know that you published a valuable opinion based on actual experience before i jumped into this.
same, still seems like a good option for pure backend tho
Sheep
why not just try it out for yourself and make your own opinion?
He said nothing about developing in Go
Go is far superior backend language, he is talking about htmx + templ which sucks 😅
I've gotten influenced though I've always wanted to learn a simpler, faster language compared to JS, Python. It's certainly... interesting to learn the Go way but the journey is cool.
Web components would DEFINITELY help your frustration with inline js in htmx and weird ids everywhere. The disconnect between event listeners and html is a big pain point for me, but web components make it extremely clear where the behaviour is defined
Have you tried hyperscript or surreal?
And wrt the params parsing - there are `c.Params` and `c.BodyParser` functions
Try new things is really essential for a programmer. Even if you go back to what you were doing before, you learn something new and appreciate the traits of the previous technology more. It wasn't a waste of time. It's about the journey, as they say. Great video.
Thanks for your transparency. I think we can take a page from natural selection and apply it to code-life: "live where suffering is sustainable and thriving is ample." Keep learning though. Who knows where weird ideas and insights will drop while learning other languages.
Regarding being able to create components right in the handler, I don't know about fiber, but echo allows you to return an HTML response from a string using context.HTML(code int, html string). It's a string so you don't get any syntax highlighting, etc., but it works in a pinch.
Welcome back.. What I been hearing from you this entire video is that the JS eco system has had time to mature and evolve into what it is today.
It's had a ton of extremely smart companies / individuals innovate over that time.
And it has been the base language for the browser since the beginning.
Go backend + Nextjs frontend is 👌👌
I don't think that's the best way to use nextjs tho. nextjs works better when you make the backend also with it imo
@@sama7496 agreed, though i would love some easy integration whereby i could kick off goroutines from the nextjs endpoint when i have something more intense to do. i hate workers api. sharing the orm would be sick as well, so maybe something like a prisma schema generating both a ts ang go client, which some tech that easily allows me to inline go in my nextjs endpoints when needed. this is what i dream of
I don't doubt it, but like I said at this point I'm starting to see more value in just having a single monolithic self contained application in a single language
use protobuffers for your backend and frontend types and it's honestly pretty great
@@WebDevCodyI can’t live without full stack typesafety. From the db orm to client form and back again through the mutation.
I think if you cant save to DB its still better to handle the error rather than panic. Panic should be reserved for when the system reached an unrecoverable internal state. An error on failed db write can be retried, ignored and maybe the write is pushed to some queue to retry later or simply respond with a system error. I dont think you want to panic there.
Edit: cody literally says this in the next sentence lol 😂😂😂 fml
Once you are in JS world, it's hard to get away from it 😂
IMO it's good to pick
- TS for flexibility and developer speed
- Go for runtime performance and memory efficiency
HTMX for using hypertext (the H in HTTP) instead of JSON
Thank you for being honest. You did a great job explaining that it's not all bells and whistles as they say.
It's great that you're exploring. It gives us a good POV too. I tried Go and I agree that for an individual project or a small team, it's overkill for two languages.
What if you use React + Go? Would it be any different? I'm new to coding sorry for the noob question
Rails dev that somehow ended up watching hours of t3 today and you were on his latest vid with this one: so kudos to you and gogo 1M subs :D
so accurate. had the same experience with go, the lack of community (and all its implications) is the biggest deal
Glad to have you back! Hoping to see more Next.js content from you ❤
This is exactly me. I've tried other languages and massively respect some of the strengths that they have over js, but mental comfortability is key with me. My brain just clicks with js. I'm much more productive with it because I enjoy it.
As much as I love Go, I agree with your take. Tried htmx and templ and results in terrible UX (and DX too). But I do think backend performance and static type is really important. That’s why I still use Go + React but no NextJS
Is it better compared to NextJS? I'm a new programmer and I would really love your input on this
@@MnamesJeff not a NextJS expert, I only learn it a bit. but I think React is simpler if you don’t realy need server side rendering
My case, I use Go for everything until I have 1 bit of html+css+js, then I switch to the TS ecosystem. Frontend or fullstack? TS. Everything else? Go.
In the same way I have just decided to stay with Laravel because it just works and I am able to achieve speed.
@@blessdarah1256 What sucks with Laravel after being in the typescript land for a bit is the intellisense, esp. for Models(read DB columns). Some guy just came up with Laravext, which brings file routing like nextjs, and another guy developed a custom composer command to generate types from barryvdh/ide-helper plugin. I'll be back once those two ideas get smoothed out coz Laravel is just a beast
this is not a wast of time. learned a lot from your journey. thanks
If you want both performance and devx, then .NET Core is the way
if you're into OOP then sure...
This. Why do people try PHP before dotnet lol
Perhaps there is a case to try out .NET as your last thing to try!
DX from microsoft? .NET devs begging microsoft to stop adding new features to language every 2 years
Will you make this public? Your original video was shared with me so I'd like to update my colleague with the latest
Yes at 9am
Hey Cody, regadring the interpolation - I think this pain is mostly related to not using a logging library, e.g. uber-go/zap, which might simplify writing logs by removing the need to do an interpolation in the first place.
yep, that's how it is, coming back fresh from burnout to use your favorite tool again is life!
I got the same issue with my lsp go to definition that just keep me opening the generated templ go files. I solved this issue by hijacking in neovim my lsp go definition to look if the result file is a templ generated file to instead open the original file but I know this solution is not as easy as pressing a button.
But I don’t know how you could easily solve that without that kind of middleware since go lsp to definition is made to open golang file and templ file are not go files…
Anyway I understand your decision, nobody here is here to say to don’t quit golang. You didn’t feel confortable, that’s right.
I feel confortable in Golang, I always find C sprintf good. I have created my own micro framework with tools to helps like form validation.
I hope your future project to success ❤
welcome back, our high memory usage, slow performance and high convenience welcome you with open arms :D
i'm tending towards using Go in the backend next or plain react in the front.
i usually prototype my features in next, there i get to basically ship something to get feedback, if it becomes important, i just extract the backend stuff in a golang api, i keep next just for whats its for (front + bff)
Amazing vid! What were your thoughts on URL's as imports instead of a separate package.json?
Complex software that uses this stack is the open core Gitea project and its open source fork Forgejo. I don't like this stack either, it's making the UX bar low and making the UI development slow, but yeah that's a real world example.
Good call mate! I have tried HTMX as well and honestly I didn't like it, it just didn't click for me. The issue with state is spot on, like not having the various components have a shared state is so weird, and the concept of HTM is probably that all your state should derive from your server, but for something like a loading button or some dynamic text it really sounds silly. And the introduction of some random vanilla JS scripts makes so much weirder. Don't feel bad about being a NextJS developer, you are a very good one so no shame from me 👍
thanks man! yeah next.js is pretty nice I won't lie
always learning, great stuff! the easiest way to integrate js frontend and non-js backend is to generate client sdk from backend's openapi definition or grpc protobuffers
You would typically put things inside an internal directory to prevent outside users importing anything within that
Elixir/Phoenix ❤
I am using astro with htmx. I do use react component when it is nedded. Dailsy ui helps me to write astro server components . productivity increased 2x as i am writting less js compared to my previous Next js project. I develop my apis using c# which i am familiar with.
welcome back Cody, i missed the JS content
Btw about error handling in Go. Yeah it's verbose. But instead of panicking you can just return errors in your route handlers. Whatever library you use usually have top error handler and it will return 500 to the end user. So no need to panic errors actually. But yeah at the end, you need verbosely return error in every function under handler so it goes up. In that sense js is easier cuz if you use async functions and something throws you don't need to push error up in the tree.
We definitely not angry I went on that journey to and it really allowed me to appreciate JavaScript, my main language are JavaScript ,C++, and csharp. I use JavaScript for web, c++ for memory projects, and csharp for game modding. I tried to replace JavaScript with go, and was not a good experience
Appreciate you gave it a good go, most people dont even try it without expressing their opinions and if they do it then i doubt they would invest 2 weeks :)
my problem with go is that it's too simple. their vision of simplicity is too extreme. you have to reinvent the wheel every time you use it. i much prefer rust. a lot of typescript developers would enjoy rust if they tried it. i've been building all of my side projects with leptos for close to a year now. it's a simpler version of next.js with a lot of the same capabilities. it has signals like solid js, different rendering modes, progressive enhancement, colocated server functions, islands, and the bundles aren't bad at all.
I had been waiting on an update, thx for the video
I never understood these holy wars that developers get into when it comes to languages, frameworks, and tech stacks. These are not your identify as an engineer. They are just tools and each of those tools have tradeoffs. Pick the tools that have the tradeoffs you need for the project you are working on.
Right but when you hear people saying how awesome something is, you kind of want to try it, but then you find it’s actually not that great so basically you learn everyone just sucks
you sound a bit picky 😅 experience talking I suppose, after 10y into something difficult to get out, you became really confi in your stack. understandable.
I agree on many point, and it is maybe a specificity of Htmx, to use Tmpl in Go... sound very weird to me,
first I would never think to use Go for something else than the backend...
having this htmx frontend stuff incorporate in it feel wrong and over complicated.
Htmx / Go is probably not the right tech stack. I don't think I will give it a try.
If I need to build a frontend I simply use JS/react and it work very well with my Go backend.
I will give a look at your JS content, good continuation 👍
I have also found myself saying hello javascript it’s not bad but I need to like get some of this straightened out
This feels more like a comparison of go vs next, I mean did you try hono or so? it lets you write straight jsx.
if you find htmx limiting, I'm on team alpine. you mention it too, have you tried it properly?
seems to me there are plenty of things in between htmx - next
I tried it with hono as well. Idk when you use next long enough you start appreciating all the little features it has
Started Watching your videos again after this 😂
Maybe i dont understand because im a backend developer, but, in my mind, frontend and backend is always separated.
What is all of these templates? Why not use your frontend and leave the backend only to go?
Next allows you to write your backend endpoints as RPC. Nothing new, it’s just much easier to code using imo compared to a separated backend api
Literally after watching your video about performance in JS I decided to give it a try with GO and I'm enjoying it a lot so far. So thank you anyway hah😀!
Htmx reminds of Django and it's templating, how we used to build stuff using jQuery, "swapping out stuff"
Mate, you are fine, dont put yourself down for shit like this. You are learning, glad you are more relieved. Its a normal learning path.
a few libraries and tools seems wonderful and revolutionary at first glance, but over the time you realize
one day you realize that everything becomes ugly at the highest levels, with the added complexity intrinsic that comes with real problems
maybe this is how the life works, there's no way around, let's embrace complexity as a requirement to win.
today i implemented a pick, extend, omit for a custom code generator that can create types from other types. you can only really do this in ts all fully typed and checked. cant beat it.
look, it's not that hard, if you're building sites or web apps, stick to php or js
go is for servers and networking (think consul, docker, kubernetes)
if you are building drivers, games, audio, cad, trading systems, then other languages are for you
thank god!
JS/TS DX honestly, can't be beat at this time.
bun, bun, bun
Haters gonna hate and never ship :)
If you like next and TS on the backend, just do it. Most of the apps we, as developers, are building are simple web apps that TS on the backend can easily handle, and if you know it, it gives you tons of productivity.
The problem is that HTMX is like AJAX made easy, but Alpine is like a client-side interactions made easy. In the case of the kanban, in alpinejs there is a way you can achieve that drag-and-drop functionality like many others, i see has chrome devtools extension, even theres a plugin Alpine-AJAX.
If you still demand low memory usage, with C# AOT, you can try blazor which is a readable frontend framework. It has a great comunity and tooling for components like sort, tables, counter, etc.
It seems less as issues with Go + Templ and more like you can't think in JS with that stack...
Thx for you work, I realy enjoy the video and most of all it helps me understand with what should I use to work.
It was fun and informative to see someone else explore go and htmx. I heard good things about it too but when I watched you try it and said nah from the first video. Not because of a specific reason, it just didn’t look appealing to me. Strange looking syntax maybe 🤷🏻♂️.
Thank you for trying those things for us. I’m glad I picked react and next… made me realize how good we have it on this side.
The videos were really helpful to bring that to light.
Pretty much same for me, I tried htmx + Templ, it's good and for sure in the right direction. But it's not at the same level of polish as Next.js, the tooling around Templ and htmx is not quite there.
The lack of good autocomplete and small things makes it very hard to work with, especially when refactoring or updating the code.
I find Go itself an excellent language, but for now, I think I would only use it if I need performance. I'll build a robust API with it and consume it in React/Next. Or building a performant CLI, a special service or something like that.
For productivity stuff I think nothing beats TypeScript/Next.js/Convex or some stack like that.
How dare you! 😂 Its really hard to give up the smooth route transitions and client-side states.
For personal projects though, I use HTMX and a compiled language like Rust since I'm the only one to use it and no one would complain that the UI/UX sucks :D
Can you do nextjs and go backend instead?
Mane you need to use neovim/LazyVim distro and read the keymaps lol. Add lazygit and some other typescript stuff. It’s weird seeing you use the mouse lol. e to open and close the menu, w to switch windows, gg to do git stuff, ft to open floating terminal, at the min. ask AI to write the configs to add in whatever vscode shortcuts you like
I use my trackpad, only simps use a mouse
What library did you use for the Kanban board and Drag and drop?
Top 10 saddest anime endings 😢. Well at least you gave it a shot.
Thank you, Cody !
For backends, I still prefer using something other than JavaScript, like Kotlin, .NET, Java, or even Swift now. I initially loved Go, but once you have to write a lot of it, including integration tests and other necessary components for a robust API, it stops being enjoyable.
Great video! Let's have Prime react to this one as well to bring balance to the Force!
Literally all frameworks with a controller have a separate template file, wtf :P
right, use next RSC or remix and you'll see what I mean
Backend in Go, frontend in Svelte. You will never will want to work with anything else.
Nah
I prefer nuxt/vue. Svelte is just a knock off with a smaller ecosystem
@@hamm8934why not nextjs?
I am trying out Elm as it is performant and minimal, but they focus on Developer experience. Maybe you could try that next and let us know?
Once you go JS, there's no going back
Until you use TS
thats not true at all...
I got tired of it. atm still the language that pays the bills for me alongside kotlin, but not for long.
Nice take 👌.
Go and HTMX are on the road map for some side projects.
Enjoyed this series! I always felt like the React + Next ecosystem is too strong for Go + HMTX, despite the performance wins. I'd love to write a dedicated API in Go, but I think it's JS for HTML/CSS.
Your Go complaints are where I've found Swift to shine. Flexible importing, interpolation, not verbose (actually, I think a lot of times it's too terse), etc.
i knew you would come crawling back
You don't need "htmx libraries", you just include script tags to include JS or JS libs. There's everything available.
Include a couple script tags, pollute your global namespace, profit