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.
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
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.
@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 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.
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.
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 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.
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.
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
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 🤣!
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.
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
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.
@@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
@@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
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.
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
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.
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.
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.
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
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.
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😀!
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.
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 👍
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?
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 :)
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)
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
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.
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
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 ❤
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 👍
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.
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.
@@WebDevCody Not saying that that's not how you feel. Using class names that are not connected to styles is the way I do things. That way you can name the object or the group of objects anything you want that makes sense to me.
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.
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
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.
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.
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.
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
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
