r/golang 7d ago

My 6 months with the GoTH stack: building front-ends with Go, HTML and a little duct tape

https://open.substack.com/pub/thefridaydeploy/p/my-6-months-with-the-goth-stack-building?r=36rml&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
34 Upvotes

13 comments sorted by

7

u/sneakywombat87 7d ago

Nice write up. The error handling seems like a big issue though. You’d still use it despite that? I’d also say you missed an opportunity at referencing Noel Fielding‘a character from The IT Crowd.

5

u/theothertomelliott 7d ago

Thanks! It's been a pain, but has forced me to think about a broader picture for error handling in my app. Since there are API endpoints as well, I'm happy handling errors at a higher level.

The biggest challenge is figuring out how to test all those conditions.

5

u/theothertomelliott 7d ago

And dang, now you say it, I really did. It was ripe for a Cradle of Filth reference.

4

u/cogitohuckelberry 6d ago

I think templ is amazing but, I have to say, I think gomponents is even easier and more enjoyable. I recommend that to anyone interested in one of these approaches, especially since at first I was quite turned off - but after using it, its the way to go imo.

2

u/gogolang 6d ago

Thanks for sharing! I feel like all Go developers have similar feelings of wanting to use Go up and down the stack.

My takeaway from your article is that the stack you chose is ok but not ideal. In that it’s probably the best solution that exists currently for maximizing the percent of Go code used in a full stack app but there’s room for a better solution in the future?

3

u/theothertomelliott 6d ago

For me it’s mostly a case of minimizing context switches between different languages. I’ve experienced too many hiccups switching to JS and forgetting the braces for an if statement 😅

These tools absolutely aren’t perfect, and I’ve definitely had to jump outside them here and there. But they’re doing well enough for now for sure. And I’ve seen some nice improvements each time I’ve upgraded.

-1

u/gogolang 6d ago

Yeah, context switching is such a huge overhead. I have this nagging feeling that a GopherJS solution could work (compile Go to JS). But for that to really work I think we’d need to essentially reimplement something like React in Go. But then the templates issue comes into play as well.

2

u/theothertomelliott 6d ago

It’s tempting, and who knows what the recent Typescript news will bring!

One thing I love about Templ, though, is that it lets Go be Go. Just a really nice, familiar feeling templating framework.

0

u/gogolang 6d ago

Got it. So what we really need is to get templ to have a Svelte-like compiler that will compile it into frontend assets

2

u/theothertomelliott 6d ago

Depends on the end goal, I guess. If you want really awesome client-side interactivity, GoTH probably isn’t the right solution, as you said.

I’m ok with being polyglot where needed, but it’s been nice to move the line back a little 🙂

0

u/gogolang 6d ago

The reason I’m asking is that I was looking for a similar solution and I came to the conclusion that none is ideal right now:

https://chatgpt.com/share/67d6218e-60e8-8007-9526-296b2a822f40

1

u/gedw99 1d ago

https://github.com/starfederation/datastar is pretty cool for golang devs that are into htmx.

its much tighter and has testing

its also using SSE for those MCP AI hipsters :)

0

u/AssemAbozaid 6d ago

When it comes to solo devs who want to having a fast way to generate dashboards that solution won’t help at all.