Hey everyone!<p>I’ve built gomponents over the past couple of years because I wasn’t satisfied with using templating languages in Go.<p>In particular, it was really hard to pass data around when using stdlib html/template, and it just didn’t sit right with me.<p>Using just Go, you get so much for free from the language, and building HTML components becomes much easier, I think.<p>The way you use it basically looks like using a DSL, but it’s not! It’s using the often-disliked but occasionally useful dot import mechanism of the language. This way, there’s full autocompletion built right in if your editor supports Go.<p>Anyhoo, I hope you find some use in it. I know a lot of people already do. :) Enjoy!<p>PS: There's gomponents-htmx as well. The two work really well together.
This looks neat!<p>What's the performance like? I thought about trying to build something similar but I figured performance would be awful if it was based on naive string appending. I presumed GC would dominate the runtime from allocating a thousand copies of half an HTML doc.<p>Does this do any kind of memo-ization/caching? That's where I ultimately wanted to end up. I wanted the Page to use generics to pick a struct for the parameters used in building the HTML, and then maintain a cache mapping hashed inputs to already-built output. I never decided whether it was better to memo-ize the whole page as a template or memo-ize just the components so it could do partial re-renders. It's ideologically very similar to React
Oh hey, I wrote something similar as part of a web framework (<a href="https://github.com/gospel-sh/gospel">https://github.com/gospel-sh/gospel</a>), not officially released yet as I’m working on reactive client-side rendering and a few other things.