Re:Show HN: htmgo - build simple and scalable systems with g...
by novoreorx on Sunday September 29, 2024 @09:36PM
(#41692596)
gomponents look better; at least the `h.` prefix could be omitted. Also, it serves a simpler purpose than htmgo.
What do you think about https://templ.guide/? To me, the ability to still write raw HTML in Go is incomparable.
Re:Show HN: htmgo - build simple and scalable systems with g...
by maddalax on Sunday September 29, 2024 @11:38PM
(#41693313)
I’m not quite sure what the roadmap looks like for gocomponents but it looks similar but I think it’s only filling one part of the puzzle. My plan for htmgo is to become essentially a ready to use framework for building your whole app, using very fast/lean modules, similar to Ruby on Rails, especially rails 8, and not just an HTML builder
Re:Show HN: htmgo - build simple and scalable systems with g...
by maddalax on Sunday September 29, 2024 @10:51PM
(#41693053)
What makes you believe the prefix can’t be omitted in htmgo? You just alias it the same way with a ‘.’
Re:Show HN: htmgo - build simple and scalable systems with g...
by novoreorx on Monday September 30, 2024 @10:55PM
(#41704244)
Sorry, I made a mistake. I thought the HTML tag functions were accessed through `ctx`, which is passed to the page function. It's true that we can import them directly to access `Div`, `Class`, etc.
I switched from using golang templates with hand-crafted HTML to gomponents[1] a few months ago, and it's been amazing. It is so so so much easier to write re-usable components, so much easier to express complicated conditionals, so much nicer to have a type checker helping you not make mistakes.
And of course I like gomponents for the same reason (I presume) JS-oriented people like NodeJS: It's just a lot nicer to have as much as possible written in the same language, be it JavaScript or Golang.
[1] https://www.gomponents.com/