Let's,

let's get let's kind of move the story along chronologically then and talk about like, okay, so you started to introduce htmx to the project, what happens next? Yeah,

so

okay, so I joined I

joined this company at the beginning, they, so they, they had a contract team. It was three, it was third party contract team was two or three other people externally of the company. And they built this platform in Laravel and they were using Livewire. And this was a few years ago. So at the time, that's when I joined. And so I inherited this as like internally as part of the company. I think I was, I'm pretty sure it was the first, yeah, it was the first developer hire. I I inherit this thing and help them manage the external team. And for the most part, everything's fine. But you know, having discussed everything we just discussed, at the time you had to build, I can't remember exactly why, but it was a mix, like a web pack mix kind of thing where you needed to build for the front end and live R and all of that to kind of communicate And so every time I would do a deploy to prod, especially on my own, I would have to either build locally, and on stage in order to get it approved by by product and QA and on prod, or at the very least on stage and on prod. And that was a time consuming process. And I felt like at least for myself, I could move faster without the build steps because I've done it before and so I'm thinking okay well htmx sounds good there were some other issues with the platform that I inherited which I fixed and then a few months into it I'm thinking okay well I have this feeling you know so I you know everything we just discussed I want to prove it I don't just want to have a feeling and run on the feeling and just say, well, if asked, be like, well, I just felt like this was the right choice for me. So what I did was I took a week of my own time over the course of, I can't remember what it was, three weeks or something. I put in a lot of overtime. And I rebuilt a portion of the site. It was one feature. I rebuilt it in HTMLX. And then I showed product, the difference between the current state of things and the HTMLX state of things. And they

really liked it. And were you mostly like showing off performance performance

was the was the thing? Yeah, it was like loaded instantly. They could interact with it. Everything was instant because HTMLX, it's just backend calls to the PHP and then you reload the HTML and browsers are fast and your bandwidth is fast, yada, everything's fast, right? So it worked out well. And everyone, including myself was surprised that I could rebuild this thing by myself in over the course three weeks, ultimately a week of time. It was actually Thinkific. I rebuilt Thinkific internally in a week in HTMX. And that was called Insomniac 1.0. The reason why is because I barely got any sleep. And so they dubbed it Insomniac 1.0. And I and I went up to Insomniac 3.0, which means I rebuilt three, two other completely external things that they were paying for and using. They were heavy and complicated.

So these weren't like the core product. These were things that the company was like using internally. Insomniac

3 was the core product, which I'll talk about in a minute. But Insomniac 1 and 2 were external products that were just completely replaced with it with the HTMX version. So they were so everyone was impressed, including myself. I didn't think it would go as well as it did. I was kind of shocked. We were still kind of dealing with a lot of the issues that were inherited from the work that was done originally without my HTMX work. And so we decided, well, we need to hire another developer. So we hire another developer, and they spent some time working non-HTMX. It's just regular Laravel, Laravel, etc. We wanted to make the developer... So here's exactly what we were talking about before. We wanted to make the developer experience nice. The developer was intermediate to senior, and they really, really liked Vue. And they were really good at using Vue, so we thought. And so the developer came to me and said we would I want I want to use view if we're gonna do a Friend and framework rewrite because I know you've been thinking it I can see it every time you do a PR and you say oh Why is this like this? I hate this we should do this, you know, I see your PRs. I see your comments Can you push review for me and my gut feeling was like I don't this is kind of the antithesis of everything that I've been trying To do but I was so swamped. I was working so much over time. I was really trying to make this successful. I was by I was by myself, running all the features, we're talking about thousands of users, us a multi million dollar company. And it was being used constantly all the time, there was a lot of pressure and investors like big companies wanted to invest in us. I think some did. I don't know all the ins and outs of that, but there was a lot of pressure of just me running the whole thing. developer can take some burden off of me. And if this developer can do really good with view and they can move really fast on the front end, well, gee, that'd be great. Because if all I have to worry about is the back end, oh man, that would make life a lot easier. So that was a big mistake.

So, so I just want to like say this again, because this is actually like kind of crazy. You're on PHP live wire. You introduce the HTMX library, you rewrite a few of the views in the app, or I should say, and maybe even in various apps in HTMX. Another developer comes up, actually I want to use Vue, and now we're introducing Vue as well.

Cool. And again, my gut feeling, and I'm pretty sure I told this to my superior, my gut feeling was I don't really like this. But the pressure, which I completely understand by the way, it's not, I get businesses have to do what they need to do in order to make money. And I appreciate it too, because I get a paycheck, I get to feed my wife and kid with that, right? So I understand, when they came to me and said, Look, man, we just need you to move, right? We've got to get moving here, you do what you think you need to do. But keep in mind that you were by yourself up until this point, we have another developer, let's maximize the usage. And I'm thinking, okay, if this developer is telling me, and based on the resume, it kind of lined up that they're going to move fast in view. All right. Okay. Now I didn't consider long term consequences. I didn't consider performance issues. I didn't consider technical debt. I didn't consider whether the, I didn't really look deeply into why the developer felt this way. Like I didn't do my due diligence. So I, you know, I take responsibility for that. But I said, okay, for the short term, maybe this will work out just fine. Right. So the developer took approximately one to one and a half years to do one feature. And they didn't finish it by the

time that that developer left. Wait, hold on. I did not realize this, that you were on this project for this long. So three years, three and a half years. Okay. Yeah. I had in my head, this was like, you know, I dunno, six months of time total. So this developer joined, this is like a couple of years ago now and took, but as you said, a

year and a half to ship something. Yeah. Yeah. And it didn't get shipped. I mean, it did get shipped, but it was never, it was never considered complete. We always had to mask features that weren't done. How did a firing

not happen? Like way sooner for this, this person, the

company runs as like a lean startup company. There are not a lot of people there. It's a pretty small, I think it's like 10 or less people overall. Um, it's really easy. I think you would know this. It's really easy to miss stuff. When, when you have people that you kind of delegate responsibility to and you, and you, you give them a, you give them a bit of your trust, you don't look as deeply because there's always something that's ready to take the distraction away from you. And again, I'm blaming myself here because I did not pay enough attention.

So like stuff was getting done. It's just like the core things that needed to get done weren't getting done. Yeah, yeah. Okay, I could see how that could like kind of slip onto the radar. It's like, oh, I shipped all those other things that like weren't the thing that we needed to ship. Yeah, there's

a whole other, there's an entire aspect of it that it happens in the background in startups where, this wasn't really a start, but anyways, in a lean company like that where you have a lot of pressure, you're changing a lot, your priorities change a lot, sometimes day to day. And so what was a priority for a long-term project at one point, day after day after day something comes up and you need to solve something. And when you only have two developers and let's say a bug comes up or customer screams at customer support, you know, something like that, you have to drop that and go focus on those things, for example, right? So that just it compounds and makes it way easier for that to fly under the radar. Now, ultimately, I should have paid more attention to that because it's technical. And that's on me. I was the seed, the lead, the lead developer. So, you know, I blame myself for that. And I made a choice against my own gut feeling. And I didn't do my due diligence. So, you know, it's ultimately my responsibility. So once I realized that these, once I finally clued in, wait, what's going on? We've had this thing for a long time. I talked to my superior and we're like, yeah, this thing's taking forever. What's going on? And, and then I thought, okay, am I, am I running on feelings again? I should have not, you know, I was thinking, man, I shouldn't have done this. I shouldn't have done that. I shouldn't have let him start this in the first place. Yada, yada. Yeah. So I went back to my roots and I went, okay, well, um, I've already put in like a year or a year and a half of like all this extra time and effort because I care about the company and the people in it. And I didn't want to, you know, I want to make sure it succeeds. And so what if I just do the whole, like I'll take a week and I'll try and rewrite this thing that he's been doing for a year ish, whatever it was in HTM X. And I'll see if my feeling about whether it should be this complicated is true or not. Before I go spouting my mouth off and say- I've been here

before, this is like, it's like, why

is this taking a

month? All right, I'm just going to sit down for an afternoon and just like, from first principles, like this feels like, like when I describe this problem in English, it sounds like something that's accomplished in, you know, I don't know, a thousand lines of code. Yeah. But this is taking months to complete. And, and a lot of times what I found, especially like, hire, I think hiring junior developers is awesome. You have to have the resources to be able to work with them very closely. Because what can very easily happen is like when you're new to development, you're solving created problems. Like you're writing code in maybe a way that's not great. And then you have to write more code to account for that. And this is a cycle that can definitely happen. Again, I think hiring juniors is fantastic and good for companies and more companies should be doing it. You have to allocate some resources to like watch and help and mentor and keep everything on track. To

your point, I think the data bears this out, the data that I have. And I think my prescription, we should be asking more of programmers as a whole, that includes from the junior up is exactly to your point. If we did that and we took a little bit more time upfront, the selling point to, see this is kind of always the crux, right? As developers, we talk about this thing, like you and I sit here and talk about it and you say, Hey, hiring juniors is great, but we need more of this and that. And I say, yeah, and I think the day it bursted out. And then you go and you talk to an executive and you're like, Hey, we would like to do this. And they go, but my money though, I have, I have shareholders, you know, that I need to answer to. And what about your paycheck, you know, and all that. And I think if you can make the case that the data shows that if you do these things, companies ultimately make more money over the long term is a good selling point to try and push that I think we should be doing that. So I completely agree with you. So I guess, oh, so yes, yeah, To bring it back. I didn't have the resources and I also should have just taken, I was already taking extra time. I could have allocated some of it. So I blame myself here. Um, but exactly what I did is what you're, what you describe where you look at it and you go, what the heck's taking so wrong? Let me try and approach it again with fresh eyes. So I thought it would take me a week with HTMX. It got feel that should only take me a week. Took me three. So what this was, the state of it as it was in a year, took me three weeks to do and it was feature complete. So it included things that were not done in the Vue version. Suffice it to say at that point, the developer was no longer with us, and I was again on my own for six to nine months, something like that. And, and you know, at this point in, we're pretty, we're a lot farther into the company's lifecycle, and more users, more expectations, more features, more, more, more, and I'm running it by myself. And when I started, I rewrote the entire. I just got to pause for a second. If this company is really

making millions of dollars off this software, I find it completely insane that there weren't, there wasn't a larger team of developers working on it. That's

a different discussion. We should talk about that after. Yeah.

Either they're just wrong. They're just doing it wrong or maybe there's like hidden costs I'm not aware of. Like they were actually spending most of that money on like marketing or something. But there were a few factors. That's wild.

Yeah. There are a few factors. Yeah. I can talk about that online. That's another thing. Yeah. It's a whole other thing. Yeah. But you know, again, just to be clear, I understand why businesses have to do what they do. And they were trying to make the best decisions they could for the business. And I completely respect that. That's what businesses should be doing. And sometimes it sucks. And it's painful. And I get it. So factors aside as to why things were the way they were, I'm by myself again for another six to nine months, I think it was more like nine. And I took a month out of that time and I rewrote the entire thing, removed livewire removed all the build processes and rewrote it all in HTML. full stack app. by the way, that's for light JavaScript interactivity. Okay, because hyper script is it's a Carson's thing with a TMS, right? So it just felt like a natural fit. So I rebuilt the whole thing in about a month from the ground up. And then as a result of that, I was moving so fast. For the duration of the time I was by myself, once that HTML thing was built in off the ground, we were two sprints ahead on our workload on every sprint for the entire duration of the time I was alone. And, and then we were doing so well, that the demands actually got higher because we were being asked to do more. It's like, whoa, things are going so well. Yeah, like

you.

Yeah. Right. Like how will you do more? And so then we hired two other contractors to help me out. One was primarily front end, one was primarily back end. So that complete rewrite was Insomniac 3.0. That was the, I spent a month, like I lost time with my wife and kid. I barely slept. Like I just went for it. And that was the complete rewrite and So we hired these other two developers and when they first came in especially the front end the front end guy He's like the heck are you doing here HTM X and I essentially I had to kind of be a jerk I admit and I had to and I had to kind of go listen man Would you're a paid mercenary? All right? This is what I'm doing. You're paid to do what I tell you to do, okay? You accepted the terms. You're gonna use HTMX and you're not gonna complain. Okay, okay, yeah, yeah. It's a contract, I get it, right? So, you know, it was, it was more jovial than that, right? I was, but I was kind of like, listen, this is how it is. Just accept it. Just trust. I'm being nice, but actually, but actually, yes, but actually, that's right. I'm three weeks in. I remember this. Three weeks, three weeks in and two days apart from each other they both independently came to me and said I'm blown away by how well HTMX works and the friend end guy said I'm almost inclined to use HTMX for a vast majority of my projects going forward, instead of the other frameworks that I typically go for, because the difference is huge. I can't believe how well this worked. And then we just, we ran with that. They were extremely supportive of the whole thing as we continued going on. But then what happened is the technical debt that we didn't have time to deal with as a result of the old way of doing things came to bite us in the butt. So I've been kind of hiding this as we've been discussing. But what happened was when I rewrote the the the entire thing in HTMX, there were two or three pages that I did not have time. There were there were small there was literally one page with like three small features and I did not have time to remove view out of them. And because we were getting so I was doing so well and we've got so much pressure and then I had new developers and just one thing after another, after another. And it was like, like, just 98% there. And I'm like, you know, I got to focus, right. And as a result of that, there was all this old legacy code that was hanging around, that suddenly became important because those features were becoming, they were like raising up, they were they were floating up in terms of visibility, because we were doing so much. And people were now seeing these features that we kind of like go for a while. We had to do a major cleanup. We had to remove those pages. We had to remove the old code that we didn't get a chance to remove. But there was an entire dependency tree that we didn't account for. That's on all of us. I blame all of us for that. We should have considered that and maybe should have even taken an extra one or two weeks and just done it and removed it. But that entire dependency tree had ballooned so much where removing view and all its interdependent things, like we had some APIs that we were no longer using. There was some code running behind the APIs. There were some database structures behind those APIs. There were some views and components and things like that all in the Laravel side. And then we had some front end stuff that on those features are being integrated a particular way. All of that stuff ballooned like we just we didn't realize what we were in for. And then we slowed down. And so

I just want to like make sure I kind of understand at least my level. So when you're looking at the app, it feels like this is small because it's like view is powering just like this. These are one or two pages. But then when you dig through like what those views, it's a confusing wording, but those views, those view pages are using, there's a lot of dependencies back there, all sorts, not necessarily it sounds like tied to view, but tied to those pages. And so it's not easy. Like I guess there's a lot of logic back there. So to rewrite it is a much bigger ask.

Yes. So imagine that someone in leadership comes to you and says, hey, these pages are actually important now. We've got so many users and features and people wanting to use it. They're important. We'd like to add some features to it. And you go, okay. And then you're like, wait, first of all, this is in the old tech, the view tech, let's say. And second of all, to remove this and replace it with HTMX. So it's things have become so ballooned and complicated that it's an insane amount of effort to even add one feature to this. And then they're like, you don't have time to rewrite it. No, we need this now. You don't understand the visibility is now. Right. And so it's like, okay, well, what do we do? And so then we actually had to make decisions of like, do we just continue supporting view for a while and just add features to view to the JS version view and then, and then work our way backwards through the Laravel and replace for, like we, like that, a thing and we slowed down. It was a huge thing. So that became a problem. And then once we got through that, the other problem became the more complex some of the features became, the more we actually struggled with HTMX in some capacity. And I'm going to write an essay on this for Carson. If it's good enough, Carson will put it on HTMX.org.