Templ: A language for writing HTML user interfaces in Go

https://github.com/a-h/templ

by nalgeon • 3 years ago

228 98 3 years ago

github.com

pier25• 3 years ago

This is great.

Is there a way to do code colocation with templates? I mean for writing presentation logic alongside the html.

Asking because it seems templ functions only allow html.

peefy• 3 years ago

A great project!

obilgic• 3 years ago

Would have been amazing 10 years ago. Client side js is what would make this messy to use in big projects imho.

steve_adams_86• 3 years ago

I find myself thinking this as well. I love the idea of this for a few reasons, but there appear to be some hang ups that would cause me to go back to typescript, jsx, and a node process serving it.

The developer experience is ridiculously nice in that ecosystem if you’re accustomed to it. So many QOL things have been dealt with and polished.

But I do love the idea of something like that dev experience with Go instead of JavaScript powering it.

Maybe this would be totally sufficient if you don’t want any SPA/interactivity features?

Some sort of live pipe to component state like LiveView or similar could make it so a lot of JS would work implicitly, which might give a lot of the dev experience and user experience ease that people want. I’m not sure. But I do think something would often be missing with this library.

Regardless, I love the idea and I’d be stoked to see it grow and improve the developer experience.

sneak2• 3 years ago

I think it still makes sense to make web apps that can function without JS.

berkes6• 3 years ago

I use templating in rust (jinja) even with rather some JavaScript.

My JavaScript modifies the DOM rather than creating it.

treyd• 3 years ago

There's a huge swathe of projects that have no (or very little) use for client side js.

lelanthran• 3 years ago

Depends. If you know at the outset whether your client side is primarily an app or primarily a document, you can choose libraries that make sense.

If you're going to shoehorn everything into "this is an app" or "this is a document" then you're going to have problems no matter what you choose.

jimmyed• 3 years ago

Nice! I like how it can double as a static site generator, so you can replace Hugo/Jekyll with this. That might need some glue code/extensions to the language though.

dgb236• 3 years ago

Hugo has some very hairy parts that make it very fast. I wouldn’t assume that it’s easily replaceable if you want the same performance?

verdverm5• 3 years ago

Hugo's speed is largely from Go.

My problem with Hugo is how the templating becomes very confusing and the flow convoluted. The projects required places for various things becomes a maze, especially if you are not familiar with the site and theme you are working on.

I definitely prefer JSX to Hugo, but this project might be a nice middle ground.

Sphax• 3 years ago

That's what I did for my website. Combined with goldmark for writing my pages in markdown, I really like it. It did require a fair amount of code though.

e67f70028a46fba• 3 years ago

Seeing a lot of people use this as part of the GoTH stack: go, temple & htmx

boyter• 3 years ago

That was my first thought. It looks perfect for use with HTMX.

markusw6• 3 years ago

Love the name. :D

ducktective2• 3 years ago

GoTH stack

LAMP, MEAN, JAM and now GoTH...damn! web people sure have good taste in naming things!

verdverm5• 3 years ago

I'm not sure how to react to this vue, opinions are quite angular in frontend and it almost seems required to flutter about the various frameworks

patmorgan23• 3 years ago

CHAD stack is still my favorite.

TobyTheDog123• 3 years ago

While this is incredible and I can't wait to use this with HTMX, I really wish it didn't require a CLI to generate the *_templ.go files.

Code generation is something I saw in Flutter/Dart a lot and it entirely killed my interest in it (mostly with JSON serialization/deserialization to classes).

Thankfully, it's by no means a show-stopper for me thanks to their hot reloading functionality. https://templ.guide/commands-and-tools/hot-reload

janderland• 3 years ago

Why do you dislike code gen?

extrapancakes• 3 years ago

I use Taskfile, fd (a 'find' alternative) and "entr" to get around any need to manually call 'templ generate'.

'fd . 'assets/view' | entr templ generate' - couple it with 'air' and developing is a lot easier. Looking forward to when Goland has better support for templ.

20after4• 3 years ago

Isn't this basically PHP, but in go? Or am I missing something?

mu53• 3 years ago

it is html templating, but php's sore points were not the html templating.

berkes6• 3 years ago

I keep saying that PHP is above all a templating language. Last time I looked every file has to start with a php-mode tag still, for example.

Which makes it funny to then realize that e.g. twig is a templating language written in a templating language.

dgb236• 3 years ago

HTML templating in PHP is unfortunately unsafe.

It has some nice properties: streams by default, it’s pretty fast for a templating language and you get a lot of stuff for free that you eventually need.

However, you have to escape and sanitize output explicitly, which is not a thing in pretty much any modern templating language.

The std lib in go for example has a very explicit security model.

The problem is that you have to escape differently depending on the micro context. So it can become tedious and error prone if you have to do it explicitly all the time.

justech2• 3 years ago

More like PHP and Pug, but in Go. As someone who likes server-rendered websites but prefers Go over PHP, I like this approach.

ckdot24• 3 years ago

The same is still possible in PHP to include HTML code into you PHP files. But it's rarely still being done like this. It's considered good practise to separate your PHP (business) and HTML (view) logic.

justech2• 3 years ago

The standard templating in Go has been good enough for my small projects, and I usually avoid adding libraries if I can help it. But seeing this makes me want to try it just to see how it compares.

mkesper• 3 years ago

Standard Go templating seems really lacking if you come from something like Jinja. Even with libraries like https://masterminds.github.io/sprig/ (used e.g. for Helm templating) it feels hard to use.

arp242• 3 years ago

It's different from Jinja, but feature-wise it's about on-par.

jerf• 3 years ago

Standard Go templating can do almost anything you want it to do, but figuring out how to do it from the documentation alone can be a real challenge.

If this sounds to the reader like a defense of Go templates... it isn't.

Plus, I would agree that while it can do almost anything you want, that doesn't mean it always does it in a good way, or in a way that makes sense if you aren't a programmer. It's a pity. There's some power there, and I like the attempt at making templating safe, but it could really use a v2.

thraxil3• 3 years ago

I'm in a similar position. I dismissed Templ by default when it started getting mentioned; I've always disliked JSX and the approach reminds me of that. I realized that it basically enables compiler and type checking of the template code though and now I'm interested. Ie, with html/template, you could easily reference a variable/attribute/etc that doesn't exist and have no way of knowing until you hit it at runtime so you had to be careful to write tests that covered all the conditional paths in the templates.

verdverm5• 3 years ago

If you pass a struct as input, you can check data & constraints. That's more or less what this is doing as well

qaq• 3 years ago

Great project. Part of my go to stack now (FE:Templ+Htmx BE: Go,sqlc, postgres)

chabad360• 3 years ago

From my brief usage it seems to lack a couple of basic stuff, but nothing that couldn't be added later on.

But, I am curious why they decided to go with reserving keywords (like if and for) instead of doing what JSX does and just wrapping any Go code in braces.

twelfthnight• 3 years ago

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• 3 years ago

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

egeozcan2• 3 years ago

You can try gomponents https://www.gomponents.com/

It also has an HTMX plug in.

markusw6• 3 years 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-htmx

kitd• 3 years ago

Here are a couple:

https://github.com/julvo/htmlgo

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

devjab• 3 years 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• 3 years 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/

trommlp2• 3 years ago

I would like to mention maud in this context:

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• 3 years 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• 3 years 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

diceduckmonk2• 3 years ago

How does this compare to html/template in the Go standard library?

https://pkg.go.dev/html/template

Which is based on top of text/template.

jitl• 3 years ago

It’s very different. It’s a meta language that compiles to Go. It ensures correct syntax at compile time, and makes it much easier to treat parts of views as real values instead of bits of text. Much better composition, at the cost of a much more complex build system.

giancarlostoro• 3 years ago

I think this answered my only question: how the heck is he just writing HTML inside of Go, as far as I know, Go doesn't have any metaprogramming to that extent, and I doubt Go ever will.

eitland• 3 years ago

Last I checked Gos built in templating system lacked one feature that I see as very basic and that IMO makes it hard to organize code and templates logically:

To very common things to do when templating is

- to include a sub-template (e.g. the article template includes the sidebar template)

- to specify that the template I work with and probably others should be rendered inside a slot in a containing template (e.g. the article template should be rendered into the general root template that contains the public menu but the admin pages should render in another root template)

Last I checked only the first of these use cases were supported.

dgb236• 3 years ago

Doesn’t go template have a way to define functions? You could then use a function to do w/e you like.

ckdot24• 3 years ago

Both is possible. See here an example how to implement use case 2: https://github.com/ckilb/golang-layout-tpl-example

I don't like Go's template engine too much, I find it a bit cumbersome in many cases. But it's quite capable.

EdwardDiego• 3 years ago

Codegen based?

Edit: Yep, codegen based.

lihaoyi• 3 years ago

Part of a long line of similar projects: XHP, Pyxl, JSX. My own project Scalatags is pretty popular in the Scala community.

The approach works surprisingly well, both server side and running in the browser (JSX, or Scalatags+Scala.js). There are plenty of websites that don't need heavy client-side interactivity where server side templating + a sprinkling of client side logic works just fine. This is especially true if you can share code between client and server (e.g. via JSX/React or Scalatags/Scala.js)

You get typechecking, interop with normal code, and a high performance runtime for free. That's a lot to like!

SureshG• 3 years ago

For java/Kotlin, we are using JTE (https://jte.gg/#getting-started), pretty nice build tooling and IDE support to generate pre-compiled templates without additional code generation steps.

nprateem• 3 years ago

JTE was a like refinding sanity after thinking I'd be stuck with Thymeleaf when I started playing with Spring Boot.

rickette• 3 years ago

"A HTML templating language for Go that has great developer tooling" as long as you're using VSCode... I don't see a JetBrains (GoLand/IntelliJ) plugin.

valxntine• 3 years ago

I'd have to ask him if it's finished, but Joe, one of the core contributors to Templ definitely has a jetbrains plugin in the works: https://github.com/joerdav/templ-jetbrains

al_be_back• 3 years ago

useful for generating tedious HTML emails e.g. export Thread to Email.

KingOfCoders• 3 years ago

Currently switching from Echo/Jet to Echo/Templ - compilation (generation) is a little bit annoying but writing simpler Go code in templates makes a difference, also easier to compose.

shp0ngle• 3 years ago

That's nice. I'm a heavy user of go html templating and it gets tiring after a while - it has no type checking, methods and attributes are called the same way, calling Parse is awkward, adding Sprig is pretty much required, the order you call functions is lisp-like, it's all weird.

This seems to be much nicer.

mjlee• 3 years ago

There's an episode of the podcast Go Time hosting "Adrian Hesketh, the creator of Templ, and Joe Davidson, one of the maintainers on the project."

https://changelog.com/gotime/291

zwnow• 3 years ago

To be honest, I tried working with it and it was really confusing. I'd just rather keep writing out the HTML I want to return and keep my applications simple and straightforward.

ducktective2• 3 years ago

So I guess SSR is back on the menu? I wonder what the workflow is like.

If one wants to go Go+HTMX route, how does one write a webapp with handling auth and sessions and everything? I assume the backend is not just an API?

It'd be nice if one points to an example repo developed with this method.

markusw6• 3 years ago

I've got my own super simple service template that I use internally for this: https://github.com/maragudk/service . I don't think I've added HTMX here (because I add it when needed), but it has auth and is totally classic in its setup.

avtolik• 3 years ago

Well, just use cookies. It's simple as that. As markusw, I also don't use HTMX. I tried it, but for me it is faster to use the fetch API. My basic stack is go html templates, chi router and sqlite.

cschep• 3 years ago

Yeah this seems like more of a majestic monolith approach.

tbarbugli• 3 years ago

This is pretty useful https://www.jetbrains.com/help/go/integration-with-go-templa... to improve productivity when working with templates in Go

donatj• 3 years ago

I was initially skeptical, because I feel like the built-in HTML templating is really powerful and good. Recently however, I listened to an episode of the "Go Time" podcast[1] featuring the author and he made some very compelling cases for it.

The most compelling to me is that Templ templates are compile time safe, rather than crashing at run time like the built-in templates.

1. https://changelog.com/gotime/291

ralmidani2• 3 years ago

There is a very intense backlash against technology like React, due to the unbelievable complexity that has crept into building “modern” JS apps.

This backlash is quite understandable. I believe Ember/React/Vue/Angular/etc. were all created with good intentions, but with the ecosystems of bolted-on technologies and now-necessary build tools, they have all become unmanageable monstrosities.

So people want to go “back to basics”. Personally, while I loved Ember with CoffeeScript (talking to a Django server via JSON) in 2015-2017, I can’t even revive the app I built without a massive effort to upgrade and ditch all the deprecated, unsupported dependencies (which might take more time than modifying my actual app code).

So I’m just going to rewrite the Web client with htmx (with Django rendering the actual templates). No churn and dependency hell, no build tools, no nonsense. Just a single script tag and some HTML attributes. For special cases that can’t be covered by htmx, there’s hyperscript (just add another script tag). Since browsers intend to maintain backward compatibility indefinitely, forced upgrades should be minimal to non-existent.

It’s a shame JS ended up being perceived as a villain, because it was meant to enable rich client applications within browsers, which are the most universally-compatible and commodified client you can possibly run such apps in.

toddmorey• 3 years ago

For those who are primarily javascript developers who want to go back to the basics, Astro.build is very nice. Ships plain HTML pages by default. Easy to progressively enhance with client-side interactivity if and where you'd like.

And for the client-side stuff, you get to pick how to tackle it: plain javascript, htmx, web components, react, vue, svelte, qwik... all enjoy first class support.

ralmidani2• 3 years ago

Astro needs a better elevator pitch. I spent several minutes on the site, clicking and scrolling, but sample code was minimal and not easy to find. This is not effective marketing in 2023. If a developer has no idea what developing with your tech stack feels like after ~60 seconds, more times than not that developer will leave. Sorry, Astro sounds cool conceptually, but in this case I think brutally honest feedback is warranted.

For what it’s worth, I also think Django needs a better elevator pitch, but Django captured me in 2010. I might try pushing for a home page improvement. Django does have tenure and mindshare working in its favor, though.

AsthmaBoy• 3 years ago

Here is an example of an old technology

TAL -Template Attribute Language

https://en.m.wikipedia.org/wiki/Template_Attribute_Language

which happens to have an (also old) implementation i Go https://github.com/owlfish/tal

I wonder what opinion HN has on this type of templating language?

everybodyknows• 3 years ago

Emacs support for syntax highlighting of .templ files would be helpful.

https://templ.guide/commands-and-tools/ide-support

Templ: A language for writing HTML user interfaces in Go

Related Stories