I rewrote my entire product in a weekend with htmx
Nice. Well, thank you very much for joining today, Eric. Yeah. How's it going so far today?
Speaker 2:So far so good. Kind of right in the middle of some big projects at work. So, you know, it's always a good day to be building software. So
Speaker 1:Yeah. Nice. Hopefully not too much right in the middle. Yeah.
Speaker 2:Kind of right in the middle.
Speaker 1:Okay. Alright.
Speaker 2:I was hoping to have it all finished yesterday, but you know how it is.
Speaker 1:Gotcha. Okay. Well, I really appreciate you taking the time to talk a little bit, you know, about some some HTMX stuff and and sort of your experience. So so I just wanted to kind of get some some background, give some background. I first, you know, saw saw you, and talking about your sort of HTMX experience back in January.
Speaker 1:And you you put out a tweet that was basically like, I just spent the weekend rewriting my whole app, with using HTMLX, and basically like here's why it was awesome. That's sort of my understanding of that tweet. And then recently you said that, you know, I I stand by everything I say. So does that sound about right?
Speaker 2:Yeah. It's still awesome. It's it's as awesome as it was that first day.
Speaker 1:Yeah. Yeah. So so I guess just some background. You so you've been building, you know, web apps for a while, and and sort of what's your preferred language, and what's your kinda like background with building stuff?
Speaker 2:So I've been doing this professionally now for a little over 25 years. For the last, like, 10 years or so, I've been kind of on the entrepreneur side of things, most often serving as like a CTO, 1st engineer on the team, building the product, getting the MVP in the market, and then eventually hiring and hopefully scaling. So, yeah, I've been building web apps in some form or another since the early 2000. Yep. As as far as, like, preferred tech stack and whatnot, on the website, generally, I don't care that much.
Speaker 2:I like web as a platform. So, you know, I'm comfortable in PHP. I'm comfortable in back end JavaScript, whether that's Node or most recently I've switched to BUN. I've done Django work before. I've done SharePoint development before.
Speaker 2:Like so, as long as it's web, I'm happy.
Speaker 1:Yep. Yep. And so is this are you sort of your own company or do you do sort of work do work for a bunch of different companies or how's your sort of setup Yeah. These days?
Speaker 2:My my current company is a startup we formed last year called Make Startups. And so we were a non profit that had existed for about a decade before I joined the team. And that company, that non profit teaches entrepreneurs how to, like, launch, design, and scale their business. And I joined the team just specifically to, like, help them build a learning management system, help them, track student record data over, you know, multiple years that were required to track that by the government. It was right at the same time that the AI revolution had kinda kicked off with ChatGPT, and it was really exciting.
Speaker 2:And so we we were at an intersection where for the first time, we could build a learning management system that was useful on an individual level, where we could make, we could use the technology to make, like, specific recommendations to each business on a case by case basis, where before that was what we were doing in person. Right? Like, our mentorship program was like, I'm gonna know about your company, and I'm gonna tell you, you know, the things that that I think you should improve. And with AI, we could really build a platform that would scale, across the world. So we started building a we we spun out as a for profit company, also called Make Startups.
Speaker 2:And we built a pro a product called Co founder OS, which, you know, we kind of are positioning as like the operating system for startup, where it's gonna have a whole bunch of apps and tools in there, it's gonna teach you some things, and we're using AI and little bits and bobs to, provide value wherever possible.
Speaker 1:Very cool. Interesting. And so just as a as a side note, I noticed that your your, Twitter handle is at blister. Is it blister or blister?
Speaker 2:It's blister.
Speaker 1:Bliss. It's a great Twitter handle, first of all. Thank you.
Speaker 2:Well, I I got spotted once because some guy wanted me to give it to him, and I I wasn't willing to part with it. Yeah. That's like a holdover from back in my like, the late nineties. I was very heavily involved in IRC, and we know, some of the servers I was in had a a nick length, thing. So I was, like, trying to think of an edgy hacker name that was, under 9 characters.
Speaker 1:Yeah. No. It's a good call. I just wanted to, throw that out there. I like that.
Speaker 1:Okay. So so you don't really care so much about, you know, you're not sort of married to a particular language and, as long as it's kind of web based because it sounds like most of the stuff you do, you know, you want it to be worldwide, you want it to be accessible to anybody with a browser, like co founder, OS, you know, basically helping other people create web startups. Does that sound sound right?
Speaker 2:Yeah. We don't even care about web startups. Most of our startups going through our program, they're they're trying to build, like, restaurants or, you know, a bagel store.
Speaker 1:Okay. Okay.
Speaker 2:We're trying to help, you know, the 5,000,000 or so businesses that start every year that don't get venture capital money or that don't, you know, it's just people that have a good idea for what they wanna do. They wanna be their own boss. And we believe very strongly that, like, entrepreneurship is not that hard. You just need to, like, know the steps that you need to take and in what order. So
Speaker 1:Very cool. Very cool. So so one thing I I think is interesting about, like, you started as a non profit or the company started as a non profit, and it's obviously like non profits are great, and I love the sort of, you know, it takes a lot of, it takes a lot of thought and effort and time and stuff to keep a non profit going, to sort of go in that direction. But I do think there is this benefit that you get from when you sort of start moving into a for profit, and I think, you know, some people don't like that, some people do, but you I do think there's some benefits there where your focus sort of things get really kind of like, you make you're forced to make a lot of different kind of trade offs and sometimes those are really good and and you can sort of expand a little bit. So I don't know.
Speaker 1:What what what was your sort of feeling on that? Yeah. Was it was it better being a nonprofit or a for profit? We You don't have to answer that if it's sensitive.
Speaker 2:Yeah. No. We're still both. And so we still
Speaker 1:You're both. Okay.
Speaker 2:Yeah. So that's one of the things that attracted me as a as a technologist to the to the business is that, like, we are eating our own dog food every single day. Like, the software that I'm writing and that my team is working on is making our nonprofit more effective. We're able to help more people, help more startups, be successful. And now we're trying to scale that, the the software nationwide to all the other organizations that are like us.
Speaker 2:And so Gotcha. There's a very clear delineation. Like, we just sell a software tool that makes it easy to, teach, and then, the non profit still has a mission of like helping startups in Augusta, Georgia. So
Speaker 1:Nice. Nice. Yeah. Because I feel like I see this kind of, you know, split in the open source world too, where like, you know, there's always open source packages, which I count HTMX as one of them. You know, this is not like a big money making package for anybody.
Speaker 1:But if it gets to the point where somebody can make money from building stuff with it and you know, then it actually does help the whole ecosystem to have this kind of, you know, the ability to get more people in there and to if people are spending more time building tools for it. So I think it's a nice mix when you get this sort of that mentality of like a non profit side plus sort of this more business oriented, you know, for profit stuff. So
Speaker 2:And and being a for profit just made it really simple from, like, an accounting standpoint. We need to be able to attract, you know, good engineers and offer them, equity. We need to be able to raise some some funds from VC, just to kind of get us a little bit of runway.
Speaker 1:Yeah. Yeah. So so you sort of having some experience, just building for the web in general and building stuff without really caring. I feel like that's kind of a natural fit already Mhmm. For HTMX, you know?
Speaker 1:Yeah. Like hypermedia on whatever stack or whatever. Howl, what is it? Hypermedia on whatever language.
Speaker 2:I haven't heard of that one. I like that. That's mine.
Speaker 1:Yeah. It's, there I might be saying it wrong. But, yeah, it's it's one of those. It's definitely howl. But, yeah, it's just this idea that, like, it doesn't you know, I come from a Laravel background.
Speaker 1:I've talked to people who come from Django and Go and, like, you know, all these different Python stuff, like, all these different sort of languages, and it really doesn't matter, you know. It's like because they've abstracted, you know, the h t m x project has sort of abstracted, the back end and some of this web stuff to to this. So it seems like that's sort of a natural fit. But what were you sort of doing before HTMX? What was the sort of tech stack then?
Speaker 2:I mean, so I I often get a lot of flack for this, but my philosophy has always been like, for a product, you should be focused on, like, what does your product actually do? So what are the features and and business problems that you're solving for your users? And so, you know, as a CTO of an early stage startup, my job is to just launch. And so anything that can get me to launch as quickly as possible is the best. So, like, for this product, I started with PHP, HTML, vanilla JavaScript whenever I needed it, and CSS.
Speaker 2:Like, I don't need to complicate my tech stack to build something that gets users. And so, you know, I know everybody's, like, super big into React and things now, and React is great for what you need it to be for. But, like, as a solo developer in a brand new company, I don't wanna spend weeks months setting up, an environment when I could just literally be writing code and launching.
Speaker 1:Yeah. No. I mean, I'm on I'm on board with that. It's, you know, PHP was kind of my first introduction, and I resisted even frameworks for a long time. I use Laravel now and haven't had for a while, but but it took me a while to get to that where I was like, okay, I can trust a framework enough, you know, to like I'm not gonna come across any, like, thing that they don't handle and then I'll be screwed and stuff like that.
Speaker 1:But it's hard to beat just a straight, you know. Yeah. You just put this on the server and now your website is up and running. Yeah.
Speaker 2:When git pull is your build step, it's it's pretty powerful. Yeah. But I think, like, a lot of these, feelings of mine, opinions have been influenced by I've been doing this since the early 2000. I've been through the jquery era. You know, we played with prototype JS when that was hot.
Speaker 2:You know, we used EXT and moo tools and stuff. Like, I've seen all of this. And every single time, everyone's like, if you don't use this framework, you're wasting your time. And then what ends up happening is it's not the framework that everyone uses anymore in 2 years. You end up rewriting it.
Speaker 2:Or there's some poor sucker who's getting paid to maintain, you know, a jQuery 1.1 application that is 300,000 lines of code, and they can't do anything about it. So I'm always like, the the less things I have to tie myself to, the better. And if we ever get to a stage where I'm like, oh, okay. We need React Native for you know, we wanna launch a mobile app or something. Well, that's a that's a technical decision where we have to have that because of that use case.
Speaker 2:And I think people reach for things too quickly.
Speaker 1:Yeah. I mean, I don't know if you if you have a chance to listen to the last conversation I I had was with, Alex. I'm blanking on his last name right now, but, Alex Petros. But, you know, his concept was the 100 year web service and it's like trying to build something that can just sit on the web without being touched and even if you have to update it you can and it's like and we've I think a lot of the industry has kind of lost that as a mindset. But, you know, I I I think personally that people who keep that mindset are gonna be in a good place.
Speaker 1:Yeah. That's kind of what it sounds like you're you're sort of heading towards.
Speaker 2:And I I I've just been burned by it so many times.
Speaker 1:I see.
Speaker 2:I have built so many version ones of products to only have to, like, okay. Now that's great. Let's rewrite the whole thing. And so I'm, like, why why do we pick things that are painful? I don't know.
Speaker 1:Yeah. So I mean, I you're you're preaching to the choir here. I've you know, I think I think we're probably in similar, you know, development, world. I kind of came out of college in 2005, 2004, 2005 era and started building stuff. But it's like I have these applications and these these things that I still support for people and the ones that I wrote in like Vue, j s, you know, I was like Vue was taken over the Laravel world.
Speaker 1:I was like, alright, I gotta get into front end, like Vue can I can you know, it's mostly attributes? I can I can do this? And the ones that I wrote in that, like, I just regret it so much. Like, I've just been burned and burned. I'm just like, okay.
Speaker 1:Like
Speaker 2:Meanwhile, HTML and CSS is awesome now. Browsers actually work. Like, you don't need things. It's so, relieving, but everybody is complicating things so much so that you have to have like an engineering team just to make your widgets. And I'm like, okay, if you say so.
Speaker 1:Yeah. No. And that's one of the things I I I'll stop talking about my last conversation with Alex, but really he was just saying like, browsers in the last 10 years
Speaker 2:Yeah.
Speaker 1:Quietly got way better.
Speaker 2:Yeah.
Speaker 1:And so people don't even know it because they don't they don't have advertising campaigns about how good the browser is now. Like, why would they? But, you know, if you actually look into it, they're way better. And, like, you can do things and things are smooth and fast and all these kind of stuff.
Speaker 2:And I had kind of the same experience with PHP, where it's like I started in PHP in 2003, and I've used it, but then I switched to JavaScript and I did some Go and stuff. Like, I've done everything. But PHP 7 made PHP freaking awesome again. And it's like ridiculously fast. I have my entire server running on like a $20 a month VPS and it's, you know, rendering pages in 0.002 seconds.
Speaker 2:Right?
Speaker 1:Yeah. No. I mean, this was one of those shocking things that, like, you know, I have I always used to like how, you know, I I so I've been an Apple user for a while, but you start to notice that, like, with each new Apple update, things are getting bigger and slower. And that used to happen with Windows and I used to always kind of like rag on Windows about it. And then, like, you know, meanwhile in the PHP world, like, PHP 5 goes to PHP 7.
Speaker 1:And I'm like, alright, am I gonna update? And one of the things they mention is like, yeah, it's gonna be twice as fast. It's like, okay, this is different. It was. Yeah, it was actually twice as fast.
Speaker 1:And I have these, you know, I did all these tests because I was like, alright, we'll see, you know. And so I set up these things and just a for loop with like a million, you know, stuff like that. Really simple kind of like basic tests, create objects, crush objects, and I upgraded the servers and did the stuff and whatever and I ran all my tests and like it was it was twice as fast and every person that I upgraded for noticed it. Like Mhmm. And this is a big deal to me to like actually focus on that kind of thing.
Speaker 1:So yeah, no I really appreciated it. They didn't just bloat their system.
Speaker 2:Yeah.
Speaker 1:They went through and were like let's make it smaller and faster. And I was like, that's awesome.
Speaker 2:Yep. And 8 just kept getting better. So like now it's a like, if I'm building if I'm starting a new company, PHP is a very dependable version 1 selection where it's like, I can just write code, output HTML, CSS, let caching do what caching does. Like, I don't have to worry about most of that stuff. And when we do get to the point where we've got millions of users and have to scale, okay, well, then the engineering team can can maybe break things up into microservices or whatever we need to do.
Speaker 2:But, like Yeah. Don't make it on day 1.
Speaker 1:No. Yeah. I might have always found the bottleneck is the database.
Speaker 2:You know,
Speaker 1:it's like if you start if you've got millions of users and things start to slow down, like, do a couple more indexes, split some database tables down.
Speaker 2:Chard some things. Yeah.
Speaker 1:Yeah. Just do a little bit of SQL work, SQL lite, whatever you're doing. Yeah.
Speaker 2:So anyway, that's a roundabout way to say that is why I loved HTMX from day 1, because I've already been operating like this for the past 20 years. And HTMLX being like, you can just add an attribute, and, like, now you're making get requests that replace content on your page, and you're sending less HTML, to a client. I was like, oh, that's great. I I love this.
Speaker 1:And, Yeah. So so, you know, you I don't know if this was, like, just kind of, the start of the rewrite, but in your tweet, you started, like, I spent the weekend rewriting our entire product. So is that, like, how much of your entire product was rewritten in that weekend?
Speaker 2:Mostly oh, so I started with where exactly you would expect I would start. We have a sidebar with a whole bunch of different pages that are linked in there. I just changed those to all say, hey, whenever somebody clicks this link, h x get and fill in the center content div with the file that already existed. Because, you know, our entire product is, like, file based routing, so when you make a request, whatever the first thing is after the URL is like, you know, CRM, for example. That's gonna load the CRM file, and it's gonna put it in the center content.
Speaker 2:And then we got all this Chrome around the page where it's like that the header bar and a search bar. Yep. And so everything was already structured in a way that made it really easy for me to test it out. And so by adding all of the things in the sidebar to say, h x get, fill in this center content, div here, with whatever comes back from the server, that was like 98% of what needed to be done.
Speaker 1:Right.
Speaker 2:But then there were like 7 or 8 different parts of the product that took a little bit longer, like almost 8 hours of, almost 8 hours. We would use, like, a third party libraries of things like, oh, I wanna have drag and drop file uploads, or I wanna have, you know, we have a map in our product, or we have, like, some charting and stuff. And a lot of those JavaScript libraries are great. I love them for the same reason I love HTML. It's like, I'm I don't need to, like, build my product around it.
Speaker 2:I just drop in a a script tag and, you know, I pass it a JSON object or whatever the format of the data they want, and it makes a pretty chart. But most of those libraries expect me to be like, okay, the page loads, it loads this script, and then, you know, like on the on ready or a DOM content loaded it, like, you know, initializes initializes whatever that canvas element is with the with the data. And the problem is as soon as I switch over to HDMX, like, it's great the first time, but then if you, you know, press the back button or something, HDMX is like, great. I'm just, you know, pop stating back, and nothing actually has has called or loaded. So I had to, like, figure out all the different events that were firing behind the scenes.
Speaker 2:So there's, like, a HTML after settle, that I that I tap into.
Speaker 1:Yep.
Speaker 2:There's also, like, I had to do something in in pop state, which is window pop state where when you press the back button and you don't wanna actually leave the page, it's firing an event, so that I can keep it. So it gives it, like, a single page application field even though it's not really that. So I just had to change a few of those things, and I ended up making some extra JavaScript code for myself that made it easier for me to, like, debug and and track our our personal application state as we were building the product. So it's stuff like, okay. Well, if I've loaded this JavaScript function already and then I go back to the page later, I don't need to re reload it.
Speaker 2:So it's like internal caching in in the browser's memory. So I do some stuff like that too.
Speaker 1:Yeah. Yeah. So that's sort of the the really specific tricky parts of of working with HTMLX. That's, like, I kind of wanted to get into with a little bit because it's not something that it's not something that I've talked about so much on here because I think, you know, a lot of the sort of the basic stuff, is easy. Like, it's just easy.
Speaker 1:You just like, you do the get, you do the post, you know. Mhmm. And everybody kinda gets that pretty quickly. And I do think, you know, having worked with it enough to come across some of those, you know, I think what you listed, number 1, the JavaScript 3rd party plugins. They have to initialize every time, you know, it's like or something.
Speaker 1:Maybe it's not even initialization, they have to refresh, like, that has been an issue. And I don't know if you did if you mentioned this just now, but like, you know, you do a partial page load and you push the you push the, you know, URL to the top. You gotta be able to refresh. Same sort of thing. It's like you don't wanna lose those nice and and HTMLX, like, does provide things to do that.
Speaker 2:I spent, like, of that 8 hours, like, 2 hours of that was we've got some pages that are really long, and if you go all the way to the bottom, but then you click something in the sidebar, I wanted it to go to the top of the page. And so I had to figure out, like, what's the HTMLX way to scroll to the top of the page when the page hasn't refreshed? And so it was just those kind of, like, dumb little tricks that you have to kind of figure out when you're in there.
Speaker 1:Yeah. I I think and that that to me is a little bit of the key is, like, what's the HTMLX way? And, like, that's not always immediately obvious, I think, because it is relatively low level. And, you know, I've been trying to kind of figure out some of those myself, and some of them are in the docs. You know, you can, like, find it and say, oh, okay.
Speaker 1:This is like sort of what's recommended. But, you know, not not everything because it's it's like there's multiple ways to accomplish how, you know, it depends how you want to split your template up, depends how you want to like show your different parts of the page. And it's like there are a lot of options and it's not I think that's one of the hardest parts for people is there isn't a smooth, here's the one way to do it Yeah. For a lot of stuff.
Speaker 2:It's very unopinionated and it makes the assumption that you're a good enough developer to, like, pick what you want to do.
Speaker 1:Yeah. And that's I mean, that can be tough. Like, even, you know, I had some relatively straightforward in my mind, like, tables. And I'm like, you know, the idea is, like, you've got a table, you wanna click to see more details. And like that is a relatively straightforward kind of setup.
Speaker 1:And then within that, you wanna click again and get more details. And that's actually like a really cool thing you can do with HTML. Anything that loads these partial things like you can have an unbelievable amount of data and then it's just hidden until you wanna reveal it and it's, you know, all loadable and stuff like that. But what I found was that there were like a lot of different ways that I could structure even that sort of simple straightforward thing. And so I sort of chose my my favorite, you know, which was like a certain way of doing it, but I was surprised.
Speaker 1:Like even for like I I thought I would just there'd be an immediate, like, this is how to do this in my head and and look it up or something like that.
Speaker 2:Yeah. Yeah. That's that's, all the extra time I spent after that first weekend in playing with H. G. Max is, like, all the things that I wanted to do that weren't that simple first use case.
Speaker 2:So it's like, I wanna do, like a live search so that as you're typing in the little search bar at the top of the page, it's like pre populating stuff that it finds in our system. And so that was great. Yeah. But then I had to like add a whole bunch of exceptions to my main template code to say like, okay, Normally, I tell you to just fill stuff in this main content area, but this time ignore it and ignore all the other so it's just all those little exceptions that I I think the problem is I enjoy them. I think that's what makes it exciting.
Speaker 2:That's why I get fired up. I'm like, oh, I have this whole new, way of building products now where I don't have to con conform to whatever. I can just build whatever is the best solution for what I'm trying to do. But I I think that turns turns off some people who are like, I just need to know how to do the thing.
Speaker 1:Yeah. I I I agree. I think it's like because I I sort of feel the same and, you know, one of the things I really have appreciated about using using it is when I go back to look at, like, okay, how is this built? What did I do here? Like, I go into the code and I'm, like, oh, there it is.
Speaker 1:Like, oh, here's the input for the text search and there's a whole bunch of h x whatever is on it. So it's, like, oh, I see what I was doing here. You know, it's, like, I think that locality behavior. And so I don't I don't I haven't ever really in my programming life, got that into events which like sounds a little silly because, you know, I've needed to and I have done it, but I've never really felt comfortable or fully trusted events, I would say, because I just, you know, I've I've I've same sort of thing, I've been burned a few times. So Mhmm.
Speaker 1:How sort of how much did you do you get into events and and do you sort of think of it as do you keep it local or do you have a separate, like, event bus where you handle kind of JavaScript events and stuff like that?
Speaker 2:I never I I have gone that hardcore in the past, so, like, it it kinda goes back to, like, my initial my my earliest programming jobs were, like, at the very start of the Ajax kind of, thing in the early 2000. And so, I did a lot of experimentation. So, like, I used to build my own framework for my team that I worked on at the time. And so I would do all kinds of stuff. Be like, I'm gonna make it like a, you know, like a Windows app inside of my browser.
Speaker 2:And so it needs to have, like, menu events and all kinds of stuff. And JavaScript, to, you know, to its credit or to its its its flaw, will let you do that kind of nonsense. And so now I try not to get into things. I try to do as little as possible all the time. But I know that I have that there if I need to.
Speaker 2:Right? I I understand event dispatching and how, you know, you you can, watch for things and how you, you know, I've had to use it in the past as a way, as a way to, like, pass messages, between, like, 2 disparate components. It's really good at that. Yeah. But almost always, it feels like that ends up being the more complex solution to something that could have been simplified with, you know, some architecture changes a little bit higher.
Speaker 1:Yeah. No. I mean, I'm kind of in the same boat. I I guess I asked because I I feel like there's, you know, I I, talked to a couple of people that I've talked to in these sort of episodes and conversations. I think there's sort of 2 camps, and and one of them is much more sort of event driven, and, you know, maybe we'll have, like the aftersettle.
Speaker 1:Like, you could put in down at the bottom of your of your page, you could put some JavaScript like aftersettle, and this where I'm going to handle all my Yeah. All my plugins. And here's the plugins I'm going to initialize. And then other people sort of, will maybe put that directly onto each attribute, like on this attribute we want to trigger this. So it's like, I kind of, you know, I haven't done a ton with the events.
Speaker 1:I've I've noticed how powerful the hx on is Mhmm. Where and especially tapping into the I've tapped into the h t m x specific events quite a bit. I found those to be really useful.
Speaker 2:I think in general so I I even in my current product, I I use both mechanisms. Right? So like the aftersettle, I had to use, you know, from day 1 to get our current JavaScript that was that already existed to work in our system. And then I'll have, you know, one offs that are using h x on, you know, for the the search bar I was talking about, where I wanted to, like, do something specific when you're typing. So it's like on, type with a delay of 2 seconds, then it then it actually sends the event to the server.
Speaker 1:Yeah. I love that stuff.
Speaker 2:And so I think they're both powerful tools, especially if you can use them where it's appropriate. I generally would lean more towards, like, I would rather write a function, at least for JavaScript side, in JavaScript code itself. So I'm almost always gonna prefer not being inside of an attribute. It's probably a bias from the early days of, web development where it's like we were trying intentionally as, like, a as a culture to move away from, you know, putting, you know, inline styles and inline JavaScript, which was how we did things, you know, 2005 to 2,008. And so I have a bias now where it's like I'd rather, you know, whenever possible, put stuff into a JavaScript file that can be then cached after it's downloaded.
Speaker 2:If that fails, then I'd wanna put it in a script tag that's, like, on the page. But Yeah. Where you can very clearly see, like, here here's the JavaScript that's executing. And then the last place would be, you know, an attribute.
Speaker 1:An attribute inline. Yeah. Yeah. Yeah. Which is And I
Speaker 2:Now that you bring it up, it's wild because one of the things I like about HTMX is that, like, it adds more attributes to it. I think what I like about it is that it really I think it's on the HTML website or in the Hato's book or whatever where it's saying, like, it's just adding stuff to HTML that should have been there in the first place. Like, we're just adding the ability to make server requests on things that just aren't links or forms.
Speaker 1:Right. Yeah. No. It's true. I I think, like, you know, my I have sort of a hierarchy of, like and I I haven't put this down into writing or anything.
Speaker 1:I'm sort of just thinking of it now, but it's like if it's like one line, I usually keep it in the attribute. You know, if it's like h x on this, some event, you know, if it's just going to be one line. Once I start to like write javascript on multiple lines within a single attribute, but just like visually, I don't like that. I'm like where's the indentation? It's starting to get weird.
Speaker 1:I'm probably gonna move that down to, you know, the script tag. And then if I have so many script tags that it starts to get unwieldy, I'm like, alright. Maybe this is a JavaScript file. So I I think that's my natural sort of process.
Speaker 2:What is the, what is the name of the precursor library to h t m x that, he's always, like, joking about where it's he runs both Twitter accounts. What's that What's that first one?
Speaker 1:It's the one
Speaker 2:that has the weird
Speaker 1:Yeah. Intercooler, JS.
Speaker 2:Intercooler. Yeah. Like, that stuff, I've never used it on purpose. But it's crazy when I see it, I'm just like, wow, that's amazing. The fact that someone built this.
Speaker 1:Interesting. Yeah. I know. I've never used that either. I I just haven't, you know, it's, like, h t n x was kind of the first.
Speaker 1:Yeah. Yeah.
Speaker 2:But there's so much of the intercooler stuff. So, like, the, when you're doing, like, h x on, a lot of that has intercooler syntax in it. So you can, like, write, you know, when I did that search thing, I'm putting in, like, hey, do this, but only after 2 seconds has passed, and there's no additional key presses. That's, like, intercooler syntax.
Speaker 1:Oh, oh, wait. Sorry. You are you talking about, like, the like, writing English Yeah. As the okay. So I think that's actually hyper script.
Speaker 1:Hyperscript. Okay. Yeah. Intercooler also like, so Hyperscript is a separate
Speaker 2:product. Both. Right?
Speaker 1:Yeah. So I think Intercooler uses Hyperscript also. But, yeah, like, you can use without using any Intercooler, you can use just the Hyperscript.
Speaker 2:Crazy. I'm glad I'm
Speaker 1:glad I'm glad I'm glad I'm glad I'm glad.
Speaker 2:Yeah. Yeah. But I'm just like, he's a he's a wizard. They build him different out there in Montana
Speaker 1:or wherever. So I don't so, like, I was this was probably 2 weeks ago, but I was like, okay, I'm I'm building a new thing right now, you know, something a new thing I'm working on. I get to choose my tech stack, whatever. So I'm gonna like I'm gonna try the hyper script rather than writing vanilla JS because I've been writing kind of, you know, vanilla JS for a lot of stuff that's in line and stuff like that. So like I'm gonna do it.
Speaker 1:Do the hyper script and I'll just say like I was like trying to figure out how to do something relatively simple. And let me think if I can remember what it is right now. I think it was disabling a button until some condition was met. You know, it's like I have a form, I don't want them to submit the form until they type it in the box. Or something.
Speaker 1:Yeah. Yeah, exactly. So that to me, this is like relatively straight this is very common and relatively straightforward. And I would say I was like I couldn't find an exact example using hyper script. And then, you know, it's in this kind of English syntax, and I really wanted to do it using it.
Speaker 1:And my first ten guesses didn't work, and I was, like, man, I can't figure this. I cannot figure out what the right wording for this is to make this work. So I'm sure it can handle that sort of obvious situation, but, like, in I at some point, maybe I'll I'll, you know, work with somebody who has a good, like, you know, idea of how it all fits together, but I could not get, like, a pretty straight straightforward thing from my own guesses to work. So I had to I had to pull it out for now, but we'll see.
Speaker 2:That's still pretty impressive. Like, I have only used it in, like, 2 places where I have an existing example that I pulled from one of the websites and it was like, on this, do this. And I was like, oh, cool. But it terrifies me.
Speaker 1:Yeah. The thing is, that's the thing is I love the concept of it. Like, you know, this kind of being able to because I just I like being able to look at something and understand what it does. It's just and some code I know so well that it feels like that, but I know secretly it's not. You know, it's actually like I only know this because I've been doing PHP for 20 years, like, so I know what this loop does or whatever.
Speaker 1:But like, I don't know. Being able to actually read it and then write it in such something so close to English is pretty tempting. So I'll probably go down that path at some point just to see what it's like. Well we'll
Speaker 2:have to chat when you do. That sounds
Speaker 1:fun. Yeah. Yeah. So let's see. So so I think overall, I mean, it sounds like this was the rewrites and everything like that was a success.
Speaker 1:Were you the only person working on it, or do you have kind of a a team that was also kind of invested in this and sort of on board, and what was that experience like?
Speaker 2:So right now I have one other engineer on my team. We're still kind of like in our 1st year. We're pretty small. And she's a really great engineer, but she's used to me, like, disappearing for a weekend and coming back with, like, a giant new feature. And so this giant new feature was like, hey, now this is HTMX powered and everything runs faster.
Speaker 2:And, you know, to her to her credit, she's she's been working with me for, like, 7 years now. So she kinda knows my, modus operandi here when I, when I get into things. Yeah. And I think, like, the way I structure so some of the the some of the decisions I made in how to, like, solve, you know, how we import libraries into the product that are third party, like, I made those decisions knowing that she was gonna have to do that too. And so, I documented everything super well.
Speaker 2:We had a couple of meetings about it. And I, like, tried to make an API for things. So, like, I made a function that you call that you pass a a callback to that automatically fires, without having to do anything crazy.
Speaker 1:So actually before so is that how you solve that? Like, did you, you know do you, like you have a you set up, sounds like a new event, like, on HTMLX header, h x header Yeah. Something. When that's fired, it runs and then you, like, requested that they add whatever new plug in into that sort of initialization process? Yeah.
Speaker 2:So, how our product worked before I switched to HMX is that every one of our, like, apps or pages was like a full standalone thing. It had its own controller and its own view. And those are just straight up normal PHP files, but how we were doing things is like, okay, well, this is the only page that needs, you know, a, markdown editor or something. So on that specific view in the template, right right above where I start writing like HTML code and, you know, echoing out, stuff from the database, I would put in like a script tag and say, hey, load this script tag and initialize the editor. So we were already kind of doing that where each one of our pages would would be the only place that, dependencies would be loaded or called.
Speaker 2:Right? Like, if the page didn't need a markdown editor, it it wouldn't ever show up.
Speaker 1:Right.
Speaker 2:So, when I switched to HTMLX, like, everything worked on individual page loads. But as soon as I went, you know, back and forth and stuff, individual page loads, but as soon as I went, you know, back and forth and stuff, it was breaking. And so I went in and I wrote a couple of functions. The first one is register HTMX handler, where it just takes a callback and the name of the the route that you're on. So the the route is everything that's like window dot location dot path name, everything after the end of the URL.
Speaker 2:And so that uses that as a key. So whenever you're on that page, if that callback is defined, it will execute. And so the beauty of that is I then don't have to worry about if I'm going forward or backward or if I landed on the page for the first time and it's just a brand new page load or I click there 15 times, it's always gonna whenever that page loads on either DOM content loaded or window dot pop state or, HTML after settle, any of those, like, hey, we finished loading this stuff now, it calls a function that says, okay, is there a function defined that has this path name as the key? And so the page is always gonna try and define it, but if it's already been defined, it will just execute.
Speaker 1:Is this a JavaScript function you're talking about? Yeah. Mhmm. Okay. So Yeah.
Speaker 1:So even if it hits that code twice, it's just it's it's fine because it's just checking to see if the function is defined.
Speaker 2:And it knows to call it because the page is loaded. So if I leave a page and then I come back to a page, I still have to reinitialize a markdown editor and things like that.
Speaker 1:Yeah.
Speaker 2:Because, like, you know, the HTML coming the HTML coming back from the server is just showing, like, you know, this is text area class markdown editor. The JavaScript code from the library still has to call easymde new, new easymde with the with the class name or the element reference. And so I have to call that on every load regardless. And so writing that function made it easy for for me, for her, and for, you know, any future engineers to not have to ever worry about, like, okay, what are the events that I would have to watch or know about for a page load event? And so because HTML adds so many different types of them, I just wrote a a a basically, about a little API internal to us that, like, takes care of that all the time so that nobody has to nobody has to worry about it.
Speaker 1:Yeah. I mean, this sounds like that's that's very cool. I mean, that sounds like something that potentially you are bringing to just any generic HT, any project going forward. You know, you can sort of use this same, I don't know if it's a code snippet or if it's like its own sort of JavaScript file. Yeah.
Speaker 1:Yeah.
Speaker 2:To be honest, like, we started having this conversation and I was just kinda, like, reflecting on what I had done to date. And I was like, I should just open source this. Yeah. It's I mean, that sounds that sounds valuable. Had to it's stuff I had to do to solve this problem for me.
Speaker 2:I'm sure other people probably have similar types of problems. It's like what we were talking about earlier, where there's just, like, not a plethora of recipes that are available where it's like this is the way to do it. I'm not saying my way is the way to do it, but it's a way to do it.
Speaker 1:No. I mean, that sounds really interesting because I think, you know, the the way that you're talking about building this stuff, I mean, there isn't no matter what, someone who's who's working with 3rd party JavaScript stuff is gonna have to do this. Like, there's just no, you know, because you you're doing partial loads. It's sort of the whole it just comes with it. And I think, you know, from my experience doing this which, you know, I haven't I I don't use as many third party JavaScript plugins as I used to, but, I mean, you need them sometimes for sure.
Speaker 1:Like stuff like I can only renders, charting.
Speaker 2:That's that's exactly it. It's charting, you know, drag and drop file uploads, all that kind of nonsense.
Speaker 1:Yeah. And then, you know, that's something that's funny because I I, I haven't done a drag and drop file upload in a while, but I think people probably would love that. Oh, there's I probably should be throwing those in there.
Speaker 2:I've just been using this for years. It's called drop zone JS, where you literally just have a class called, it's a form. You make a form element with a class of drop zone, and when the page loads, it automatically attaches to it and replaces it with one of those, like, drop here to upload. Thanks. It's so cool.
Speaker 1:Yeah. That's awesome. So, I mean, have you ever done any open I'll just say, like, I have never contributed to an open source project. I've never created my own. I put some stuff on GitHub and then just never did anything with it because I wasn't So I I haven't done that.
Speaker 1:Is this something a world you've sort of, been involved in at all?
Speaker 2:I have been very heavily, open source influenced for the past 20 something years. Like the early stage of my career, I was working in a in a government facility, so we were like on our own separate network. And so my hobby at the end of the day of working on things that nobody ever got to see was I would go and make, like I made a pirate themed JavaScript library where everything was, like, named after ships
Speaker 1:and,
Speaker 2:you know, this this is like 2004.
Speaker 1:Yep. Yep. At the height of Speak Like a Pirate Day, if I
Speaker 2:remember correctly. Totally totally into that back then. Yeah. I've contributed significantly to libraries that I was using, like EXT JS, you know, or Ricoh JS. We would find a bug.
Speaker 2:I'd be like, hey, when I use this select drop down, you say it does this, but it doesn't because of, you know, IE 6 sucks. And so I would
Speaker 1:Yeah.
Speaker 2:You know, contribute and submit patches.
Speaker 1:That's awesome. Yeah. Yeah. I I I I've just it's just a world I never got into. I've I'm such a user of things of, you know, I love I'll try stuff out.
Speaker 1:I've never source dived on HTMLX and I've never tried to, you know, I haven't
Speaker 2:You should. It's so true.
Speaker 1:So I am considering it. Like, I'm not considering it. I'm gonna do it. I'm trying to figure out how one of the nice things, Carson, I've seen on the website is that he has himself walking through the source code of HTMX video. And that feels like such you have watched that.
Speaker 1:Oh, nice. Okay. I have not watched that yet, but it seemed that's such a good idea. Like, it's such like a here's an introduction from the person who wrote it. Just, like, I don't know why I don't see that more in, like, the open source world.
Speaker 1:Like, now that I think about it, like, what a what a straightforward good idea.
Speaker 2:I think most people don't like to be on camera.
Speaker 1:Yeah. I guess so. I mean, you don't have to have to show your face, you know. You can just, like, talk over it. But if you're the creator, like, that's such a cool thing.
Speaker 2:There's some scariness to things. I, you know, I I can definitely remember having hesitation 15 years ago of, like, oh, I'm I'm building this library, but it was okay for me to publish it because I was just going by my pseudonym. You know, it was just a blister release, and it was just on SourceForge, and nobody had to know who I was. If it sucked, oh, well.
Speaker 1:Yeah. Well, let me tell you about something who's never published anything. It's super easy. Don't even worry about it.
Speaker 2:Yeah. I published a book. That was fun.
Speaker 1:Oh, really? Mhmm. Like a, for a tech tech book?
Speaker 2:Or so, like, 5 startups ago, we had a robotics company. We we, sold a robotics kit that was programmable. And so a part of that was, we had a curriculum that taught you how to program, the robots using Arduino c. And so I wrote a textbook to go along with it. That's awesome.
Speaker 1:What was it like though, like writing a book, actually? I'm just curious about that because
Speaker 2:It's awesome. It's exactly as good as being a software engineer. It for for me, it's the exact same ish where, like, I don't have to talk to anybody. I have information in my head, and I'm just gonna type by myself, and at the end of it, I will have something done. And so Like
Speaker 1:a real product ad. Yeah. That's that's actually, like, more tempting to me than trying to to do open source stuff because then you maintain it forever. My sense in writing a book is that it's a ton of work and, you know, you maybe do revisions or something like that, but you're creating something that will last forever. And that's just, you know, that's just cool.
Speaker 1:A tech
Speaker 2:book and then, you know, Angular 2 comes out. Your Angular 1 book is useless.
Speaker 1:Yeah. Well, you got yeah. You're you know, would you write it? It was about, like, c and Arduino. Right?
Speaker 1:Like, that's not changing anytime soon.
Speaker 2:That's not good. Company went out of business, so nobody needs to buy,
Speaker 1:that bug. Gotcha. Yeah. I guess that's a there's a platform risk there. So I think just like in some of the details of kind of implementing, let's say there's someone out there who is like considering.
Speaker 1:Like okay, I've got a pretty straightforward style, you know, maybe that's not exactly descriptive of of your sort of, app.
Speaker 2:No. I think that's descriptive of almost everybody's app. Almost everybody. Everybody else is lying.
Speaker 1:I don't like to, like, make people feel bad if they're not open to that idea. But, like, everybody's app is basically a pretty simple crud app and let's just We are
Speaker 2:all just building database interfaces for people.
Speaker 1:Yeah. So so someone who's trying to do that, like, it sounds like, you know, the 3rd party plug ins is 1, but, like, what what dragons are there that, like, they should maybe, you know, just to, like, have in the back of their mind? Like, you've been developing for 20 years, so you probably had a pretty good idea. You know, first of all, did you start by just creating a new git branch or something? Or, like No.
Speaker 1:Do you just dive in and
Speaker 2:just, like, dig
Speaker 1:a lot of production code right here? Right here. I hope I log in to
Speaker 2:production server. Yeah.
Speaker 1:Yeah. I'm kind of in the same boat here. So I usually do the git thing when it's about it.
Speaker 2:So at the time, like a year ago, January or whatever, like, we had just launched. We had, like, 4 users, and it was mostly me. So I wasn't prepared about it. But now we're now I take the you know, I have a demo server and staging and stuff. Woah.
Speaker 2:Woah. Woah. Yeah. It's crazy. What are some things to watch out for?
Speaker 2:So I I think one of the things that I am most attracted to about HTMLX and that I have had the most success with is the same thing that I think makes it super powerful, which is I am building a Web app as if JavaScript doesn't even exist. So I'm building, you know, my back end code, it's it's just a CRUD app. You go to a page, it's at this URL, I display some stuff, and maybe if it's a form on it, you post it back to server and I save it somewhere. So that's the philosophy and everything that I build. And then, HTMLX gets to come in here and it it reminds me of, like, the early 2006 era, concept of progressive enhancement, where it's like, if JavaScript is turned off, if you're if you don't have it at all in your browser, everything on my page will still work.
Speaker 2:It will just be less, smooth. It will be less flashy. And so I build my apps that way. And that's why I think the transition was so easy for me, which is, I'm always trying to operate it as if, like, my user is on a bad browser or they're on a mobile phone or they're behind a network and something is blocked or, you know, someone else on the team wrote something that has an error that we didn't catch properly. I just never trust JavaScript as anything other than, like, nice.
Speaker 2:Right?
Speaker 1:Right.
Speaker 2:Yeah. And so when I'm building an app, I'm I'm already building it. I'm trying to break things up so that, like, I I like, file based routing is a good example where it's like, I don't wanna have an API for my framework. I just want to have, like, you went to this page, and, you know, HT access behind the scenes in Apache is just saying, like, okay, whenever someone asks asks for this, like, actually call index dot PHP, but pass that in as a query parameter. And so if if someone is building out a tool where they're going to, you know, I know that it's going to go to this file, this file is going to execute, and then output this HTML, it's really easy for you to make wild and sweeping technology changes, whether it's HTML or you can you know, I have at times using this exact same type of structure been like, oh, I need a document viewer, you know, to be able to, like, display and render PDFs and, you know, Microsoft Word documents and stuff inside the browser.
Speaker 2:Well, there's a really good library that does that in React, so I'm gonna make that one page by itself be a React page.
Speaker 1:Yeah. Yeah.
Speaker 2:Interesting. That kind of separation where you're, like, not tied to any text stack on the front end. The front end is literally just me sending data to the user, and how the user wants to render it is like, know, I'm gonna give suggestions with CSS and JavaScript. Alright. But I'm I'm never building my product as if the front end has to be there.
Speaker 1:Interesting. Yep.
Speaker 2:Like, you could use my tool today just using, like, Postman and making get and post requests, like, directly in the browser because it's still gonna work. I kinda build the product like an API in the first place. I really, like, bought into the idea of REST and restful design being, like, a super important part of your structural identity as a product. And so I, you know, I've been doing that for almost 20 years now where it's like, okay. If I if I think of things like I'm gonna have the view be the first parameter after a, after the server name, the ID is gonna be the 2nd parameter, and, like, an action maybe is the 3rd.
Speaker 2:That gives me a framework where, like, I don't even have to I don't have to do anything but, like, write 4 lines of code, and now every page in my platform will follow that same kind of structure. And so if I'm on CRM 7, that means, like, look in the database for record 7 and, display it.
Speaker 1:Yep. So so what was the thing like? Do you you know, you're not using a particular framework. You're using a language. Like, do you you don't use Laravel when you use PHP, or what's that sort of decision process?
Speaker 2:Project. So I have been, for the past, like, 3 companies that I've started that have been in PHP, I'm using a a framework that I built myself, like, 15 years ago called, PHP pain free. I built that framework literally to just, meme on my I I worked with a coworker who was, like, very into the Code Igniter community at the time. And so Code Igniter was like a precursor to Laravel, where you had to my complaint was always is not that they weren't great, because they're all freaking amazing at what they do. Like, Ruby on Rails is awesome.
Speaker 2:Right? Laravel is is amazing. But I'm not a programmer. I'm a framework developer. Right?
Speaker 2:I'm doing what they you know, I have to know what their API wants me to do. And I always felt like my my responsibility was to be a really good, software engineer regardless of frameworks. So I can go work in Laravel. I can go work in work in SharePoint because I know the language. Okay.
Speaker 2:Whether that's c sharp or PHP. And if the language changed, like, I'm never gonna be the greatest Laravel programmer because I don't do it all day. And so then I would pick Laravel in a in a situation where I'm like, oh my gosh, I have to build a product that is ideally suited for Laravel to solve. And I just don't have those kind of problems, but I'm, you know, biased as well. So,
Speaker 1:yeah.
Speaker 2:Yeah.
Speaker 1:No, I mean, I think like I will say I've also I dabbled before I before I started using Laravel. You know, I was working as the lead programmer or for a little while the the only programmer at a company and and I ended up building my own, essentially a framework myself. But the problem with my framework, was that I was the the requirement from above me in the company was we want to move to an SPA. Mhmm. And I like I was like, okay, I don't I don't like Angular, I don't like Ember, you know.
Speaker 1:These were the things at the time that were big. And so the framework that I ended up building was basically, an SPA, like a JavaScript, like a way from for PHP to send stuff to JavaScript so that it worked like an SPA. And it just was so, you know, I lost the back button. I lost all these things that I really liked. And so, you know, I think that that experience though of building a framework is just It was so valuable to me.
Speaker 1:Yeah. Even though I I really don't like what I ended up with and I hated working with it later, for me, you know, this was because I I moved away from that whole that's not what I actually should have done, I don't think. Yeah. Like it wasn't the right call in that moment. But how much you sort of learn about about things when you try to do that, that's hard to kinda, like, duplicate.
Speaker 1:I
Speaker 2:I tell that to everybody. You know, it it kinda comes across as, like, curmudgeonly a little bit, but it's, like, be good at what you do, but be good at your language, but then build solutions that are unique to you. Like, so I have this framework that I've been using for 10 years now, and it's a it's a framework in the sense that, like, it makes a database connection and it, like, does some routing. So it it's file based routing. If you go to this path, it reads this file.
Speaker 2:It's like 200 lines of code, but I built 4 companies with it now, and it has been awesome every single time. And, like, one of the companies was really, really successful until COVID happened. And so I've got little PHP pain free engineers floating around the United States. That's cool. But it's like, if I was working at a different company, I don't want to use React.
Speaker 2:I wanna use what, like, the CTO of that company built. Like, let me do your specific solution for your specific, your specific, like, business use case. I don't know.
Speaker 1:Yeah. That
Speaker 2:that's the fun part, I think. That's where you learn the most.
Speaker 1:Right. No. And it is interesting. I mean, there really are a lot of different types of businesses out there where they would just reach for a totally different type of solution. Although I will say like the basic generic solutions for some of this stuff work really well as you're sort of describing.
Speaker 1:You know, it's like, you know, if you can handle routing and authentication and some of those basics, like that's going to last you a long that's going to take you a long ways for most apps for sure.
Speaker 2:I mean, that's like 90% of it. Yep. Yeah. But like there's nothing there's nothing wrong with them. Just, you know I think that everyone should feel comfortable trying different things.
Speaker 2:Like, I think that's where you grow as a person. It's where you grow as an engineer. You should be willing to like, okay, well, what if I build a library that is specific to our business?
Speaker 1:Yeah. No. I mean and there's just there's such a benefit of it's almost like when you're, as a developer, are willing to just really take control of your environment and your, you know, it's like I do this sometimes with projects where I'm like, I know I'm focusing on the wrong thing right now. Like I'm I'm like I'll just say I spent like even just a couple weeks ago, you know, I'm working on some mobile stuff, and I wanted the the top of the app to have a background image. Right?
Speaker 1:And it's like that's I'm like this is pretty straightforward. And I wanted to be able to load it dynamically, you know, whatever. It was just this little thing and I was like I could just I had difficulty and I was like you know, I could just skip this for now and come back to it. It's not the most important part of the app. It's the least important part of the app, but what is important is feeling like you understand the system and have like just a level of control over your code where like you can do stuff like that and you know how it works.
Speaker 1:And so it's like sticking with that and just kind of powering through the the difficult parts and not skipping over them so that you yourself have this confidence of like I now control this code, it doesn't control me. There's something really powerful to that, I think.
Speaker 2:Yeah. And that's what I love about more traditional languages like PHP or Python. It's, like, it's very, linear. Right? Like, you start at line 1 and you read your way through.
Speaker 2:You might have to go to a different file. You might have a function call over here, but you can reason your way through how you got from point a to point b. I don't like it when a lot of magic happens where you call an API and it spins up a microservice somewhere else and, you know, calls a Lambda function that returns some data blob. Yeah. That stuff drives me crazy.
Speaker 1:No. This is the antithesis of control. You are now at their mercy for what they included in their API, and I really dislike some
Speaker 2:of that stuff. They don't upgrade or they don't change the API, and, you know, now we're on use hooks instead of useEffect or
Speaker 1:Yeah.
Speaker 2:React things.
Speaker 1:Yeah. So what do you think is what do you think is next for you? Like, are you sort of, you know, you're working on this on this project. Is it sort of done in the HTML in the sense that like, you know, the product maybe you'll add features and stuff like that, but is it kind of like the HTMLX part you feel like is solved? Particularly with your sort of snippet on including third party packages and stuff like that?
Speaker 2:No. Because we have like a very ambitious, goal with this project.
Speaker 1:Nice.
Speaker 2:You know, we named it cofounder OS because we really do want to be like a web based operating system. And so part of that is we hope to become a platform. I built this, API layer so that any type of developer with the right credentials could install applications into our product that would then run on any other user of the product. So there's kinda like this multi year mission where, like, okay, I want every startup to use us, and if they want a different CRM, they install that CRM. And so I have to be able to, like Interesting.
Speaker 2:Yeah. So that's why, you know, that's why building your own framework is important because I have to be able to, like, not only say, okay, this is the way you do it inside of our product, but I have to build an API for other developers to consume that will play nicely with all of this stuff. And so, it's like a it's an architectural challenge. It's like structure of the project, structure of, you know, how files are laid out.
Speaker 1:Interesting. So, you know, that's probably less so on the front end stuff. That's gonna be more on the back end architecture and stuff like that. So the HTML side of it is
Speaker 2:Yeah. To some extent. But like, you know, why someone would wanna use our platform to build, you know, their own application would be that, you know, we've got this captive audience of brand new startups. And so if they wanted to, as an example, like, sell health insurance to brand new startups, so they wanna sell the health insurance directly in the product. They're gonna have to be able to interact with the front end and display to the users, you know, whatever types of selections that they wanna make available.
Speaker 2:And so I have to not only build it so that it works on our side, I have to build it so that it renders, you know, 3rd party content and so that 3rd party developers would be able to, you know, make use of clever, clever stuff as well. Like, it it won't just be static content that we're displaying to users. It will be kind of like, if you remember back to, like, the early days of Facebook when Zynga was like, they were building inside of Facebook as their platform. You know, you you would have, like, they would be publishing to people's feeds, but then also, you would click on something and you would bring up a full screen FarmVille inside of Facebook.
Speaker 1:Right.
Speaker 2:That's kind of the vision, I think.
Speaker 1:Interesting. Interesting. So you have to build the interface with parts unknown from systems that are yeah. Yeah.
Speaker 2:So right now I'm just trying to build a good API, and then I'm also trying to build, like, data controls around, like, how do we protect our our users' data while still making it possible for it to be exposed to third parties that I don't know about yet.
Speaker 1:Yeah. Nice. I mean, that's I would just throw in a little minor thing that I think this sort of server centric approach there where you're not having a ton of of, stuff on the on the client side, not having a lot of, you know, that's probably going to help with some of that.
Speaker 2:Yeah.
Speaker 1:I hope Not exposing information kind of thing. That's at least my sense of how that stuff works. So, you know, maybe, just a last few last few things here. But, is there anything you can you could think of or that like while you're building stuff like that you feel like is missing from the the sort of HTMX hypermedia ecosystem where you like wish that while you're I mean it sounds like it was a pretty smooth process and like you appreciate the low levelness of it almost to the point where maybe it's unnecessary to sort of do, more stuff with it.
Speaker 2:I I think just from this conversation today and from, you know, having spent hours and hours with my other engineer, my team, I think there is an opportunity for a large corpus of, like, language specific, recipes, tutorials, things like that. The documentation to me is great. I'm like, okay, there's an attribute, server returns stuff back. But if I was going to go and as a as a new u let's say I was a junior engineer, a mid level engineer, I got a ticket for something. It's go add dynamic searching to this thing using h t max.
Speaker 2:I would go there. You have to be able to, like, combine 4 or 5 different examples, like, you know, dynamically filling stuff in and, like, delay for, hypermedia or whatever whatever it's called. And there's a whole bunch of stuff where okay. Now we're doing this in PHP, but what if you're a Go shop or you're a Python Django shop? Like, even just seeing examples of, like, here's how you would do this.
Speaker 2:So I think Stripe is probably, like, one of the better players in this space where they're like, we know you just want to be able to, like, charge your customers for things. Here is examples how to do 7,000 different things in 15 different languages. I think that would be great.
Speaker 1:Interesting. Yeah. Yeah. And one of the things that I, you know, Stripe always kind of, provided, like, I think you're right. They had a little, like, switcher, you know, which language you're doing.
Speaker 1:Every single example, and they're mostly copy paste, you know, examples. Like you can, for the most part, just copy and, you know, click the copy button, and then you can switch and choose your language. So yeah, that's interesting.
Speaker 2:Yeah. I I think little things like that would be helpful to at least increase adoption where I don't think a lot of people have as much breath as much breadth of experience as we do. You know, we've been doing this 20 plus years. I look at HTMX, I'm like, oh, that reminds me of stuff I was doing in 2008, and it looks awesome. And so I'm like, that's it.
Speaker 2:But new people, maybe they graduated from a boot camp, or maybe they're a recent college grad, or, you know, they've only worked at 1 or 2 companies. They come in and they're like, why would you do this? And I'm like, because it's awesome, and it's gonna save you so much time and stress energy. But, like, I I don't know how to show that to you without you knowing that it's available.
Speaker 1:Yeah. No. That's an interesting point. There really is like kind of a a background of web 1 point o, that I wonder I almost want It makes me wonder if sort of like like a If you're from the react world, what does an h tmx bit of snippet of code look like to you? Because I can't I know what it looks like to me coming from web 1 point o.
Speaker 1:I'm like, oh yeah, Ajax, like we got a request, we'll fill impartial. Like it's just like it's so straightforward in a way. And I don't know what the mental model is if you have started in the virtual DOM JavaScript React world.
Speaker 2:The first time I saw JSX, I was like, that has got to be invalid code somehow. There's, like, fake elements inside of HTML with no string quotes or anything around it. I was like, that's gross.
Speaker 1:Yeah. Well, I had that experience. Have you ever used Tailwind UI?
Speaker 2:Yeah. A little bit.
Speaker 1:Yeah. So I had you know, I I like to I use Tailwind for pretty much everything now, and I love it. I got the Tailwind UI, and and I was like, you know what? I'm gonna I've paid for Tailwind UI now. I'm gonna use it as my, like, dashboard Not my dashboard, but my, my landing page.
Speaker 1:And so I go into the code for Tailwind UI, how they recommend this. And first of all it's like, you know, you download and it's like It was like maybe 45 files, I would have to guess. And I looked at like inspect element to see. I was like, okay. I got the example booted up.
Speaker 1:You inspect element, and like you're going maybe spect element and like you're going maybe 30, 40 divs deep before you're getting to like basic stuff. And I was like holy moly, this is all Next JS. And so I was I felt very removed from that. I was like this is appealing. This is like making sense to somebody.
Speaker 1:Obviously, Tailwind UI is huge. It's probably most of the industry sort of is familiar with this kind of code, but very obfuscated from what was happening. It was my my impression.
Speaker 2:Is a really good example. So, like, the I've historically been more of a bootstrap guy, and I've played with Tailwind a bunch of times. And I I like, you know, I like a lot of the designs and stuff that are capable with that. But it feels very much like that too is a return to, like, 2000s era. Like, we're just gonna inline style things, and it's, like, w 100 and with, you know, background blue.
Speaker 2:I'm like, we did that before. I just I don't get it.
Speaker 1:Yeah. Well, I mean, I've liked it. I'll I'll say I'll just give my quick pitch for tailwind. Please. You like before when you would inline stuff, you know, you're using CSS.
Speaker 1:Some of the things that tailwind encapsulates are several lines of CSS. So, like, even like a shadow, you know, you just do like shadow and tailwind. And what's actually happening behind the scenes is like box shadow 0 0, Mozilla box shadow 0, like, it's like up to, you know, 45 And there's a ton of attributes or classes that are like this. And so I think that the things that I really appreciate about it The thing I don't appreciate about it is that it recommends a build step which I just don't use anymore. So But they have an option around that so that's fine.
Speaker 1:But what I really appreciated is that you don't have to know some of the details of CSS to use the the things. It helps to know some of it, but And then also just like you don't have to reload any, any, CSS files. Like there's just one CSS file. So as you change your classes, it's very immediate, you know, what what happens there. You're not like command r, like, oh, I got to pull in the CSS again, you know, that sort of thing.
Speaker 1:Break the cache or something like that. So, I found it very nice for for using attributes. I do think that your page starts to get all if if you're really doing a lot of design, it does start to get, a little heavy. Yeah.
Speaker 2:Yeah. Like, the things that I like about Tailwind are the same things I like about Bootstrap, which is, like, it's a very well structured, well designed, super thought out, CSS, like approach to CSS. And then what I like about Bootstrap is they go, like, maybe one level higher, where they're like, we're gonna design a few elements that you're gonna reuse everywhere, like a card or Yeah. You know, card body, card so it's like yeah. And so Tailwind, what I think it exceeds Bootstrap in in in a lot of ways for is, I think that there are a lot of people right now that are very talented designers that are doing all of their best work in Tailwind, and I see stuff and I'm like, oh, I wanna do that.
Speaker 2:And I have to do it in Tailwind or like, you know, manually myself convert it to something else.
Speaker 1:Yeah. Yeah. So I mean, I'll just I'll I'll tell you like 1 2 of the things I'm working on are Cool. That are, you know, one of them is I mentioned a couple episodes ago, the htmxlabs.com, which I'm actually going to change the name of soon. Right.
Speaker 1:That's right. But htmxlabs.com is going to be a page of examples.
Speaker 2:Oh, sweet.
Speaker 1:Yeah. So it's like, you know, I've been I've been trying to get feedback from people on what Yeah. Yeah. I mean That sounds good. So one of the things I'm thinking is, like, I'm wondering if you know, like I said, I've never been an open source, you know, but I'm I'm sticking of ways that people could, you know, contribute or just make suggestions.
Speaker 1:And even, like, what you know, pulling from a repo, I just never really got comfortable with that. So I'm like, what do you think about if people could just submit a code sample? Like, if I had Yeah. A place where they could type it in
Speaker 2:I think that'd be fine.
Speaker 1:Submit it with a thing.
Speaker 2:It kind of what what I hope you're describing, kind of based on our conversation, is that it kind of reminds me of, like, CSS Zen Garden from the early days of the web. It's like one page and here's everyone uploads their own CSS file to show off what can be done. And so if this is just like a whole bunch of different recipes and and cool things to do in c in, HTML, you know, you might be on exercise, you know, example 7, and it's some cool, like, accordion widget. And then, you know, you put in the first one, but I can come in here and be like, hey, that's really cool. Here's another version.
Speaker 1:Oh, that's interesting.
Speaker 2:So it can kinda be its own thing, I think.
Speaker 1:I loved CSS Zen Garden. Yeah. And I I think I've I've since I think I even I even have an episode where I talk about how it sort of sold us a lie. But I loved it. And because I think
Speaker 2:What's a lie?
Speaker 1:To to me the lie with CSS Zen Garden is that there is a full separation between design and data. Mhmm. And I just that has not, you know, it worked so beautifully on CSS Zen Garden that I really bought into it. And I really tried. And and what I've found since is that to make realistic changes to your design, you have to change the HTML too.
Speaker 1:Yeah. Like, it's just you just do. Like, they're they're not you can't just swap out the CSS and change your site. You can in some cases, but it's so and what I saw on CSS now that I, like, looked back at that Zen Garden, it's like, man, they were doing some wacky stuff with CSS to get some of the effect. They could have just moved some divs around, you know.
Speaker 1:Yeah.
Speaker 2:But that's even, like Bootstrap and Tailwind, when they've got grids and stuff, they can be like, well, you can put this one over here first even though it's 3rd in the list. I'm like, that's stupid. Who's gonna do
Speaker 1:that? Yeah.
Speaker 2:Yeah. I mean Structure it correctly.
Speaker 1:Right. No. There's so I think for now I think of CSS Zen Garden as, like, it was one of my favorite sites, but it also I I do think of it as, like, a case for locale for some of the locality of of behavior and and one of the reasons I like kind of, you know, having stuff there because, like in line and keeping the data and the design together because they just kind of go hand in hand for sometimes for me. So,
Speaker 2:the other thing that comes to mind for HMX Labs specifically is maybe, maybe it's more like genius.com where it's like a song lyric, and then people are contributing, like, little notes and comments. So like this section over here could be like this. That's maybe another, like, more modern,
Speaker 1:So is that, like, new people sort of take their interpretations of of lyrics and kind of I've never seen that site. But do
Speaker 2:you like That's all user contributed to for the most part. So, like, when an album of a new band came out, you know, anyone can go in there and contribute, transcriptions, upload album art and stuff.
Speaker 1:Interesting. So
Speaker 2:Yeah. So so that to me is just as much open source as a repository, like those kinds of, projects where you're collaborating. Like, Stack Overflow is open source too. That's like people collaborating to make the world better and to improve, you know, Wikipedia.
Speaker 1:To to improve the large language models that, you know, they gotta they gotta do their work and make sure that
Speaker 2:Which then feeds into my product so that my product tells my users what to do a little bit better.
Speaker 1:Yeah. Yeah. So you mentioned there's
Speaker 2:2 projects you're working on?
Speaker 1:Yeah. Well, so so actually so yeah. I've got, you know, I've got a lot of dumb projects going, in the back of my mind. But the you know, the other one I have been thinking is like, this kind of idea of, like a UI kit but for hypermedia stuff. That's something I would say like inspired, but if you ever use Pico CSS Yeah.
Speaker 1:So, yeah. Pico CSS, I tried to use it, but then like you come across like some things you want to customize or that you want to be different and it's difficult. It doesn't cover every case. I I think it's such a cool idea though where like I actually did nothing to this page and it made it look much better, you know? Like I think that starting that as like a base, but then kind of expanding that.
Speaker 1:Because there's a lot of these UI kits, and I can't think of them right now, but there was one just released for LiveWire, like Flux, and there's like, the Radix or whatever. There's all these kind of ShadCn, like but so many of them require you to be have already bought into, like, a Next or React to Livewire. It's gotta be like, it's just, like, they have all these preconditions, and I looked for something that was, like, I don't want those. And Bootstrap used to be my go to. Yeah.
Speaker 1:You know, now I'm like, Tailwind is good, but it's that same thing where it is very low level. And so what I really want is, like, I want some defaults taken care of, and then I wanna be able to add some stuff. So, I've just been sort of thinking about that and and sort of trying to see if there's a you know in in my experience, I've needed that. So that's the sort of tool, you know, that I'm kind of looking at as well. So
Speaker 2:That sounds awesome. Also, I am a Nice. I am a lifelong front end avoider. So I I love templates and things that are built for me that look good. So
Speaker 1:Nice. Yeah. No. Me too. I mean, that's the, you know, that's the that's the dream.
Speaker 1:So Mhmm. Cool. Yeah. And then and then I'll just throw I'll throw in one more, you know. Have you ever had to build mobile stuff before?
Speaker 2:Mhmm. Not, I've never built mobile native except for some games. I worked for I ran a game studio for a couple of years.
Speaker 1:Oh, nice.
Speaker 2:Not like never Swift, never, whatever was before Swift.
Speaker 1:So what did you use? Like Unity or something?
Speaker 2:Yeah. Unity mostly. So we were a government contractor. We built games and simulations, like, for for training purposes. Yep.
Speaker 2:And so oftentimes we didn't even get to pick our tech stack. The government would just say, we would like this thing and, you know, here's the amount of money. And
Speaker 1:then Nice.
Speaker 2:Yeah.
Speaker 1:That's cool. But yeah, I mean, so I guess like I've had the need to or maybe not need, but I've had the desire to be able to turn some of my web apps, not just give them like a online way to click through, but give them actually like a real app. So I did that with Flutter, and you know, my my experience with that was that, like, I hate Flutter. And I hated the way they organize their widgets, and it The code was a mess, and I hated every time I had to make a change I had to, like, submit it to Apple and Android. Like, that's a nightmare.
Speaker 1:Right?
Speaker 2:Yeah. That's why I don't do those.
Speaker 1:Yeah. So so here's my here's my concept, which I guess my question is, like, you know, does how appealing does this sound? But if you had, like, and this is so I think that there's a project called Hyperview that is already sort of doing this, which I'm hoping to learn more about in the future. But if you had something that you built on the back end, like, you you just sent it data and it just the app itself is a shell, empty shell, does nothing until you pass it Essentially, HTML, JSON, whatever, and then it populates, but using all the native elements in it in it, you know, the app itself functions and moves like a regular mobile like a regular mobile app. So you're
Speaker 2:gonna build like a native app itself that is kind of a shell like Electron is for for desktop where it's, like, okay, it exists now and here's the code to display inside, but then it translates to native?
Speaker 1:Yeah. Exactly. So so instead of showing you because I think I, you know, I don't know that much about Electron, but doesn't it kind of do a browser
Speaker 2:Yeah.
Speaker 1:Inside? Yeah. It's just
Speaker 2:Chrome and then
Speaker 1:So so this is what I don't want to do. Like, I don't want to think of it as a website. I want to build a bunch of native components that are driven by sending back end code, if that makes sense. So let's you can just imagine as HTML, you know, like you have like your h t outer HTML, but that translates to like your screen, and then you're doing like data within the screen. So they're like, you know, when I need to make a change on the app, I'm actually just changing back end code that I send, and there's never any updates to the app.
Speaker 1:You know, I'm not changing anything. It's like every screen is dynamically built from
Speaker 2:Okay.
Speaker 1:You know, some back end thing. So anyway, that's kind of the concept.
Speaker 2:That sounds pretty interesting too. I mean, my my historically, I always build a really good web product first, get traction, and then I'm like, I will eventually hire mobile engineers and they'll come in and switch it over.
Speaker 1:But Yeah.
Speaker 2:That sounds cool.
Speaker 1:Yeah. And like and my problem with the mobile stuff, like, is I've looked into hiring people to do it and it's like the way that it works, like, man, every time I want to make a change, I'm freaking screwed.
Speaker 2:Mhmm.
Speaker 1:I've got to wait 2 weeks. Like that feedback time is just not good. It's it's terrible for some of that stuff.
Speaker 2:So I, I've been like on x, you know, every couple of weeks, Elon will come out and be like, would you guys buy an x phone? And I'm like, yes. We need more competition in this space because Apple and Google have kinda a stranglehold on their Play Store and stuff.
Speaker 1:Yep. Nice. So, yeah. I mean anything I know this was I this was me pitching you on stuff, but like I I think like, you know, I'm just curious, like you you're someone who's who's dove deep into some of these h t m x details Yeah. And and hypermedia and stuff like that.
Speaker 1:So I really appreciate, the feedback and and talking to me about some of your experience. And, I think people will I think people will really appreciate, some of the tips and tricks and the kind of actual things. If you end up open sourcing what you're doing in some
Speaker 2:way. I'll open source it this weekend. I also I've got a couple I've given a similar type of presentation of, like, here's what I did, here's some tips and tricks. I'll send that to you as well if you want to share that.
Speaker 1:Yeah. That'd be awesome. That'd be awesome.
Speaker 2:What else? And definitely keep me in the loop with all your projects. HTMX Labs sounds awesome. So whatever that ends up being, I'd like to help somehow.
Speaker 1:Nice. Yeah. No. I think the I think that what you sort of said about, like, even if I put up an example, because, you know, so I was sort of thinking having a submission process and then I could approve and and stuff like that. But I think the way you sort of framed it as like, even if there's already examples there, showing alternatives, giving maybe whether it's in a different language, or maybe it's just a different way of approaching it, or something like that.
Speaker 2:Or it could be as simple as letting me publish an article, like, hey, here's a cool thing I did with my specific technology.
Speaker 1:That's related to this example or something?
Speaker 2:It just becomes an HTMLX, like hub of documentation and learning.
Speaker 1:Yeah. No, I like that. I like the sound of that. Cool. Awesome.
Speaker 1:Well, so I'm gonna be building that in public over the next couple Perfect. That's that's my next season of this podcast. This season was all conversation, so that's my plan is to build that in public. So
Speaker 2:As soon as you're ready for beta testers or whatever, hit me up.
Speaker 1:Awesome. Alright. Sounds good.
Speaker 2:Well It was great talking to you.
Speaker 1:Yeah. No. Thank you very much. I really appreciate you taking the time and, going into it. And, yeah, any any anything else you'd like to to, plug or kinda, like, mention on the way?
Speaker 2:For anybody who is interested in starting a new startup, it doesn't have to be tech, doesn't have to be, you know, we help everybody of every kind. We have a really nice AI powered tool. We have people that have we've got, like, combined 80 years of startup experience on our team. We've raised $15,000,000, you know, over a bunch of times. We just like helping people be more successful in startups.
Speaker 2:So if you're interested, make startups.org.
Speaker 1:And this is like any startup in any industry. Like this is like
Speaker 2:Ideally, I think the best version of our tool is the 3 month in person boot camp that is like in Georgia, because that's like more hands on. But we have like a self paced online version. Yeah. Anyone? Anywhere?
Speaker 2:Anytime the bus. Awesome.
Speaker 1:Awesome. Well, yeah. Thank you very much for, for sharing. And, yep, have a good night. You too.
Speaker 1:Alright.
