Is htmx the way to Go?

Hello everyone, and welcome to Go Time. Today I’m joined by Carson Gross. Carson, do you want to say hi to everybody?

How’s it going, everybody? Great to be here. Excited to talk a little bit about how you can do more work in Go.

So Carson describes himself as a gray beard programmer. He’s the creator of htmx, which we’re going to be talking about today. He’s also the creator of Hyperscript and grugbrain.dev. We’re also joined by Chris James, who’s an unemployed bum, but he is looking for work, if anybody’s hiring. Chris also wrote “Learn Go with tests.” Chris, how are you doing?

I’m doing great. I’m really excited to be on the show. I’m very htmx-curious, so I’m excited to talk about it and learn more.

Sounds good. And lastly, we have Dave Wickes, who is a wannabe gray beard and an employed bum, who likes to fix - I don’t know if he likes to, but he fixes typos in Learn Go With Tests… And he’s unnecessarily belligerent on Twitter, and he’s written a lot of JavaScript.

Yeah.

If you like this podcast is going downhill. We’ve got somebody who writes JavaScript, and an unemployed bum…

Yeah. I think you have to be. Is it possible to be overly belligerent on Twitter? Not sure.

How can you be kind on Twitter? I’m not sure… I walk into these things too often.

Alright, so today, the goal is to talk about htmx, which Carson created… But before we get into that, I wanted to talk a little bit about sort of the history of how we’ve come to learn to develop web applications, and sort of how they’ve evolved over time, so that people understand how we kind of got to the state that web applications are in today, and why these different technologies have been created to help us… Because I think that’s gonna help us understand, where htmx fits into the whole equation.

So I guess starting off, whoever wants to take this, where did you guys start with like developing web applications? What did they look like? Or rather, what did that process look like?

I’ll just start off. I’d be interested to hear what Chris and Dave went through as well, but I started pretty early on in the late ‘90s doing web development, and back then it was CGI stuff. So you’d just use Perl, or Bash, or whatever you could, and you created a little dynamic website; a little bit of dynamicism with using a CGI gateway. So very unstructured compared to what you have today.

I actually ended up getting a lot more interested in something called Applets, which were Java-based… They’re kind of, in some sense, very similar to SPAs. There was a sandbox around them, so it wasn’t as interactive with the browser. But I ended up going kind of that direction for a while before I – sort of when j2e, when the Java world sort of embraced the web and all that stuff came up, then I started doing what will be recognizable web programming to today’s developers. So that’s kind of how I got into it.

So if I remember correctly, weren’t applets supposed to be the future of web applications? Wasn’t that the big pitch, they could run anywhere?

[03:48] Yeah, they were. There was Flash too, which sort of the design side of the world did a lot of work with. Today’s developers might think of like Canvas, what a Canvas is… Think of that, but with a really elaborate API within it. It’s funny that I’ve ended up becoming such an ambassador for hypermedia, because in the mid-2000s I gave up on the web, and I use something called Java Webstart, which was a way to deliver thick clients to customers over the net. So it was a way to build that client application, network applications. And I came back to the web sort of after that phase, and started to appreciate it more for what it was… But I do think it’s a little funny that I sort of went through this. I kind of saw it very early, didn’t like it, went and did thick client stuff, and then came back and went like “Oh, there’s actually something to this.”

So when you were working with like the CGI type pages, was it similar to like PHP in the sense of it’s mostly an HTML page with like little snippets of code inside of it?

Yeah, imagine PHP, but like without the elegance.

Okay.

It’s like a hacky version of PHP.

Okay. Chris?

Yeah, so I also still I’d making my first website in the late ‘90s. I was 14 year old at the time, and I was extremely cool, so I made a website about pro wrestling. And I did it on a thing called Geocities, which was a thing that Yahoo kind of made available for free, where you could upload your own HTML files and make a website. I didn’t know programming or anything like that. I could view source, I figured out how to view source, and I just went to other websites and more or less copied it all together.

What I find interesting now is that - yeah, that seems like an archaic way of making websites, but actually, if I reflect on it, that’s basically how my current blog works. I have HTML files. The only real difference is that we have CSS now to style things, whereas at that time, it was all inline styles. But the basic tech really was kind of the same… You know, like 24-25 years later.

So when you were doing that, was that back when designing a web page usually meant like a big table, and you’d cut up images?

Yeah, there was no such thing as like CSS layouts. There were no jokes about centering divs; it was all making tables with nested tables… And also, there was a technique called spacer images, that you used to artificially create space on your page with images… Which is quite an interesting way of – I guess in a way it was quite ingenious, but obviously, it seems absolutely appalling these days. But it worked.

I think I’ve actually done that like later in my career, not that long ago… I was trying to design something, and I’m like “I know this works, from whenever I first learned.” And I’m like “Whatever. This will work for the time being, and then I’ll fix it later.” So also, on Geocities, have you ever checked out Neocities?

No. What’s that?

I think it’s supposed to be like a recreation of sort of what Geocities was, but I’ve never actually used it enough to really know for sure. I just remember seeing it somewhere at one point.

Do they have the fire gifs?

I hope so, but I don’t know.

It’s the only thing that matters as far as I’m concerned.

I was absolutely rocking the fire gifs. Flamingtext.com was just incredible to me. I couldn’t imagine technology greater than that. It was amazing.

I also remember like the scrolling marquee text, which was on every Geocities website. So some good features there.

I was really worried that this conversation is just going to be people talking about how wonderful the old days were; you know, just a lot of reminiscing… And now I’m just like “Oh my God, it was hell.” [laughs]

There was definitely some downsides.

Every time period has its highs and its lows, so…

So continuing my journey - so I eventually did learn to program, at least somewhat, and I think like the first big-ish website I worked on was a PHP website. So that was doing something a bit more dynamic. It was like pulling things from a database, and stuff. But at that point, CSS still wasn’t well supported, I seem to recall… So you still had this issue of – even though I could do some programming and stuff, in order to generate HTML on the server I was writing PHP, which was putting inline styles into markup.

[08:01] And I think, for me, in my view, a big step forward for web development was when CSS became a lot better supported, not only because it sort of gave you a simpler way of styling things, but it also meant that the work you did on the server was suddenly a lot simpler, because instead of creating HTML of inline styles, you were just creating HTML, which actually made the job a lot simpler. For me, that was like a moment where web development started feeling a bit more productive than it was before.

Alright, so we’ve got – I don’t want to say static pages, but we have like server-side rendered pages, with PHP and these different things. And then at some point, the web started pushing towards this, I guess, more interactive version of it. And the first place I really remember, at least that has like a sticking impression in my head, is with Flash. I’m sure there’s – like, you mentioned applets, which I believe were doing something similar… So I guess, do any of you have experienced developing with Flash? Okay, I’m getting a bunch of head shakes no, so I’m assuming not. But for anybody who’s out there who’s younger, who maybe doesn’t remember this, Flash used to be the way that every game on the internet was made. So you’d go to these pages that had these pretty well-built games that would run on Flash, and you could do all these interactive things. And I think that’s kind of what led the way for like what we now view as like an application being built into the browser. So now it’s pretty common, like you have Google Docs and you have all these things, but I think back when the web was created, the idea of thinking that you could actually have a text editor inside of your browser was kind of crazy at the time. Did you guys have that same impression when you were first starting?

Yeah, I think there was definitely – early on there was a big disconnect between rich content and then hypermedia content. So hypermedia stuff was relatively - and still is, in many cases today, pretty basic forms, with some pretty simple form controls. At the most elaborate it was often just hypermedia documents you were clicking around in. And then there was this other world that had much richer event handling, and typically it was canvas-based, or there was some infrastructure built on top of it. A pretty raw canvas that you had access to. That’s what Flash gave you, and it’d let you do much lower-level graphics programming. And actually, in many ways, Flash is a really cool technology to go back and look at, because it had a lot of very interesting things going on inside of it… So some low-level as well as high-level tools for building these things.

I always think looking Flash is one of the great tragedies of the early web, in lots of ways… Not in terms of writing it, but because so much extraordinary content got built in Flash. I can think of hundreds of websites I used to visit in Flash. Games, everywhere. And these are now inaccessible. Nobody can see these things anymore, nobody can play them anymore, nobody can visit them, because they’re built on a platform that just went away. It’s just really sad.

Did all of those sites shut down? Like, if I were to boot up a really old computer with an old browser - are there any of their sites still working?

I think you might be able to get the Homestar Runner, if that rings any bells…

It does… I could watch him check his email. That’s about it. [laughter] Okay, so now we have, I guess, what we considered modern web applications, which to many people are just maybe web applications. So things like Gmail, and Google Docs, and pretty much anything you’re used to seeing online that feels like an interactive page. So I guess, when you think modern web apps, I guess, how do you guys see them being built? What is like the traditional approach?

Well, I would say today the default approach is going to be a React-based frontend, talking to a backend using JSON, some sort of JSON API. That’s sort of the standard approach that I see most people taking. So I don’t know if you want to call that the traditional web application architecture, but I would definitely say it’s the most common thing that I see online now. There’s obviously plenty of websites are being built different ways, either in Vue, or Svelte, or something like that… But by and large, I think if you were to ask ten web developers what’s the standard way to build, they would say that. Tom MacWright I think has a blog post about that, saying this the standard way today that most people build websites… So I don’t know if Chris and David would agree with that.

[12:28] I don’t think it’s – it’s not the way I would choose to build a website, but it’s definitely the way I’d get paid to build a website. It’s very rare you get a technology choice in many companies outside of React. You’d be directed to “Here’s a stack. Get React going. Please use exciting feature number seven that’s been added in the time since you last used React”, but that’s something else to talk about. “And build your backend service, make it RESTful”, air quotes there for people who can’t see the camera… “And you know, build the frontend using lots of React components.” Yeah, that’s pretty much what you hear these days. And you know, I’m sure people use Angular or other things, but I don’t think that’s got the same reach these days.

I would agree that – if people think about what’s modern, I think that’s what pops in their head. As you said, it could be a different JavaScript frontend of some sort, but it’s going to be something in that realm that’s going to be pretty similar. And I’ve even seen people using – what is it, gRPC…? Because there’s some services that allow you to use gRPC in different ways, whether it’s like setting up some sort of frontend that translates to JSON, or like just having something it automatically handles that for you. But for the most part, it’s roughly the same idea. And I guess GraphQL is mixed in there… It’s still returning JSON, but it’s just like a slightly different approach, I guess, to getting your data.

Yeah, it’s the technology to layer on top of a JSON. David mentioned RESTful… I would say GraphQL is a step away from RESTfulness, and more towards a generalized query language… Which I think makes sense, because in my opinion the SPA approach is a thick client; you’re effectively building a thick client… Like I was trying to do in Java Swing back in the day. And when you start building a thick client, you have different needs from your network protocol than what the web provides out of the box, and you want something like a general query language, like SQL gives you on the backend. So GraphQL starts to make a lot of sense. And then why even use JSON? Use Google’s serialization technology, or whatever.

So when somebody goes to actually build an application using this modern approach, I’m assuming you’ve all had some experience with it. Or if not, you’ve at least talked to developers who have. What does it actually look and feel like in practice? Because I feel like in theory it’s one of those things that sounds great. It’s like, you’ve got the server, it’s separated, you’ve got the frontend, and it’s all going to just interact beautifully… But I guess my experience has been slightly varied. So how has that been for you guys? What does that experience feel like?

I think, to be fair, a lot of time you can feel very productive. I think if you can get to that sweet spot where everything’s set up correctly, and you’ve got the correct blend of the various libraries and frameworks and everything else, it can feel productive. But for me, whenever I’m working on these systems, I feel like I’m having to hold a lot of knowledge about React in order to get some work done. And I think it’s quite easy to create something that’s not very good in this one.

A classic example is like quite a lot of time you can go to a React website and if it hasn’t been written correctly, it won’t be optimized, so therefore you’ll download like 30 megs of JavaScript or something like that. Or maybe they’ve made a mistake and if you try and press the Back button, it doesn’t work correctly. And always, people will say, “Well, there’s a React router, and there’s all these other things”, but to me, I start to feel exhausted in this world, because it’s just another thing I have to learn.

[15:52] You know, coming back to when I was first making websites, when I was 14 - I didn’t have to worry about the browser history, or the Back button; it just works out of the box, because the browser takes care of that. But when you go into this world of having these fat clients, what you tended to be doing was throwing away a lot of the functionality that the browser gives you, and then you’re having to either reimplement it yourself, or at least know enough to bring the particular version of a particular library in order to plug into your thing, so that it’ll still work like a browser. I think for me that’s the exhausting thing about it. There’s no doubt that SPAs have a good fit for a number of things, but it’s a lot of complexity you have to take on. And you know, we’re on version 18 of React now, I think… What’s interesting is that Go and React are basically the same age, in terms of like – I mean, I know React is a framework, or library, and Go is a programming language, but it’s interesting to me that they’re both the same age, and yet, Go’s path has been a very small, simple evolution. I’ve never felt like I’ve had to relearn Go. Whereas like with React, at first I was doing class components, and then suddenly, that was the wrong thing to do, and I should be doing functions instead. And no one can really articulate why, other than people having a big distaste for OO, as far as I could tell… So yeah, I think it’s just a lot to take on, I think… Particularly for some projects, where I feel like it’s just not – you just don’t need all that complexity.

Yeah… So I came to software developer very late in my life. I was 35, and I went to a bootcamp, because I hated marketing, which is still reasonable… And I got lucky, in lots of ways. So I hit the inflection point. I learned to build my web apps using server-side rendering: Rails, I learned Sinatra… I was a Ruby developer, as a lot of bootcamps are… And it was basically the second thing I worked on was a React app, ultimately. The first thing I worked on, frontend HTML, a sprinkle of JavaScript, lots of server-side rendering. And then ever since then, it’s been on and off React. And every time I’ve come back to it, every time I had to do it again, I’d take a month break, I’d take three months or four months, to go back into this come back - I had to start again. I had to start literally all over again. You know, all of a sudden inline styles comes in, “Well, we’re gonna put the styles over here now. Now everything’s – we’re using hooks”, which as far as I can tell is just a sneaky way of getting state into your application, rather than say you’ve got objects… But you know, that’s fine.

And then every time I stopped doing that, and built something with server-side rendering, it’s still the same. I’m doing the same things I was doing way back in 2014-2015, the first way I learned it… Whereas React has just been a constant battle just to stay ahead, and also to produce exactly the same websites. It’s just a real disaster. [laughs] As far as I can tell, the websites I was building in React, with React - I don’t know which version it was then; 8, maybe 10 - are going to be exactly the same things as every iteration is. So yeah, I feel like I’m in some sort of horrible samsara of React development there; the pain just never ends… But you know, please hire me to build your React websites.

Yeah… So after the early stuff, I got back into web development, and I was working in Rails in the mid-2000s, because that’s what everyone who was doing a startup was building them in at the time. And that was right when React came out. And what I noticed about React - and I was like “Oh, this is new and interesting. It has some relation to some of the thick client style programming I did previously.” But what I noticed about it was that we started building up a big JavaScript frontend, like a separate codebase. And I think a lot of people take that for granted today, but that wasn’t the case earlier on. Previously, you worked primarily on a backend language. And I’m not a huge fan of JavaScript. I’ve come to terms with it has it’s good and it’s aspects.

[19:47] But at the time, I was much stronger in my distaste for JavaScript, and we just started growing this big JavaScript code base, and I didn’t want to deal with that. So the motivation for Intercooler.js, which was the sort of initial version of htmx back in 2013, was this sense that “You know what - I know Rails, and I like Rails, and I want to stay in Rails, but I still want more interactivity. And so how can I do that in such a way that I can still do most of my UI work in Rails, using Rails templating (which I knew pretty well), instead of having this big frontend codebase?”

I think you’ve seen that that same pressure with people that I noticed - when you start having this big JavaScript codebase, it puts pressure on you to have JavaScript on the backend, too. Because why have two different programming languages? Why not have the same programming language and share, for example, domain logic between the frontend and the backend, and so forth? Validation logic, all that sort of stuff. So that was a big motivator for me, was I just – I didn’t want to take on this big JavaScript frontend codebase. I was working by myself; we didn’t have a frontend/backend split, and so I kind of had to do both, and I just — I couldn’t keep React in my head and still remember everything I needed to remember about Rails. So…

So just to make sure I have this right - you didn’t want to work on a big JavaScript application, so you built another JavaScript application.

Yeah, it is ironic that in order to avoid writing JavaScript, I have written quite a bit of JavaScript. It got worse after that though… Maybe we’ll talk about hyperscript. That was a lot of JavaScript to avoid writing JavaScript.

Carson, I think one of the things you mentioned is really worth reiterating, is the fact that with that JavaScript frontend, and with a separate backend, which tends to happen fairly often, one of the things that can also be hard is that smaller teams or solo developers can struggle to sort of build applications with that setup, because like you said, they have to know so much more. And I know, like, the first project I worked on with a React frontend - what always killed me was that we had one person who knew the React side, and everybody else, there was like four developers who knew the backend. And for us to make changes, even if it was something really small, the backend would be a bunch of code, but then there’d be a small two-line change on the frontend, but to figure out how to do that and to make sure it got done correctly was always a struggle, because that one person was so overwhelmed that they rarely had the time to sit down and explain to us “This is what you need to do to get it running locally, and this is what you need to do to test it all.” So it was just kind of tough all around. And I think sometimes people can look at the technology and think, “Oh, this is great”, but they can ignore like maintenance costs, and like whether or not it’s going to change their velocity, and things like that, that it can speed you up in some ways, but I think you have to have a team that’s designed around that.

Yeah… What you’re kind of touching on is the idea of full-stack development. And I think one of the really nice things about early web development is that it was full stack. You were responsible for not only the business logic, and often the database queries and all the REST of it - although you often had a DBA to help you - but you also were responsible for the frontend. And there was a sense of completeness in your work. Mark calls it, it was not alienated labor; like, you didn’t just screw one bolt into a car that was going out the front door, or whatever. You built the whole car. So you built the whole feature, and you could point at it, and you could click… Being able to interact with something on a screen is a really satisfying aspect of computer programming, and when you have this frontend/backend split, I think you kind of split the brain a little bit and enter into a times a little bit of a dissociative state, where you just don’t have this sense of completeness in your development that you can have if you’re able to do full stack development. And there’s arguments that that’s good, at times; you’re producing a generic API, maybe in JSON, or whatever the argument is, specialization and all that sort of stuff… But at the same time, I think it robs velocity, because you can have miscommunication, you’re waiting on them, they have other things they need to do, whatever it is… And as soon as you split a particular complete feature into two sides, you just introduce friction in all sorts of different ways. This is maybe a little bit out there, but I would say - I think some of that is actually sort of a spiritual aspect. There’s a spiritual aspect, like this sense of completeness and satisfaction with a feature that is hard to achieve if you don’t have something like full-stack development… At least for me, that’s what I’ve found.

[24:23] If I recall correctly, I believe Bill Kennedy was on the podcast not long ago, and he told a story about how he built his backend for somebody who was building the frontend feature, and then later when he sat down to try to figure out how they would build the frontend, he realized that what he provided them on the backend was just terrible for what they were trying to build. And he asked him, “Why did you not tell me that this was the case?” and the frontend developer basically just said “We just deal with what we’re given.” And he basically sat down with them and redesigned it all. But I think, like you said, another downside people forget is that if you aren’t involved in the whole process, sometimes you design what isn’t a great backend for the frontend, just because that’s what’s easiest for you, and you don’t really realize what they need, or what they’re going to have to show data-wise, and it ends up causing more work in some ways, rather than actually having it be much more effective, like you expected, I guess.

Yeah. And also, you can optimize across the entire stack. Like, if you provide a generic API – this is why there’s so much pressure to adopt GraphQL, because it kind of gets you out of the business of having to predict what your frontend needs are; they can do whatever they want to now. And so that’s where a lot of that pressure comes from, “Just give them a generic API and then let them figure it out.” But if you have full-stack development - and this is one of the wonderful features of hypermedia in particular; htmx is - I would call it a hypermedia-oriented language, or a hypermedia-oriented library, I should say. But hypermedia, because of the way it works, lets you be much more dramatic in your changes to your backend, because you’re consuming, and it’s all just one hypermedia system. And so you’re able to tune what you do with that hypermedia response much more extensively, and for yourself, because you’re on both sides of the wire. So it opens up a lot of opportunities to optimize systems that aren’t there when there’s this hard break between the frontend and backend, and you have to submit a ticket to get an API updated, or you have to look at a ticket that’s been submitted to update your API, and maybe you get it done in a couple of weeks, or whatever. “Now I want to get this button on this screen, in this spot, and I want it to do this thing on the backend”, and you’re done in 10 minutes, instead of a back and forth, and whatever, maybe a week later it works. Having that ability is really, really nice… Being able to hit Refresh in a browser and have it work is pretty magical.

I would even say – you had mentioned that like GraphQL was kind of this push for like design the backend once and let the frontend people sort of just make it work… Even – like when people talked about building a “RESTful” API, I feel like that was kind of revolving around that same mindset, of like “If you base this around resources, they can call the endpoints they need to get the resources”, and it ignores the fact that like on a lot of pages you need information from like six different resources. So like you get to these pages where like the frontend developer’s only option is “Let me make six different API calls.”

Yeah.

But if you’re designing it from front to back, you’re gonna be like “Well, that’s kind of silly. Why don’t we just send all the data in one query, and have it there?” And it’s kind of weird how we’ve gotten to this point where people build applications that way, and they kind of optimize things around that, when in reality if you were to sit down and think about how you’re designing an API for a specific page, you’d like “Well, I want to give them all the data in one request. I don’t want to like make them make six requests.”

Yeah, that’s right. So on the backend, the way we used to think about that was we want to minimize the number of database queries we make, right? You’ve got a database, it has tables in whatever form it has, and you wanted that issue… We were always like five or less queries before we get out the door; ideally, like two or three queries would be even better. And to do that, you’d have to use some pretty sophisticated SQL, with a lot of joins, and a sophisticated collection, and build up your data structure, whatever it was. But that was done in order to optimize the performance of a given page. And I think that as frontend developers, with these SPA frameworks getting more and more into it, what they’re going to find is they’re going to need something as expressive as SQL to do this stuff efficiently. They’re in the same boat; they don’t want a whole bunch of queries being issued on the backend, they don’t want to be hitting a bunch of endpoints to wire together a UI. And so they’re running into the same problem, which I think is where GraphQL – that’s where GraphQL kind of emerged from, was that particular problem.

So you created what’s now htmx. How does that sort of fit into this equation? Or can you just describe what htmx is for somebody’s not familiar?

Like I said, htmx is a hypermedia-oriented library. So it’s a JavaScript library, but it’s a JavaScript library that basically completes HTML, is the way I would say it. So HTML is a hypermedia, we’re all used to it, and really the only hypermedia controls in HTML are anchor tags, so links, like we used to clicking on, and then forms, which if you use a more traditional web application, you’re used to filling out dropdowns and checkboxes and clicking Submit.

And what htmx does is it takes those two basic elements of HTML and then generalizes them using attributes that you can put in your HTML. So if you want, with htmx you can make any element make an HTTP request to the backend, a get, or a put, or a post, or a delete, or whatever; you have access to all the HTTP actions, which is in contrast with just vanilla HTML, unfortunately.

And then what makes htmx special, or what I think really improves on HTML is that you can take the response that comes back from the server, which will be HTML content, and you can place it anywhere you want in the document. So you don’t have to replace the whole page. And I think that’s sort of the crux of why people moved away from the original web model, to SPA, to JavaScript-heavy applications; it’s a big part of it, in any event. In the traditional web applications you have this big, clunky, click Submit in a form, and then there’s a big page refresh, and the whole page flashes often, and you lose your scroll state, there’s often not a very good indicator of what’s going on, and so forth. And so that led older HTML-based applications to have this very clunky feel associated with them. And newer SPAs would update the DOM kind of in memory, and that would make them feel much smoother.

[31:58] So what htmx does is it allows you to update the DOM in line, but it does that with an HTML exchange with the server. So in that sense, it’s much more like the older apps, but it has the feel of more modern, single-page applications. So that’s the big idea with htmx. In practice, you end up annotating your HTML with attributes that are htmx-specific. So if you wanted a button to issue a put to /update, on your button tag you would say ‘hx-put = “/update”’ And that would, when that button was clicked on, it would issue a put to that URL with whatever information happened to be around it.

And since we’re using attributes, we’re not writing JavaScript. Htmx is JavaScript, but when you’re an htmx user, you’re just using attributes in HTML. And so that means you’re just annotating your HTML, which means that traditional templating technologies like PHP, or like Go’s templates, or Rails’ ERB templates and all that sort of stuff - those all suddenly are relevant again, because you can take those and they’re not just sort of an afterthought. You actually annotate those with the interactivity that you want from your system.

Maybe you can quickly explain what hypermedia is in a little bit more layman’s terms, and also relate it to REST, because a few of us have been a bit snooty about REST already. So I think it’s probably worth us laying out what we feel REST actually is, and why that’s important, and maybe like contrast it to the SPA approach of sort of building web applications.

Yeah, I’m happy to nerd out on that, absolutely. So all hypermedia is a media. So in the case of HTML, which is hypermedia we’re all most familiar with, it’s a media that has what are called hypermedia controls in it. And the classic hypermedia control is an anchor tag or a link. And when you have an anchor tag in an HTML document, it makes that document nonlinear. Early on, that was the big deal about hypermedia, is that you’re not just reading a document, you’re interacting with it, you can follow links to other documents, and that’s the idea of this web.

And then the form tag, which I think came along in HTML 2, introduced this idea of updating. Actually, it was more than just following links around in academic documents, which is where the web sort of started out. Now, suddenly, with this form tag, you had the ability to actually pass a significant amount of information up to a server, and update the notion of updating content on the web was baked into HTML.

And so HTML has sort of these two core hypermedia controls, these two core ways of interacting with the document in a nonlinear manner. And that’s why HTML is a hypermedia. And so people recognized that this was a new and interesting technical approach to things. The idea had been kicking around for a while, but Roy Fielding, who did a lot of the initial work in the Apache Project on a lot of the early web technologies, he wrote a thesis - or a dissertation, I should say - for his PhD, and in that he coined this term REST, that we’ve been sort of talking about.

And so what he tried to do in his dissertation - it’s very academic language, unfortunately, but what he tried to do is discuss how’s the web different than other network architectures that have been adopted before. So he had been in technology for a while, so he was familiar with the older thick client model of network applications. It was very common in, say, the 1980s, before the web came along. So he wrote this dissertation to contrast “How’s this web thing different than that?” And the term that he came up with to describe the web was REST, Representational State Transfer, as a network architecture, as a system architecture.

[35:59] And it’s unfortunately pretty academic language, but the crux of REST, in my opinion, is – you define it in terms of constraints, but the crux was this thing called the uniform interface. And boy, how can I summarize this in a layman’s term, as quickly as I can…? The core idea, and what’s interesting about HTML, is when you get an HTML document from the server, you have no idea what the content is going to say in it. It could have links, it could have a form that does some action, whatever. The browser, when it asks for a particular URL, doesn’t have any idea what content is going to come back. It just knows it’s going to be HTML. So it’s going to render that HTML, and let the user select from the hypermedia controls that are on the page. And so there’s this really interesting aspect of hypermedia where you stream down not just the data, but also the operations on the data together. It comes down in one sort of complete package. And by doing that, then the user can see “Oh, here’s a new action”, or “I want to delete this thing”, or “I want to update it” or whatever. But the user selects the actions from the hypermedia. And that’s in contrast with JSON.

So JSON, typically, you would get down just sort of the raw information about, say, a contact or a bank account. A client-side template would be responsible for turning that into a UI, and the clients would have to know, “Okay, for updating customers, I need to issue a post to this URL.” It would all be encoded in your application code.

And so that’s the big distinction between like a JSON-style data API and a hypermedia response that you would get in a hypermedia system. And it’s ironic, the reason we’ve been saying sort of REST in quotes when we’re talking about JSON is that these days people would describe the JSON API as RESTful. They probably wouldn’t even describe the hypermedia API as an API; they would say, “That’s just a web page. What are you talking about? That’s not an API.” That’s unfortunate, but that’s just the way the industry has gone. There’s a long story behind that. There’s an essay up on the htmx website on the htmx.org/essays page called “How did REST come to mean the opposite of REST”, that you can read, which sort of really goes into the gory details of how that happened, technically.

But that’s the big idea… So that’s what hypermedia is - it’s media that has hypermedia controls inside of it, typically links and forms and HTML. And then a RESTful system, a RESTful system architecture is something that has a bunch of constraints on it, one of which uses a hypermedia for server communication.

So as a Go developer, in practice, what that really means is that rather than creating some JSON API with some data in it, and then tossing it over to the frontend friends who then have to know that, “Oh, if this field has this particular flag, that means you should show this. Or if it has this flag, you should show this.” Instead, you’re now in control of this, and you present the controls by, in practice doing - again, all the way back to the late ’90s - your web server returns HTML, and we let the browser take care of showing those controls.

That’s right.

Because I think a big downside of the fat client approach is - yeah, you have to put these rules on the client, but quite often you have to put it on the server as well, just in case there’s some shenanigans, right? Like, I don’t know, if I have a bank account thing that has like a zero balance, I may not show a Withdraw button. Right? But I need to have that logic sealed up in the server AND in the client.

Yeah. That’s an excellent point, you do have to have that logic on both sides of the wire, and there’s a technical reason for that. The browser is not a trusted execution environment. Right? It’s open, you just have no guarantees about it. And so any computation that you do on the client side has to be redone and reverified on the server side. And so if you’ve got a bunch of frontend JavaScript logic - again, there’s that pressure, “Well, I’m gonna rewrite all that logic in Go? Nah, I don’t want to do that… Fine, we’ll just bite the bullet and we’ll use Node on the backend, too.”

[40:13] And as Go developers, you probably don’t wanna hear that; as a Ruby developer, I didn’t wanna hear it… So that’s a reason why hypermedia-based approach is helpful, because you move all your logic onto the backend, and you exchange hypermedia with the server.

It is ironic, and again, I keep saying this, but if you built just a web app with just HTML documents, you’ve built a more RESTful system than the vast majority of JSON API developers have, because you’re using an actual hypermedia, and so you actually do satisfy the constraints that Roy Fielding laid out in his dissertation. So just using HTML is all it takes. Once you do that, you don’t have to worry about levels of Richardson Maturity, or whatever all that crazy stuff was. You just build an app using HTML, and it’s going to be a RESTful system by its nature.

I do think it’s worth noting that – I don’t think it’s the worst thing in the world. Like, the way REST is used now, I think it’s not terrible to use it that other way, just because it’s kind of become synonymous with that across the entire web industry. So I know I’m guilty of this; I teach programming type stuff, and sometimes I’ll use it in that way, because I know that’s what they’re gonna run into, even if it’s not technically accurate. I am pretty cautious in the sense that there’s no “This is the correct definition of RESTful”, based on – at least based on what they’re gonna read on the web, they’re gonna see 100 different answers.

So I think a lot of people are used to this idea of REST is sort of resource-oriented endpoints, and you’re using HTTP methods that are associated with that… And I think understanding those is a good thing. But I do agree with you that is kind of disappointing that people act like they’re being RESTful fanatics, when in reality they’re so far – it’s diverged and evolved so much at this point that it’s kind of a weird place to be in, or to get like really hung up in it, I guess.

Yeah, I would recommend no listeners get hung up on it. It is extremely funny at this point, and that’s the way to treat it. The situation is hopeless, but it’s not serious. It’s just like… [laughs]

It’s really good to waste like a good hour, half an hour at work just argue about what REST is, if you’re looking for something to do in a room.

Yeah. Keep it in your back pocket for that annoying engineer.

Yup. “Oh no, that’s not REST.” Carson, you mentioned it, so it really sparked some thoughts that what we’re dealing here when we said hypermedia is something that contains the data, and also its behavior at the same time. Well, this should be ringing bells in almost every developer’s head that this is what we’re talking about as objects almost, in terms of traditional classical object-oriented programming.

Yeah.

These two disciplines, if you like, having hypermedia and having objects - they suit each other quite well.

I think that they share a lot of characteristics. It’s hard, because when you talk about a hypermedia system, the client is the browser. So we have web browsers now, which are these incredible pieces of software, that have all this incredible technology baked into them to make hypermedia work… And the crazy thing about a browser, if you take a step back and think about it for a second, is that you can use this one piece of software, this one network client to talk to a bank, a pet food store, a car automobile dealer, a calendar, an email client… It could talk to anything, anything at all. What that shows is the power of hypermedia.

Now, it became so powerful that people actually started using it as just like a VM for almost thick client style applications, which is what the SPA world really sort of became, I think. So it was so powerful it almost undid the advantages of hypermedia, or maybe transcended, depending on how you want to think about it. But early on, in particular, when browsers first came out, this idea of like one universal network client that can talk to any application over this crazy hypermedia technology was really, really novel. And it still is.

[44:09] I mean, again, I think if you just take a step back and think about that, that’s really unique. If you told someone in 1980, “You know what - you’re gonna be using the same piece of software to access your news, your bank, your calendar, this stuff called email, and all this stuff”, they would have looked at you [unintelligible 00:44:23.01] know what you were talking about, unless they happened to be in one of the small research groups that was looking into this sort of stuff.

So it does have a lot of overlap conceptually, I think, with object-oriented programming, and it has a lot of flexibility that comes along with that style of data hiding, and all that sort of stuff. It’s a really interesting technology. I certainly didn’t appreciate it when I first was doing web development. To be honest, I didn’t really appreciate it until I built Intercooler. I just kind of made Intercooler because I just didn’t want to deal with JavaScript. But when I put it out there as an open source project, some people who understood hypermedia a lot better than I did started saying, “Hey, this is really neat, because this is still RESTful, but you’re getting more interactivity out of HTML. That’s really cool.” I’d kind of given up on REST at that point, because like a lot of people, I was pretty alienated by the REST purity spirals that you saw online in like the mid 2000s… But when people started telling me, “Hey, this is very RESTful”, I went back and looked at the concept, and finally understood it, and appreciated the web platform a lot more once I did.

So we’ve talked about how htmx kind of allows us to do something similar to what you do with React, but using this traditional HTML, and actually having full control over the whole thing. Are there any downsides to this approach, versus any of the other approaches out there, or just downsides in general?

Yeah, so again, I’m going to just point people to the essays page on htmx. I have an essay on when to pick hypermedia and when to not; when to use it, and when to not use it. And the hypermedia approach is great in situations when you want to minimize complexity. It’s a simpler model than managing a bunch of complex frontend and backend state, and to have to synchronize one another. And you can actually accomplish quite a bit with it.

If you go to htmx.org/examples, there’s a bunch of examples of user interfaces built with that technology, and some of them are probably going to be richer than your listeners probably expect. But there are times when a hypermedia approach isn’t going to work well. The classic example that I give is something like Google Sheets, where when you have a Google sheet in front of you, and you’ve got a cell here and updating that can have this cascading effect across the entire UI - that is something that is not going to be very amenable to a hypermedia exchange where you make a big server-side call, rerender on the server side, and then stream the updated UI state back to the frontend.

So if you have a highly dependent UI, where the UI dependencies aren’t sort of enclosed in a natural hierarchy of elements on a screen, then htmx isn’t going to be a good approach. If you have a really modal, like if you have a lot of like modal state – the web isn’t really a state… One of the characteristics of RESTful systems that Roy Fielding pointed out was statelessness. They’re supposed to be stateless. Even cookies, really, if you have a purist take on his dissertation, shouldn’t be allowed. Or not cookies, but sessions, excuse me. Sessions stored on the server side. But if you have a lot of frontend state that you’re really attached to… Like, “I really want to do this update with a modal, and a modal on top of the modal”, and then it’s modals all the way down, that kind of UI isn’t gonna necessarily play particularly well with a hypermedia approach. It’s doable, but as you start getting more sophisticated with hypermedia, you’ll probably end up using events a lot to make those UIs work properly. And that’s a more complicated solution.

So those I think are the big ones to think about… Then on the practical side, when I wouldn’t use the hypermedia approach is when your business just won’t allow you to do it. The reality is that React is the standard today, and as much as I like htmx, if someone were to come to me and say, “Hey, I don’t know anything about programming, and I want a frontend job. What should I learn?” I’m going to tell them “Learn React.” Because if you go to indeed.com and do a search for React, there’s going to be 30,000 jobs in your local area. If you do a search for htmx, there’s going to be zero jobs. So I think there’s a practical reason to consider – you know, we’re all developers, we all have careers that we have to consider as well… And so from that perspective, I think React’s certainly a much safer bet than something like htmx.

So I guess next I wanted to talk a little bit about somebody who wants to get into using htmx, and we’re assuming our listeners are Go developers… So what are some tips for sort of going about and trying it out? Any advice, I guess?

Yeah, so htmx is going to play really well with Go, and just the templates that are available in Go out of the box. There is – I should have written it down beforehand… There is someone who did a Go web framework - I’m blanking on it right now - that has htmx baked into it. I’ll have to dig that up and send it along afterwards.

But the nice thing about htmx is that because it’s using hypermedia, you’re going to be able to do your work mainly in Go. Depending on how sophisticated you are, you may have to write some frontend scripting, but you’re going to be able to primarily focus your logic on the back in Go. And I think that probably the best thing to do if you wanted to play around with htmx is go and look at the examples, htmx.org/example, and just implement them in Go, using Go as the server side for them. They’re pretty straightforward, and so I think that you can grab those and reimplement them in an afternoon, and get pretty proficient with htmx pretty quickly.

Again, the idea with htmx is you’re just going to annotate your HTML. So if you wanted to do autocomplete for a textbox, for example, then you’re going to end up putting two or three attributes on that textbox, saying “When a key up occurs, effectively, I want you to issue a get to this URL, and then take the results and jam that into this div down below.” And you would do that by ID. “Here’s the ID of the div down below”, use a CSS selector for that.

[52:18] So that would be like, say, three or four maybe attributes that you would have to put on an input, and you could have it suddenly issuing an HTTP request, which you could catch in Go, and return a table of results that match that, and it’ll all start sort of magically working.

So HTML really builds on – you do have to know HTML a little bit, so that’s another thing I would say to maybe Go developers, is pick up some base HTML knowledge. But once you have that, you should be able to get stuff done pretty quickly. Has anyone tried picking it up and just playing around with it? I’d be curious what your impression was.

Yeah, so before Christmas I just decided to give it a go on a Saturday morning, make a to-do app - not the most revolutionary thing in the world, but… I don’t know, I had something that you could look at and think it was an SPA, in terms of like there was no page reloads, I could drag and drop, I could add things, remove things, delete things, add search… Honestly, I did it in a couple of hours.

I do think the examples on the htmx website are excellent. They really do kind of give you a kind of – it’s almost like a menu of just common stuff that you have to do on a website, like Edit in Place, reorder things… So it really is excellent. And I think for me, the other thing to bear in mind is that whilst the net complexity is reduced with this approach, at least in a lot of cases, you are going from sort of a thinnish server to a slightly fatter server. So your Go web server is going to be doing more, so you need to think about the way you kind of structure your code. You need to make sure that you keep your controllers really skinny, don’t have too much business logic leaking in…

I definitely spent some time having a look at the Go standard library HTML template package documentation, because again, it’s got really simple examples as to how to generate HTML on the server. And once you get familiar with that, honestly, you can drive out some really rich-looking applications very quickly. It’s really satisfying. It just feels like so much friction suddenly disappeared, and I can just get stuff done.

Yeah. I’d second all of that. I actually took an old-fashioned server-side rendered app, because I like building to-do applications in as many different languages as possible… And I took that and tried to htmxify it, basically. I tried to add htmx to the root of it. And again, it was just a very simple experience. The templating stuff was already there, it was already all in Go, but it was just very smooth. What I found very interesting about doing it was it further improved the application structure. It necessitated improvements in the way it was structured, because much as when Bill Kennedy was building his little CLI app to basically drive out what he felt were behavioral problems or data issues with the backend he built for the front end, by dwelling more on the frontend, by working there, you start building a better backend as well. Things start getting cleaner, more obvious, more usable, because they’re getting used in the front.

So yeah, it’s a delight, is what I would say. I actually find myself grinning and quite happy when the thing that you think is going to work – you think, “Oh yeah, it should be something like that. Oh, it just does! It just works.” Never has that happened to me with React. [laughter]

Yeah, I was gonna say that this whole episode has felt quite sort of theoretical in a lot of ways, but I think it’s really important to say that it’s so much fun. Honestly, I find it a lot of fun working with htmx. And it feels like a weight off my shoulders. I feel like I can be productive. But yeah, honestly, it’s fun. I’d really recommend anyone just to give it a go.

Yeah. It’s a different way of thinking. Hypermedia is a different mindset, and there’s almost a Lego-like satisfaction when things snap together with it, that I find that just doesn’t come up with other approaches to building web apps, for whatever reason. I’m obviously partial towards it, but I agree with that.

[56:11] And one thing I do want to say, Dave, about what you were mentioning, where the frontend can improve the backend code is that one of the strengths of hypermedia is that because you’re streaming down the data and actions associated with the data, you can actually be much more dramatic in your restructuring of your application. You can change the URL layout of your application very dramatically if you’re building a hypermedia-based application, which is not the case, obviously, with a JSON-based application. With JSON-based APIs you have to version it, you have to be very stable, and all that. One of the strengths of hypermedia is that it is very flexible, because the actions are coming down with the data that they operate on. If you decide that an action no longer exists, or there’s some other condition, or whatever it is, you can completely change things around and completely change the way your back end generates the HTML, and the frontend client, the browser doesn’t care; it just renders HTML. So it gives you this flexibility that you don’t have if you adopt a JSON API, unless it’s not a public JSON API. So the hypermedia approach really is very flexible. That’s a big advantage of it that was pointed out by Fielding in his dissertation.

Okay, I think that wraps it up for the htmx discussion. We do have time to do unpopular opinions, though… So are you guys up for that?

Oh, yeah. I’ve got a fun one.

Heck yeah.

Okay.

Okay, so who wants to kick us off with an unpopular opinion?

I’ll go on then.

Everybody was really eager until I played the theme song. Then everybody went silent.

No, no… I want Chris to go first, because I think his will be – well, no, I’ll do my first then. I like mine first. Okay, so mine isn’t so much an opinion as a conspiracy theory which I’d like to inflict upon everybody, since it infected my brain a few years ago… And I call this the SPA conspiracy. The idea is this - the reason that all of frontend development has moved over to thick clients JavaScript applications is to make sure that we always have to have JavaScript enabled in our browsers, which makes sure that the large corporations, who are, I should point out, the developers of the single-page apps, so they can track us.

So basically, Google made Angular in order to make sure we turn on JS, in order to make sure Google tracking cookies could execute properly. Same for Facebook. You might notice that many of the other frameworks - I think of Svelte here - is also, its original design was for visual advertising, to make sure we also require JavaScript to run. So there you go, there’s my unpopular opinion. The entirety of the last ten years of frontend frameworks is all there to make sure that Google can follow you on the web. I mean, I don’t really believe it, but…

But you kind of do…?

Maybe…

I kind of do. There’s plausible deniability, right?

You’ve got to stand by it, Dave.

Like, you turned JavaScript on. You said we could.

Yeah, you said you can follow us now, because you wanted more JavaScript. And we are now at a point where the web is essentially unusable unless you turn on JavaScript. So it worked.

Yup.

So the only thing that would possibly debunk this is that I believe Remix is supposed to be designed so that it mostly works without JavaScript still… I don’t know if you’ve looked at it. Remix.run I think is the website… But it’s like a JavaScript frontend that a lot of their goals are to make it like core normal HTML type things all work. And that company was started by like a smaller group of developers, but it was bought by, I think – who bought it? Was it Shopify? Somebody acquired them. So I’m curious to see if that’s one of those companies that goes away from that goal.

Remix is interesting. It’s a fascinating idea.

[01:00:15.06] I do have to say it is a little confusing how HTML has made so little progress in the last 20 years. Like, why hasn’t HTML gotten any better as a hypermedia? It’s obviously gotten new widgets, and a canvas, and new APIs in JavaScript. But as a hypermedia, it’s been pretty frozen in time now since HTML 2. It’s easy to develop a conspiratorial angle on the thing, for sure.

There was a time where it was – I think it was Apple that wanted to sort of… Like, HTML was the future for apps. Like, that’s kind of how they were. And I think if that had actually been the future, like that it panned out that way, I think it would have developed a lot more. But I think in reality, for whatever reason, apps with proprietary programming languages is basically what ended up being the case. And now we’re coming to the realization that “Oh, HTML actually is strong enough now to actually build a lot of apps.” So we’ve kind of come full circle. So maybe it’ll start to get developed again, but who knows…?

I was gonna say that all HTTP – HTML doesn’t even meet HTTP, right? You can’t even use, I’d say, the vast majority of the HTTP verbs in HTML, right? So it doesn’t even meet the Hypertext Transfer Protocol. All it’s missing is like components and being able to do the rest of those methods, and maybe a few bits and pieces here and there, which htmx has covered. And I find it weird that it got stunted like that. It’s just weird.

Yeah, I would love it if htmx, the functionality, or at least concepts of htmx were folded into the browser, into the HTML spec… To me, that makes it makes sense. You just want a more powerful hypermedia; you want the ability to have more than just links and forms that do stuff, and more than just clicks and submits to trigger them events-wise. And then, like you said, you should be able to issue put, and delete, and patch, and all that stuff as well from HTML, why can’t you do that? And then the last thing is take the response and stick it into something else on the page, instead of this big refresh. I think they could do that in one release pretty easily, and it would make HTML a much more powerful development tool, and htmx could go in, and I could relax a little bit more.

It is always weird to me though that – especially like somebody who’s teaching other people, you go teach about all these HTTP methods, and then when you’re showing them HTML, you’re like “By the way, none of these works, so you just have to post everything, and just make different endpoints for it.”

It doesn’t make any sense…

So it’s kind of frustrating in that sense. It’s like, “Why did you teach me this?” “Well, you should know it, but you aren’t gonna use it right now.”

“I’m introducing you to the disappointment that comes with web development. This is your introduction to the psychological beatings you’re going to take for the next 20 years.”

You get excited about what could be, and then somebody yanks it away…

I still remember feeling that about form posts; this is like eight years ago, seeing it and it’s just like “What?!” It still bugs me…

Well, the worst part is you’ll see forms that have method equals post, and you’re like “Oh, I can change that.” [laughter] It’s like, no…

You can change it to get…

[Laughs]Yeah! It does [unintelligible 01:03:19.22] Oh, God…

Chris, what is your unpopular opinion?

Alright, I believe the Earth is flat – no, no. No more conspiracy theories. So imagine you start a new project with a half a dozen developers, and the first thing you do is you write 10 Go interfaces describing the lumps of code that you think you’re going to need to solve this problem. And then you divide them up between everyone, and say, “Go implement those interfaces, and we’ll stick everything together in a few weeks time.” You’d probably rightly question my judgment with this approach, because surely this is premature abstraction. How do I know that the design is correct? How do we know these interfaces are what we need? And is it not risky for us to work so independently at first? Are we not going to integration hell? And yet, there are loads of teams out there who will start a project with microservices. And that is just like what I’ve just described, but it’s even worse, because there’s a distributed system on top of all of these assumptions that you’re making.

[01:04:27.02] So whatever mistakes you’ve made in your design are so much harder to fix than if it was just in a single codebase. And my unpopular opinion - maybe it’s not unpopular, I don’t know, but I believe in the vast majority of cases rather than starting a project by drawing on a whiteboard 100 microservices, just start with a monolith. Start with like one codebase. Because if you make mistakes in your assumptions, it’s so much easier to fix within a single codebase than if you’ve just scattered it into a million services. And if you can write a good monolith, then you’ll be able to break it out into separate distributed services when you actually need to distribute this work.

And I guess my second unpopular opinion on top of it, which is kind of the same, is if you can’t write a good monolith, you’re going to write a dreadful microservices architecture. To me, the skill – it’s the same skill set to do both. So if you can’t do a good monolith, you can’t do good microservices, in my view.

So what would the counter-argument to that be? Like, are people just imagining that they can just have a really ugly microservice because it’s small? Like, they don’t need to design that code well? I’m asking, like, how do you talk to others about it?

The counterargument that I hear online is that microservices don’t solve a technical problem, they solve an organizational problem. And so they allow a particular unit within a business to deploy sort of independently. I don’t buy that argument, but that’s what I hear when people defend the microservice architecture. I, like Chris, and it sounds like everyone here, I’m not a huge fan of microservices. So I’m on your side on this unpopular thing.

Well, to be fair, I’m not against microservices, I’m just against microservices at the start of a project. And I do kind of buy the kind of organizational sort of aid, if you like. I guess the thing is I’ve worked in enough organizations where we’ve organized ourselves terribly, and Conway’s Law is just like hurting us so much, because our organization dictates our architecture, and our architecture is garbage.

And to me, when you start with microservices, what you’re kind of doing is you’re saying, “We understand how we need to organize ourselves before we’ve written any code.” And to me, that strikes me as a very kind of waterfall style of thinking, of “We can just design everything perfectly, and then just do it and we will execute brilliantly.” But in practice, most of the time when you’re building something you don’t know enough about it at first. You need to live in the domain a bit, and write some code, and iterate on it, and feel what it feels like, and then start to understand what the problem is a bit better. Then you can start doing your fun design stuff.

If anybody is interested in the whole microservices as organizational tool, my colleague at my current business, SaltPay we are hiring shortcut bonus for that, Adam, he gave a fantastic talk at GopherCon London earlier this year about how that works. I’ll see if I can find the link for that, but it was really wild. I sort of disagree, but his argument was really convincing that by using microservices, you actually force an organization to talk to each other properly, rather than – that it drives communication, basically, failures to integrate your microservices properly, that the difficulties of communication across the network boundaries are only really solved by having a good social communication between the teams and the rest of the organization. So yeah, it makes you address those social problems, rather than hide them away in a monolith, maybe.

[01:07:53.00] It’s hard for me to give like a real good feedback on this, I guess, because - like, I’ve been self-employed or working with teams of less than five people for like the last decade. So I haven’t worked on a large team with like microservices. And I’ve been lucky enough to be in these small teams where like we have a monolith…

Glorious!

…and it’s real fast…

It sounds fantastic.

…and we can iterate quickly, and everybody’s good with it. And like that’s great. So when I hear about a microservices structure, I’m just like “Yeah, I don’t need that, and I really don’t want to mess with it when I don’t need it.”

For sure.

But that’s also because I know anytime I try something new, I’m bound to make mistakes. So I know if I went and designed something with microservices right now, it would not be that good. I could probably jump into a codebase with it and help do some stuff, but I don’t think I would set it up correctly from the get-go. Carson, do you have an unpopular opinion you’d like to share?

Well, no. I’m just right about everything, so… My unpopular opinion –

I mean, we can take a poll on that…

[laughs] Yeah, take a poll on Twitter and see what the results are on that one. It would not be good for me. It’s okay. I’m a contrarian.

It’d say “Are you married? Because if so–”

I was gonna suggest that htmx might be just one really long, unpopular opinion.

Yeah, that’s true.

The entire library. [laughs]

Boy, it’s a target-rich environment here, but the one that I wanted to mention is I’ve got a website called grugbrain.dev, which is a joke website of mine that’s sort of like my experience in programming over the last 26-27 years now… And – boy, even longer than that. But anyways, one of the things that I mention in there is this idea of the fear of looking dumb. And my unpopular opinion is that in technology, a huge number of technical decisions are either made or not objected to out of a fear of looking dumb.

So someone comes in with an architectural decision or some code decision, or whatever, and it’s crazy. And there’s a bunch of engineers in there looking at it and going, “Man, that looks crazy to me. But if I say, so I’m going to look dumb. I’m going to look like I’m not smart enough to understand what they’re doing, and so I’m going to keep quiet about it.” And I think that that is a problem in general in technology, and it’s understandable, because it is a pretty brutal industry. We rely on our intellect quite a bit, and there’s ageism, and if you come across as not being intelligent, it can be really detrimental to your career… But I think that, unfortunately, it ends up in a lot of situations leading to bad architectural outcomes, and bad code outcomes, because people are unwilling to say, “This is too crazy. Let’s do it a simpler way, if at all possible.” So that’s my unpopular opinion. The fear of working dumb ends up driving a lot of technical decisions.

And I also think that I lead by example by constantly saying dumb things… But seriously though, I don’t think that should be unpopular. I think it’s spot on. I think it’s so important for everyone to try and create those kind of safe environments where people are unafraid to speak their minds, even if they think that what they’re saying is dumb… Because quite often, it isn’t. I think a lot of the time my experience has been, almost with like junior engineers, are the ones who are so call I don’t have a– have very little experience, often ask questions that just make you look at it slightly differently, and you think to yourself, “Oh, thank goodness this person was here asking that question… Because if they hadn’t, we would have gone down a horrible path.”

Yup.

Do you think that turnover at companies contributes to that? If you’ve been in a company for three years, and you know your coworkers for that long, I feel like it’s easier to speak up. But when you’re new to a team, you definitely do not want to speak up and look like the weird idiot who just joined and doesn’t know what he’s doing.

[01:11:55.05] I think this is one of the reasons why the prevailing kind of thought around teams is that stable teams are really important. And you shouldn’t – and we were talking about these big organizations… I certainly don’t subscribe to the view that we should view developers as these kind of interchangeable cogs, that we can just reconfigure teams on the fly… Because that just completely forgets the social aspects of software engineering, about the fact that it’s valuable to have a really healthy and open working relationship with your colleagues, but you don’t get that for free. You can’t just suddenly trust a new colleague that you’ve just met after a day. It takes time. I feel very strongly about this sort of thing, actually.

You know, there’s all these layoffs in tech right now, and I guarantee you that’s increasing the number of bad technical decisions that are allowed to slip through, because everyone’s keeping their head down… And so some lunatic can come in with just the dumbest idea… Or not the dumbest, but a very complex solution, and no one’s gonna say anything. They just want to keep their heads down, keep their job, understandably.

So if you’re in a senior engineering position, where you know you’re safe, and you have a lot of credibility in your organization, I think it’s very valuable to your organization to say things like “Man, this seems really complicated.” Or, “Boy, I don’t understand that”, especially in front of younger developers and developers that aren’t as comfortable… Because if you can use your social standing in your company to develop that lack of fear, I think you’re going to end up with better technical decisions being made as an organization.

Absolutely. I try to lead by example on that front, but I also tell every junior I’ve worked with that their job is to ask questions. Their job isn’t to write code; they’re not going to be amazing at it to begin with. Their job is to get better, and so their job is to ask all the questions, in every meeting, ever. What they don’t understand, why they think something is wrong, why they think something is stupid… Because that’s how they make everybody better, just being on the ball on that stuff. I love it. I love being asked really difficult questions, or really dumb questions, because it makes me look dumb sometimes… Because I am dumb. [laughs]

Sometimes it’s just good to go back to the drawing board and think “Why did I decide this?” and just to reiterate it, and make sure something hasn’t changed since you made that decision. And Chris, I completely agree with you with the interchangeable part. I think it’s kind of nuts that – like, we instinctively know this with like a sports team. You can’t just take one player out and replace it with another and expect the team to be just as good. But we expect it to work with software, where every decision builds more and more like technical debt, and all this other stuff… And having people you can work with and understand how they’re going to make decisions in different stuff can be really valuable… But I guess that’s probably part of the reason why I haven’t worked for big team in a long time. I’m very spoiled in that sense.

Okay, I think that’s it for this episode… Carson, thank you for joining us. Chris and Dave –

How about you, Jon? Do you have an unpopular?

No unpopular opinions today. I’ve not even had time to think about unpopular opinions. I’ll let you guys take the limelight there.

Okay. Sounds good.

Alright, I will play us out…