3 ms·

So I like the idea of it but am feeling a bit wary about UI elements as runtime types. Good thing about this is the strong typing but then you have a fair bit

So I like the idea of it but am feeling a bit wary about UI elements as runtime types. Good thing about this is the strong typing but then you have a fair bit of lispifying going on which I swing back and forth on. I actually like templ's approach on this (though hate the extra build step). So I finally just settled on plain old go templates. Not quite eloquent but just feels staple and simple. Clearly a lot of get off my lawn type of biases here :)

OccamsMirror 2y ago
I agree with you, but I like Gomponents over html templates due to the type safety. It's also easier to reason about with. Some of my html templates can get quite difficult to maintain, with often the context not being obvious.
- flashgordon 2y ago
  Totally. I am also in this journey where I keep going back and forth between templates and something typed. I really need something like native jsx inside go. Gosx anybody?
  - markusw 2y ago
    Isn't that basically Templ [0] then? But Templ has that extra build step for preprocessing and converting back to plain Go files. For me, gomponents is the middle ground. You don't get everything, but quite a lot of JSX-like feel. I was inspired by JSX after all. :) [1] Although I called it GOX back then… :D [0]: https://templ.guide https://templ.guide [1]: https://www.maragu.dk/blog/gomponents-declarative-view-components-in-go https://www.maragu.dk/blog/gomponents-declarative-view-compo...
    - flashgordon 2y ago
      Yep yep - templ was what i was referring to. But for somereason I was holding back because I wanted my templating to be "format" agnostic where as templ seemed to be tied to html/xml kinda syntax. Big asterix - I have only skimmed through the doc so havent actually seen whether my assumption is wrong. Also I know I am contradicting myself. i guess i didnt settle on templ because I did not want to go all jsx-like but then i also do :facepalm:
- markusw 2y ago
  I started with html/template, but got fed up with it because I thought it was so hard to pass data around to different components. I don't know, I just didn't jell with it.

OccamsMirror 2y ago

I agree with you, but I like Gomponents over html templates due to the type safety. It's also easier to reason about with. Some of my html templates can get quite difficult to maintain, with often the context not being obvious.

flashgordon 2y ago
Totally. I am also in this journey where I keep going back and forth between templates and something typed. I really need something like native jsx inside go. Gosx anybody?
- markusw 2y ago
  Isn't that basically Templ [0] then? But Templ has that extra build step for preprocessing and converting back to plain Go files. For me, gomponents is the middle ground. You don't get everything, but quite a lot of JSX-like feel. I was inspired by JSX after all. :) [1] Although I called it GOX back then… :D [0]: https://templ.guide https://templ.guide [1]: https://www.maragu.dk/blog/gomponents-declarative-view-components-in-go https://www.maragu.dk/blog/gomponents-declarative-view-compo...
  - flashgordon 2y ago
    Yep yep - templ was what i was referring to. But for somereason I was holding back because I wanted my templating to be "format" agnostic where as templ seemed to be tied to html/xml kinda syntax. Big asterix - I have only skimmed through the doc so havent actually seen whether my assumption is wrong. Also I know I am contradicting myself. i guess i didnt settle on templ because I did not want to go all jsx-like but then i also do :facepalm:
markusw 2y ago
I started with html/template, but got fed up with it because I thought it was so hard to pass data around to different components. I don't know, I just didn't jell with it.