11–20 of 50 posts
are event handlers possible? neither the Github repo nor the linked page showed an example of a button or form submission.
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 o…
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 o…
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.
Closures, modules, functions, loops or recursion, conditionals, every feature of your programming language just right there, without some large templating library in the way. Debug your templates with the actual debugger. Very high performance with just a bit of care in the API design. Every programmer in your language can pick this up very quickly with hardly any effort and doesn't have to learn yet another complete templating language to start using your project, it's just comparable to picking up an API.
So many advantages... it's just... you have to be programmer if you want to modify the resulting code. Other than that, and I guess the fact you need to implement whatever discipline you may want on your own[1]... but those are a total killer in many cases.
[1]: This approach does not require that you mix presentation and logic, but if you want that separation, you will need to discipline yourself to maintain it. Though I have to admit, 25 years of programming on the web and I'm frankly still unconvinced by this argument, or, at least, unconvinced that it is the absolute most important thing in every context and only a cretinous lunatic would dare mix logic and presentation. It seems to me to be a rule espoused by far more people than it is followed by.
While acknowledging the use case of "the designer who doesn't know how to program" and the desirability in some sense of separating logic from data, if I am going to slam together some HTML as a programmer, with no "non-programmer" designer in sight, I tend to slap together a local version of templates like this if I can't find a good one available. The reason is, if I'm going to mix logic and presentation anyhow, wh…
That’s awesome! I have a very similar project Dovetail, that tries to nudge you into making things accessible. https://github.com/RoyalIcing/Dovetail
Looks cool. There is also Templ[1] that does something similar, though uses codegen. I wish there is an equivalent of Storybook for these things though, it would be really nice! [1] https://templ.guide/
are event handlers possible? neither the Github repo nor the linked page showed an example of a button or form submission.
I don't see any used of a `Script()` function or similar in the example apps, though you could always chunk some JS in a public directory and link it in the HTML.
They do have a starter example that uses HTMX. That'd be my go-to as well for a tool that's sticking with server rendering HTML.
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 o…
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.
Earlier quoted context omitted.
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.
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?
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 [1]: https://www.maragu.dk/blog/gomponents-declarative-view-compo...