4 ms·

Recently I've been drifting away from template engines toward native data structures + serialization for programmatically creating html/yaml. For example, CDK i

Recently I've been drifting away from template engines toward native data structures + serialization for programmatically creating html/yaml. For example, CDK is following this pattern for building cloud configuration YAML. Do folks know of standard libraries or patterns in Go or Rust to generate HTML without string templating? (As mentioned elsewhere, I'm looking for a backend for HTMX)

alisonatwork 3y ago
If you want to really go back to oldskool way you could use XML for this.
egeozcan 3y ago
You can try gomponents https://www.gomponents.com/ https://www.gomponents.com/ It also has an HTMX plug in.
- markusw 3y ago
  Thank you for the mention! :) Relevant libraries, for those who want to dive directly into it: - https://github.com/maragudk/gomponents https://github.com/maragudk/gomponents - https://github.com/maragudk/gomponents-htmx https://github.com/maragudk/gomponents-htmx
  - arccy 3y ago
    i just wish gomponents/html would define an alias for gomponents.Text so i don't have the impedance mismatch of switching the package qualifier but otherwise, I'm quite liking it so far
    - markusw 3y ago
      Hmm. I see what you mean, but <text> isn't a valid HTML element, so that wouldn't work for that alone. But try dot imports for the html package and you don't have to have a package qualifier for most of your view code at all! :D
  - egeozcan 3y ago
    Oh, thank you for open sourcing it! I'm having a lot of fun, and it's nearly as agile as react, only hit by the lack of expressiveness in the go language in some cases.
    - markusw 3y ago
      You're welcome! :) I'm always open for feedback, so if you think there's room for improvement, feel free to open an issue for discussion on the repo. (That said, I'm fairly conservative about the API, trying to keep it simple for everyone to use.)
  - tauchunfall 3y ago
    I tried it yesterday until far past midnight. gomponents is amazing! I find the abstractions just right. it now looks possible that I can port my minimalistic bun/deno setup with htmx to go. I found "gow" watcher that allows auto-restart of the development webserver when go code was changed. And I'm using "hx-refresh" header paramter and "hx-trigger='every 250ms'" to have a simple polling browser refresh. it also integrates well with tailwind css. you can use tailwind vscode extension and define a custom "classRegex" for gomponents "Class(...)" function. I needed to write a custom `Classes()` function that allows me to have conditional classes like `clsx()`. it's a bit hacky, but I like the simplicity. func Classes(nodes ...g.Node) g.Node { var classes []string for _, node := range nodes { if node != nil { var builder strings.Builder _ = node.Render(&builder) c := builder.String() c = strings.TrimLeft(c, " class=\"") c = strings.TrimRight(c, "\"") classes = append(classes, c) } } return Class(strings.Join(classes, " ")) } the runtime panics for functions that use vararg for optional arguments and have an invalid number of arguments is probably an okayish trade-off. mixing attributes and children elements in the builder functions, I don't know if it's good or bad, but I like the simplicity; JSX and hyperscript-like functions separate tag, attributes, and children into three different parameters. edit: reformat and typos.
    - markusw 3y ago
      I'm really happy you like it. :) And thank you for your comment, I really appreciate newcomer viewpoints especially. Have a look at the `Classes` helper component already available: https://github.com/maragudk/gomponents/blob/main/components/components.go#L42 https://github.com/maragudk/gomponents/blob/main/components/... Yeah, I'm not a total fan of the runtime panics, but it was a tradeoff where I chose in favour of API simplicity and readability. In practice, it works out well, because you catch any typos at development time. I've had elements and attributes in separate packages before, but then you can't dot-import both packages and not have name clashes, and have to either prefix elements or attributes with the package name, which makes the code much less readable. Again, a tradeoff. :)
kitd 3y ago
Here are a couple: https://github.com/julvo/htmlgo https://github.com/julvo/htmlgo https://github.com/rohanthewiz/element https://github.com/rohanthewiz/element I'm sure there are many more. The thing about these is that performance is often not as good as when using templates, especially when the templates are compiled to native code. Quicktemplate [1] is still the leader here IMO, and I don't think the OP project brings much that couldn't be done pretty easily with QT. [1] https://github.com/valyala/quicktemplate https://github.com/valyala/quicktemplate
devjab 3y ago
Even in React we do a lot of programmatic “UI generation” for data structures, and mostly use react for the more “unique” things, which is arguably a big part of our Enterprise application. We do use shared components, but it’s also very nice not to share them too widely in terms of testability and maintenance. So I think it’s perfectly reasonable not to use tempting if it works for you. Especially if the templating isn’t very good, which is frankly most of them. I do think some templating can be good for prototyping, but as soon as you’re doing the same thing a lot of times and that thing doesn’t really change beyond what happens to the underlaying data structure, I think it’s very worth it to build it programmatically. Which is basically a lot of data CRUD UI in many organisations.
rmetzler 3y ago
I don't really understand what you're looking for and I don't write web apps in Go, so sorry if this is a wrong answer. The templ language linked here is compiling something that looks similar to React's JSX into Go code. And then you can do HTMX: https://templ.guide/server-side-rendering/htmx/ https://templ.guide/server-side-rendering/htmx/
trommlp 3y ago
I would like to mention maud in this context: https://github.com/lambda-fairy/maud https://github.com/lambda-fairy/maud It is refreshingly different from other Rust templating libraries. It uses a proc-macro that compiles your HTML into Rust code. I also happen to use it in conjunction with HTMX and it works very well for me (at least in small projects). You will still have to learn a little bit of "special" syntax though, which you are looking to avoid if I understand you correctly.
- norman784 3y ago
  while it looks nice, I’d prefer html and not to learn yet another DSL, the reason is that migrating is easier between template engines.
rthrfrd 3y ago
I believe I recently built something to do exactly what you're describing for HTML, though it's C++ (but maybe a useful basis for a rust version - I don't know). https://github.com/rthrfrd/webxx https://github.com/rthrfrd/webxx

alisonatwork 3y ago

If you want to really go back to oldskool way you could use XML for this.

egeozcan 3y ago

You can try gomponents https://www.gomponents.com/ https://www.gomponents.com/ It also has an HTMX plug in.

markusw 3y ago
Thank you for the mention! :) Relevant libraries, for those who want to dive directly into it: - https://github.com/maragudk/gomponents https://github.com/maragudk/gomponents - https://github.com/maragudk/gomponents-htmx https://github.com/maragudk/gomponents-htmx
- arccy 3y ago
  i just wish gomponents/html would define an alias for gomponents.Text so i don't have the impedance mismatch of switching the package qualifier but otherwise, I'm quite liking it so far
  - markusw 3y ago
    Hmm. I see what you mean, but <text> isn't a valid HTML element, so that wouldn't work for that alone. But try dot imports for the html package and you don't have to have a package qualifier for most of your view code at all! :D
- egeozcan 3y ago
  Oh, thank you for open sourcing it! I'm having a lot of fun, and it's nearly as agile as react, only hit by the lack of expressiveness in the go language in some cases.
  - markusw 3y ago
    You're welcome! :) I'm always open for feedback, so if you think there's room for improvement, feel free to open an issue for discussion on the repo. (That said, I'm fairly conservative about the API, trying to keep it simple for everyone to use.)
- tauchunfall 3y ago
  I tried it yesterday until far past midnight. gomponents is amazing! I find the abstractions just right. it now looks possible that I can port my minimalistic bun/deno setup with htmx to go. I found "gow" watcher that allows auto-restart of the development webserver when go code was changed. And I'm using "hx-refresh" header paramter and "hx-trigger='every 250ms'" to have a simple polling browser refresh. it also integrates well with tailwind css. you can use tailwind vscode extension and define a custom "classRegex" for gomponents "Class(...)" function. I needed to write a custom `Classes()` function that allows me to have conditional classes like `clsx()`. it's a bit hacky, but I like the simplicity. func Classes(nodes ...g.Node) g.Node { var classes []string for _, node := range nodes { if node != nil { var builder strings.Builder _ = node.Render(&builder) c := builder.String() c = strings.TrimLeft(c, " class=\"") c = strings.TrimRight(c, "\"") classes = append(classes, c) } } return Class(strings.Join(classes, " ")) } the runtime panics for functions that use vararg for optional arguments and have an invalid number of arguments is probably an okayish trade-off. mixing attributes and children elements in the builder functions, I don't know if it's good or bad, but I like the simplicity; JSX and hyperscript-like functions separate tag, attributes, and children into three different parameters. edit: reformat and typos.
  - markusw 3y ago
    I'm really happy you like it. :) And thank you for your comment, I really appreciate newcomer viewpoints especially. Have a look at the `Classes` helper component already available: https://github.com/maragudk/gomponents/blob/main/components/components.go#L42 https://github.com/maragudk/gomponents/blob/main/components/... Yeah, I'm not a total fan of the runtime panics, but it was a tradeoff where I chose in favour of API simplicity and readability. In practice, it works out well, because you catch any typos at development time. I've had elements and attributes in separate packages before, but then you can't dot-import both packages and not have name clashes, and have to either prefix elements or attributes with the package name, which makes the code much less readable. Again, a tradeoff. :)

kitd 3y ago

Here are a couple: https://github.com/julvo/htmlgo https://github.com/julvo/htmlgo https://github.com/rohanthewiz/element https://github.com/rohanthewiz/element I'm sure there are many more. The thing about these is that performance is often not as good as when using templates, especially when the templates are compiled to native code. Quicktemplate [1] is still the leader here IMO, and I don't think the OP project brings much that couldn't be done pretty easily with QT. [1] https://github.com/valyala/quicktemplate https://github.com/valyala/quicktemplate

devjab 3y ago

Even in React we do a lot of programmatic “UI generation” for data structures, and mostly use react for the more “unique” things, which is arguably a big part of our Enterprise application. We do use shared components, but it’s also very nice not to share them too widely in terms of testability and maintenance. So I think it’s perfectly reasonable not to use tempting if it works for you. Especially if the templating isn’t very good, which is frankly most of them. I do think some templating can be good for prototyping, but as soon as you’re doing the same thing a lot of times and that thing doesn’t really change beyond what happens to the underlaying data structure, I think it’s very worth it to build it programmatically. Which is basically a lot of data CRUD UI in many organisations.

rmetzler 3y ago

I don't really understand what you're looking for and I don't write web apps in Go, so sorry if this is a wrong answer. The templ language linked here is compiling something that looks similar to React's JSX into Go code. And then you can do HTMX: https://templ.guide/server-side-rendering/htmx/ https://templ.guide/server-side-rendering/htmx/

trommlp 3y ago

I would like to mention maud in this context: https://github.com/lambda-fairy/maud https://github.com/lambda-fairy/maud It is refreshingly different from other Rust templating libraries. It uses a proc-macro that compiles your HTML into Rust code. I also happen to use it in conjunction with HTMX and it works very well for me (at least in small projects). You will still have to learn a little bit of "special" syntax though, which you are looking to avoid if I understand you correctly.

norman784 3y ago
while it looks nice, I’d prefer html and not to learn yet another DSL, the reason is that migrating is easier between template engines.

rthrfrd 3y ago

I believe I recently built something to do exactly what you're describing for HTML, though it's C++ (but maybe a useful basis for a rust version - I don't know). https://github.com/rthrfrd/webxx https://github.com/rthrfrd/webxx