Kelvin Omereshone is the lead maintainer of Sales.js. In this episode, they uncover the complexities of the "Boring JavaScript Stack" and its implications for building full-stack web applications. They engage in in-depth discussions on MVC conventions, data modeling, front-end and back-end integration challenges, and the role of frameworks like React and Vue in UI development. Kelvin shares his insights on the "Boring JavaScript Stack" and its aim to simplify development by leveraging stable technologies. Alongside these technical discussions, they share personal anecdotes and delve into topics ranging from aquarium hobbies to drone certifications. Join them as they navigate through the multifaceted landscape of JavaScript development

 

AJ_O’NEAL: Well, hello, hello, everybody. And welcome back to another exciting episode of JavaScript Jabber. Today on, well, today on our show, we've, we have, we've got your hostess with the mostest that's me and Joe Neal for now. Yo, yo, yo, coming at you live and all that stuff. And then we've got Steve. 

STEVE_EDWARDS: Yo, what up from Portland. 

AJ_O’NEAL: And then we have our guest today, Kelvin. 

KELVIN_OMERESHONE: Hey. How you doing? No, we from Nigeria. 

AJ_O’NEAL: All right. So let's jump right into it. Who are you? What makes you famous? Or if not, what makes you famous? What do you want to be famous for? 

KELVIN_OMERESHONE: Okay. Thanks, AJ. So I'm Kelvin. I am the lead maintainer of SalesJS and I'm currently working on the boring JavaScript stack. Hopefully, the name is not a turn off for most people. I aim to make it a go-to stack for beautiful stack web applications in JavaScript. 

AJ_O’NEAL: So how long have you been maintainer of sales? Did you start it? 

KELVIN_OMERESHONE: No. Not at all. So sales was created by Mike McNeil. I became the maintainer of sales June last year. 

AJ_O’NEAL: Cool. Why did it change hands? 

KELVIN_OMERESHONE: Okay, so Mike is still the BDFL, you know, and but currently he has his hands full with being the CEO of Fleet Device Management. So Fleet is a security and endpoints company based on OS query. So they just help you get. Visibility is into your computers and all that stuff. So, um, the sales from up there, more hands on maintenance, which is where I come in to like lead the framework. Yeah. 

AJ_O’NEAL: Okay. And for those that are not familiar, BDFL is benevolent dictator for life. So the person who gets to call the shots. All right. And then what is boring.js because that kind of sounds like a generic term like vanilla.js. 

KELVIN_OMERESHONE: Yeah. Yeah. So the full okay. 

AJ_O’NEAL: Go ahead. 

KELVIN_OMERESHONE: Yeah, for sure. So the full is it's it's kind of like a mouthful. So it's called the boring JavaScript stack. And it's my own no like I just think that in the JavaScript space, we sort of have a lot of excitement when it comes to building full-star JavaScript apps. There's so much going on, but in terms of actually putting everything together, it's sort of like not complete. So the boring stack was started I think back in 2020 where I was like, you know, the old promise or the premise of Node.js was that we can view the JavaScript across the stack, right? But what we have to do most times when you want to build single page applications, you have like a single page app, which is like a, like his own repo and everything. Then if you, if you're going to do anything sophisticated, you're going to leave like an API, so that's two separate JavaScript apps that are in separate repos. And of course there's a lot of things. We have double routing where you have to route on your API routes, then your client side routing, and that's just scratching the surface, right? So I wanted something where I could all this together, still have a single page application, but with the more server centric flow, right? So that means no more loading spinners, no more double routing, and a bunch of other things I saw for us. So that was it. Like that was the old inspiration and I get to use it in my own platform and then I figured out, you know what, at first I called it like the VIT stack, which is Vue, Inertia, Tailweed and Sales, but it supports React as well. So that's this reads and sees, which just doesn't make any sense to me. I was like, you know what, let's call it what it is, which is like, it's not. Exciting is just boring and it gets you move really, really quickly. So hence the name, the boring JavaScript stack. 

STEVE_EDWARDS: I've got to say you preach into the choir because I'm looking at the repo and I have been preaching about inertia tailwind in view for years. Oh both here and when I was doing the views on view podcast, because I have talked to Jonathan Reinick, the creator of inertia twice on this podcast. And I had been using inertia and Tailwind in view for an app that I've been writing for last year and for other stuff. The difference between what you're using, what I normally use is I use Laravel on the backend. But yeah, this this stack is the bomb. And I understand what you're talking about, double routing. It makes it really nice because inertia handles all that and you only have to define your route once on the backend. Everything gets passed through those. So yeah, it's, I don't, I mean, I'll take, I don't know if I would necessarily coin this as its own separate stack, simply because the point of inertia, is to plug and play your backend with your frontend. And I know initially, when I had first talked to Jonathan, Node was not an officially supported backend, supported by Inertia, but the community had come up with plugins to use Node. So I know like, I think Ruby and Laravel were the first backend that were supported by Inertia out of the box along with sales, excuse me, with Svelte of you and react. 

AJ_O’NEAL: So walk us through the stack. What are the pieces and what, how long have they been around and what's the goal of each? 

KELVIN_OMERESHONE: Yeah, for sure. So one thing I like about the stack really is that I kind of see it as basing a lot of cool technologies stable and most boring versions. For example, we all like React for GXS, right? But most of the time when you get to like do full stack, okay, not full, I don't really use it, I use Vue. But the point is, at the component level, React is stable, right? And it's really good for what it does, except when you want to layer stuff like routing, all the meta frameworks and the work, it just gets out of hand. So my thought process was, you know what, let's just take the component, which is made possible by inertia, right? And just let you build your pages with React components, which are just as view, which is a single file component and it's built on stuff. And let those be the pages and a more server centric web framework like sales, which is really old. So this is like what, 12 years or more now, which is really old and just take the stable versions of all this tech. And of course, still in CSL, which makes styling super good and just give you an holistic monorepo like all a monolith where you just build full stack JavaScript application. So there's sales, which is going to control everything as the web framework. There's inertia, which pieces your view, spelled or react components together with sales. So why I think is it makes sense to make it his own stack because this is just like the earliest version of it. The vision is to get it in such a way that for you to build the pages, the way your users are going to consume it. For example, I don't think your marketing page should be a single page application because you literally don't have any JavaScript that should run there. So with this stack, you should be able to use your JXS and still just ship or send back HTML at the end of the day. Or like what you do when you have a single page application with SSR, like there's no need for SSR in your marketing page really. So my thought process is let the dev use the DSL, which is the views, templates, the views components, reacts and just give them the option to build either apps or websites, but all in the same code base. 

AJ_O’NEAL: You say, don't say no to chasing JavaScript trends. 

KELVIN_OMERESHONE: Yes. 

AJ_O’NEAL: And then you've got view react and Svelter supported tailwind, et cetera. So what do you mean by say no to chasing JavaScript trends? When I mean, those seem kind of trendy, all those things. 

KELVIN_OMERESHONE: Yeah, not really. So, like I said, we know everything happening in the JS world, for example, now, when we have things with RSC, you know, the app router, like the NextJS or the Pages router, where there's just all these complexities that you have to learn in order to just ship your rectangles to users to do stuff with. What I'm saying is that you don't really need to go all that trendy. All you need is the component, which is the basic DSL of all this front-end framework. Leave the whole state management jazz because in the boring stack, you don't need the state management at all, right? You don't need to know sustained or whatever you use for state management. Leave all those trendy because there's a more stable and boring way to do things that actually gets you moving really quickly. So those are the trends. So the frameworks, they are really boring at the component level. There's not so much you could do with JXS than just write it. But when you start adding all the trends on top of it, that's where you just get out of hands. And we've seen applications that are just terrible for these cases. Yeah. 

AJ_O’NEAL: All right, I get that. 

STEVE_EDWARDS: So you mentioned state management and there's no need for state management. I'm curious to see why that is. Or why you say that is because I have found niche cases where yes, it is still. But I'm curious to see why you say it's not even needed with this stack. 

KELVIN_OMERESHONE: Yeah, definitely. So most times, why you need a state manager, especially when you're building a single-page application the normal way, you often want to sync states across your app, right? Because the front end is separate from the backend. But with this stack, the only source of truth is the state from the backend, right?Ncan be cached, of course, to make it really fast. So there will be no need to, like the way I've been building apps and I've even seen this, even I think Remix also have this as well, where there is no state management, you don't need any state management. So I'm not talking about use states here, I'm talking about state management libraries, right? Like the source stand, like in view with Pinya, you don't really need to synchronized states in the front end because again, it's server-centric. So all the state comes from your backend for your database and it just gets sent to your front end as props or as shared data all facilitated by inertia. Yeah. 

STEVE_EDWARDS: Okay, so basically the premise that you're saying is that, I mean, is that because, I don't know if it's because of a speed issue, because of the source of truth, you don't need the state management. Now I ran into a case using inertia with you with Laravel where I had, I was dealing with the calendar app and because of the hierarchy of, of components, um, without state management, I would have been having to either go back and forth to my server or pass props from A to B to C to D. And granted with VIA 3, you can use, um, inject inside the components, what are they called, provide inject, I think. You can do that. But for Jonathan, state management isn't prohibited. You can use it if you want to. And I think there probably are going to be some cases where state management needed. But to your point, yeah, you don't need it to the extent where you're just using a REST API from the front and the back end. Now I think what you should probably do for those that might not be as familiar with inertia as you and I are, is to explain how exactly inertia is working and what it's how it's working behind the scenes that invalidates the need for state management. 

KELVIN_OMERESHONE: Yeah, definitely. Thank you, Steve. So the old premise of inertia is that it acts like a routing library, right? Sort of like view router or the, or anyone using React land, right? But it's kind of interesting the way it works. So two things you have to know it has a protocol, which is like a page. So there's a page object that initial expects to get sent from the backend. And that page object has the name of the components and prop, which would be like the prop you want to pass to your component. So for example, if on the page we have like an initial link, if you click on that link, inertia is going to intercept that click so that you don't make a full page request, but you're going to send an Ajax request to get that page object. So once you get the page object, it uses the name of the component to find the component in like maybe a pages slash index.jxs and then swap the current page with that page as well as passing the problems that the page needs. Just like that. Okay. So doing so you find that you don't need like a loading screen, right? Because as soon as you click the link, it goes to the backend, it gets the pages component and also the prop. So it's, it comes with the data it needs. So you don't have to make an extra request to get the data. So that's at the high level. That's how it works. And of course there are headers you have to send, which is all going to be taken care of by the server-side adapter that you're using. So I wrote the one for sales. So there's also official one for Laravel and of course Rails. 

STEVE_EDWARDS: Yeah, so basically what it's doing is this, the best way I've heard it put is that it's hijacking the request from the browser. And instead of doing a full page reload, it's just passing the data back and forth so that your browser isn't doing a full load. And so when you're writing your backend, no Rails, Laravel, what have you. You say, okay, in whatever your function is that's saying, okay, return this value, you're telling it, okay, this is the component that I want you to pass it to, and here are the props that go to this particular component. And so then in your front-end component, you just expect your props as you normally would from anything else. And that makes it very much a lot quicker because you're bypassing the page reloader. It uses, if you look in the inertia docs at inertiajs.com, it talks about the headers that it uses to determine what's going on. And then even within, you know, if you're within a component and you wanna click a button and you want to, you know, just go to your backend and get some data without reloading a page that has some helper functions like visit, where you can say, okay, go to this URL, it calls your method, you do what you need to do and then it returns it. So it makes it very quick because of bypassing the whole page reloading. That's really all it does. And then, not sure if we covered this in detail, but your routes, you're only defining your routes in your backend, and it's just using those. If you go to the docs, it just says, yeah, you just define your routes in your backend, you call them from the frontend, where normally with like a Vue SPA, you would have all your Vue router configuration where you got to define your routes, and then it calls this endpoint, so on and so forth. So it makes it much neater and cleaner. And that you're only finding your routes in one place instead of, instead of two different places in both your front end and your back end. 

AJ_O’NEAL: All right. So what are some other things that you wanted to, that you want people to know about the boring stack, either implementation details or philosophy? 

KELVIN_OMERESHONE: Yeah, definitely. So the first thing is that you don't need to um because in the javascript cycle of new trends and new flow if you already know vue and um react was built and you like the component because i find that most times what we like in these frameworks is the dsl that they like that they let us write our uizing right so if you if you want to shut out the noise that you have to piss yourself because why I liked sales back in I started Node.js with Express and it was a pain to always have to go find everything I need in order to build an API in Express. I have to piece everything together. So I found sales and it just have everything you need. So there were a lot of conventions that work with the MVC. So that same thing that sales let me do, which is the move really quick, that's what the even if you are a new, but you already know components in whatever UI frameworks you like, all you have to do is to use this stack, write your components like 60% of the time, because your backend just add like the data layer, right? Just sending down a page with the prop, then you do everything that you normally do in your components. And it's just a bridge to work have a demo of the stack and they really, really love it because of how simple it is. And it takes a lot of stuff. Like cause is no longer an issue because you're backing and you're front-end at the same page. So you don't have to worry about all that. All right, so the old reckless hell of cause is no longer your thing to worry about. And it just sort of like makes sense, right? Like when you use something that is this holistic, like I said, no loading spinners. Like I've had to deal with that where why is the page loading and I still have to go fetch data for it again right like give it this empty shell which is your SPA promise you know just load the page and get the data but there's no benefit of the page to the user if you're seeing a loading screener so the page load first of all with the normal browser load that's some seconds then you now have to go load your own it's just too much so I feel like you want to keep things simple keep things really really fast you should and again, you are not constrained from not sending JSON over the wire. You can also do that because it doesn't constrain you not to do that. So you could still have pages sent the initial way and also go fetch your data with JSON if you want. 

AJ_O’NEAL: Okay. So two questions. I'll start with this one. I mean, I, I hear both sides of this argument about should your application use its API? Are you going to export an API to customers? And then if so, should your application use your API? And I've kind of always been on the side of yes, your application should use your API. And my reasoning for that has been that when people design like most people don't have experts on the team, right? And when people are designing their front end and their back end together, then everything starts to look like the front end, right? So when there's a form on the front end, then the data model starts to look like that form and the database table starts to look like that form. And then when it comes time that you need to modify things or add an API or expose a customer integration. You're just screwed. And I, I'm curious with, with this stack, are you advocating it to people that are going to be exporting things that are going to integrate with others? Are there some guardrails in place to, to help people fall into the pit of success in terms of data modeling, uh, or, or is it really just for kind of like the JavaScript versions of Rails where it's, you're going to create a cookie cutter sites and you, you're not, you're not really going to be, you know, exporting an API or something. You're just building a, like, uh, like it's more customizable than WordPress, but you want to do it in JavaScript rather than in Ruby on Rails. Like, uh, I guess that was a lot of stuff there, but yeah, feel free to pick it, pick at any of that. 

KELVIN_OMERESHONE: Yeah, definitely. So as a for sales mix for really good framework for building APIs. Like I do know Postman and PayStack, they use it. Postman for microservices, then PayStack for like public facing API. You can't build an API, right? And the thing is, what I've seen, and I think a couple of us, so I used to be a very good advocate for REST APIs. I still am, but the truth is for most app, you won't need to expose the REST API. Sometimes I hear people say like, you know what, let's use the REST API now and use it so that when we have to expose it, it's just there. But the truth is, your API that you use for your app, a lot of the time, if you want to expose it, it won't be the same. So I've seen this work, what's like when teams start to be like, you know what, let's build an API so that we can consume it. And of course, expose it. It's not gonna be the same thing. So the use case is never the same. That's when we have terms like backend for frontend and you start having to modify different parts of the JSON you're sending back. So to your point, this stack is mostly for full-stack applications. Most apps are okay being full stack applications, especially if your client is on the web, you don't have to build an API, which is the entire idea of of inertia, which is like, you don't need an API, but if you must, you can expose your API routes. But I wouldn't say that the same API routes for your own private use, the same you're gonna expose, it most likely doesn't always work out really well. 

STEVE_EDWARDS: Deep thoughts, AJ. 

KELVIN_OMERESHONE: I know, right? I think the whole REST API talk, right? If you could use your private one, I use the same one. Have you had to do that, AJ? 

AJ_O’NEAL: So I just think that if the data is modeled well, well, then this comes to the SPA versus the server-side render issue. But I think if the data is modeled well, then you should be able to use it externally and internally. And yes, you may need to tweak it for the internal use. But the- But then you have to, you have to model it well. And if it's modeled well, I mean, but this, this, this is the whole thing of like the PHP style where you're exporting the data specifically for a form view or a gallery view or whatever, versus you're exporting information. Like, are you exporting a view as JSON or are you exporting information? If you're exporting a view as JSON, then it's not really an API, it's a particular view of the data. It's not about the properties or the values of the data or the relationships of the data. It's about, I wanted to show this gallery with this pieces of information. You're selecting that, right? And that's kind of like the promise of GraphQL is that you don't have to make the decision. You get to do both. And then, you know, we saw how that turned out, but, you know, on the other side. If the data is not modeled to the UI, then if you're trying to do, whether you're doing client-side rendering or server-side rendering, then you have to have another layer that's going to consume the API, which I guess, you know, either it's the backend for the front end or it's the, or it's it's more sophisticated front end where you, you need to fetch a bunch of objects, you need to iterate through them. You need to attach some extra data for them. And so I guess, I, I guess. Maybe I think of a, of an API as being a little bit closer to the model with some of the business logic that needs to be done on top of it solved. And a view is more like what, what's going to be templated. I don't know. I don't know where I'm going with that. I'm just thinking out loud. 

KELVIN_OMERESHONE: No. Yeah. Like I get the thought, but I think when we go into real world, we sort of like see, so you just painted an ideal API agent. But if that was the case of every app, we wouldn't need GraphQL or all the different solutions we have tried to come up with just for like our UIs to get just the data it needs. So the whole over-fetching and under-fetching thing, it gets to tell us that that ideal API is not really what the end consumer would need. So if I just send, you know what, this is my generic API, which is tied to the data and it's modern really well. My UI, we have to now do some extra work right to get just the data it needs. You know, like, okay, let's put a GraphQL layer on top of this one so we can now pick this. So with the boring stack now, the UI only gets the data it needs. And this is suitable for just web apps. So instead of you thinking of, okay, GraphQL so I can hit pick, so the page will only come with the data that that page need. So there's no over-fetching, there's no under-fetching. You're only getting the data you need. 

AJ_O’NEAL: So we did have a couple of questions here. I'll go ahead and field, which I think you just answered this one, was to confirm the boring stack compiles the page with the props you passed into it, right? 

KELVIN_OMERESHONE: Yes, it does. 

AJ_O’NEAL: So it makes an SPA look like a static site. 

STEVE_EDWARDS: If you look at the source code of an inertia page, what you'll see is there's a big huge data attribute of the top three page that has all the data that's been passed into it as props. And that's how it's storing that and accessing that. Yeah. Um, I'm not, I'm not sure I understand what it means, what makes it look static because it's still because the, what I guess, because the data is passed in before the page is actually compiled. I mean, you can be very easily, I do a lot of really cool dynamic stuff with the page as well, once it's loaded, you know, where I just send, you know, a little bit of data back to my API and it passes it back and I only update that certain section of the page without the whole, you know, browser reload, which is part of inertia. And there's some stuff you got to do. There's some really cool props you can pass that says, okay, only get me the change data or only get me such and such data. Yeah. So it's doing the absolute minimum in terms of traffic between the front and the backend. 

KELVIN_OMERESHONE: Yeah, definitely. And to add to that point, sometimes in the old traditional way, you often get to like if I submit a form or I like I want to reload the page back after like an update you just get everything back right like maybe I have like a course to speed and I just edit just one course when I submit the form with my agents and everything the the data would like just send back the gfb right but with this one with this type which is really cool and is powered by inertia what you want back. You'll be like, okay, this course in this process list was the only thing changed, return it back for me. Right. So it's, I don't want to call it giving you the power of GraphQL, but it's sort of like you have control of what gets returned back from the server with all the APIs that inertia is going to provide for you. You could preserve scroll and you could do a ton of stuff that is really, really cool that we can't really actually get into because it's just It's simple It's a routing layer, but it has so much power. 

AJ_O’NEAL: Well What are some other what what are some other questions that we we should be asking you 

KELVIN_OMERESHONE: No, yeah. Yeah, so to Steve's point, so um earlier on he mentioned that he's not sure why this should be zonstack, but i'm making it zonstack because at the end of the day, my vision is that inertia is not just, so not all pages are made equal, right? So in an SPA land, because you are using React SPA, everything should be a React SPA. Because you're using Nectar, everything is SSR, if you want that, or the ISR and everything you have to do. But in my world or in the Boeing staff world, we know that not every page should be a single page application should have SSL, right? So we are using inertia to power the single page apps, right? And there is something I'm currently working on, which I've actually mentioned a little bit before, which is even now in Salesforce, we use EGS for templates. But I feel like having to learn to DSL to author pages, people don't like, I think me myself, I don't like EGS at all. I don't like the syntax at all. So my thought process is what if you can use the same GXS you write for your client-side app and also your backend views in GXS as well. So that for pages like the home page, the about page, the pricing page or pages that don't need JavaScript at all, you can still write the same GXS, but when it gets axed for like by the user, you just send them HTML, which is SEO friendly, is does not have anything to do with the user in terms of JavaScript's node. All right, so this is a key piece of the boring stack which is still being worked on today because I feel like you can have this hybrid app, but the same code base, the same DSL you are writing, all you have to do is to know that, okay, for this, this is, so my slash dashboard is my single page app. My marketing page should be HTML because that's what's value you get from the marketing page is more content, right? Content and SEO. So I saw this talk from someone at Netflix where they had to remove React from the marketing page and then saw an increase in conversion because the whole hydration was taking too long and people were actually clicking away. So just imagine you are still using React, but you are sending down HTML by default. 

AJ_O’NEAL: Yeah. Yeah. I mean, I that as somebody who is a big fan of scraping and being able to get to data when no API is provided, I really do hate react sites because there is no data on the page. And it is yeah, it's it's really frustrating because there's so many sites out there that have useful information. It's like, I just want to automate something off of this. And they, you know, they haven't bothered to create an API for it. And, and so, yeah, from, from that perspective, whether it's because the, the search engine is going to be able to understand it better or the GPT is going to be able to understand it better, or just because I know that a lot of people don't like the idea of somebody scraping the content off of their site, but I don't know, I hope if you've got valuable content and you're not, you're not in a business where you're creating a product out of the content, particularly like just make it in a format that's easy for people to consume. Otherwise, I guess, why are you, why are you creating the content in the first place? Some people should be able to use it in some, some way. So yeah, I really like the idea of for static pages, render them. So, so does this, does this have some sort of mechanism where you can say. Okay. These pages are mostly static. So treat, treat them as such. And then these pages are mostly dynamic. So, you know, these pages are more component heavy and these pages are more content heavy. Is there a differentiation between the two or is it just, you're always getting the static benefit by way of, you know, it's rendering things as the props are passed in. 

KELVIN_OMERESHONE: Yeah, so what's gonna happen is that there are gonna be two places you define your components, right? So now in the stack, so we have assets like JS and pages. So that page directory is where you'd find your XPE pages. Right, then if you want to define your HTML pages, which is still going to be in your components, you could do it in views. So we all know the old MVC, right? Model, views and controller. So once you define something in JXS inside the views folder, it's going to be compiled at request time and send back as HTML. So the only convention you have to know is in the views folder, you are only defining components that are going to be used as templates for your server-side rendering. And once it gets to the user, there is no hydration because you don't need it, right? It's just these pages are static, they are HTML, but just for your DX, you can still use the same components you are using for your single-page applications. So that's just the convention. Like I said, this part is still being worked on. And I saw Hono from Cloudflare, I think. Is it? Yes, I think Hono from Cloudflare. So it's a new framework. They also do this where you can write your templates in JXS. Yeah, so it's actually a very good and valuable idea. I think Netflix does it too. And a little bit of PayPal as well. So we can do this like for like since forever now, right? But with things like Next.js and Remix, it's sort of like I've been archived for you to just go use Next or something else. But I think those components can be really good templates if you just have the engineering to just make it really nice to use. 

STEVE_EDWARDS: Now for what it's worth, it's probably worth mentioning along these lines that, I know this came in later after the initial release, but Inertia has a server-side rendering capability. 

KELVIN_OMERESHONE: Yes. 

STEVE_EDWARDS: That's mentioned in their docs. So there's a whole page on how to implement it. But it does have that capability so that not every page has to be a JavaScript rendered template. 

KELVIN_OMERESHONE: Yeah. So the only difference with that one, with the SSL one, it needs to hydrate, right? So, you know, and for the server-side views that I'm talking about, it shouldn't hydrate because you don't need the JavaScript. 

STEVE_EDWARDS: Right, and even in Laravel, I know you can do, you can just return and, you know, you'd use a view, you know, and then you'd have your hard-coded HTML. There's ways you can do that, so. But the point is even with this, there's not every page doesn't have to be a dynamic JavaScript template. 

KELVIN_OMERESHONE: Yeah, for sure. 

AJ_O’NEAL: All right. Well, it sounds like we're kind of wrapping up here. I think we've covered a fair amount of the topic. If people want to learn more, or if they want to reach out to you, where should they head? 

KELVIN_OMERESHONE: Yes. So you could go to the docs for the boring stack, which is docs.salescast.com slash boring stack, or just do salescast.com slash boring to take you to the repo. You can also get the links to the docs. So if you want to reach out to me, you could join the salescast discord, salescast.com slash chats, or you could just tweet at me at dominoes on the square. Yeah, your questions. 

AJ_O’NEAL: And do you know about pics? Were you informed of that? We do a thing called picks at the end of the show. 

KELVIN_OMERESHONE: No, I did not. What's that? You have to feel me. 

AJ_O’NEAL: Steve and I will go first. It's just you pick something you're interested in or something that you thought was cool. Could be tech, could be a movie, could be some sort of article in a newspaper or whatever. You just pick pick something that that you think is cool. And then before I do that, Steve, did I do everything right? Do we leave anything off before we close out the show here? 

STEVE_EDWARDS: Uh, no, I think we got it covered. If we do remember something, it will be after we're done and we'll have to add it in somehow, I'm sure. But I think for now you're pretty good. 

AJ_O’NEAL: Okay. Well, I will go ahead and lead us off with a few picks. So as I mentioned last time, I have gotten into the aquarium hobby. And it's very fascinating because it's, there's a lot of technical stuff to learn and do some stuff that's pretty rote. Like if you learn how to do, I like things that are, that are functional from the perspective of if you do X, you get result Y and you get result Y every time. That is something that, you know, has, has drawn me to computers and programming. And I like to optimize things in my life. I will take the same routes on a road. Like my brain is like a reduced instruction set processor. I will take the same routes on the road. Even if I know a more efficient route is available because I just rather get better at these particular set of routes rather than every possible route. And I've got a buddy who, when he drives with me. He's like, Oh, well, you know, if you went this way, you'd get there faster. I'm like, yeah, but I'm just going to take state street or main street because. Because that, you know, that's, I just, I traveled the same roads. I do the same things. I even oftentimes eat the same foods. A very, very much, um, that I'm sure of. Well, it's, it's beyond habit. It's I am optimizing for fewer mental inputs. But this, the aquarium hobby kind of goes against that because there, there is no way to really jumpstart your aquarium. You, you can have anyway, you, there's, there's just a lot of levers and knobs that you have to learn and they're going to be different for everybody because your tap water is different where you live. The fish that you get might be used to different parameters. The plants that you want are different than the plants that somebody else wants. The type of things you're trying to combine in your tank to create the environment you want are different. And, and the ecosystem just isn't natural. You know, that these fish don't naturally to go together. These plants don't naturally go together. These fish and these plants don't naturally go together. And so trying to create a self-sustaining ecosystem is kind of impossible. Or at least there's trade-offs. There's, there are no solutions, only trade-offs that, that quote certainly applies in this case. Anyway, um, I, I didn't mean to go that much into all of that, but, but I guess it's just super fascinating to me because I'm trying to learn how to create the ecosystem that I want inside of this little glass box and it's hard to get the parameters right because they're living things and you can't just even even if something is generally true, the evolution that you're getting, like that, if you breed some fish, if you breed some guppies or you breed some Tetris or whatever, the the next generation that you're getting from what you bought is more specific and tuned to its environment. So the next generation is going to be different as you get more fish the bioload of the tank is going to be different, well, assuming that you're feeding them more. You know, at some point you can reach equilibrium by just letting things die. But then the problem with that is then the water starts to turn kind of a yellowy color like it is in real life in ponds and whatnot, because the decaying matter taints the water. But if you wanted to just let stuff die and grow and die, then things will reach an equilibrium in terms of, you know, the water can only support this many fish, it can only support this many plants only this many nutrients you can create a clued system like that but it's just it's super fascinating and so yeah i'll i'll just um i i just pick that as a general concept and uh it's i'm having a lot of fun learning about it i'm trying to get my wife into it a little bit she kind of will dip her toe into it with me and she's not as excited about it as i am but she helped me she helped me put together an aquarium last night and it's It's so I tore one down, I bought a $10 aquarium on sale and I tore it down and I built it back up. And I used a higher grade silicone and it's so crazy because there's like, there's like four millimeters of silicone holding this thing together and that's it. Like that's that's all you actually need is the silicone in between the glass if you clean away everything else. Like that's the four it's it's like a quarter of a millimeter thick and about four millimeters wide. And it's so scary. But in reality, like that is actually what holds the thing together. All the rest of it is just because they use a lower grade aquarium. That's like 10 cents less. And probably more importantly, they use, they don't, they don't use people that are as highly skilled to put them together. So at the shops, they just slop on the silicone. So you see, you know, when you go into the pet store, you see this tank and it's got like a full freaking inch of silicone on it, but that's literally just slop that's left over because they didn't bother to clean it up when they put it together. The part that actually holds it together is the quarter millimeter by the four millimeters. It's insane. So it's so scary to look at the thing, but it holds water. So anyway. 

STEVE_EDWARDS: So AJ, that pic brings a couple things to mind. First of all, I guess. 

AJ_O’NEAL: Yeah, that's great because it's your turn. 

STEVE_EDWARDS: I guess you could say that you're acquiring this sort of unopening native framework. Right? Okay. Right. It doesn't give you all the rules. It lets you do things however you want to do it. 

AJ_O’NEAL: Well, there's a lot of rules. They're just not easy to understand. I mean, there's, there's basic trade-offs like the nitrogen cycle, how much food you put in, how much water you take out. If you clip your plants, then you're taking out some of the nutrients, which means you have to add nutrients. But, but yet it's just, there's a ton of variables. And if you want to get the low maintenance self-sustaining aquarium, it's gonna take like a year to do it because you have to get, everything has to reach equilibrium and then you have to stop doing, so it's just constant change. 

STEVE_EDWARDS: Yeah, well, like I said, from a code standpoint, it's like an unopinionated framework versus an opinionated framework. 

AJ_O’NEAL: Yeah. 

STEVE_EDWARDS: And then- 

AJ_O’NEAL: Yeah, but like a code morph framework where every time you run the code, the code changes. Because I mean, it's biology, like every day some different processes happening and then that affects other processes. 

STEVE_EDWARDS: The other thing was, I don't know if you ever heard a song back from the 80s, a guy named Kippa Dada. He was real big on puns. He had all kinds of songs and he had one called Wet Dreams. It's all a whole thing about fish puns. And it goes into a bar and anyways, talking to some, some gal and he says, so what's your science? You go to the aquarium. He said, great, let's get tanked. Anyway, that's what it reminds me of. So pick for the day. I just, as last week, I might've mentioned this before, apologies if this is a duplicate few months ago, but I've been studying to get my, it's called the FAA, Federal Aviation Administration part 107 drone certification. And it's what you need. It's what you have to have if you are flying your drone in any capacity other than as a hobby for fun. So if you're doing, you know, you're getting pictures, something, anything for money, you know, a commercial, if there's a commercial aspect to it, those limitations on the types of drones. The reason I got it is, um, to be able to fly drones for our, uh, fire district, the fire department I'm with, we getting a drone program going. And it's very useful over some larger instances and stuff. Anyway, it was recommended that I take study for the course by taking, there's an online course from a place called Pilot Institute, pilotinstitute.com. Really good online course for this, this guy who does it, he's a French guy who lives in Prescott, Arizona now, but he has online classes for pilots as well as the drone courses. And, you know, with the FA, there's books you can get, and there's FAA has study guides for all the things you need to study. I never even had to crack those. I just went through this course and took all this course and was able to pass. I got an 87%. A lot of people get above 90% on the FA test, which is 60 questions. But really, really great course, really thorough course. The guy's name is Greg Revardieu, but pilotinstitute.com. If that's something you want to do. And now for the. Dad jokes of the week, which is you might not know this Kelvin, but this is the high point of every podcast. So recently I told my wife that husband is like a fine wine. We just get better with age. The next day she locked me in the cellar. All right. So I did a little bit of putting money on the horses and I got, I was misled. Unfortunately, I put a bet on a horse that supposedly had excellent breeding. So in the race after the horse left the starting gate, he stopped and closed it behind him. Get that AJ? 

AJ_O’NEAL: No. 

STEVE_EDWARDS: Excellent breeding, you know, manners. He stopped and closed the starting gate behind him instead of racing. Oh, okay. All right. 

AJ_O’NEAL: So one of the things with being highly pedantic and very, you know, like the way I was just describing my brain is that puns get more and more difficult for me every year. 

STEVE_EDWARDS: Okay. Because it kills a joke, but for you all, actually, 

AJ_O’NEAL: literally. Yeah. So it's. It gets... 

STEVE_EDWARDS: Anyway, what do you call a group of chubby newborns? Heavy infantry. Pfft. 

AJ_O’NEAL: I got that one. 

KELVIN_OMERESHONE: That's good. Yes, thank you. 

STEVE_EDWARDS: Those are my picks for the week. Awesome. 

AJ_O’NEAL: All right, now Kelvin, now you get to go hug wild. 

KELVIN_OMERESHONE: Yeah, so for the picks of the week, I don't have no dad jokes though, but for me, I've been really interested in film music. So I played the piano, I've been playing it for a while now, but late last year, I...I don't know whether I discovered Hans Zimmer and what it did in Interstellar kept me up like most nights. I just had it on repeat because it was just so good. So I was like, I think this is something I need to do for my next step of like playing music. It's like taking the emotions in pictures and infusing it in like a musical production. And it's something I've been like working on you know, trying to like see how to really understand it because I am not classically trained. I played that ear, but I feel like this is really, really good to like interpret words and acts in music. So yeah, so Hans Zimmer is someone I've been studying for a while on that one and his work on Interstellar, The Paris of the Caribbean, even The Lion King. 

STEVE_EDWARDS: Yeah, my son is like you. He is, you know, I take piano lessons too. I just started here a few months ago and I'm one of those people that, you know, I'm got to learn how to do this and it's really slow and learning how to play without watching the keys and all that kind of stuff. My son is a musical freak in that he can just sit down. I have yet to, he can't, he plays by ear and he can sit down and watch a demonstration of how to play a song. And pretty soon he's playing this stuff like he's been playing for years with just a couple hours worth of work in it. It keeps me off. Here I am working and working and 10 minutes later he's playing this beautiful song with all these chords and he doesn't know what the chords are. He just knows they sound good. 

KELVIN_OMERESHONE: Yeah. 

STEVE_EDWARDS: So he's crazy gifted that way. It's really amazing how he's gifted. So I'm jealous of people like that. 

KELVIN_OMERESHONE: That's amazing really. Awesome. 

AJ_O’NEAL: All right. Well, with that. Thanks for coming on the show and teaching us about the boring stack. And we look forward to catching up with you again sometime in the future. 

KELVIN_OMERESHONE: Yeah, definitely. I look forward to being here. Thank you. Thank you, Steve. Thank you, AJ. This was amazing. 

STEVE_EDWARDS: Our pleasure. 

AJ_O’NEAL: Have good one 

STEVE_EDWARDS: Adios