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