[Richard] You're listening to software unscripted. I'm your host, Richard Feldman. On today's episode, I'm joined by Marc Grabanski, the founder and CEO of Front End Masters an online education company where I've been an instructor for both Elm and Rust courses over the years. We talk about getting back to basics with web development, not just from an educational perspective. But how using techniques that today might be considered old fashioned can actually be better than modern, quote, best practices. Software and scripting is sponsored by my employer. No Red Ink. No Red Ink makes software for English teachers and we're on a mission to help all students harness the power of the written word. We're also hiring, so the next time we're thinking about a change, Take a look at noredinkdotcom slash jobs. And now back to basics in production.

[Richard] Alright, Marc. Thanks so much for joining me.

[Marc] Yeah. Well, thanks for having me here. Appreciate it.

[Richard] So you're the founder of Front End Masters from whom I start off by thanking you because I get a lot of paychecks from you for for the Elm and Rust content I've made for you. And I think Front End Masters is an awesome place to, like, work for. So thank you for building an awesome organization.

[Marc] Yeah. Absolutely. It's been really, really awesome, especially lately. It's like Yeah. Just the love from the community, like, the people that are using the product to to, you know, upgrade their jobs and and all that kind of stuff. It's it's really really cool. But we have kind of this specific slant that I think you and I resonate with, which is language fundamentals and really focusing on the fundamentals of of kind of, like, how to think about programming and programming fundamentals instead of just jumping to you know, higher level frameworks and that kind of thing.

[Richard] Yeah. I think well, so speaking of fundamentals, something I wanted to ask you about because I remember this is, like, maybe four or five years ago now, you were, like, redoing the the Front End Master's website and, like, you were doing it. You... I don't think you, like, contracted somebody else to do this. But, like, there was a big focus on, like, you know, this is Front End Masters. Everything's gotta load super fast. And, like, you know, you go to that website. It can't be... it's not acceptable to be called Frontend Masters dot com and to have it like like a low, you know, slow slow loading experience.

[Marc] Absolutely.

[Richard] And, yeah, that's something I care a lot about too, but I I also know that, like, a lot of sense when I talk to people about web front end performance, they're like, okay, here's this off the shelf thing that's gonna do all this JavaScript and, like, all this, like, prefetching and, like, you know, when you hover over a link, it's gonna, like, load this in the background automatically and, like, that's the answer is to, like, add a lot more frameworks than, like, use the word framework.

[Marc] Just shove it in just take it all and just, you know, shove it in the background and then, like, load it so it looks fast, but really, like, you loaded eight megabits of stuff in the background and just kinda shoved it back there and... and, wow, it's so fast.

[Richard] Yeah. But I I don't think that's what you did.

[Marc] Yeah. Exactly. So so what did you do? Yeah. So, yeah, along with language fundamentals, like, you know, I guess that comes from my personal slant of, like, performance. I want things to load fast. Like, who doesn't want things to load faster, right? Yeah. Like, in general, like... and with that, you know, I think our our CTO... well, I should say our CTO is sort of, like, he has the exact same engineering mindset when it comes to... on the back end as I do on the front end. And so, yeah, we build everything in house and everything is vanilla JavaScript on the front end. So everything on Frontend Master dot com is vanilla JavaScript. And then on the back end is is vanilla Go. So built with the exact same philosophy.

[Richard] Yeah.

[Marc] Because, you know, I don't know, like, a whole lot of engineers when I talk to them these days that ever look at a two thousand twelve code base and pull it up and be like, wow - that's really, really great stuff. And I feel like that. Like these days, it's like, I can pull up some of my old code and it's like, there's so many really cool concepts here that the industry is still wrapping their head around. It's like I had time travel debugging and, like, being able to, like, walk back and forth through state and all this stuff. And I had all this stuff. I just I just came to that decision through just trying to get better at engineering in general. Learning, you know, as many concepts as I can and applying them. And so, yeah, it's just a general concept and to answer your original question of how did we make it fast? Well, it's all statically built. Right? So the the goal is just have HTML files. And that's it. Just serve the HTML files and, you know, add JavaScript where you need it, which, you know, the site should work really, really fast. So as as minimal amount of code and modules as you can. And... and so anywhere you can just write the code that does the job instead of pulling in external libraries. I think that's just my general philosophy because it's like good engineering, doesn't need a lot of external stuff. And... and when you pull up... open that project later, it should, you know, be clear where the things are and and also just not have a lot of, you know, have the, like, NPM update for, like, the next two days before you can, like, write my code. You know, it should be about the product and not be not the dependency management problem that we current... you know, a lot of engineering has today. So yeah, it's all statically built. And and then for the dynamic stuff, Go just kind of hydrates. It says, okay, the cookie exists, and then it just hydrates the template, you know, the Go template with the authenticated data.

[Richard] The username...

[Marc] So Yeah. Yeah. Yeah. Exactly. So we just we kind of have a hybrid in that, like, all the static pages are built for the public. People are not logged in. And if they have a cookie, then we just yeah. We just send that data down and and so that... that... now that page can be dynamic.

[Richard] Yeah. I think it's really interesting this sort of, like, there's been this shift towards, like, libraries by default for everything over the past, like, I don't know, ten, fifteen years maybe. Because I remember, like, I  have a lot of nostalgia for the jQuery era of, like, the web. When that was, like, the biggest thing. And, like, Yes, there were some problems with like, okay, mutating down directly all the time. If you do that enough and your thing gets big enough, it's like a big mess. But if it's not that big, it's not a big mess. It's just fine. It's just totally like you can do a couple of small mutations that's really not the end of the world, it just, you know, it it can become a problem if that's, like, you know, the DOM becomes, like, your source of truth, and you're making some really, really big, you know, thousands and thousands of lines, like, complicated web app.

[Marc] Yeah. Absolutely. And we we had that debate internally. Right? Like, we have we have engineers back in the day, it was just mostly me and Brent, you know, our CTO. And now we have a bit larger team. And, you know, the team is like, why don't we use tools that we use everywhere else, you know, like, especially coming into the team, like, why are we doing things this way? So it kind of like... it was a interesting moment where it's like, okay. Do I actually know what I'm talking about these days? Like, you know, you know, I made these decisions a few years ago. So let's let's take a look. Let's dig in. So I made a project called to do MVC with Vanilla JavaScript in 2022. So you can just basically type in vanilla JavaScript twenty twenty two or whatever, and you can get this project. And it was it was surprising I, like, kicked off a lot of discussion on, you know, all the usual suspects in Twitter.

[Richard] Oh, I'm not surprised.

[Marc] Hacker News and all that stuff in there. And, you know, surprisingly, there is like a lot of positivity towards this approach. The initial code only took me about an hour. It was a hundred and seventy lines. you know, no dependencies. It was just like and it it did everything that I needed to do. I granted to do MVC is not that complicated. Right? But it was -- Right. -- yeah. know, it's just kind of a proof of concept because the... the, like, original vanilla JavaScript version was, like, nine hundred plus lines. And this was just like, here here's all the modern, you know, features with, you know, arrow functions and whatever. Like, I was able to, like, extend event target and make a, you know, a class be able to emit events and stuff like that. And so that was, like, know, there's some fun new tools that we have that are just kind of, like, built in the browser and yeah. And, like, template literals and all these kinds of, you know, things that... that make... we can make, essentially, it feel like a modern framework with just new modern things that are built into the language. And so, you know, using those things, I was able to, you know, yeah, not... not leave the state in the DOM and, you know, render things top down and all that kind of stuff. And so I've got a a blog post that kinda walks through all the architecture decisions and that kind of thing. And so then I'm kind of using that to, like, also educate, like, our internal staff when it comes to the front end engineers on our team and was, like, here are... here are what frameworks provide you, and here are why I think that this approach is is better. And, yeah, it's... I think it's proven to to stand the test of time, and I think it will continue to stand the test of time. And I... I'm very interested in, like, teaching people how to kind of think about just using JavaScript to build large, you know, applications because the reality is there really isn't much material. That's why you reach for, you know, I think a lot of these frameworks because there's there's plenty of examples where you can kind of just pull how they built this or that, whereas in vanilla JavaScript, it's like, yeah, like you talked about back in the day, it was like, jQuery. And so everything was jQuery. And there still isn't like, a modern vanilla JavaScript guide to, like, building, you know, ambitious web applications. And so... but that's something I'm very interested, but, obviously, I run a company and... and we have a, you know, a lot of engineers. So I don't know. Maybe... maybe I'll... I'll take a a short, like, two weeks sabatical and just kind of, like, knock it out or something. I don't know. But these days is just I have debates with with my team about architecture and and that kind of thing. It's...

[Richard] Well, I like what you said about Like frameworks provide certain benefits, but they also come with certain costs. And a a weird cultural dynamic that seems to have emerged over the last, I don't know, like, like I said, maybe ten, fifteen years. I'm kinda ball parking there. It is that the costs have just been started to, like, become taken for granted. It's like if you're doing... and like, you know, I'm setting aside the Elm world, like, if you're in JavaScript land and you're like, I need to start a new web project. The norm is you're gonna have a big old NPM, like, package config with, like I mean, maybe... maybe your package dot JSON is, like, itself pretty small, but there's a bunch of transit dependencies, like megabytes of stuff. And all of that's third party not, like, you know, baked into the browser or anything. And all of that stuff has varying degrees of working well with one another. And like this is just like the baseline for like hello world with like modern tech stuff regardless of the size of the project. And also, like, I mean, I'm I'm pretty open to the idea that, like, maybe, you know, to your point, like, maybe these things are, like, they have certain benefits, but also maybe the costs outweigh those benefits.

[Marc] I absolutely think the costs outweighs the benefit in in ninety nine point nine nine nine nine percent of cases, I think you should just write the code for the job at hand and just have no dependencies and just, you know, if you need that's the thing. If you a code base is only as good as the people who are working together on it. Making... and how they make decisions together. Ultimately, that is it. Right? So how fast it it ends up being you know, how great the architecture is, etcetera. Like, it's all a function of how that team works together. And I think to your point about costs, it's like the more tools you adopt, the more things that I think get in a way of you actually having the real discussions you have to make because a lot of engineers, instead of having that really hard discussion, they decide to reach for another tool. Oh, this will solve it. Oh, this will solve it. Oh, this will solve it. And so what ends up happening is at the end of the day, somebody pulls the escape hatch and just hacks it together with either, you know, something else, and it's just like, there's you you see it in every framework code base. There's like a... you know, like, even when framework authors, you know, we work with framework authors. So it's like, me as the CEO of Front End Masters, the disparaging frameworks is sort of like a a knock to some of them, I think, in some ways. But I recognize that, you know, there are a lot of jobs out there, and we want the best education for learning these frameworks and being productive in them because our goal is to make people successful. And so I don't let my own slants, you know, get in the way of of having the best education on these frameworks and stuff. I understand their place in a lot of these organizations. And the only way to be productive in these organizations is, you know, to learn the tools de jour or, you know, every the joke is in in JavaScript. It's like there's a new framework every five minutes. It was like, you know, it was people are really excited about Vue and then people are really excited about Svelte and now people are really excited about Solid. And on and on and on the cycle goes, I get that these tools are adopted. But what I would like people to consider is just writing the code for the job at hand, you know, with just the language or try it. You know? If it... if it doesn't work, you can always be like – Okay. Now I have a better understanding of the problem domain, and now I can introduce a tool that I feel is exciting, you know, or that solves the problems that I have for this particular, you know, problem. But, like, the fact that we have to reach for a framework immediately is just absolutely asinine from my perspective because, you know, you don't even know the problem at hand a lot of times, and you're already starting with the framework because it's exciting. Like, I get that a lot of people, you know, that works out for them. Great. But I just think, you know, at least for me personally, I think that's a major misstep. When you could just write the code that does the job and be excited about it and evolve it. And you know what? Maybe it doesn't completely fulfill every single use case that you have. Okay? Well, you can change the architecture using solid architectural, you know, principles because you... you are you are an engineer and you can think of things and you can talk to your team. Well, maybe we should maybe we should, you know, break these all into separate modules that we can reuse over here and here or whatever. Right? But, like or just make, you know, these kind of... but you're the ones making the trade off. You're not outsourcing the trade offs to the framework, which then all of a sudden, you know, you run into an issue where, like, the framework doesn't handle this one particular situation. So you go in... you go into the Discord and you go on or whatever Slack and you start going. I have this specific problem and, you know, the framework is, you know, barfing at me. Like, you know, I just don't know what's going on, and and then they're like, here's this undocumented API with this specific escape hatch you know, to, like, solve this or get around it. And every single framework has this problem.

[Richard] I have definitely run into that, like, over and over a career of, like, using something that's, like, yeah, there are benefits for sure, but there's always a moment where I hit something and I'm, like, this would be super easy if I had done this all myself, and now it's super hard. I'm like, I'm fighting against the framework because, like, it just doesn't happen to support... or... or the abstraction that they've chosen is, like, somewhat leaky and doesn't quite work for this one scenario. And so now I need to start – Okay. How do I how do I try to salvage this? It's it's always in, like, damage control mode instead of being, like, oh, this is a very helpful tool. It's like, no, no. The tool is actually the problem now. I've always run into that, like, at at some level with every, like, big framework I've ever used.

[Marc] Yeah. And this is gonna date me, but It's gonna definitely date me. But, like, you know, back in the day when I was writing... I would write, like, you know, basic PHP, and then I was starting to use Cake PHP, and then I, you know, I built some apps on Cake PHP on dot net, on Rails, and then some stuff on the on the JVM, which had a million different Jars that all...

[Richard] Oh, yeah.

[Marc] You know, so I built stuff on all these frameworks and, you know, and then there is ORMs, and that was a big movement. And it's just like... and then WordPress too, where it's just like, all of a sudden, it just generating a thousand SQL queries to just load this one page. And, you know, just every environment, I can go through on and on and on every environment. It's just like, at the end of the day, all you really needed to do in those situations was write a couple lines of SQL. And, you know, I'm not a SQL master, so, you know, I'm probably a bit of a a hypocrite there, but that's why I rely on folks like Brent, our CTO to, like, write the optimal SQL queries. But I recognize that, you know, you can write the right query to get the right data and then just render the page versus, you know, having these ORMS spit out now I need this data and this data and this data and this data or, you know, and then all of a sudden, let's put GraphQL on top of that. And now it all spirals out of control because you can endlessly, like, nest these things and and get, you know, it's just Yeah. We adopting tools more and more and more tools to, like, patch the problem when the problem is just ultimately, at the end of the day, what is the problem that you're trying to solve? And what is the minimal amount of code that needs to be written to to solve that? Then let's talk about the trade offs as we're building it, you know, as a team. And and so, yeah, at the end of the day, it's just it comes down to communication, what's the problem and what what do you need to actually solve it?

[Richard] Yeah. I love that. That's a that's a great, like, philosophy feel like that, what's the minimal amount of code I can write to solve this problem? And, I mean, I think some might take that to be like, oh, so that so that means I need to grab a huge dependency and then that will let me minimize my number of lines of code. But, like, I would... I would take that a step further and say, like, what's the minimal amount of code I can write without bringing in a dependency if I can avoid it. And if there is a dependency that'll, like, save me some code, why don't I try, like, writing it first and, like, get partway through it and see if it's, like, oh, this is gonna be a big project unless I bring in the dependency. You know, like, my my threshold for adding dependencies has definitely gone up over time, like, the more time I've spent with programming.

[Marc] Yeah. I'm glad that's the case, and I think that any good senior engineer or or team lead you know, I think eventually gets to that point where it's like they start squinting when the new engineer says, you know, Solid is the next thing or or whatever the next framework is. Like and and a lot of times, you know, we were we were like that when we were young too. So or, you know, young in terms of engineering. It's like, right, you grab the next crazy whatever, you know, in the next, you know, wild tool that you know, has dropped and and promises to solve all our problems. But, you know, it's just... it's just another day and another hype cycle. And it's... it's, you know, it's fun to jump on the hype cycles and and see what a new solution has to offer. But a lot of times, it's just the same patterns rinse and repeated throughout the decades. And it just seems like those cycles are now going faster and faster. It's... it's, like, it used to be, you know, a lot longer before, you know, big cycles – hype cycles happened. Right? And the hype was bigger. And then now it's just like, as the communities and social media and stuff gets fractured into these smaller communities, now the hype cycles are... it seems like faster together, and and now it's like, yeah, there's a new new framework, new tool, new library, new language, new whatever. And it's like yeah. I mean, it's fun to play with new things for sure. I'm not gonna... I'm not gonna disparage trying new things. Like, definitely... explore. But at the end of the day, like, I think when it comes to building a production system that's going to stand the test of time and deliver real business value. It's time to think about you know, what is the maintainable path, and what is the performant path, and what is, you know, what is the... you know, what is the... the... the thing that's gonna get us all writing better code and communicating and writing better documentation and these kinds of things? Like, these are... these are the things that are going to, you know, ultimately make us all move faster together and, like, have less battles. Like, we shouldn't be battling over frameworks. We should be battling over, like, what is the...

[Richard] Business problems. Yeah.

[Marc] Yeah. One of the business problems. And what's the architecture we should build in order to solve that.

[Richard] Yeah. Speaking of documentation, so I had a related experience. I was... I was building the, like, docs site for rock. and, like, this is something that's... it needs to be kind of flexible because it's not just, like, standard library docs, but also there's, like, a command you can run to generate docs for your own, you know, code that you're writing and, you know, like, it generates it from the the source code and everything. But I was just making this mock up of, like, okay – what do I want the HTML CSS JavaScript to look like? And basically, it's it's all static content except there's a little search bar on the side and you can type that in to sort of like filter all the module names, based on, like, whatever string you typed in so you can, you know, narrow it down more quickly and not have to, like, hunt through the whole list. Really basic thing. And I was like, okay,  kinda like what you said, what's the simplest thing that will work? And I was like, no dependencies, no, like, obviously, like, someone's like, oh, surely you're gonna bust out Elm for this. But I was like, well, let me just I don't think this is gonna need that. Like, this is just gonna be a really, really basic thing. Let me just do it the obvious way. And so I in part was thinking about this because couple years ago, I read about this idea of, like, what if you just disable JavaScript and try using the web and, like, everything will either load much faster or not work at all. And sure enough, that was kind of the experience. It's like a lot of a lot of pages just loaded instantly and then a lot of other pages didn't work at all, because they just needed JavaScript to function on the basic level. Now I was like, why don't I try and make this work as much as possible without JavaScript? And I'll just have this little tiny bit of opt in JavaScript for the for the search bar, and it'll just add a little bit of functionality to the page. It ended up being fifty lines of JavaScript to add that whole search bar. And that was it. It works. It's held up. It does its job. There's nothing nothing else to it. And those fifty lines are still, like, two years. Like, there's still... they're still doing their job and, like, I don't think it needs anything else.

[Marc] And I'm sure you feel good about that to this day. Right?

[Richard] Yeah. And something else is funny. Like, it's been a while since I've, like, written, like I mean, other than this. Like, I... it's it's been a while since, like, my job was writing JavaScript. Like, years since because I've been doing all the Elm for front end stuff. But I remember, like, reading about I remember JavaScript before bundlers and after bundlers. And, like, there became this whole big thing with bundlers where, like, first of all, it was necessary at the time because in order to get modules, you kind of needed that. Right. And, like, now the browser can do that, which is really cool. But back in the day, it wasn't it wasn't really possible. But one of the things that I was reminded of was, like, If you're just writing a dot JS file, I also didn't bother with TypeScript or anything. It's like, against fifty lines. Like, I don't I don't need any kind of a build step for that. I could just write the code and, like, keep it all in my head. It's not it doesn't even take up more than one screen, like, in my editor. It's just all right there. So with that small scope, there's just there's no problem that really needs solving by, like, additional, you know...

[Marc] But I would argue that if you take that mindset and you apply it to search and then you apply it to, you know, each piece of functionality in your site. And then you you just get this super powerful set of modules that you can apply everywhere because here... here's my example. So, you know, this Frontend Master dot com, you know, has been built with all these small modules with this mindset. And I sat down and I had to write the our customer dashboard, which is it will, like, our once you log in to the site, like, it's kind of an app like experience where you can, like, drag and drop things. And but... but the... the thing is it's like all of the functionality from the website like, piled into this dashboard. So you have, you know, bookmarks and you have pagination and you have, like, selecting your learning path that you're going through and yada yada. It's like a bunch of different pieces of functionality built into, you know, a dashboard. That's what, like, an app or like a web app or whatever that people think of. They think of these rich web apps that have all this functionality. And it was like, I sat down and I did the entire dashboard I'm not kidding you. It was, like I mean, he was, like, two hours or something or less. And it was, like, you know, I would have to, like, go pull up the code to find the exact amount lines of code, but it was just, like, I wrote, like I don't know. I think it was, like, sixty lines of, like, glue code. you know, going these, you know, basically, like, import the module, apply it to this, import it the module, apply it to this, and import the module apply it to this. It was, like, all of the functionality in the site just worked, you know, on this dashboard. And just a couple of lines of code. And... and, you know, I pulled in... I did pull in one dependency for the particular, like, how you kind of drag and drop. And, like, resort, reorder, it's kind of like a Pinterest kinda style. And I just yeah.  I put together a prototype using that. And I was like, oh, maybe I could write that myself. But I was like, oh, that that piece would take a bit longer and, like the business needs me on other things right now, and it... it works well and it and I used, like, you know, one of those micro libraries. And so it's, like, it still was very fast. But the the point is, like, I did exactly what you said, like, build the search, build the bookmarks, build the whatever with... with, you know, each one of these modules are tiny, tiny modules. And, you know, the way that we handle data fetching and all these kinds of things is, like, they're all little modules and then I just, like, wrote a, you know, a dashboard module that imported those modules and then initialized them and and sent them on their way. And they all they all worked and and they're all fast and super snappy. And then, you know, the data... the data layer module, like, you know, handles all the data fetching, and so all the other modules use it. And it's just like, it's beautiful. And I love... it just makes, you know, and that's why I asked you, like, did it feel good, you know, to write those fifty lines.

[Richard] Yeah.

[Marc] And and looking back at them later, and I just I want engineers to have that feeling of like, wow, I feel good about this. It's like not loading people's browsers up with a bunch of garbage. It's just like, it feels good from an engineering perspective because you wrote the code, you know how it works, you can modify any of the modules or architecture if you ever want to. And, you know, there's this one bit of code that... that's a dependency. That if I wanted to, I could just sit down and write in a couple hours, you know, and rip it out, which I've done, you know, over over the years. It's like, there was one thing that, like, made our... our, you know, these, like it kind of, like, revved up or it kind of works like a it's an animation that kinda works like a the dashboard of a of a sports car where where it, like, revs up. So the the learning path or whatever.

[Richard] Cool. Yeah.

[Marc] And, you know, I originally kinda built that. I, like, pulled in a library for it just to see, like, how I wanted to look and feel. And then, you know, I just replaced all of that with I think it ended up being five hundred lines of code, and it took me, like, an afternoon but I just used, you know, pure SVG and HTML. And then I... the JavaScript took a bit of code because there was some, you know, some easing and I had to, like, count up from zero to a hundred and back to zero and do it in a performant way and all that kind of stuff. And so it was request animation frame and... but the fact is, like, I know all the browser APIs. I know how SVG works. I know how request animation frame works. I know all the stuff works. you know, and I was able to, like, assemble this pretty complicated looking, like, you know, widget or whatever and and just such a few lines code, and I feel good about it this day, and it it just it just works. And it will always work in the future. It's like, sorry to keep going on another rant, but I built this very large application for a furniture company, which... which is you can assemble these custom sectionals. I believe I can say it publicly, but Roman board, you can kind of like pull these... and these are like these are the models that they they send to SAP and they, like, manufacture these parts. And, like, I was able to take their source files and, like, export them to SVGs. And then I built the entire UI on SVGs. So they've been using this thing forever because they can, like, develop a new collection of four thousand products and just export them to SVGs and, like, my system is flexible. You just mark up, you know, the rules of how these things connect. And they just... you know, they like, it just works. And so, like, I built it all on SVG on you know, and and at the time, Android didn't support SVG well, the Android Browser. But because I used browser standards, and I was like, well, the product requirements, was it only needed to work on iOS devices because they were using -- Uh-huh. -- these iOS devices in the actual stores. And so it just needed to work for iOS. But now, like, over time, browser support has actually gotten better. And so instead of degrading... my app degrading over the years, my app just keeps getting faster, faster, more browser support, and you know what I mean? It upgrades over time. It doesn't degrade. Like, there's no NPM modules that that team has to you know, this maybe someday there'll be some engineer over there, like, oh my gosh, he's talking about that code or whatever. But, you know, if any engineer over there pulls up open that code, like, I'm proud of that code. And, you know, I'm proud of that code to this day, and it just keeps working on more browsers and getting faster. And now it works on Android, now it works on... across all browsers.

[Richard] Was that generating the SVG's server side or client side in the browser? So the export process was using... I can't remember if I was what I was using to export from. I think they were, like, in those SAP, like, inDesign documents or I don't know how they they they have factory parts. Right? And -- Yeah. -- the process is if there was a tool I use or if it was... Node didn't exist back then. It could have been just an Adobe product that just converts it from the specs, the blueprints, to the SVGs. And then, you know, my tool just imported the, you know, just use the SVG clientside.

[Marc] I see. So so somebody's just like, they just like press some buttons in a tool they already have. It's not even like about as a server. It's like it's like, no. You just use the software you already have and like press some buttons and then send this put this file in this place. and then it'll take.

[Richard] Yeah. And then you basically mark up, I think, like, you know, on the in the database. They have, like, this product has these connect rules that I built, and then, you know, the interface just builds itself. Right? So we're, you know -- ah cool -- there's, like, a sidebar with all of these different SVGs, which are the parts that are, like, straight from the, you know, factory onto the the website. And you can drag and drop these onto the stage and kind of build your sectional... your custom sectional and all the, you know so, yeah, obviously, pricing and all that... those kinds of things like were done by the back end team. But it was a super fun project to to build and and, like I said, there are so many cool things back in the day where it was like, you know, that was the example I was mentioning with time travel debugging. It's like, they're QA team would tell me that there is a bug and, like, connecting these pieces and then they would do something weird or whatever in a certain way. And I could just have them export all of the steps that it took to hit that bug. And then I could import it into my test suite, all of those dates, and I could just play through... Okay. There's the bug. Okay. And then I just write the code and and that entire glob of state is just in my test suite. And so now everything in the QA, every bug that QA hit, I would just do app dot export grab that in all those blobs of state, throw it into my test suite, and then just keep, you know, keep fixing bugs and and moving on until there is nothing. until they couldn't produce a bug. And then now it just works for, you know, thousands of parts and, you know, it just works. It's like all of the things that QA ever found, I was able to just ingest them into my test suite. And then now I have, like, a full library of of tons and tons of real world use cases where QA is trying to do certain things because they had a great team over there of... of QA that would, like, you know, find these bugs. And so, yeah, just like building things a state and then transitions between globs of state. I think you you were talking about it in your episode with Anjana Akhil about you know, how Elm works or whatever, you know, that that you have globs of state and you transition between them. And that's that's how I built that thing and, you know, I built it you know, honestly, I used some of that money to bootstrap Front End Masters. So that's back in, like, 2010, 2012 I was, you know, doing that stuff.

[Richard] I think that's really interesting how, like, how much leverage you can get out of, like, different tools, and they don't have to be off the shelf tools either. Like, that's the system for, like, time travel that you built just based on the fact that the way that you architected the application was, like, as a series of state transformations so you could export it as a data format and then have, like, QA do that. Sometimes it's, like, kinda difficult to tease apart, I think, like, what are the benefits you get from an individual thing? Like, people look at, like, Elm or, like, React or Like, there's a new bundler out there called Vit, but it's it's spelled like Vite, but it's apparently French.

[Marc] Vite... Vite,

[Richard] It's Vite.

[Marc] Yeah. Vite.

[Richard] Wow. Okay. I have to go on a slight tangent here. So, like, that is astonishing to me because I remember hearing about this thing and I was like, oh, it's Viite. Cool. Let's let's this white thing. And the first thing that it says under its description is like pronounced and then it's a pronunciation guide. And I was like, we're off to a bad start if I haven't even read the first sentence of your self description and there's already a counterintuitive UX thing going on. Like, that is not, like, pick a different name. Like, if you need to start by explaining how to pronounce the name in in English and like you're an English product, just... if you're French, okay, fine. Like, I got it. but it's not a French product. Anyway.

[Marc] I don't see that on their site now. So to be fair to them, like, it seems like they...

[Richard] Okay. This was at the time or maybe let's see. But Evan Vue, you know, who created Vue, created Vite. And...

[Marc] Got it. So he definitely knows how to... that man definitely knows how to manage a community and make them productive together. So I would definitely not bet against Vite over.

[Richard] Sure. Sure. Alright. But like that,

[Marc] Nothing superficial. But I get your I get your general -- Yeah. -- point.

[Richard] Like I said, it was a tangent. Right? But Yeah. So I have heard lots of good things about it. Like, it's really fast, etcetera, and, like but one of the other things that I remember, like, thinking about when I was doing this, like, fifty line of JavaScript thing was was, like, like, hot module reloading is, like, a big selling point in, like, modern JavaScript bundlers and that's almost as good as just not having a bundler. Like, you there's no what do you mean like hot module? Like, I just hit save, and then that's it, and the browser takes care of everything I guess you could argue it's better if you've got the little, like, automatic snippet that, like, reloads the browser, but I've always had feelings about that. So when I was building this... this small thing, one of the things that sort of came to mind is like I really like not having NPM anywhere in my, like, project. Like, just no NPM. Like like aside from, like, dependencies in general, like, NPM in particular, there's, like, a lot of security problems. Like, when you install something by default, it gets to run arbitrary code on your machines, which means and it's also, like, the biggest repository, which means it's, like, the most likely that someone's gonna try and exploit that. There's just a lot of, like... and and you can you can configure something by default to make it so that it doesn't do that anymore unless you explicitly authorize when you're installing, like, to to give us a good permission to run arbitrary code in your machine, but a lot of popular packages don't work if you have that enabled as I've discovered over the years. So I don't know. There was there was definitely something... What you're saying resonates with me in terms of, like, I'm just gonna do stuff myself. I'm just gonna... I'm not gonna, like, bringing a bunch of dependencies. I'm just gonna write simple obvious stuff. Having said that, I have also definitely had the experience of... even when I was, like, writing my own thing with no dependencies and I liked what was going on in the small, I've definitely had code bases like get out of control where, like, after a while, I just... even though I was kind of taking that approach, like make small modules, try to keep like... think a lot about the architecture of them. And in some cases, even, like, re architecting them from scratch and then running into different problems later on. Maybe that's something where, like, over time, I would just get better as a programmer and, like, wouldn't need, like, an Elm or a Typescript or something like that, like, to to help me out with, I don't know, giving the code base manageable, but and I also would say that it it depends on the type of project, in the sense that, like, when I've had a lot of different pages and each page has, like, maybe a couple of different things going on versus if I have, like, like Dreamwriter is one that comes to mind versus this, like, single page. And when I say single page app, I mean, like, single route app. It's just like there's it's all one giant editor for, like, writing novels in. And there was just a ton of stuff going on on that one page because it was really kind of like a native desktop app just like in the browser. Like... like a a Google Docs would be like another, you know, thing like that. And we've had a couple of things like that at work where justeven within a single page, there's just so much going on. There's just tens of thousands of lines of code of, like, application logic, not even dependencies. And for those cases, I definitely have appreciated, like, having something, like, bigger helping me out, whether that's my favorite, obviously, is Elm, but Even like, I think uh React something might have helped me out.

[Marc] Well, I gosh. If you wanna open up the can of worms...

[Richard] Let's do it. Let's open it up.

[Marc] So we had another debate in the company around... there is a a large dashboard with... or there is a part of the site where, you know, you have to... there's a lot of settings and stuff like that and it -- Mhmm. -- we had a debate, it's like, they started... like, one of the engineers love him, but he introduced the framework because he said, well, there's... there's all these forms on the page. And there's too much state, and we need a tool to manage state and reactivity across all these different forms and stuff like that. And I said, I just, like, like, I got a little bit upset, walked away. And then, you know, I tried to, like, calmly say, like, I think at some point, I just let the cat out of the bag and just was like, why in the hell is this a single page application? Why? Why is this a single app a page application? None of this should be complicated. This is just like... think about it. Like, there's a couple different settings that you have to set across the app and across your profile and about, you know, whatever. It's like, none of this is hard. It's all easy. Like, just -- Oh, I see. -- here's...