10 ms·
Templ: A language for writing HTML user interfaces in Go
- pier25 3y agoThis 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 3y agoA great project!
- obilgic 3y agoWould have been amazing 10 years ago. Client side js is what would make this messy to use in big projects imho.
- steve_adams_86 3y agoI 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.
- sneak 3y agoI think it still makes sense to make web apps that can function without JS.
- berkes 3y agoI use templating in rust (jinja) even with rather some JavaScript. My JavaScript modifies the DOM rather than creating it.
- philipswood 3y agoStealing this quote for future use: > My JavaScript modifies the DOM rather than creating it.
- trommlp 3y agoI agree. I use server-side rendering heavily in my projects at work and thus largely avoid custom Javascript (edit: the reason is laziness, not because I outright disliked Javascript). But if I want to enable some very basic user interactivity that does not alter "state" in any way, I will always go for a few lines of JS that e.g. toggles the visibility of some items when a button is clicked etc. So (as usual) the key is to find the balance that works for you instead of pursuing one way (only server-side rendering or only SPA Javascript framework). For the time being this approach works very well for me.
- dgb23 3y agoThis can get hairy very fast. With every project that grew the need for UI state I either wished I went with client side rendering or did so from the start for the parts that needed it. The issue is: manipulating the DOM can become hard to reason about. You either somehow manage to use the DOM as your source of truth, or you manually sync your state into and out of the DOM, and other things like the URL etc. The “immediate mode” style GUI model is much easier to reason about, because you can think of each render as a fresh start. You don’t need React for this, in fact other libraries do this faster and without additional complexity such as Lit. Plus if you use something with web components, it is easier to mix and match client side and server side templating.
- sneak 3y agoI think JS is fine for some UI sugar, but the app should be usable even with JS off. What you are talking about is indeed better accomplished with an SPA.
- treyd 3y agoThere's a huge swathe of projects that have no (or very little) use for client side js.
- lelanthran 3y agoDepends. 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 3y agoNice! 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.
- dgb23 3y agoHugo 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?
- verdverm 3y agoHugo'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 3y agoThat'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 3y agoSeeing a lot of people use this as part of the GoTH stack: go, temple & htmx
- boyter 3y agoThat was my first thought. It looks perfect for use with HTMX.
- markusw 3y agoLove the name. :D
- ducktective 3y ago>GoTH stack LAMP, MEAN, JAM and now GoTH...damn! web people sure have good taste in naming things!
- verdverm 3y agoI'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 3y agoCHAD stack is still my favorite.
- TobyTheDog123 3y agoWhile 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 https://templ.guide/commands-and-tools/hot-reload
- extrapancakes 3y agoI 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.
- janderland 3y agoWhy do you dislike code gen?
- 20after4 3y agoIsn't this basically PHP, but in go? Or am I missing something?
- mu53 3y agoit is html templating, but php's sore points were not the html templating.
- berkes 3y agoI 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.
- dgb23 3y agoIt’s funny but also sad. There is a very simple and productive subset of PHP that I feel got neglected over the last 1-2 decades. The simple, but relatively fast “array”, which has value semantics. The batteries included networking (HTTP, SMTP etc.) and SQL stuff. The stateless execution model and straightforward way to combine and execute scripts. And finally the in-built, seamless HTML templating. It’s unfortunate that especially the last one got neglected so developers feel the need to build a safe abstraction over it.
- berkes 3y agoYup. Unfortunate indeed. It's 2023 and there is jinja, liquid, moustache and then some. Nothing extraordinary. Nothing truly cross language. I think that if the dice fell just slightly different, PHP could have taken that niche. Be the best templating language that has bindings to all major languages. It was really good at arrays, but then piled objects, hashmaps and more on top of these arrays. It had very good and broad string manipulation std functions. But the it piled SQL on top of that. Imagine if instead of mysql_real_escape it had focused on (nested) caching. Or if instead of the umpteenth mediocre OOP class inheritance it introduced template partials as objects to be defined. If, instead of clumsy form handling, it had the world's fasted serialization (to xml, html, JSON etc). Instead of csv parsers, it offered the best stdlib for rendering data. And so on.
- justech 3y agoThe 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 3y agoStandard Go templating seems really lacking if you come from something like Jinja. Even with libraries like https://masterminds.github.io/sprig/ https://masterminds.github.io/sprig/ (used e.g. for Helm templating) it feels hard to use.
- arp242 3y agoIt's different from Jinja, but feature-wise it's about on-par.
- jerf 3y agoStandard 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.
- thraxil 3y agoI'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.
- verdverm 3y ago
- qaq 3y agoGreat project. Part of my go to stack now (FE:Templ+Htmx BE: Go,sqlc, postgres)
- twelfthnight 3y agoRecently 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 agoIf you want to really go back to oldskool way you could use XML for this.
- egeozcan 3y agoYou can try gomponents https://www.gomponents.com/ https://www.gomponents.com/ It also has an HTMX plug in.
- markusw 3y agoThank 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 agoi 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 agoHmm. 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
- chabad360 3y agoFrom 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.
- diceduckmonk 3y agoHow does this compare to html/template in the Go standard library? https://pkg.go.dev/html/template https://pkg.go.dev/html/template Which is based on top of text/template.
- jitl 3y agoIt’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 3y agoI 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 3y agoLast 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.
- dgb23 3y agoDoesn’t go template have a way to define functions? You could then use a function to do w/e you like.
- diceduckmonk 3y ago
- EdwardDiego 3y agoCodegen based? Edit: Yep, codegen based.
- lihaoyi 3y agoPart 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 3y agoFor java/Kotlin, we are using JTE (https://jte.gg/#getting-started https://jte.gg/#getting-started), pretty nice build tooling and IDE support to generate pre-compiled templates without additional code generation steps.
- nprateem 3y agoJTE was a like refinding sanity after thinking I'd be stuck with Thymeleaf when I started playing with Spring Boot.
- rickette 3y 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 3y agoI'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 https://github.com/joerdav/templ-jetbrains
- al_be_back 3y agouseful for generating tedious HTML emails e.g. export Thread to Email.
- KingOfCoders 3y agoCurrently 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 3y agoThat'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 3y agoThere'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 https://changelog.com/gotime/291
- zwnow 3y agoTo 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.
- ducktective 3y agoSo 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.
- markusw 3y agoI've got my own super simple service template that I use internally for this: https://github.com/maragudk/service 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 3y agoWell, 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 3y agoYeah this seems like more of a majestic monolith approach.
- deleted 3y ago[deleted]
- tbarbugli 3y agoThis is pretty useful https://www.jetbrains.com/help/go/integration-with-go-templates.html#define-mapping-of-a-type-between-go-template-and-application https://www.jetbrains.com/help/go/integration-with-go-templa... to improve productivity when working with templates in Go
- donatj 3y agoI 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 https://changelog.com/gotime/291
- ralmidani 3y agoThere 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 3y agoFor 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.
- ralmidani 3y agoAstro 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 3y agoHere is an example of an old technology TAL -Template Attribute Language https://en.m.wikipedia.org/wiki/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 https://github.com/owlfish/tal I wonder what opinion HN has on this type of templating language?
- everybodyknows 3y agoEmacs support for syntax highlighting of .templ files would be helpful. https://templ.guide/commands-and-tools/ide-support https://templ.guide/commands-and-tools/ide-support