go podcast()

Dominic: 00:01

Hello there. I'm Dominic SMPI and you're listening to Go Podcast. Today I'm joined by Adrian Eskith, the creator of Temple and Joe Davidson, a maintainer. And we are talking about Temple. Hey, just a quick note before we dive into the interview.

Dominic: 00:21

So, I took a small break of the podcast lately. So I need to think a little bit about the future of Go Podcasts. You know, it's almost it it will be 3 years in December that I that I'm doing it. So yes. I mean, it's, it's tough, but, I'm, you know, I I I need to think a little bit about that.

Dominic: 00:42

But, yeah. Again, if you have any suggestion on topics or if you want to, to join me as as a guest, I mean, do not hesitate to contact me. The best way at the moment is on Twitter. I'm considering to open a channel on the the Go Slack community. So, I mean but, yeah.

Dominic: 01:01

We are talking about Temple today. And to be completely frank, after, you know, after having this this talk, I I have been in contact with Temple before. And now, I mean, now that I've talked with those 2 guys, and reread the entire documentation, which is it is not, you know, it is not big. You can digest the documentation in, in like 20 minutes or something like that. And, and, yeah, I'm, I'm, I'm now tempted to, to probably try to switch.

Dominic: 01:37

I'm I'm build I'm building something at the moment. I'm building a a small a small SaaS, a small startup. And, I'm using the HTML package. And, yes, I, I'm I'm now very tempted to, to try and see if if Temple could could work for me. But enough of that, let's let's dive in into the interview.

Dominic: 01:58

Hello, gophers. So I have 2 guests, today. So thank you very much, Joe and Adrian, for joining me. So, I will let you introduce yourself a little bit. So you are both maintaining, or maintainer of Temple, the, you know, the Go, I don't I'm not even sure how to describe it correctly at this at this at this point, but let's say a library to, to do some HTML in Go.

Dominic: 02:26

So if you want to introduce yourself, we will we will start from there.

Adrian: 02:32

Okay. Well, I guess I'll start first. I'm Adrian. And, I guess I started Temple and, worked on it with Joe.

Joe: 02:44

Yeah. And I'm Joe. I've been developer for, like, 10 years now, and been doing Go for 4 ish years. And, yeah, jumped on the temple bandwagon. I don't know.

Joe: 03:01

Maybe 2 years ago. Right?

Adrian: 03:02

I think, yeah. I I mean, I think you really helped shape the, the design of it, of of how it sort of came about, certainly version 2, after the kind of initial first 12 months.

Dominic: 03:16

So I'll I'll hold this this temple, actually. I I I came I came across, I think it was kind of a long time ago, but, may maybe, you know, from the the brief talk that I had with with Joe, it seems to be, it seems to be an an older project than what I would say, you know, most people are are seeing it.

Adrian: 03:35

Yeah. I think it's probably 3 years old. Maybe a little older even than that. Okay. It started out as a bit of an experiment.

Adrian: 03:44

I've just come off a a big project to work doing full stack TypeScript, and, I kinda felt unsatisfied with the the outcome for a few reasons. I mean, commercially, it was a huge success, and, you know, the product worked and all the rest of it. But I felt like we'd spent a lot of time fiddling around with JavaScripty stuff and haven't spent a great deal of time, on the back end. And I just started to think to myself, like, you know, is this really the best we can do? You know, is there is there something else we could do?

Adrian: 04:17

Like, could I have spent more time improving the performance of the back end, and that would have resulted in a more traditional front end actually being a completely fine way to to build this sort of site.

Dominic: 04:32

So I I guess you you were, like, building some kind of React application on on the front end. Is that Yeah. That's right.

Adrian: 04:39

Yeah. Exactly. A big retail site. It was doing, you know, a couple of £1,000,000 of of revenue every day. It was doing great, commercially, but it was a lot of, like, things like the build process for the front end were was really long took a long time to to build that stuff, and I guess that was a bit of a shock to me having been a developer for a long time just how long a JavaScript build can take with all the kind of bringing in all the NPM modules and all the rest of it.

Adrian: 05:13

It seemed to take way longer than it ought to.

Dominic: 05:16

Oh, yeah.

Adrian: 05:17

And and then also the the coding of it was pretty complex as well. You know, people had really gotten into things like useEffect in React, and you could quite quickly tie yourself into knots in the in the ecosystem, and and it took a bit of digging to get yourself back out of it, especially once you started layering on library after library and how how those started to interact with each other. And, yeah, I just thought to myself, hey. Is there something else that we could be doing? And that kinda led me to looking to things like Hotwire as it was at the time and then later, HTMX.

Adrian: 05:54

And I think, initially, with Temple, I was, like, looking to try and introduce some of the developer experience, things that I felt like you couldn't really live without, like so things like I now expect to have autocomplete in a in a in tooling. I expect something that's a little bit like JSX. I expect components. And I expect syntax highlighting in my editor I expect all of these kind of luxury items and couldn't really see that in the Go ecosystem so I started to so basically started out trying to add things like IDE auto completion to Go's built in templates and then, looking at things like quick template and trying to add IDE auto completion into there, but I realized quite quickly that it was probably not gonna work because of the design of of each of those. Haven't really considered, those capabilities from the outset.

Dominic: 06:51

When you say completion, you you you mean from from the data that you are sending to the views, for example? Am I Yeah.

Adrian: 06:59

Ex exactly that. So, you know, if you for instance, if you if you're trying to sell, car insurance or something, you typically want to have, you might have an insurance document or something that has, like, hundreds of fields and just making sure that you're displaying the right fields to the user and that you can discover them.

Dominic: 07:19

Yeah. Totally. I I get it. So so at some point, you you wanted to to try and see if you could, like, replicate the experience that you were having on the back end, but for for front end kind of

Adrian: 07:34

Yeah. Outbound. Yeah. I I guess I realized that a lot of the work I was doing was really just building forms. You know, it's like, you know, a pretty basic form app.

Adrian: 07:44

You know, you're putting in your address. You're doing some basic stuff. You have to do some validation on the client side, but then you have to do the validation again on the server side anyway. And I thought, well, you're kind of developing it twice there. You're kind of doing something on the client, doing something on the server.

Adrian: 08:00

Okay. You might be using, you know, one of these JavaScript frameworks where you've got sort of server side rendering, on the back or or you might do some sort of back end stuff with Next. Js or so on. But even then, you've probably got some of the APIs that you're interacting with that also do some validation. And it just seemed like, oh, you know, there's there's a lot of layers here, and there's a lot of, replication of effort.

Dominic: 08:24

Yeah. Yeah. I hear you on that. So would would you say so how how would you describe Temple, for example? You know, to whom exactly are you are you targeting?

Dominic: 08:34

Or at least in that moment when you started the project?

Adrian: 08:40

I get you know what? When I was starting the project, I was really targeting, the Go development team, the people that make the Go programming language, if I'm if I'm honest. What I was really wanting to show was, like, a demonstration of, you know, what was really necessary, I felt, for Go to be useful, for building web front ends. I didn't feel like the built in templating was go was was enough. And I guess what I was hoping to do was show, like, hey.

Adrian: 09:15

If we have this sort of thing, that would be great.

Dominic: 09:20

Yeah. And and do you do you have any any well, the yeah. This is interesting to me. So that sentence that that you just said. So the Go HTML template was not enough.

Dominic: 09:31

And I I I feel you on that. I'm half and half, I would I would even say. So sometimes I feel like I would I would want something else. Sometime I just find it, like, decently, stable. So my my question is at this point, in the Go community it's kind of difficult to bring a new library to the table.

Dominic: 09:56

I mean, it's built in into our mindset. You know, people that are doing Go for a long time. I don't know if it's because we have been bitten by dependencies or third parties, libraries in in the past or what what exactly it is, but so what was that a concern when you when you started the project at all?

Adrian: 10:21

Oh, yeah. I mean, I I guess, you know, you absolutely. You know, I I first, I mean, I didn't want to create a new library. You know? I wanted to, I wanted to work on quick template or, or work on, adding auto completion to the built in features of Go.

Adrian: 10:41

I didn't wanna be that person who makes another library when there's already 10 perfectly good ones. But, like, a lot of the, like, front end I I guess a lot of the HTML templating libraries for Go had either been sort of abandoned, or, you know, didn't really have that support for the syntax that would allow them to support, the auto completion.

Dominic: 11:06

And would you say that Temple is well, may maybe maybe today or or at least, back back then when when when it started, more targeted at people that that are used to build React application that they are kind of finding things that they are used to, like the component, for example, and things like that. So so are would would you say that yeah. Okay.

Adrian: 11:31

I think that's a first statement because, I guess, you know, I've been developing web apps for over 20 years now. So I guess when I started out, I was doing sort of Perl and that kind of stuff.

Joe: 11:44

Nice.

Adrian: 11:45

And then went into ASP 3.0 with, when, you know, using VB script.

Dominic: 11:50

Yep.

Adrian: 11:51

And then moved into ASP dot NET Web Forms and stuff like that, and then moving through to MVC. And, obviously, you know, there's all sorts of different techniques along the way like, you know, Django apps and all the rest of it. So I've seen lots of technologies kind of come and go over the years, before moving on to things like Knockout JS and then, you know, through to React and and all that kind of stuff. So I've I've seen a lot of different tech come and go through the period. And I guess there's always, like so to me looking at the Go side of things that that's available in the templates, It looked far worse than what I had 10 years ago and I just thought that that that can't be right you know in the sense of developer experience.

Adrian: 12:36

You know when with Razor Views I had a lot of a lot of the kind of ability to build components or partial, partial elements, the ability to sort of bundle things up in libraries and distribute them, share them across teams, and that sort of thing. And then, so but yeah. Like, definitely I guess, if you if you think about it from the most basic proposition, these kind of there's a few libraries in Go that, take the approach of writing HTML in Go code. So you just kind of write HTML out by hand. I can't remember the name of them, of one of them.

Adrian: 13:09

I think one of them might be components. I think that's right. And with with that one you kind of write HTML in Go and that's probably the most efficient way. You don't need a kind of DSL or HTML parser and all the rest of it. But I thought it, you know, what what people are used to and, you know, when I'm when I'm introducing this concept to a team of, right, okay everybody, if you get web developers today, you know, chances are that they've learned React.

Adrian: 13:40

They they might in many cases, they haven't really learned to build HTML apps outside of that React ecosystem. They've often started from React, and that's their first experience in building web applications. So we've gotten to the point now where I think, I remember working with a junior engineer, and, you know, the concept of a HTTP form post was completely alien because he'd spent his whole career so far sending data over, you know, the fetch API and and didn't really understand that you could do a HTTP form post. You know? That that's that's the world we're in now where we're so far removed in some cases from that that you have to go back to the beginning and and sort of re re explain some of the old fashioned ideas, which I guess is where the hypermedia book comes in, handy, I think.

Dominic: 14:32

Interesting. So yeah. So I I I guess that's a little bit why you you were saying that maybe h t m x for you was was was not was not the solution or at least, for for this this particular junior developer, at least, probably.

Adrian: 14:47

Well, HTMLX is great. It it was more it's more the case of you know, when you're introducing something to a to a team, it has to be something that, you know, the whole team has to be able to buy into that concept if you like. So the I felt like the idea of writing raw Go and building up web web applications through through that would be a little bit intimidating, and I thought that it would be more straightforward to see something that looked a little bit more like the JSX that they were used to, but ultimately gave you, like, the you still have the composition. You still have the developer experience. You still had all the other stuff that you were used to, but you have that kind of familiarity.

Dominic: 15:29

Right. So Joe was telling me that at first, there were like, the the templating syntax was not what it is. Because what what it is today, correct me if I'm wrong, because I I haven't used Temple, yet, but it's it's similar to it's good old HTML at the moment. But at first, you you were having, like, handlebar, braces, like, for for inputting the the data, I guess?

Adrian: 15:55

Yeah. I think, well well, Joe, do you wanna tell that story? Because I think it was, the feedback came from you, like, when through our first use of it in a commercial setting. Right?

Joe: 16:05

Yeah. So I I think, yeah, it's hard to describe the syntax with, with words. But, essentially, if you've used handlebars before, that was the initial syntax. So if you wanted a, if statement, for example, you do open curly brace, percentage sign, if percentage, curly brace. Well, after the if, you would put your condition, and then you'd have, your HTML inside of that, which would be rendered conditionally.

Joe: 16:39

And to close that off, you would have a open curly percentage, end if, and then another percentage, and close curly bracket. And it served its purpose for a while, like, because the the initial thing was to prove that we could have, like, strongly typed Go templates, with language server capabilities. But as we were using it, ergonomically, we started using it to generate documents, legal documents. So the strongly typed part was was very important for us. We couldn't be getting any kind of runtime errors like you can with the go HTML templating.

Joe: 17:28

But we're getting our hands dirty with with using that syntax. It felt less familiar to actual Go code, so the the benefits that I could see were that you you had familiarity moving from go code into dot a dot a dot temple file. And I wanted to kind of increase that familiarity. I wanted to kind of have everything be ergonomic. Like, a user could guess what the thing that they I thought that a user should be able to guess what the syntax was for the feature that they were trying to use rather than having to refer to the docs.

Joe: 18:21

And I think that meant a lot of thinking around syntax and how can we build how can we combine HTML and Go and not add a third component, which is like temple syntax? Right. And there there's still there's still some parts that that are kind of temple specific, but I think, yeah, keeping in mind HTML and Go as much as possible was the priority that I had when I came to Adrian with the the idea of changing the syntax.

Dominic: 19:00

So you I was

Adrian: 19:01

sick I was sick of typing the extra characters as well by that point. So I was like, yeah. Let's do this.

Dominic: 19:06

So it was it was, it was still a it was compiled at some point. Right? Was that was there any parser, or it was directly compiled into something else at that time?

Joe: 19:17

Yeah. There was

Adrian: 19:18

there was always a parser. So I I set out, with a with a basic parser from the from the get go. So it would, it would turn into a basic object model of of HTML elements and then, kind of, it would look specifically for if statements. But it was a really like, initially, it was quite basic. It looked for things like, you know, the end of the line and stuff like that.

Adrian: 19:40

But it you know, the initial kind of proof of concept works really, really well, and I was comfortable enough to sort of take it into production. And, yeah, it was a sort of 2 step process. So the first step is to pass it into the object model, and then there's a Go generation step that generates raw Go code. And what that what that really does is, really helps on the performance side of things because the the object model disappears at runtime. You it's just rendering out strings as quickly as it can, so it gets, it approaches really good performance like, you know, approaches the performance of quick template.

Dominic: 20:19

So even even back then, you you had, like, a way to to know what data was passed to to a function, for example. And

Adrian: 20:31

Yeah.

Dominic: 20:31

You were having, like, not the you know, auto complete and and whatnot. Right? You you were having suggestion about this is this is the the structure that I'm receiving. Those are the fields and and whatnot.

Adrian: 20:43

Yeah. Absolutely. Yeah. Right from right from the first go. Because that that was the whole point really was I I was basically looking for a templating language in Go that I could that I could say, yeah, this is good.

Adrian: 20:56

And I wanted it to have autocomplete. That was it. I just well, you know, I thought to myself, I'm not not not having autocomplete in in the in 2021 or whatever. It was like Yeah. Can't live like this.

Dominic: 21:11

Okay. May maybe maybe it will be a a newbie question because I I haven't used it. So let's say let's say I'm creating a function or a component. Let's call it a component. So I I would expect I would guess that it it's it's it's going to be a a function that returns some kind of HTML or things like that.

Dominic: 21:30

Yeah. How can I, you know, how can I be using that function? So if if it's going to need to be parsed and there's some go generation, you know, what what is the flow for for a typical developer to continue to to have access to those new function that you are creating? So is is it always running on the background, for instance?

Adrian: 21:55

Yeah. So when you're when you're, when you're in the editor, if you like, the language server is constantly being notified in real time of every tech every keystroke that you make. So what it does is it's constantly passing your your document every time you make a change, passes it into the object model, and then converts it into Go code. And, when it generates the Go code, it keeps references to the specific, locations in the Go code, that it's just added. Like so if you if you create an if statement, for instance, it keeps in memory it keeps in memory the location of that if statement within the within the go the generated go go file itself.

Adrian: 22:39

And then when it it generates that go code and sends it to the go, please, language server. And the go, please, language server might respond back with some diagnostics, and those diagnostics might might be referencing a section in the Go code, which was, which is ultimately back in the temple code. So it looks it does a reverse lookup on the location in the temple file and then puts the diagnostics in the correct location in the in the in the temple file. So in that in that way, that's how the kind of language server element of it works. But in terms of, like, developer workflow, you create a temple file.

Adrian: 23:15

You write, you know, temple, which is like a replacement for the keyword func. And then you define a function, and you can just write HTML in that function. And then, you run the temple generate command line. It generates you a Go file that has that function that you just created expressed inside the Go file, and then you can call the render method that, on the results of that.

Dominic: 23:39

Okay. So you you constantly need to to call this generate, tool.

Adrian: 23:44

Yeah. That's right.

Dominic: 23:45

Okay.

Adrian: 23:46

But it's fast.

Dominic: 23:48

Right. Right. Right.

Adrian: 23:49

And there's, there's also a watch mode built into temple as well. So you can run you can run temple watch, and it'll watch all of the temple files and auto generate new files in the background. In in fact, there's a there's a a little optimization in there that one of the contributors added where if you're in watch mode, you can also, get it to read from files on disk so it doesn't actually recompile your Go program. So I think one of the challenges of working in, in a compiled language and building web applications in a compiled language is what happens when you're like, you get used to this idea of, like, I'm looking at my web page. I make a change to my code.

Adrian: 24:26

I hit save. When I look back at the web page, I wanna see those changes reflected in real time. Right? Yeah. And, you know, in a Go program, if you're building a kind of monolithic web like, web app, it might actually take a second or so for the web server to start back up again, as you do things like reestablish database connections or, you know, it depends on the start up time of your application and what you've done to optimize it.

Adrian: 24:51

Right? But you you wanna get into this kind of quick cycle of make a change. We see it reflected on the screen. So one of the like, somebody contributed a, a change, which you can put the the watch into a mode where it only recompiles your it only like, it reads the text strings from from a file on disk. So you can make changes, to the text that's on the screen without completely recompiling and restarting your web server, and that that makes it, faster.

Adrian: 25:23

So you can have this kind of cycle of of of looking through your changes really quickly.

Joe: 25:28

Which is a it was a massive, massive improvement, and people do expect to have that these days in their their web development stack. Like, I think, initially, there's a lot of kind of requests for a hot reload that was faster. So I think someone must have I wish I could remember, their name now. But yeah.

Adrian: 25:56

I'll have to look at the commit history. Yeah. That's That was it as well. That was the only change they've ever made. Like, just came in and did that and, like, never seen them again.

Joe: 26:04

Yeah.

Dominic: 26:05

This sounds, this sounds awesome. I mean, the yeah. I I can see. I can see. So maybe maybe I can tell you exactly why I haven't used temple yet because I I think maybe I'm I'm not alone or maybe I am.

Dominic: 26:18

I don't know. So for me, when I when I started to look at the documentation and, you know, understood that, okay, you know what? I I will have this new this new temple file format now, you know, I was kind of distracted by the fact that maybe I would not have all, how can I say that, the, you know, all all all the the things that I'm used to from my editor when I'm when I'm editing HTML file? I'm talking about, maybe auto complete, maybe collapsing some, some some divs. Sometimes I do that because I need to move them.

Dominic: 27:00

Being a blind person for me, it HTML is kind of a pain to edit. So I was kind of very prudent to, about that because now there's some Go codes, you know, intermixed with HTML. So I would that was my concern.

Adrian: 27:22

Yeah. I can't even begin to imagine the challenge there, to to run us to that's, yeah, that's really tough. You're absolutely right. It has been I think people have, you know, I guess, it's inter what's really interesting about having a library like Temple that some suddenly becomes popular is that you realize how different everybody's workflow is. And, you know, there isn't there certainly isn't a one size fits all kind of thing.

Adrian: 27:50

You know? Like, Joe and I both use Neovim as an editor. Right? But a lot of users use Versus Code, and others use, kind of the IntelliJ Suite as well. And one of the things that really surprised me was how much people use the HTML auto completion features in Versus Code, which, frankly, I didn't even know existed because I've only ever really done React in Versus Code.

Adrian: 28:17

And in React, you don't get those features at all. So I was like, what are people going on about? I don't understand. But it took a while to to get to to to get to understand it. And, I think somebody just recently added the, some basic, document, outlining, didn't they, Joe?

Adrian: 28:36

You you merged it just the other day.

Joe: 28:38

Yeah. Yeah. The kind of attribute autocomplete based on, HTML Because kind of, in Versus Code world, you can't have a multiple extensions kind of controlling one file. So for for me and Adrian, we're using Neovim, where you can have multiple language servers running against the same file. So we can just turn on the temple language server, the HTML language servers, the HTML language server, and get all the features from all of them.

Joe: 29:22

Whereas with, Versus Code, you have to assign one extension to 1 to one file type. But, yeah, a user had found a setting in the Versus Code configuration that allows you to kind of pull in another language server, essentially, as a dependency. So yeah. Now now there's, HTML completion as well as the standard temple, and Go completion.

Dominic: 29:57

Yeah. That's interesting. Very and what what about yeah. For for me, it's not really, the the auto completion more than the, when I when I'm on a dev, I I I often need to go to the end of that div. So when, you know, for for sighted people, it's very easy for you to navigate around.

Dominic: 30:15

So that is, you know, that is crucial for me. So is and, you know, I understand that that everything that you say, about about the the language server be being a single a single but that that that's good. I I will need to to test it. So let's, let's return a little bit to I mean,

Adrian: 30:34

that's you know, that sound that does sound interesting, you know, being like, I think, Neovim has some features around sort of moving between, different elements and so on. So I think, again, it might be it's very sort of individual specific on that stuff, but, you know, always happy to sort of try and accommodate people for sure.

Dominic: 30:54

Oh, yeah. You know, I I mean, it's, yeah. I I would I would personally use use Vim more, but, yeah, Versus Code is so so friendly for, you know, for blind people. So for for instance, when it when I'm when I'm collapsing some some div, there's some audible, audible sound, that that tells me, you know, this this this block is is now yeah. Because switching from HTML is so verbose when if you can imagine a person that is using a screen reader as to kind of listen to all all the div, the classes, the the the things.

Dominic: 31:31

So I mean, it's it's pretty, it's pretty rough.

Adrian: 31:34

Yeah. But

Dominic: 31:35

but but yeah. I mean, it's it's it's not I'm I'm I'm not, I'm not representing a huge, a huge portion of the of the Google Developers. So let's say let's say I want to to do, you know, looping and whatnot. So so are you are you are you just doing some good old go in there? Like a I can use a 4 with the range and things like that.

Dominic: 31:59

Do it, do ifs and things like that. So it's it's all it's all, like, standard go, basically, in the template?

Joe: 32:09

Yeah. Exactly. It's kind of like the control flow, keywords you would expect to work in a temple file all should work. Like, you have here for if switch statement. They all work you you you write your HTML, and if you write an if statement, there's no special syntax to kind of signify it's an if statement.

Joe: 32:35

You just write it and then continue writing HTML with within the curly braces of that if statement. The only time you have to kind of do any kind of temple syntax is to do interpolation into HTML. So you need some curly braces, opening and closing to write some maybe a go function that returns a string or something like that.

Dominic: 33:05

Interesting. And what about I mean, when I'm using the, the template slash, the s HTML template, the bay you know, the barebone things. I'm often using like I don't know how to when I structuring my pages, for example. So let's say we are building an app, like a CRM, for example. So you might you might have a template for your main application.

Dominic: 33:33

And when a user go from pages to pages, I mean, they, you know, the the global shell of the application stays the same. So how how how how would I structure a template like that in in Temple, like a base views, for example, or or layout pages?

Joe: 33:54

Oh, so we have, composability. So the ability to put, like, other HTML, components into your into your component and kind of build a tree of, temple components. And you do that by putting a at symbol before the function call to your your subcomponent. But there there's kind of this other concept of, I think we call it block components. So you do at symbol your function call, and then you would open curly braces and start writing HTML within that.

Joe: 34:41

So it's kind of like a a wrapper around the child HTML. It's kind of like in React how you would do, like, a an open tag and close tag for a React component. And within that, components code, you would be able to tell it where to render the children. Yeah. So that that composability is how I would do a a layout in Temple.

Adrian: 35:08

There's a there's essentially, like, the components, like, are essentially functions. So it's a case of passing functions to functions is one way. Or you can or you can have this concept of, like, let's say, like, the concept of I'm I'm wrapping some children, and you can pass so you can you can kind of you don't wanna make a big song and dance about the, kind of creating an extra component. You can kinda create an anonymous child component for for for elements because it's the most common, I guess, the most common use case.

Dominic: 35:41

Right. And, you know, what what what does it look like? So let's say let's say we are in a typical Go handler, an HTTP handler. So so how how would I render, you know, the top top level component for instance? Because I I would I would guess that if it's component based like that, I would choose let's let's render, I don't know, the the dashboard page or whatever it's called.

Adrian: 36:05

Yeah. So you you might I might start out that approach by having a page component. Mhmm. And the page component is a function that takes in possibly the body. It might take in, some meta information or, some other info.

Adrian: 36:23

And since the page is, aside from that page, I might have a page 1 function, and, that page 1 function is really the content of the of the page. So it just starts from h one and proceeds, you know, to display an article or something. And then you would, call the page function and pass it the page 1 function. So you've got, like, the layout. I should have called it layout instead of page.

Adrian: 36:47

So let's say you've I'll start again and say, okay. I'll create a function called layout, a temple component called layout that takes in a that takes in a component called content. And then it's a case of calling layout and passing it the content.

Dominic: 37:05

Yeah. I got it. So and and you and you would pass the so let's say let's say you you wanted to pass a structure, you would pass that to your content component directly.

Adrian: 37:14

Yeah. Exactly. Right. You you can also do, there's also a concept of, of of drilling through like, prop drilling through through context as well. So you can pass a component through and grab it out of the context for later if you really want to, but I prefer to be explicit on the whole.

Adrian: 37:30

There's a there's a some information on the documentation about, like, the the concept of prop drilling and and how that kind of manifests itself. It's a kind of React concept, but the idea is obviously, like, if you've got, like, a lot of top level information and then you want to use that sort of deeply nested within the hierarchy, you can either pass that information all the way down through each component call. But that can lead to complexity in, in refactoring where, you know, a simple change that's deeply nested in the hierarchy results in, you know, changes all the way through the hierarchy. So you can kind of avoid that by the concept of prop drilling by passing things through the context if it if the interleave inter if the layers in in between those two elements are not really important.

Joe: 38:15

And it's kind of as as a as a usability kind of standpoint, if you're building a component to be used elsewhere, if you're using values from the context, you're not really communicating the contract of what's required for that component.

Dominic: 38:34

Right.

Joe: 38:35

So it may it may just throw an error because you're not passing the right things into the context. So that might be fine if you're a a developer on your own, and you know exactly what's required for for each function. But on a team, and especially if you're building a component library or something for other people to use, you want to be very explicit about what's required and what can be passed in.

Adrian: 39:02

But, you know, Temple is really flexible because it's really based around the concept of a single interface. And so the Temple component interface, is an interface that has one function on it called render. And the render function takes a context and an IO writer and returns an error. So you can implement the the temple component interface in program code, and that allows you to do things like, if you have a HTML template, there's a there's some, conversion functions in the temple library that just let you include that as a temple component in in the rest of your system. There's no and vice versa.

Adrian: 39:44

Actually, you can, you know, you can render a temple component and use it within another within another ecosystem.

Dominic: 39:51

Yeah. I can I can see how sharing things, from, you know, across teams would would would make more sense than, I don't know, pitching some HTML loose a HTML file and hoping

Joe: 40:03

that yeah?

Dominic: 40:04

Yeah. I I I would expect that once you once you get used to having strongly typed, you know, views like that, I mean, you you just cannot really go back to having some kind of, I don't know, you know, the the any interface, pass to your views.

Joe: 40:22

Yeah. It's definitely, gives you a lot of confidence. I actually had someone reply to a a tweet. It's they said that Temple reduced their anxiety, which was interesting.

Adrian: 40:37

Well, that that's good. That's good. Although, you know, I also said I think, that same tweet, I think someone said, I will never use that. Are we allowed to swear on here? You know, they're because I think some people react really strongly to the kind of DSL element to it.

Joe: 40:57

They're like,

Adrian: 40:58

Some people are like, oh, yeah. Okay. That looks friendly. That's like HTML. And other people are like, what what's the point of that?

Adrian: 41:04

Right? Like, you know, you could you could write that in Go code. Why why would you, why would you introduce the DSL? I guess my my stock answer to that is, you know, with React, JSX and TSX is compiled down to JavaScript. Right?

Adrian: 41:21

Ultimately, under the covers, it's it's writing out React dot create element, but you'd never see anybody write that, do you? Nobody sits down and goes, today, I'm gonna write down react to dot create element. Mostly people use the JSX and TSX syntax because they find it convenient.

Dominic: 41:39

Yeah. Totally. And you don't you don't have to to sell me on that. I was a huge fan of Elm, and, I mean, Helmond at the end of the day. It's it's just a DSL as well.

Dominic: 41:49

Yeah. I'm I'm curious to to know a little bit more about when you say earlier that there might have been some challenges turning an an an issue or a warning from, from the language server back to the temple code. Because at the end of the day, when when the temple code is is, generated into Go. So how how are you going from that error or or or this Go code back to the the template?

Adrian: 42:22

So the when we generate Go code from the from the template, when, like, we have the concept then of we bring the we pass the template into a object model, and the object model is, like a it describes each of the elements in the temple file. So it it has the concept of Go expression, and it has the, like and it has the concept of, like, an interpolated like, so that so, for instance, if you look at HTML element. Right? It it has the concept of a HTML element that you pass into, And then the attributes themselves can be of different types. And one of the attribute types is, like, a string expression attribute which knows that the, you know, that it's going to render a bit of Go code as a as a as an attribute value.

Adrian: 43:13

And then there's also a string expression when you're rendering when you're rendering out some go code in a html context just in the body of your html so when we're rendering those little sections into the target go code we keep a record of where those are in the target, in the target go code. And when we receive a diagnostic from go, please, about that, we can then remap, the the location from the from the go code right the way back into the temple code. And so that puts the red squiggly underline, if a visual for those who can see the visually the visual kind of things, that's where you see the diagnostics. Or you, I guess, in your case, maybe get a list of the diagnostics for your for your tool.

Dominic: 43:55

Yeah. When you're using a screen reader, there there's also a sound for, for this squiggly line. Yeah.

Adrian: 44:01

I'm gonna have to check this out. I was

Dominic: 44:03

Oh, yeah. VSCode is pretty good for, for a screen reader user. I I would I would prefer to use Vim, but, I mean, what? At the end of the day, what you want to do? I need to go with the I was an Arch an Arch user, Arch Linux user for a long time, but at some point, I needed to switch to screen reader.

Dominic: 44:22

So it's Windows for me now. What Oh, yeah. Can I do? Yeah. It's it sounds pretty interesting.

Dominic: 44:27

So what what about the challenges? We know, I mean, this this sounds, this sounds pretty interesting as as code, the the parser, the generator, and also going back to was was that was that hard? Is is there, is there any challenges, left for Temple, actually?

Adrian: 44:46

I think so. Yeah. I think there's a lot I think there's a lot of challenges. I think the initial challenge of LSP was really that at the time, there wasn't a great deal of documentation around, how to do

Joe: 44:58

it. Mhmm.

Adrian: 44:59

So, you know, the the the language server protocol kinda came about through Versus Code, and it was really driven from the Versus Code development team. And then other people adopted it, really. It's not you know, it wasn't sort of so it's written in TypeScript, basically, is the specification. So you have to have a pretty good understanding of TypeScript anyway to to read the spec. But it's also it also has some JavaScript isms in it.

Adrian: 45:29

You know, as in, like, oh, we're gonna return something, but it could be one of these. But it could also be a different type completely, and it might be an array. Like so you have those kinds of issues to deal with. And I guess I initially started off with the source graph, LSP library, but then there were some changes to the spec and it wasn't really sort of maintained. So I switched over to, another library, and figured out how to use that.

Adrian: 45:57

And I maintain a little fork of that now because occasionally I run into sort of incompatibilities or or issues or need to move a little faster than that library. That one is a lsp.dev library, which is is pretty good. But it seems like it's mostly, you know, generated from kind of the spec and trying to sort of follow the the spec. But, I think the main challenge really was trying to, you know, understand what the editor was going to send and the structure that it was going to send. So it's okay to read the spec, but the spec really just covers the message structure.

Adrian: 46:28

It doesn't really cover, like, so much the handshaking between the editor and the and the LSP and how that works. So, like, it works over, a protocol called JSON RPC. So, like, there's a concept of a a sending sending a message and then receiving a message or sending a notification, which then doesn't receive a message, back. But they can also be interleaved, so you can send multiple messages and then get out of order responses. And you I guess you can do the you can do JSON RPC over any transport but the one that the LSPs mostly use is standard in and standard out.

Adrian: 47:06

So you kind of you open up a process So in my case, if you open up a Temple LSP, Neovim will kind of open up Temple LSP and then start passing messages over standard input and then it'll expect some responses back over standard output. So I guess the main challenge was really kind of inspect like, building up inspection of those kinds of things, working out what was going on, which bits of the messages were important, which bits weren't important, and and that sort of thing. So I think that that that was a bit of a challenge to get started with. And then I guess it's it's just a lot really. You know?

Adrian: 47:44

Like Yeah. Building a Versus Code extension, dealing with the LSP and dealing with everything else, it's just, like, none of it is particularly, you know, hard. It's just that there's a lot of it.

Dominic: 47:57

Yeah. I would I would guess there's a lot of noise as well probably in in those, in those payload that that you're receiving from or at least that you have to send and things like that. Yeah.

Adrian: 48:07

Yeah. I think that's a fair statement. But I was really keen to try, you know, to make temple into you know, I have a I have a job. You know? I have, I have hobbies and things that aren't temple.

Adrian: 48:17

You know? So Yeah. I wanna make sure that this thing is a a sort of sustainable project, like, not a, you know, not something that needs, like, you know, a full time team to look after it forever. You know? Although if someone wants to pay me, go for it.

Adrian: 48:33

But, you know, the it's got to be sort of maintainable, over the period. So we have to also be careful not to try and do too much. And I think, you know, initially, I I probably tried to because I think initially, I was thinking of it as more of a demonstration, in the 1st year. You know, some of those decisions have had to walk back a little bit around, like, taking on too much around things like JavaScript bundling or CSS handling and that sort of stuff.

Dominic: 49:01

Yeah. That that was maybe my my next question. So are you are you sensing some kind of pressure or something like that, you know, since they're you know, the the the project seems to to be growing, you know, decently and things like that. I mean, it's it's getting more and more popular, I I believe, as time goes. So how how are you handling all all this?

Adrian: 49:23

I think Yeah. I'm Yeah. Go for it.

Joe: 49:27

I was gonna say, I think we're still learning on that. Like, I think but I think we're getting better at it. I'd say, at first, we were just very excited that people were using it to the point where they had their own ideas about how it could work. But like Adrian says, now we're kind of coming to the point where there's a lot of people who, have have some ideas about it. We need to kind of pass through those and think what is the cost to implementing it.

Joe: 50:05

Because when someone even if someone contributes code, it's not zero cost for us because we we're gonna have to kind of interface with them to ensure that the the quality is what we're what we're expecting and that kind of thing? And around the design, does it does it flow with the rest of temple? If someone's adding a language feature, is it ergonomic like we were talking about before? Is it introducing the least amount of extra code as possible? So I think what we're trying to do now is kind of have a a bit of a slower process to adding language features where there's discussion, and we invite everybody to pitch in on the conversation to make sure that we're doing what's best for Temple, the users, and us.

Dominic: 51:16

Yeah. I would imagine. I would imagine it's hard to, yeah. This is a challenge for sure. What was there any any kind of breaking change at some point?

Dominic: 51:26

Or it it it always has been, like, very stable? I've

Adrian: 51:29

been been really careful on breaking changes, actually. So even though, you know, even the massive syntax change between version 1 and version 2, I built a, a migration tool so you could run temple migrate, and it would migrate everything over to version 2. I don't I don't think it was a 100% perfect because of some kind of actually, bugs probably in the early version, in version 1. But, yeah, I I was able to eventually get the last kind of early adopters off version 1 and and remove the v 1 to v 2 conversion tool and all the old v one stuff from the repo. So, yeah, I've been, like we've been try like, being a bit more conservative.

Adrian: 52:14

So instead of, like, adding a new feature, we've now got experimental feature flags as well. So we can put in an experimental feature and sort of try it out for a little while before we kind of break anybody's workflow by mistake and that kind of thing. So, that's, that's another important element of it. But at the same time, I don't wanna have a configuration file in Tempur Yeah. Because as soon as you have a configuration file, you then have, like, like, multiple ways that something can break or things can interact in ways that you weren't expecting.

Adrian: 52:47

So trying to keep it, you know, that's that's one of the strategies to sort of keep thing things simple. It means that, you know, every now and again, someone will complain about the way that things are formatted or something. You're like, well, that's the way it's formatted. You know?

Dominic: 53:01

Yeah. Oh, yeah.

Joe: 53:03

We did have one one breaking change, which I remember, which it was kind of interesting because it was completely unexpected. So, we had this idea to so in the generated Go code, there's some variables that are used. So there's context variables, there's, variables to temporarily store the string literals, and all the Go code expression responses. And we wanted to reduce the likelihood that someone's variables that they're declaring in their component wouldn't clash with our sort of runtime variables. So what we did was we prefixed every temple variable, with sort of a randomly this this kind of random string, temple underscore, and then some numbers, just to avoid a clash.

Joe: 54:09

And I think we thought that was kind of a sensible thing to do to avoid any really unexpected things from happening. But it turned out that people were actually using the context, variable that gets passed into the render function to do prop drilling, as we mentioned before. So we've actually we had to revert that change for just that context variable, which I, yeah, I found that kind of interesting. And it now forms part of our our documentation where we point out context values as a a way of kind of passing information.

Adrian: 54:52

Yeah. So you so you do have, like, an implicit context that you can just grab hold of, which is probably the only weird, weird bit about it, I guess.

Joe: 55:00

Yeah.

Dominic: 55:01

Interesting. So what what what is what is next for you guys? I mean, is it, is there any v3 on on the pipeline? Is is the v2 is mostly what, you know, the vision that you had for the for the project?

Adrian: 55:21

I think there's still a lot to do, particularly around, integration with JavaScript and CSS and really rounding out, like, a comprehensive way of building web applications. So like if you like, you know, React isn't really powerful because of React as much as it is powerful that I can pull down a React component that does something really well. So, like, you know, if I wanna have a table that has sorting, I can grab one. I can I can pick one of these off the shelf user interface libraries, and I can knock myself up a website that kinda looks okay pretty quickly? You know, one of the in the commercial kind of settings that I work in, you know, you'll have, like, an organization, and they'll make a design system.

Adrian: 56:10

And they'll put all the work into making sure that each of the components has been through the kind of, accessibility testing requirements and all the rest of it, meets the brand guidelines and uses the right fonts, has the right shape, and everything else. And so, you know, when you're building an application for one of these big companies, you're really just kind of collecting all of these, premade, you know, text boxes and other elements and and assembling them together. So people have started to make, a similar ecosystem type components for, for Temple. So, for instance, somebody's made, like, a a real like, an interesting hot reload capability that adds on to what what kind of Temple ships. Somebody's like, there's been at least 3 different, design system type things, with kind of libraries of components that I'm aware of.

Adrian: 57:04

There's some work to do around CSS bundling, and, people have got some interesting ideas around how we might tackle, bits and pieces like that. And then we've been doing a bit of work around, like, interacting with JavaScript. Because, you know, JavaScript doesn't go away just because we decided to do some sort of server side rendering. Right? Like, it's still super important for us.

Adrian: 57:26

But then we're looking at you know, people are using tools like Alpine, and they need to pass data to sort of Alpine stuff and how do we make that easy. So we added some features around that recently. So, we've got there's there's a whole bunch of news new stuff. So recently, we added, support for a new feature called the declarative shadow DOM, in HTML. So, we added streaming responses.

Adrian: 57:54

And declarative shadow DOM is a is like a bit like you can define templates in in HTML as part of the HTML standard. So what that allows you to do is render a placeholder, render the rest of the page, and then go back and populate the placeholder later. And that's kind of interesting because a lot of the time you might have loaded a web page and then done some kind of asynchronous loading using JavaScript to populate some sections of the page that you didn't want to do server side for some reason. But now you can do that entirely within a single HTTP request so that's kind of interesting.

Dominic: 58:35

Yeah. Yeah that this this sounds great. So so when you say design systems, so am I understanding that something like Temple UI? So so so so, you know, component that would be already styled or, you know, not tailwind, but, you know this would be my dream. I mean, this I'm searching for that for a long time.

Dominic: 58:59

Just something that I that would be similar to, you know, what native desktop and maybe mobile. I had never done mobile, but just having some decent style for HTML without having to have all the the Tailwind, the classes, or or any other CSS framework. So am I am I understanding that there there's people working on that?

Joe: 59:25

Absolutely. Yeah. It's, so we mentioned before that the kind of build process for temple is going from a dot temple file being generated into Go code. This means that shipping a temple component is just a case of doing that generation step, and then pushing it to a public GitHub repo. So there there's various projects out there already, like, I think there's one called go ship it.

Joe: 59:59

There's one called temple UI, I think, that all provide components that you can use directly in your your own dot temple files. You just have to do a go get and then import it at the top of your temple file just like you would import anything else in Go.

Dominic: 01:00:22

Wow. This sounds, pretty interesting.

Adrian: 01:00:25

Yeah. Well, I'm really excited about that. It's what I always hoped would happen, like, because I kinda designed it around this idea of, you know, building component libraries just because that's kind of what we like, what I was seeing commercially. So in fact, the temple repo has a little bit of a it's got a storybook, thing. So I don't know if you've come across storybook, but it's it's like a way that you can kind of share component libraries and stuff.

Adrian: 01:00:51

So initially I was thinking about like, you know, what what is the story for for a kind of comprehensive system for for building web apps? You need to have, like, components. You need to be able to reuse components, share them. You need to have to integrate with JavaScript. You need to, you know, have a good developer experience, and the performance has to be adequate.

Adrian: 01:01:08

Not it doesn't have to be amazing, you know, but it has to be adequate. I mean but just by the nature of it being written in Go, it's much faster than the JavaScript kind of ecosystem anyway. So, yeah, I think I I I wrote down just yesterday actually, Joe, that we need to create, like, an awesome Temple GitHub repo that just has, like, a list of all of the cool stuff that people are building with Temple and sort of, start to maintain that because I I guess, yeah, there's a there's a bunch of kind of adjacent projects like that that kind of round out the ecosystem. And I think, you know, that's really what what you need, I think, to build an alternate like, to build an alternative world to that JavaScript stuff, it it requires, like, a whole set of ecosystem components. Like, so some of the things that people have been asking like, well, I guess, actually, you know what's really what one of the things that you might not realize about Temple is that a lot of people who are writing Temple, it seems to be the first Go they've ever written.

Adrian: 01:02:10

Like, they're not they're they're coming to Go to write Temple and and that completely blew my mind. I did not expect that at all.

Dominic: 01:02:18

Because those developers are more, like, front end developers?

Adrian: 01:02:23

Not necessarily. Like, a lot of a lot of the time it can be a number of things. It can be like they're either, like, beginners or they just fancy picking up a bit of Go, or you know or they just come to it from a different ecosystem and you know they use it like one person said oh yeah I'm using it at work. You know because and you know that suddenly they're they're using temple And so they ask questions, and you go, okay. Right.

Adrian: 01:02:47

And it becomes obvious that, you know, they've never written Go before, because they don't know about things like imports or or some of the other things. And I think in so and again, the other thing is, in some cases people are writing their first web apps as well, because, you know, they're they're not familiar with some of the techniques and, and stuff around it. Or, you know, they're not you you or perhaps they're not used to things like CSRF or the techniques as well. So there's a lot of kind of questions you have to kind of help people through, which is why I've been focusing on the documentation as well. So at some point, you know, we need to get an LLM bot in there for sure.

Dominic: 01:03:25

Of course.

Adrian: 01:03:26

Yeah. I was seriously I was seriously thinking about publishing a set of embeddings, like, you know, pre pre populate the embedding so people could run it through their own lens.

Joe: 01:03:38

Nice. Yeah.

Dominic: 01:03:40

This is intriguing. I I will I will need to test it to be frank. I I I've read the entire documentation. I think it was probably 6 or 7 months ago. And as much as I've I was reading, I was very, very interested.

Dominic: 01:03:54

But again, I mean, I I have I have some challenges myself, which has nothing to do with temple, but it it I would just need to to test it myself. So what would you so if, you know, if we were to wrap up at this point, because I don't want to to keep you too long. So what, you know, what would you say to someone that, you know, has heard about Temple? Maybe they haven't started yet. So, you know, what's, what's a good tip?

Dominic: 01:04:24

Where should they go? Or at least, you know, are you recommending them to start a new project? Or it could be side by side with the HTML template package. You know, what what's what's the game here?

Adrian: 01:04:38

Absolutely can be side by side. This, you know, we're trying to sort of fit nicely with the rest of the ecosystem. DC is an ecosystem. So, like, that's why, you know, things like components will work very well inside Temple and all the rest of it. So we're looking for an ecosystem.

Adrian: 01:04:57

I guess the the I guess it depends on what you're trying to build really, and what you're trying to do. You know? And and the skills, like, everybody brings their own kind of problems if you like to to whatever scenario they've got but I would just say to people give it give it a blast you know do a hello world and and see how it feels to you And there's there's there's a website at temple.guide, and there's a kind of getting started guide. It's fairly straightforward to to begin.

Dominic: 01:05:33

Yeah. We will have this link on the show notes. So, so thank you for your time. I mean, so it was great. Maybe maybe we could do that a little bit, further, maybe in 2, 3 months.

Dominic: 01:05:44

I I don't know if you if you, if you are up to it. I I I would still pretty much like to test it and give you some feedback on on how it's it's working with the screen reader. But, but, yeah, I'm I'm very interested in the project.

Adrian: 01:05:59

That would be great. I'd like to, I'd like to see how that works and see what kind of missing features we might have. It may well be that we need to add some sort of semantic markers into the into the, into the LSP feature. Because I think someone was adding some, basic outlining because they were they were complaining about the lack of collapsing of, of elements. You know?

Adrian: 01:06:23

Like, I think you you mentioned that earlier. So this kind of concept of outlining and stuff is is certainly something that people are working on. Like I say, we I think we've had over well, we've had over a 100 contributors now to Temple, over the over the last couple of years. Mostly, obviously, like, little things like documentation and stuff, but people are people are taking on, like, bigger, bigger pieces over time.

Dominic: 01:06:48

Very nice. It's, it's it's pretty inspiring to see that because, like, I was saying at some point, I mean, there's a little bit of friction sometimes in the Go community for library that that do, you know, a little bit what the the standard library is doing, if we if I can say that.

Adrian: 01:07:08

Like I said, if the standard library wanted to introduce, introduce a strongly typed system that allows you to call arbitrary functions, that doesn't panic and all the rest of it. Yeah. Absolutely. I'll write the you know, the last temple I'll ever write will be the migration tool to get you Yeah. To get you off temple onto the standard library.

Adrian: 01:07:27

That'd be great.

Joe: 01:07:28

Yeah.

Dominic: 01:07:32

Alright. Alright. Thank you very much for your time. So, again, I would encourage everyone that, if if you if you haven't checked, Temple yet, go go ahead. Those those those guys are there.

Dominic: 01:07:44

You can you can contribute on on the project, and it's it seems to be very great. Thank you very much for your time.

Joe: 01:07:51

We also hang around in the, Gopher Slack if there's any questions.

Adrian: 01:07:58

Nice.

Joe: 01:07:59

Oh, yeah. Trying to.

Dominic: 01:08:00

I will have that on the show note for sure. Alright. Thank you very much. Alright. That's it for this week.

Dominic: 01:08:14

I would really appreciate if you can talk or share about this podcast. It's always helpful. Also, another way to support this show is by purchasing my course. There's always a link in the show notes. So on that, see you next week.