Hello, Hello, and welcome back, lovely listeners for another exciting episode of JavaScript Jabber. Today on our show, we have myself as host, Ag O'Neill, Steve our dad joker what, and then we have I'm trying to find your last name now, Zach. Zach writes code, last name rights code. That's all word, that's what it says, That's what I'm going with. Go ahead and introduce yourself. Tell us what you're here for. Uh yeah, my name is Zach langdon and or Zach writes code in this
case and software developer. I've been writing code for fifteen some odd years, probably more than that, everything from see maybe a little assembly all the way to like JavaScript and HTML and things of that nature. Front end, back end, not afraid of any of it. I like DevOps. I do a little bit of DevOps in my daytime, daytime job, and I'm a containerization zelot, a bit of a Kubernetes enthusiast, but I'm very beginnerish on that. Husband and a father, and recently, in my very limited free
time, a front end framework author. That's good because we don't have enough of those, yeah right, we need more of that. Well, my first question is actually going to be it's got something on my tongue there. Yeah, okay, my first question is actually going to be I see that you offer hosting services. That is unusual. Like, you know, just about every guest we've ever had has some framework for the front end thing that
they've written, but not all of them offer hosting. So will you will you tell me a little bit about that just just is like a unique thing about you. Yeah. Actually, it's interesting that you asked that because nobody uses that service except for my previous company that I worked for. They're the only ones who leverage. Basically, I have one server and a data center that I own, you know, and then some that I don't own that
you know, for failover and things of that nature. And so I think a couple of years ago, maybe three or four now, I just started trying to build that website which I haven't updated and probably about that long. And that was one of those things that I put on there is like, hey, if you're looking for this, uh you know, you know, send me, send me an email, we'll chat and maybe I can offer
you some hosting services, try to help you out with your project. But most of that is geared toward doing like building things for you know, a client or a contract or a customer as far as like, hey, they've got this thing they want to build, and that's what I have. Uh, this one customer, I built a custom erp system for them and I host it. So they've been using that for five ten years now. So yeah, I nerd out a little bit on the DevOps side of things.
And I always wanted to have my own server in the cloud, if you will, one that I owned and that I maintained. And so that's where that comes from. So do you use is it proxmox? Yes? Are you using? All right? Yeah? I also am using proxmox on a four server cluster with high availability and all that. Yeah, you're you're further along than I am because I've just got the one server. No, it's
not a cluster at all. Well, we bought on eBay the last gen servers that were being dumped, and now the next generation of is just getting dumped because all of these companies, you know, I mean you know this stuff. You know, Amazon's running servers that are like fifteen years old, and as they offload them, they eventually end up on eBay and so you can get the same technology with the same power that Amazon's running today on their servers that have been retired, you know, from and and so yeah,
we just we got them super cheap. I think it was about six hundred dollars a server, seven hundred dollars a server, pretty much more or less maxed out, yep, exactly. And so so yeah, so we we paid less than the cost of what someone would pay for one server, and we got the cluster in anyway, But that's that's cool. That's cool. Yeah, that's what it's. That's where it's at right there. Get them on eBay, host them yourself. Yeah, and it's it's been going well
for us. We've been running it a year. I've transferred almost everything. There's only two projects I have left that haven't transferred, like you, running some client stuff there as well. Hoping to open it up to the general public as well, but want to do it in an automated fashion when we get to that point. But yeah, anyway, so that was cool just to see that. And fellow proxmoxx user. So yeah, now the reason that we actually have you on the show, or that Dan reached out to
you, I'm happy to talk about you know, any of it. By the way, I think that's that's totally fine. But uh, you know, Dan was thinking that res act was a rather timely framework to discuss. So among the sea of front end frameworks, now we've got resact. Tell us about res act. Oh wow. So I don't know that I picked up on that piece with Dan. He just found it interesting and wanted to talk about it. But yeah, So resact is basically, you know,
it's a front end framework. It's like React in the sense that you write components using JSX. It's very at home if you've used React for anybody who has. But it's also like Spelt in that there's some pieces of it where it transforms the code that you're right, because it's not exactly I mean, it's all JavaScript, it's valid JavaScript or typescript in this case, but it
transforms it into code that does more under the hood. So like spelt, will you know, you do a ruin or a statement that is a variable, and then all you have to do is assign things to that variable, and wherever that variable is used in the code, it'll update in the UI. And so I've taken something like that and made it but with JSX, which is was important to me because I really like JSX. I've actually really loved the templating, and I also like the fact that I can author multiple
components in one file if I need to. It's pretty wide open in that regard. Whereas spelt, there are some things about well that I really liked in that is that whole create a variable and just assigned to it and it'll update where it is. But I didn't really like the authoring of the components themselves and that it had to be one file. And I know there's a whole host of people out there who believe that you should only ever have one component in one file, and they may be right, they may be wrong.
I'm not going to argue that. I just know that I like to have the flexibility if I want to to drop a separate component right in a file I'm in and not have to create a new file for it. So that's my long winded intro. But there are other things that I've done that I think make it more interesting. With the way you do state in general, and that is a lot of frameworks you have to download a third party
state management thing. There's not a lot of frameworks that actually give you for like example, for like REDUCS or any of these other global state management libraries. What I've come up with is a way that you can create signals anywhere in a module, in a component, outside of a component in a loop, you can So there's no like hook rules. You can create these signals
anywhere. And because of that, you can just create a module that has these signals in it, import those you know variables into your component and update them from anywhere. They'll update all the places that they occur in your js X, in the UI, et cetera. So signals is a thing that is I know it's been a recent hype train. I don't actually know what
it means. So for background, I don't know how much of the show you watch, but my background in JavaScript is node and I do like the stuff that I do in the browser is like the engineering stuff in the browser, like web sockets or or like niche browser features. I don't do any of the CSS or or the application state management. So I think we had someone that that had talked about signals before, but I have totally forgotten what
it means. And I imagine that along with many of our listeners. It's you know, not something that that has been adopted by everybody yet or that people are familiar with. So give us a rundown of what you mean by that and what the what what's the benefit? Yeah, that's an excellent question because I do think there's a some very a lot of similarities between like,
let's say, for example, and React. You'll reach for use state in your component to manage a piece of state, uh the but you know, in like pre Act, they've got signals and so you'll use use signal, and Spelt has signals as well, Solid has signals. All these frameworks have
signals. The fundamental difference between like React, where you can throw a used state hook in your component is that anytime you update that state, it will re render the entire component, whereas signals are designed to not require needing to re render the entire component. They're designed to render or update is granular as
possible the thing that is in the dom. So, for example, a text node, if you create a signal, assign it to value l world, throw that signal variable in your JSX in a P tag or H one tag. When you modify that variable or signal, it will automatically update the text node's that it's attached to in the dom as opposed to trying to re render the entire jsx component. So that's really what I think the key difference
is between you know, like state and react versus signals. So how is this different from the old two way data binding like what Angular really had its heyday with. So that's another really good question because I was thinking about this. I have this and resact where you can do this pseudo two way data binding. But I know a lot of people are really like, oh no, that's a code smell. You shouldn't do two way data binding anymore. We moved away from that a long time ago in their right because one way
data flow has one out for a lot of really good reasons. But there's a trick involved in that. I'm not really it's not really two way data binding and resa act and so it's different in that it is a one way data flow under the hood. So a lot of that transformation that happens when you compile the code out will transform it into code that is very much a one way data flow. So the thing that's parsing the code is looking for
mutation and then creating a function that calls an update routine. Correct. Okay, So it's it has a look of two way data binding and that you can just create a variable and you don't have to do the updates, which you can actually, so a resact gives you that ability to step in and say, you know, I want to take full control over that update cycle, and so you just you create, you can create that mechanism that will particularly with forms, right, so inputs, you do this on change event
and react that will update the state. You don't have to do that in resact, but you can, and as soon as you do it, you now own the cycle of the update. Okay, so here a signal it look, I'm just looking at your demo code. Am I to understand correctly that a signal is just any variable that's declared where a dollar sign is going
to get transpiled into a signal container? Correct? Okay, So just out of curiosity, I come from the view world, and so, uh with the rewrite from View two to three, one of the big under the hood changes was using proxy jobscript proxies, and so I'm just curious, you know, everything I've seen about signals, you know, and I'm not a real under the hood guy, more of the top level, you know, making the UI type of stuff. It seems like six or one a half dozen
to the other. Is that an accurate statement when you're comparing you know, the proxies versus using signals. I agree with that. I well, and I'll start out with saying that when I wrote an early version of his act,
I used you know, the proxies. Two I guess I'll start off with the fact that I didn't start with this transpiler compiler, so I was trying to just make a way to write code that was nicer to write, and then eventually I ran, you know, just ran into some obstacles and walls where I was like, that's okay, and the proxies are good, but I also saw a lot of hot code running through it, and that might just be a skill issue on my part, Like I wasn't maybe doing
something right, but everything was running through this proxy like a lot, and so I went I went away from that, and now I'm not using proxies. I'm actually just writing or transpiling the code into keetters and setters and updates and subscribers and things of that nature. Okay, yeah, with the two way data binding and one way data flow. I know, like in your
view when you're in components, it's generally have props to pass down. Then you in a mid event, you know, if you want to change from a child, doctuparent, then you admitted event and catch the event and then you do your thing. But I know within state, you know, within using ux you can use a mutate a state and I'm already blanking on the term. You know, where you can have a variable that's defined in the state in your component and when you change it, it changes in state and
vice versa. It's real easy to to change that. I think it's you know, probably one way under the under the hood, but it makes things very easy. Yes, and I do know you know that you were talking about having to re render the whole component versus just the particular variable. And what this does for you is exactly that. Yep. You know, if I change a piece of static, it's just cann change it right on my screen with no no update in play or no re rendering of the whole component.
Yep. So and then I'll go down another route, and this is you know, one of my well beaten horses just because of something that I use so much is I do a lot of that also with something called inertia.
Are you familiar with nursia jas not very much? No, Okay, short version is it's sort of a glue level between your front and your back end, and you can plug and play your front end in your back end with you know, in the front end you can use view reacts, belt on the back end you can use Ruby, Larevell, Node whatever, And it basically just sort of a glue layer that sits in between the two and hijack your post request, then uses some headers and then you use all your
route definition everything else that's done in your back end, and it passes everything up as props into your component. And so because it's hijacking the post request and saying no, don't do a page reload, I'm just going to pass
this data back and forth, it's crazy fast and very efficient. And then you have you know, it has some helper methods and they're like what's called the visit route visit where you can do that just go okay, I want this data from the back end here it comes on doing this update in my front end. So sort of another variation from what I gather, and we haven't gotten into the details too much, it sounds like similar to what you're doing with resact, and that you want to be able to just update certain
things without the patre render because of efficiency and speed. Yes, well there is a except for there is no server component at all, so I'm not at this point. This framework is all client signed render, just like the old days of the original, like the way we would do React applications in a browser. So I mean you're basically obiying on what standard like graph QL or standard rest s API from your back end that you're communicating with exactly.
Yeah. So yeah, I never set out again because this is just kind of like a side pet project. I definitely never set out to create a full stack framework. I was just like, I want to play around with this idea that I have, and that's what became Resact. And I'll be honest with you, I've got a lot of mileage out of clients signed rendered apps even with re react, you know. And I know that a lot of people and a lot of the solutions that have been created today around next
gs and server components and all that stuff are solving real problems. They're just not solving problems that I've ever experienced. Are you sure they're solving real problems? Well, I guess I'm trying to be nice about it. Oh yeah, I just I'm I'm I'm worn. I'm very, very worn. It just feels like, you know, the the idea, like the hope is that you know, we swing from one extreme to the other and we say, okay, well, this extreme is bad, this extreme is bad.
Okay, maybe somewhere in the middle is nice. But it's like we just keep on swinging from one extreme to the other with more force. Yeah, yeah, no, this is like there is a middle ground that is it's helpful. I actually feel the same way. I feel like the pendulum just keeps swinging and it's gaining momentum. It's not reducing a moment, and I just find myself in the middle quite quite happily in the middle, and I
just develop how I develop. And so far, I haven't, you know, been in situations that required me to really dive that hard into oh well we need next JSS and server components. I've played around, but I just lament it because like I know that, you know, people got upset about
the the misconstrued sequel on the front end. I think I think there is some risk there and in terms of just when people don't have a clear conception of where things are separated, they will eventually you put something in the wrong place. But it's just like from my perspective, it's just been oh man, you know, like getting getting you know, like say you got a Node package that or just you have a JavaScript package and there's nothing Node specific
about it. There's nothing React specific about it. It's just JavaScript code, you know, it's just turning complete JavaScript code. Okay, Well you got to get it to work in Node and then and then you gotta like add little hacks so that it works with Webpack. But now now there's ES built, So then then you got to refine your hacks to work with ES built.
And then they come out with next and then it breaks again. And so now in some of this code, I have like six lines of boilerplate on either side, and all it's doing is like it's like a UMD type
wrapper. But it's like I don't want to just transpile the whole file for just like using export syntax differently anyway, So that that's where my my lamentation comes from is having figured out like the magic little one line snippet that'll work in every framework, and then next comes out with the server side stuff, and then it gets detected as node by the bundler, which causes it to want to use record, which causes it to not want to obey the exports.
And then that's that sort of thing, and you know state management related stuff where people are doing like like they're they're building out a call to the database, which makes the front end not like it can't be self contained because it's got the server code in it. But all it's doing is getting an
option that could have been hard coded or something like that. That's that's where I'm i. You know, maybe there is a use case for it, but the things I've personally encountered, I've only known that I've personally encountered them because of you know, the weird stuff that's going on. That's like somebody just decided I gotta do this, I got to do it, but they didn't. It's like Ian Malcolm from Jurassic Park, just because you could anyway,
I'm I'm curious, I am curious, why go with JSX. Well, I mean I guess you're transpiling anyway because of the other stuff you're doing. But why JSX rather than template strings. Uh. You know, I've never been a huge fan of template strings, and part of that is just because I've probably part of it is because I've never committed fully to them. I know that there's some people out there doing that and they really like it.
I just never found that is ergonomic as just being able to write my tags right in the right in the return, and so that's just where that comes from. It's mostly personal preference. Okay, yeah, I mean ostensibly you could still write the tags right in the return, it'd just be instead of a Parenthesi'd be using a tick mark. Yeah, yep, exactly. But no, hopefully they come out with the triple tick which will preserve white
space the way that you'd expect it to. Oh yeah, so yeah, if you right now, if you use the single tick that you know with the code alignment, you're like, I want this component to have the white space, like you know, straight up and down where I've aligned it to the component with the indentation of the component. Problem with the single tick is that it brings in all the white space, all the way to the beginning
of the page. Ye, the triple tickspeck is two. Make it like with the triple quotes and or the triple carrots and other languages, where it brings the white space to the level of indentation of the function or component or
whatever, wouldn't Yeah, that sounds really interesting and really awesome. So if we get stuff like that, that would definitely be great, because that's definitely a pain point when you have you're trying to maintain white space with with single ticks, yeah, because then then you almost need a transpiler just because you just you want your white space to look right. Yep. Yeah, So,
Zach, I probably good idea. I think here to sort of walk through all the stuff you highlight on the exact iocite, okay, and you know if there's something else we miss because I asked some questions after you know, prousing that and what you're talking about doing. I think I get what you're shooting for, what you're trying to do, but I just want to make sure I understand before I ask a stupid question. So so we talked about signals, right, Was there anything more about signals and your use of
signals? That you wanted to to address. I guess we'd be getting starting into getting into like, uh, I think we've covered most of it, but there's a piece that I guess I want to cover a little bit of and that is the form handling aspect, and I think we've already touched on
it already. But the data binding example on form inputs, I think is one of the things that I found I've never really cared for and React, and that is one thing that I s to do differently in res Act, which is to have that idea of two way data binding where you can just create your state variable and assign it to the you know, the value of the input and not need the on change handler. You can do that. That's an option because there's some reasons that you may want to, but it's
not required. And part of the thing that has driven me the most nuts about that, and why I emphasized on this is because when I realized that React was basically preventing the default action when you type in a textbox essentially right, because if you type in a textbox that has an on change of handler and you're not updating the state that's in the value, nothing happens inside that
textbox, right, And that was just wild to me. I'm like, these are browser component or inputs, elements, whatever you want to call them, that have had state management built in for as long as they've been around. They have their own state management, but React circumvents it. It says, no, we're going to have circumvent it, and we're going to catch your keystrokes. We're going to update the state, and then we're going to re render the whole thing, and then we're going to update the value and
that input so you see the keystroke that you hit. And that has just driven me bokers for mostly out of principle. It's not a performance thing, because I don't think I've ever actually personally experienced a really bad performance issue with that whole cycle. But it just hurts my soul a little bit to think that all that effort is being redone in JavaScript when it's already taken care of for you in the browser. And so one thing that resact does is not
do that. Right. It will capture the keystroke and it will make sure the state is maintained, but it does not unless, of course, you add your own non change. If you add your own on change, then it does that whole react cycle where it's like, okay, prevent default, capture keystroke, do the thing you want me to do, update the state, rerender the value. It does all of that. But that's what it does anyway, when you do on change in the browser in the first place.
Correct, Yeah, you know, I guess. I'm not one hundred percent sure how it works. And in the actual native browser, like is it actually blocking you know, the render of the value being displayed in the input when you press the keystroke or does it display it and then on change happens or on input happens or whatever your event is. I don't know,
So let's see because you can. It depends. It depends on how you do it, because there's on key up, on key down, on change, on blur, and so you can basically hijack any part of the life cycle, and you can hijacket in different places. So depending on what you're trying to hijack, you can either hijacket all the way at body dot document or I mean document dot body. Some things have to be hijacked by the
form. They won't propagate up all the way to document dot body, so they have to be handled within the form, and then some things have to be handled within the input. So if you wanted the input to not show the keystroke that's being typed, I don't remember where that has to get handled at. It could be all the way up at document dot body, but I think it I think it would probably happen sooner than that. But you
you are in control. You can choose where to attach the event handler, and depending on the event you have control of whether that keypress will get displayed or not. Yeah, so that is that is correct. And actually, as we've sitting here talked about it, I've been thinking about it. I'm like, yeah, that is basically what I believe. If you do a non change and you just hit event prevent a fault, I don't think the keystroke shows up. I think that's enough. So whether or not where in
that cycle that happens, I guess is different. But as long as you're not calling event prevent default, then the browser handles the life cycle of that keystroke and everything else, and you're just doing something else with it. Uh in not necessarily in parallel, because it's all synchronous, but you're not trying
to take full control over that input, so to speak. So that's that's one thing that I just I wanted to point out that I find interesting about REACT and has been something that just out of principle, really, I don't have any other good reason than that to take issue with it. That has just been the thing that I wanted to make sure I did differently and resact well, I think one, there's a lot a lot of thoughts here.
So given given that we're reaching the limit of hardware we are, you know, Apple's M one was amazing, and then the M two is five ten percent better, and the M three is like another five ten percent better, you know, thirty percent better on the things that they actually got wrong the first go around, and we're able to optimize, but we're not looking towards a future where every year we're having an M one leap in CPU capability, and the laws of physics dictate that, you know, we're at the end
of the S curve. We're we're at the trailing end where we're approaching the limit of what computers is. So software has to get better because software is where we can literally get tens of thousands of times more performance, especially you know in the web, right yep. So when you when you look at
the way that things have gone, it seems like component mania. And my main, my main canonical gripe is the sign up form on a website, like you want to subscribe to a newsletter because you want to know when a product is going to be available or something like that, and it doesn't work. It's like you put in your email, you click submit and it doesn't
work, Like why can't this work? And it's and it's because you know, instead of having input equals email like what you show here in your your example, you know, input type equals email, like that would work. That does the validation You can tack on required, you know, and it'll hand, it'll do all the things. But people, people, basically, you know, they have these components and then instead of an input field, it's like a thousand divs and then every single one of those events is being
re implemented in the component stack rather than letting the browser handle it. So it seems like, you know, we we have to get back to letting the browser do what it does well rather than re implementing it in a way that is like literally literally prevents the business objective from from being fulfilled depending on you know, the thing like like one of the things you see most often.
I don't know if you noticed this, but on an HTML form for people that are old enough, if you hit enter, it'll submit the form. Right, most websites today that won't work anymore. Nope, And this is because of this like componentization and the hijack and everything. So I see, like I love seeing in your example that it's like, hey, we're going to use an input like a literal HTML input, and we're just going
to do type equals email and that's going to do stuff for us. But I am a little curious about, Like, so you also have this validator input and it looks like it's exactly the same as an input, Like there's no proprietary or API specific fields, like we're required is HTML, type is HTML, name is HTML, placeholder is HTML? Like all of that's just HTML, but it's got this capital I in there to signify that it's like
a special component. So like how much of the underlying HTML is it using and what's the difference that you're using that's not HTML and why So in this particular example, I am hiding a lot, right because obviously you're not seeing the label, but I think there's a label prop and I don't even I'm not actually looking at the example now and I'm not even seeing the label prop, but there is, and it will do a very simple div wrapper with
a label in the input. And then of course the magic is that there is some events that are tied to it as far as catching your keystrokes. If you wanted to do masking, or if you're doing any kind of validation of that sort, then it will do that, you know, in ways that the browser currently doesn't support us, Like right now, I'm not aware of the browser supporting the ability to do like a phone number mask. So
that's one thing that you can do with this this component. And I think there's another piece where the validation without job descript anyway, it's limited, right, Like you do the type email and you get a lot, but if you want to do anything more than stuff like type email, you got to
branch out. Yeah, I see the mask option, and I see the data accept now HTML, I don't think it's called data accept, but it does have the option for putting in a regular expression that has some confines, but you know, like you get regular expressions type stuff so I'm particularly interested in the email example, like would I what behavior would be different if I use a lowercase I rather than an uppercase I on that input for the for
the email example, uh, none. If you wanted to Zach, absolutely, let you just do it basic HTML form that will submit on entered, so you can go all the way back to the original just use the broser In fact, rezact is only involved in that example with the email in the fact that the it's wrapped in that capital F form and so when you hit submit, it is running some JavaScript to grab the values from your form, turn it into Adjason object that you can then do whatever you want, right
because like in a client side rendered app, that's how you do that. You grab ad Jason blob, you ship you know, send a request off to the server, get a response, do something, update UI. That's all completely optional. With rezact, you don't have to do any of that, and resact will get out of your way if you never use hardly any of these functions and the only thing that you're really doing is just basic HTML.
Your your your Jason bundle, a Jason JavaScript bun that gets shipped to the client is just incredibly tiny it's actually smaller than us well, spelt four. We'll see how Spelt five is. They're claiming that it's even smaller than spelt. They're claiming spelt by five is smaller than Spelt four. So we'll see when that actually comes out how much smaller it actually is, which is
impressive because it's already pretty small. Well, I guess my number one question on that is, or the number one gripe that I see people make that I think is a pretty fairly legitimate gripe, is that when you use required on an input, there's you can style an input to be almost whatever you want. There have been some quirks now and then with the auto complete changing the font size back to the original font size, but I think that's mostly
been worked out by the browsers by now. But the required has a pop up that you can't to my knowledge today, you still can't customize the look and feel of the pop up that you get with the required and so it is by default. Is Rezact using that same required or do you have some sort of custom pop up that I can edit the CSS and make it look different. Yeah, no, we're we're not using the built in browsers validation display if that's what you're referring to, Yeah, yeah, yeah, because
it's so painful. It's so hard to try to make that look the way you wanted to look. And I have yet to meet a designer or a project manager that has ever just been okay with the default browser's validation when it comes to you know, forem inbus, they all are like, Nope, here's the design. You need to make it look like this when it validates, and so you have to you have to do that. I think that's a pity though, because this is a luxury that Apple and Android developers get.
You don't say, well, we're gonna publish this as a native iPhone app, but we think iPhone sucks and everything it does is wrong. So we're gonna redesign everything. Instead of looking like an iPhone app, it's gonna look like something no one's ever seen before. But that seems to be very very That seems to be the more common approach to the browser is like everything
about the browser is wrong, it all sucks. We're gonna eliminate all the design that goes into Chrome, and rather than a Chrome user having a Chrome experience, we're gonna give them some random experience that they've never had before, which I think is a real pity. Like I agree, I agree that the validation pop up is not the ideal for every single scenario. It's not like ninety percent of people want this as like the height of perfection. But
I also so the other way around. I just have our time seeing ninety percent incent of people saying, oh, this is completely unusable. This doesn't communicate anything valuable to the user. It's it's too difficult to be understood.
It'll just confuse people. I don't really see that either, So I get the argument for wanting to have it be customed, but I also think that people just need to calm down a little bit and treat it more like they would an iOS app, and say, you know what, Apple did research into this, they figured it out. We're not going to rewrite every single component that Apple ever created. And likewise, you know, the Chrome team,
they've done some research. You know they've done a decent job. It's not bad and unless it's like really part of your And also, this isn't even on the happy path, right, I mean, you're talking about somebody types in a phone number. Wrong do they need it to be in your company colors in order for them to understand that they need to fix a missing
digit. Yep. No, I actually went down this path with a you know, it was supposed to be just a simple form, and my job is about like sometime last year, and I was like, well, it's just a simple form. You know, ninety percent of the time, these people are just going to fill it out right the first pass. Well, my you know quality in PM and designer. They get involved and they start poking at it, and they're like, well, this is what happens when
when I don't do it right. When I when I do it wrong intentionally, I don't like the way that looks, I don't like the way that feels, I don't like the way that works. Can you change it to do it? You know all this custom stuff. And so that's where that came from. Was exactly that. I'm like, Okay, that's I guess how this is going to go. And to be fair, I haven't used
Resact in that application, but I am using the same. I ended up creating the validation engine for that project that I'm now using also in res Act.
So it's like a completely customed from the ground up written validation and masking engine, and you can go ahead, well, and you can do exactly what we're talking about as far as uh, you know, designing and CSS your error messages and how they display, when they display, how will they display all of that to your heart's content, but absolutely disabling the browser's native
you know, responses to those validations. So with the examples that you gave here, I think they're actually really really good examples to to bring up some some talking points. I love the idea of the mask, like from from the the idyllic perspective, like we live in the world of fairy tales and rainbows. Couldn't we just provide a mask equals like you show here in the
example and everything just works and is wonderful. And then the most simplistic case, like you know what you've showed here, it seems like that could work. If all we're going to ever accept is US phone numbers, yep, then we can use this mask as you've defined, which is the case for
most people in the U Ied States. Most people like they might have in their heads they're going to scale the international but they're not yep, right, So so this is actually like it's really convenient, it's it communicates really effectively, Like so much about the experience of this in the ideal world is perfect,
Like what what more could we ask for? You know, so to for people that are listening audio, it's parentheses with underscores in between a space, some underscores, a space, some underscores, and I'm imagining what that means is that the underscore means that as the user types, it's going to fill in the value so that the value will be visible to the user as
they type with that formatting and space. Yep. And you know, if anybody's you know, on the site, just below that code example, is the actual form and you can see that in action as you type in the in the in the phone field. Oh I didn't even I didn't even notice.
No, uh yeah. But then but then it's like, okay, well, realistically, we're only going to be doing us you know, email address or phone numbers, so we could we could actually we could let that one slide that it's not going to handle two hundred different formats for phone number
because we're practical, right not, We're not. We're not having a delusion that we're gonna go plant scale with our if the were our startup app here, okay, but now the next one is the one where it just it breaks utterly because I am going to have people that have visa discover an American Express. So your credit card validator has the the sixteen dots, and do the dots mean that it turns into an asterisk as they type or it stays a dot or what does the dot mean? There his mask and mask slots.
So it actually is the dots in this particular case, the mask slots. So it's saying, you know, the dots are the placeholder. Is what those end up being for when you type in a number, and so it doesn't actually display anything while you type. It just shows the numbers, and then as you tie, you'll see the space, you know, be inserted as you type Okay, now I'm trying that, okay, and then you know and yeah, and so you see the mid length is fifteen in
the max of sixteen. And I actually I actually work in payments and it's all US based payments that we currently work with merchants in the US. We
don't work with international merchants. So we have been doing fifteen to sixteen digit card inputs as long as they've been in business, and that has not been a there's never been a request so far from someone say well, hey, I need you to accept the nineteen digit version of the twenty digit version because there's new standards that are coming out about how you we may end up with
card numbers that are longer than that. Oh, the validation for the actual check will actually work with either the fifteen digit version for American Express or the sixteen digit version for Visa MasterCard and discover. The algorithm that's used to basically validate a card number is very very simple. It's like CRC thirty two or something. It's basically something along them lines. Yeah, and so it's not
even actually telling you that the card number is real. It's just telling you that it passes that check and it could be real, and so you submit it and then from there, you know, it goes through the card network brands and all that, and then they actually will return a response if it's real or not so. But the mask there's I think there's four different, no, three different formats for a credit card if i e I remember on the top of my head. But American Express, yeah, starts with five
digits. Visa does four, visa maestro master, I'll do four and then discover is that I don't remember is it four or five? Anyway. So but the point is like, realistically, this mask value breaks down really quickly because now if I wanted to display somebody's American Express card, it's going to mask it in a weird way that's unfamiliar to them, right yep. So in this example, you're absolutely right, it will break right away. In our card fields that we have where I work, we do extra work to
detect that first digit. I think it's three, and it's like, if it's three, it's American Express, and so we will update the mask to fit that format. When you as soon as you hit that first key, strug you hit three. Now, this example isn't going to do that, but in our other fields at work, that's how that works. You hit
three and it goes. It changes the format of the mask. So my question there is when you when you look at a situation like this, I know that for the purpose of an example, everybody wants to see this cute little example that does a bunch of magic, But like the reality starts to
break things down pretty quickly. There's I think there's I don't know how many types of inputs where where like the way you've shown it here, which is so idyllic, like this is what I wish we could have, right, I don't know how many inputs there are that actually are simple enough that that
they can they can work this way. So my question is do you think that it is, like, is there really a significan advantage just striving for this kind of template like syntax that you know it looks so good versus just yeah, just do it in JavaScript ninety percent of the time. You know.
That's a great point, because you're right obviously with the American Express example, that's what we're talking about, right, is now it's no longer this nice example mask equals you know, sixteen dots with spaces is no longer mask equals sixty other spaces. It's mask equals a signal, you know, and then you're updating that signal based on and now you've got an unchange event or an on input event where you're looking at while they're typing and deciding which mask
to show. So you're right, there is a breakdown there. But I really like personally the option to start here, and then once I'm moved, you know, beyond or running into the issues, I'd like to have something
that facilitates that process of customization more easily. And I think there is here, and I'm just not showing it. Like I think the ability to move from this really idealic, simple example into the complex scenarios that you're going to run into once you, you know, start actively having users use your stuff, I think is actually available, Like you could really easily move from, you know, just from the simplistic example of handling the American Express mask.
It's it's not out of reach in this in this framework. Okay, Well here's here's another thought that I was just just thinking of. There's there's a number of things that are that are very finite, right like, like everybody has to do them, and there's very little variation and how we want to do them, even if we're really artistically expressive, right Like the the error message falls a little bit outside of that bounce because people just want to be
so freaking artistically expressive. But displaying a phone number or a credit card, there's I mean, we literally have a list of internationalization for this, right Like you can there are standards that specify this is the American way to format a phone number, this is the European way to format a phone number. And there's not thousands or tens of thousands, or hundreds of thousands or an
infinite number of ways that you could want to do it. There's i don't know, on the small end, like three or four, and on the big end maybe a dozen or two. And then same thing with the credit card that that's even more constrained, Like these credit card companies how they format their card is part of the brand, and it's basically you're down to do you want spaces? Do you want dashes? So what do you what do you think about taking the opposite approach saying you know what, it's a shame
that browsers haven't decided on you know, type equals credit card. What about just bringing that full on into the primitive of the system to say, hey, validator input handles credit card as a type of input, and it handles phone numbers the type of input. And your option is you pass in the you know, do you want the space or do you want the dash?
Do you want to mask the last four or do you want or do you want to unmask the last four or do you want to unmask the whole thing, like yeah, I mean there's literally for credit cards, there's literally a PCI document that I mean you know this because you you know, like there's a PCI document that tells you what your options are, so you have a finite number of options that you could just say I want it this way or that way and be done with it and not have the artistic expression and not
have to go and to do it in JavaScript. Like I said, Oh, I would love that. Like I think if there was a way to standardize this and have the browsers support these various you know, permutations of the way that people are trying to do inputs, especially in forms, then I
would use it. But I I don't know what that looks like. Like no, I mean, like you you in your own framework, Like what if you just update your validator input and say, hey, one of the key features is that we support something that every single business on the planet wants, the ability to put in a credit card. Sure, yeah, I could easily create a I can imagine as you're talking how I could use and by the way, I should actually step back and clarify that a lot of
The code that is in this isn't actually framework specific to resact. This is code that I could port to and I have. It's actually currently existing in my work infrastructure code God bless you. It is, you know, just a basic library, right, So there's nothing special about this code that makes this happen. And so as you're sitting you're talking, I can imagine how
I could create a component that would handle all of what you're saying. As far as the internationalization, I think there's some question marks around, like, well, what do you want that to look like? Should the selection should auto detect as you type? Should you be able to select you know, your prefix or whatever, and then that automatically updates and changes the format things of that nature. So there's some questions around what that should look like.
But I can imagine how I could make a like a component or an input that would would handle that, that you could consume and say, hey, here's this component that does phone numbers, which is kind of wild because we're geared to just download an NPM package for stuff like that, and so I can imagine there might even be an NPM package for a component for a phone number input. I bet if we just did a quick search right now,
we'd find one. I'm sure we'd find dozens. But the finding a finding one that works reliably and that doesn't require having a particular you know, finding something that just works the way the browser works, that I think is not going to be as as popular as like an entire UI kit, right, And that's that's what I'm talking about, is like if I can style an input and you can just put the stuff in the input, yeah, and
I and and I yeah. The question about well, one thing that I hate that I absolutely hate, and it looks like you've taken care to solve and what you've created is if I can't paste in a value like I paste in something that has dashes where it expects dots or dots where it expects dashes, and then it just like pasts in two characters and then stops and it pastes them in wrong because it has like the leading one so it's like one eight zero, and then it stops. It helps. That worked? Did
it work? You were able to post in a number, paste in a number with dashes and that and that worked. I didn't try I'm gonna I'll try it right now. Yeah, I'm dying Oh, I'm like curious to see what happens here. We're all on the edge of our seats waiting for AJ's copy paste test. Let's see. Okay, so it did it did do the wrong thing if it starts with a one, but your example didn't. If I just paste in with dashes, yes, it works. If I don't put the leading one, it works. I'm gonna try with dots
as well and see how that goes. Works. So like that, that's that. The only thing that I would wish differently is that it kept the leading or the trailing character so that when I go back to delete the one that I it kept, it kept the trailing five. Gotcha. Yeah, so there's some work there to be done. I mean, I mean that's good. That's like, that's better than the experience of ninety nine point Masking is so hard, Like it isn't one of the hardest things to do right.
And I'm not going to sit here and say that I did it right, because I don't know. We're talking about dashes and dots now whether or not those work and pacing. And that's the first time I've ever thought to the test for that. So and yeah, it's definitely a very very difficult thing to to implement, especially like from scratch in JavaScript. So with resact, it sounds like this is something that you know, you're not necessarily saying, hey, I think that this is going to be the next hot framework.
This is something that has personally brought you value, has brought value to your clients, and that you you're not sure if it brought value to your clients. Well, I don't have any clients that I've used the framework with, so that's just so far, there's a this is a zero user framework. I've got, you know, a discord channel where some people were playing with it, and I think there's one guy who's really interested in, you know, using it in a production app that he was you know, had
a vision for. But I'm one guy and I tried to talk to him. I was like, hey, you know, if you really are passionate about this and want to see this work, let's get together, let's develop it and try to engage the community to you know, participate. But he was like, no, no, I'm not. He's like, I want you to do it all the work and then I'll just use it. I'm like, okay, well I can't make you any promises. So yeah,
we have as far as I know, zero users of this framework. Okay, all right, so that's because you want to use a syncle weight then instead of promises, is at it well as far as the like, uh yeah, oh now I get it, Now I get it. Okay.
So what's the moral of the story then? Because you, like you, you did something interesting, you tried out some stuff, you created something that seems to be of you know, pretty high value in terms of well value value would we'd have to throw that to the market with the market decides the value of it is. But it's I mean, it seems like it's high quality, thank you, So but what like, what's what's the moral of
the story with this? You know, you created a framework and then what so you know, I've just from the time that I last wrote any code for this and committed, I got just slammed. I'm super busy, and so I haven't had any time to dedicate to the project. But it is my intention to continue building on this and using it at the very least in my own personal projects. It's something that I find useful. So for sure that's there's value there, just in that regard there has been some people who
have expressed interest, and so there may be some value. But is my goal right now to take over you know, you know, become the next react or the next Svelt or anything like that nature. I'm not that grandiose. I'm having a lot of fun building it and playing with it, and if other people find joy in it, then that's just icing on the cake. So what what what's the most valuable thing about this experience to share with our listeners. Oh, the honestly, the most valuable thing, you know,
is just the act of trying to build something like a framework. You go through all of the mental gymnastics that many smarter people than me before me had to go through to come up with stuff like this, and so you get a really valuable insight into the process and you only get that if you
try to build your own front and framework. And so that's what this started out as in the fact that it became somewhat valuable to me was an accident, to be completely honest, And yeah, that's the takeaway, Like, I'm just struggling with the same struggles at least some of them that framework authors today have to struggle with. Uh, And it brings you a level of yeah, maybe compassion for some of those authors because they a lot of them are not getting paid to do any of that. Well, and I'm not
getting paid to do any of that that either. So so let me see if I can summarize this. You know, I've been listening to you and AJ talk for a while, and you know, reading through the docs and and all this, and I'm looking at you know, a lot of the
stuff you mentioned I see already done in view. For instance, you know, I'll give you an example reactive computations, yep, So where you have So the gist is you have an underlying say a data set or a it could be a scalar value, could be an array, could be you know, you name it right, and then you have a top level variable that that returns some value from it, whether it's the entire array, whether it's you know, you're adding two numbers together two plus x. You know it's
going to be. And so the way that you describe it in there is that you're behind the scenes. You're handling any changes. You're only going to re render, rerender the value when something changes. So if you go to you know, your page loads and it has it changed, then you're in other words, you're using a cash value almost is the way you look at because if you use this computed values, and that's exactly what this does.
I'm watching, I'm you know, reading this, and I'm going, huh, that sounds like a lot like a view computed value behind the scenes. But the overall gist I'm getting in it specifically, specifically if you look at the stores page where you're talking about, uh, what you do with resact as compared to reduct reducts react, right, and you've got to set up the story, create actions, and your reducers you know, provide reduct story
react and all this kind of stuff. So the gist I'm getting and tell me if this is is a an accurate overall statement, you know, as we sort of wrap up here, is that you're basically using the platform and doing a lot of the stuff that other frameworks have to implement other tools to
do the same thing. Is that a fair statement. There's a lot of that, yes, and including you know this idea that you're looking at with the stores I it's baked in, it's and it's actually the same thing as the using a signal or is you know, inside a component, it's actually the exact same code. So there's no new mechanism that I've created in the actual core of the framework to enable stores. It's the same code that you used to create signals everywhere. Okay, yeah, it's I'm noticing that most
of your your uh, your examples are in comparison to React. So obviously we talked about the ahead of time about the naming. You know, it's resact. I mean from a historical standpoint in your development history, did you start out doing React and you were saying, I don't like all this the way you're acts doing stuff, so I'm going to complete create a more simple and more efficient way to do it. Is that was that the driving force behind this? Uh, it's a bit of that. It's a bit of
that. And i'd say because I've played with a lot of the frameworks. I've played with Spelt and Solid and unfortunately I can't say that i've played with View as much. A long time ago, when View was first starting, I think I played with it, but it's been a long time since I've done that. And so I saw what other frameworks were doing, and I've you know, done React a lot in my daily job, And there was just things that as I've written React, where I was like, man,
it made me think of Spelt and how Spelt handled something. I'm like, yeah, I see a lot of Spelt in here. Yeah. And that was exactly a lot of the inspirations Like I want js X, I want function components, but I also want Spelt And so that's really where this, uh you know, I guess inspiration came from. So why not just use Felt? Why do this on install? In particular, Spelt you know, doesn't really use js X, it's using its own uh you know language.
Really, it's like a whole preprocessor on that, uh in Spelt or in React. And so my my understanding is that JSX is just it's just syntax sugar. Like if you ran a preprocessor on a JSX file, you'd end up with a file that just has like template string and a couple of functions, attitude ors. I could be completely wrong about that. I mean, it's maybe absolutely wrong, but I my understanding was like, basically it it's
just doing string escaping for you. So in this particular case, the transplation, so I'm using VT and it's using whatever it uses I'm not one hundred percent first and the whole underlying structure, but I've used created a plug in basically that will transform very specifically things surrounding these keywords that I have as far
as like oh it's a dollar sign, it's variable. You know. It's actually looking at the oh ASC syntax to try to pick up on a lot of that stuff, and it will pick up on it and then make the transformations. And it's literally just rewriting the code. So it's like, oh, you're assigning a value to this variable that was assigned earlier or created earlier. Okay, well I'm going to do a setter here. Oh you're going to read this value here. Oh, I'm going to do a getter here.
That's what the transporlation is, and that actually happens after the JSX gets compiled into a well code that can be read by the browser. So it's like from a step standpoint, res act doesn't do anything until after the JSX has been transpiled, and then the plug and picks up after that and it parses that code to look for uh, you know these these you know, dollar you know, variables, And I think I've got a couple of keywords in here too that it looks for. But but you you don't feel like
that could be done in SVELT. You couldn't. You couldn't just run a preprocessor step on SVELT and then have it run its processor. Maybe after that, I, you know, I probably could, but then I'd have missed out on all the fun of starting from scratch. I think that there's value in that. I think that we don't need everyone to publish their own framework,
but it we might. We might do well to have people kind of you do a Hello World framework or something like that, you know, take that, take that path and gain some of the It's maybe it's not so much you speak to this. I haven't created my own framework yet, but maybe it's not so much magic as it seems like. Maybe it's more approachable than we're led to believe. Ah. I think that just depends on your level of experience, because if you're a beginner, I would not recommend you
set out to build a you know, JSX framework. But if you've been using React for a while and you understand React well enough, then no, I don't think you could have any problem. In fact, I'm sure that I started with an article that I found online. It was like build your own React framework. I'll try to find that link and then post it somewhere.
But it was a long time. It's been over a year now since I read that article, and I don't know if I actually used the article to do it or if it just inspired me, like, oh, this is approachable, And I just kind of saw some of the pieces and I'm like, well, how hard can it be. I don't have to write
a JSX parser or transpiler, because that's already done. All I have to do is write a framework that can handle the code generated by the JSX output of the you know, the transpiled output of the JSX And it's like create element is like the first function you write. You know that, because that's what JSX gets transpiled into is a bunch of create element calls and things of that nature. So I'd say more approachable than probably a lot of people think,
but not approachable for like someone just starting to learn. Sure, yeah, I mean I think that's that's fair. All right, Well, thanks for coming on the show. This has been enjoyable and enlightening, and I'm glad that you were able to share your experience A last thing you think, Man, I want to get to this next time, but give people a teaser for this time. No. Actually, I feel like I covered a lot, even more than I had planned and prepared to covers, So I
feel pretty good. All right, Great, well, then we will go ahead and head into picks, which is just where we give a short or fifteen minute long snippet about something that we're into recently. And we'll go ahead and let Steve start us off with that. Steve, you have some picks for us or the usual high point of every episode. My dad Jokes of the Week. Didn't really have anything else on the mind to share with today, so Zach, I don't know if you listen to the podcast, but
I had people begging me to tell more dad jokes just kidding. Really I don't anyway, So question, what kind of car does a sheep drive? A Lamborghini? Just kidding. Sheep can't afford a Lamba, They just take a uber. It's a long time ago, you know. I used to have a dog. I had a legless dog. His name was Cigarette because every morning I took him out for a drag. And then finally, where's my mask going? I'd like to say, welcome to the Plastic Surgery Addicts
group. I see a lot of new faces here today. Nice. That one was good. That one was good. Yeah, and the dog one too. You have a lot of good ones today. Yeah. I know. Either I'm getting more used to it and my my expectation of quality of humor is declining, or you're getting better. But I'm not sure. I think it's just probably getting numb. Aj that is what it is. I liked it. I enjoyed it. I actually got some genuine laughs out of those. But I'm also a dad. I don't have as many dad jokes.
I don't have any dad jokes to say today. But that was fun, all right, That's all I got. All Right, I will pick I did I mention the last time that I've been listening to the andrama to strain? Yes, I believe so I remember that discussion from previous. It's I really did enjoy the book. It's it's written in nineteen sixty nine.
It's aged fairly well. Other than that, computers, of course still today can't do any of what they do in the book, but it's written with that just that little bit of extra belief about computers being able to do more than they can. It's like it's it works, it works, it's it's I would say that it's that its use of of computers as part of the plot, which is they're not like a major part of the plot. It's just you know, secret government research facility, and the computers can do all
this stuff. I think that it's it's fairly timeless and has aged well, and in another two hundred years computers still won't be able to do those things, but people will still believe that we're right on the cusp. The one thing, the one thing about the book is that it just ended. And then I was like, wait, what did it? Did it skip a chapter? Like and this is a lot of people's experiences. The ending of the book is a sentence, which it needs a little bit more than that.
It's like a sentence for the ending of the book. And then the epilogue and that, Yeah, I just like so much Pranos or that type of thing. I don't know, I didn't I didn't watch The Sopranos, but the famous black screen where just everything just stopped. I don't know about it, but just the ending was completely unsatisfying because the book has all this build up, it has all this. The plot thickens, it has all this, and if only they had known a few hours before this hypothesis was
completely incorrect. And then when they get to the end of the book, it's like, and this quintal coincidental thing happened, and all is well, and it's like, oh, but that said, you know, Michael Crichton's cranked out a lot of books, a lot of them pretty darn good, and and drama to strain. I think I'd say it's worth the listen or
the read. And I don't know, hopefully, I think I spoiled the ending already by saying that it ends in a sentence, because I was like three quarters the way through the book and I'm like, man, this is a lot to wrap up. How are they going to tie this all together? They don't. It's just like just like well, I mean, I mean, but that's that's real life too. I mean, you know, real life often has unsatisfying endings to projects. You spend three weeks, I
mean, like as a web developer or whatever. You know this, right, you spend three weeks investigating a technology thinking that you're gonna switch databases and use the latest framework and then it turns out that all you needed to do was type Equal's email on the input field. So very true. Yeah, I'll have check it out. I haven't read any Michael Crichton in a long term, actually, so so I think I'm due. I don't know if he's come out with anything a long time. I don't know if he's still
like I don't know what his age was or anything. But I loved Jurassic Park. Although I think that they did the movie better than the book, not that the book was not done well. John Hammont is a much more relatable character in the movie, and there's just a few things that they're just done better in the movie, just like with The Hunger Games, there's a
few things. I wouldn't say that the movie is better than the book in the Hunger Games, like I would say the movie was refined for Jurassic Park and the Hunger Games, the movies telling another side of the story that you don't get from the perspective of the narration. But yeah, I like a lot of his stuff. I think it's I think it's done well. I might pick up some more at some point, although I've got a backlog of like twenty books to read slash listen to. So I canceled my Audible subscription
and definitely until I can actually work through that stuff. But anyway, why don't you give us a couple of your picksack? Well, I just have one for today. Recently because I don't even really have time anymore, I feel like to engage in, you know, leisure activities as far as reading books and even watching some TV. But I did find some time just to take a break and watch the show that caught my eye called It's on Netflix, A Man in Full. It's got Jeff Daniels in it. Does that
ring a ball anybody? I think it's relatively new, like maybe just came out like even this year. I mean, I know Jeff daniels is, but I haven't. I think I've heard about it or see I mentioned I'm not familiar with it. So it's basically, he's a real estate mogul and I think Georgia, and you know, he's like this big, big to do. He's got you know, lots of real estate and it's a big
building. But you know, he may be a little bit shady, but he also employs some really nice people and so it's got you know, some side stories where, you know, like his lawyer struggles because he's actually a nice guy and really would like to be doing something a little more holistic as opposed to just defending this real estate mogul who maybe has some shady business practices. But and so there's like a whole side story in the episode where he
fights for this guy's read him that. I don't want to give too much away because it's actually a pretty good side story and the main story is like okay, but I think I really liked the side story better, Like I think I committed to watching the rest of it and was you know, kept coming back to see the rest of it. It's a mini series, so it's not very long. Was this side story of this lawyer and how he helped this gentleman basically through like some legal troubles. So I don't want to
give away too much, but really good recommend it. I think it's a I think it's a fun watch, like an ongoing series mini. Well, it's based on it's based on the book by Tom I'm looking now, I can't remember what the author's name was, And it's based on a book Tom Wolf. So it's based on the book by Tom Wolf named A Man in Full So I don't think it's going to be a continuing thing. It's a
mini series. I think that's it, which is something that I find that I'm leaning toward lately because I just don't have the commitment space to engage in series that are going ongoing anymore. Like I feel like I'm like already beyond season whatever one, two or three of things that I want to watch,
and I'm like, uh, I don't have time to catch up. I really wish they would just focus on a story that has a beginning and an end and not artificially drag out seasons of things forever and ever, because eventually they just they become the same thing. Like there's no there's no character development because once the main guy gets with the main girl, at that point,
all that tension is gone. And then they keep it going for another three seasons by having them separate and then get back together again, and you know, it's there's Yeah, that's sort of the the mech if you're familiar with Mexican telenovelas, that's their approach, right, It's a it's a there's a beginning and an end, you know, it's not like As the Stomach Turns that's been going for thirty years or you know, something like that, where
they tell the same story over and over. It's just a different twist. It's like, okay, here, it starts here, it ends, it's done, you know, and then they to be honest, then they do a whole new Televila that's sort of like the previous one with different plot twists.
You know. So it depends on your variation. Yeah, well, there's so many Somebody shows that could be great if they would just end them six or twenty seasons earlier, right, like give me one, two, three seasons, maybe four is like a reprise or a bonus or a you know, a year in the life. But don't don't give me eight seasons, Like just give me a good story. Yeah. One of my favors was on Amazon was the John Krasinski Jack Cryan Seria. I loved those series.
Those are good. The third one is a little week, but the first two were really good, and they were just like, you know, I think it was eight episodes, start, done, end of the storyline, you know, and then it come back and I think this last one was third one is supposedly the last one that was great. I was hooked on those things. Man, I'm sitting at night watching them on my phone, you know, when I'm supposed to be in bed, and but yeah, stuff like that is really good. So all right, well, oh,
I should have switched the screen of Bob earlier in all chatting. Anyway, thanks for coming on. It's great to have you and have a nice life. Hopefully there's a good resaction to this episode. Well, thank you guys for having me. I really appreciate it. Yep, all right, and to all the listeners, thanks for tuning in. Well thanks and uh, I guess we'll go ahead and click the end stream button. All right, Adios, Adios