This reminds me of Lucky Framework for Crystal
Show HN: Gomponents, HTML components in pure Go
41–50 of 50 posts
Re: Show HN: Gomponents, HTML components in pure Go
#42This is a horrifyigly bad idea.
[dead]
Re: Show HN: Gomponents, HTML components in pure Go
#43[dead]
Re: Show HN: Gomponents, HTML components in pure Go
#44I saw the dot imports and thought “What a neat feature! I wonder why nobody uses it.” Then I googled it and saw a million articles saying how they should be avoided and removed from the language because they make code more difficult to understand. Typical gophers, can’t accept that there’s a time and place for everything and need to have a hard rule to use that applies to every single situation. Imagine that code, bu…
It's the same with the Ginkgo testing library: "After the package books_test declaration we import the ginkgo and gomega packages into the test's top-level namespace by performing a . dot-import. Since Ginkgo and Gomega are DSLs this makes the tests more natural to read."
Re: Show HN: Gomponents, HTML components in pure Go
#45I saw the dot imports and thought “What a neat feature! I wonder why nobody uses it.” Then I googled it and saw a million articles saying how they should be avoided and removed from the language because they make code more difficult to understand. Typical gophers, can’t accept that there’s a time and place for everything and need to have a hard rule to use that applies to every single situation. Imagine that code, bu…
> (Some people don't like dot-imports, and luckily it's completely optional.)
You can rename imports to whatever you like, but the default name for the package that contains the HTML elements is `html`, not `gocomponents`.
Re: Show HN: Gomponents, HTML components in pure Go
#46While 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…
Exactly. EDSLs are underrated.
Re: Show HN: Gomponents, HTML components in pure Go
#47This is a horrifyigly bad idea.
Another horrifyingly bad idea is to make a comment like this without presenting any form of argument.
Re: Show HN: Gomponents, HTML components in pure Go
#48I just learned Golang, and i liked your idea, i'm going to test it soon! saved in bookmarks
Re: Show HN: Gomponents, HTML components in pure Go
#49I just learned Golang, and i liked your idea, i'm going to test it soon! saved in bookmarks
Cool, good luck! :)
Re: Show HN: Gomponents, HTML components in pure Go
#50Earlier quoted context omitted.
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?
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 [1]: https://www.maragu.dk/blog/gomponents-declarative-view-compo...
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: