[HN Gopher] Templ: A language for writing HTML user interfaces i...
___________________________________________________________________
Templ: A language for writing HTML user interfaces in Go
Author : nalgeon
Score : 210 points
Date : 2023-12-11 04:18 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pier25 wrote:
| 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 wrote:
| A great project!
| obilgic wrote:
| 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 wrote:
| 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.
| sneak wrote:
| I think it still makes sense to make web apps that can function
| without JS.
| berkes wrote:
| I use templating in rust (jinja) even with rather some
| JavaScript.
|
| My JavaScript _modifies_ the DOM rather than _creating_ it.
| philipswood wrote:
| Stealing this quote for future use:
|
| > My JavaScript modifies the DOM rather than creating it.
| trommlp wrote:
| I 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 wrote:
| This 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 wrote:
| I 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.
| berkes wrote:
| I disagree with that premise.
|
| While "it must be usable with JS off" was true decades
| ago for accessability and compatibility reasons, this
| isn't the case anymore.
|
| In my case, the reason for _changing_ and not _creating_
| the DOM with JS is pure simplicity. I 'll just as gladly
| make something that won't work, because it cannot be
| _changed_ this way. Because everyone except for a very
| few "mormons of the internet" have JS. Modern JS even.
| berkes wrote:
| Certainly. I never meant to say "my javascript strategy
| is X and its the best fit everywhere'. As always "it
| depends".
|
| Though, the simple idea of server-side rendered HTML that
| is enhanced with JS goes a very long way.
|
| > or you manually sync your state into and out of the
| DOM, and other things like the URL etc.
|
| The thing is: with server-side-rendered HTML, the issue
| of "State" is solved! Hypermedia is a state-machine
| (REST, HATEOAS etc). What is left, is "state" needed for
| rendering some variations.
|
| You don't need to store state of routers, or the state of
| JSON objects being pushed through immutable-redux-saga-
| whatevers. All you need is some state to determine "the
| accordeon is closed" or "the dropdown is open".
|
| I've applied my strategy to a client-side search system
| once. And while it worked, it quickly showed that actual
| state-management was needed. I used the URL/history-api
| to store all state - so that links where sharable, but
| there's only so much you can put into paths, query
| strings and anchors. I used HTML5 template tags for
| templates and components and some simple JS to fetch JSON
| from a search-backend and pull that through the template
| to insert into the DOM.
|
| What I'm saying is: yes! I agree. You'll need proper and
| nice design patters or architectures to build a UI of any
| scale. But I'm also saying: if you move state-management
| to REST (the backend, server-side-rendered) what you are
| left with is simple enough that it needs no framework
| most of the time.
| treyd wrote:
| There's a huge swathe of projects that have no (or very little)
| use for client side js.
| lelanthran wrote:
| 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 wrote:
| 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.
| dgb23 wrote:
| 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?
| verdverm wrote:
| 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 wrote:
| 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 wrote:
| Seeing a lot of people use this as part of the GoTH stack: go,
| temple & htmx
| boyter wrote:
| That was my first thought. It looks perfect for use with HTMX.
| markusw wrote:
| Love the name. :D
| ducktective wrote:
| >GoTH stack
|
| LAMP, MEAN, JAM and now GoTH...damn! web people sure have good
| taste in naming things!
| verdverm wrote:
| 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 wrote:
| CHAD stack is still my favorite.
| TobyTheDog123 wrote:
| 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 wrote:
| Why do you dislike code gen?
| 20after4 wrote:
| Isn't this basically PHP, but in go? Or am I missing something?
| mu53 wrote:
| it is html templating, but php's sore points were not the html
| templating.
| berkes wrote:
| 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.
| dgb23 wrote:
| It'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.
| dgb23 wrote:
| 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.
| tannhaeuser wrote:
| > _However, you have to escape and sanitize output
| explicitly, which is not a thing in pretty much any modern
| templating language._
|
| Idk if it has to with "modern" or not. Proper escaping
| contexts (whether, and which delimiters to quote in
| attributes, in content, in markup declarations, ...) are
| already defined by SGML, with HTML-aware templating or
| other vocabulary-specific expansion such as suppressing
| <script> elements injection as would be required by basic
| user commenting also being covered by SGML. My impression
| was that go/templating (and maybe pug?), while considered
| advanced relative to other templating packages shitting
| strings into markup, still requires explicit sanitation
| depending on the insertion context.
| justech wrote:
| More like PHP and Pug, but in Go. As someone who likes server-
| rendered websites but prefers Go over PHP, I like this
| approach.
| ckdot2 wrote:
| 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.
| justech wrote:
| 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 wrote:
| 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 wrote:
| It's different from Jinja, but feature-wise it's about on-
| par.
| jerf wrote:
| 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.
| thraxil wrote:
| 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.
| verdverm wrote:
| If you pass a struct as input, you can check data &
| constraints. That's more or less what this is doing as well
| thraxil wrote:
| I'm not sure what you mean. Eg, here: https://gist.github.c
| om/thraxil/5ee7cdb4edb3b4846580e33f17ec...
|
| there's an obvious typo of a variable name in the template
| "Titl" instead of "Title". Program compiles. Parse()
| succeeds. It just fails at runtime (outputting "<title>"
| and stopping. My understanding is that a Templ equivalent
| would probably end up with a compile error much earlier on
| (and probably more obvious in your IDE as well).
| verdverm wrote:
| That's something that should be caught at test time. It's
| like having a bug in your code.
|
| There is another class of template bugs that comes from
| input data, that's what I'm referring to. The validation
| catches it before rendering
| thraxil wrote:
| Yes, it's exactly like having a bug in your code. Using
| Templ means that it gets caught at _compile_ time (if not
| earlier since your IDE can show you that there 's a
| problem as soon as you write the code). That's (IMHO)
| almost always preferable to catching it at test time.
| verdverm wrote:
| You have to introduce a new tool to your box and run more
| commands, so it is not free
|
| people have a resistance to increasing tooling, and
| especially learning a new syntax or language, for a small
| task in a larger project
|
| Since we test already, adding a test is often a much
| easier ask and lift
|
| on top of that, you still need to validate inputs and
| test rendering with Templ anyway
| qaq wrote:
| Great project. Part of my go to stack now (FE:Templ+Htmx BE:
| Go,sqlc, postgres)
| chabad360 wrote:
| 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 wrote:
| 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 wrote:
| If you want to really go back to oldskool way you could use XML
| for this.
| egeozcan wrote:
| You can try gomponents https://www.gomponents.com/
|
| It also has an HTMX plug in.
| markusw wrote:
| 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
| arccy wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.)
| kitd wrote:
| 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 wrote:
| 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 wrote:
| 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/
| trommlp wrote:
| 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 wrote:
| 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 wrote:
| 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
| diceduckmonk wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dgb23 wrote:
| Doesn't go template have a way to define functions? You could
| then use a function to do w/e you like.
| ckdot2 wrote:
| 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.
| shhsshs wrote:
| That is not quite a true "slot" behavior because the
| containing pages have to have a reference to the main
| layout via `{{ define "main" }}`
| ckdot2 wrote:
| You're right. But this only means that it won't be
| possible that you use the same template for different
| slots. Personally, I don't remember I ever needed that.
| Actually, most template engines I know work this way (htt
| ps://twig.symfony.com/doc/2.x/templates.html#template-
| inh..., "{% block content %}"). But still, it's easy to
| archieve that by just creating another sub template. So
| your first template file is the layout, the second one
| contains the main block definition, and that definition
| you just include another sub template which can be reused
| elsewhere.
| ckdot2 wrote:
| Here's a blog post which goes more into detail:
| https://kilb.tech/golang-templates
| EdwardDiego wrote:
| Codegen based?
|
| Edit: Yep, codegen based.
| lihaoyi wrote:
| 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 wrote:
| 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 wrote:
| JTE was a like refinding sanity after thinking I'd be stuck
| with Thymeleaf when I started playing with Spring Boot.
| rickette wrote:
| "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 wrote:
| 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 wrote:
| useful for generating tedious HTML emails e.g. export Thread to
| Email.
| KingOfCoders wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ducktective wrote:
| 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.
| markusw wrote:
| 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 wrote:
| 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 wrote:
| Yeah this seems like more of a majestic monolith approach.
| tbarbugli wrote:
| This is pretty useful
| https://www.jetbrains.com/help/go/integration-with-go-templa...
| to improve productivity when working with templates in Go
| donatj wrote:
| 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
| ralmidani wrote:
| 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 wrote:
| 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.
| ralmidani wrote:
| 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 wrote:
| 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?
___________________________________________________________________
(page generated 2023-12-11 23:02 UTC)