Zach Lankton is the Product Engineer at Signature Payments. They dive deep into the world of software development and tech innovations. In this episode, they explore a wide range of topics, the main focus is on ReZact, a cutting-edge front-end framework discussed by Zach, which shares similarities with React and Svelte. The conversation covers the framework's unique features, the challenges of customizing form inputs in the browser, and the value of leveraging native browser capabilities. Additionally, they delve into the concept of signals as a means of state management, the technical implementation of signals, and their benefits compared to other state management tools. And that's just scratching the surface! So, get ready to enrich your knowledge and dive into the latest trends in software development with this insightful discussion.

 

AJ O'Neil [00:00:05]:
Hello. Hello. And welcome back, Lovely listeners for another exciting episode of JavaScript Jabber. Today on our show, we have myself as host, Aj O'Neil, Steve, our dad joker.

Steve Edwards [00:00:23]:
What,

AJ O'Neil [00:00:24]:
And then we have I'm I'm trying to find your last name now, Zach. Zach writes code. Last name Reitzcode.

Zach Lankton [00:00:33]:
That'll work.

AJ O'Neil [00:00:34]:
That's what it says. That's what I'm going with. Go ahead and introduce yourself. Tell us, what you're here for.

Zach Lankton [00:00:41]:
Yeah. My name is Zach Langton and or Zach writes code in this case. And, software developer, I've been writing code for 15 some odd years, probably more than that. Everything from c, 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 I like DevOps. I do a little bit of DevOps in my daytime daytime job, and I'm a containerization zealot. Bit of a Kubernetes enthusiast, but I'm very beginner ish on that.

Zach Lankton [00:01:18]:
Husband and a father. And recently in my very limited free time, a front end framework author.

Steve Edwards [00:01:27]:
That's good because we don't have enough of those.

Zach Lankton [00:01:30]:
Yeah. Right? We need more of that.

AJ O'Neil [00:01:33]:
Well, my first question is actually gonna be if I can just got something on my tongue there. Yeah. Okay. My first question is actually gonna 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 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 as, like, a unique thing about you.

Zach Lankton [00:02:02]:
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 1 server in 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 years ago, maybe 3 or 4 now, I just started trying to build that website, which I haven't updated in probably about that long. And that was one of those things that I put on there. It's like, hey. If you're looking for this, 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.

Zach Lankton [00:02:45]:
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 wanna build. And that's what I have, this one customer. I built a, custom ERP system for them, and I host it. So, they've been using that for 5, 10 years now. So yeah. I nerd out a little bit on the DevOps side of things, and I always wanted to have a 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.

AJ O'Neil [00:03:27]:
So do you use is it Proxmox?

Zach Lankton [00:03:30]:
Is that what

AJ O'Neil [00:03:30]:
you're using for okay. Cool. Alright. Yeah. I like I also am using Proxmox on a 4 server cluster with high availability and and all that.

Zach Lankton [00:03:43]:
So that you're further along than I am because I've just got the one server. No. It's not a cluster at all.

AJ O'Neil [00:03:50]:
Well, we we bought, on eBay the last gen servers that were being dumped, and now the next generation of last gen is just getting dumped because all of these companies you know, like, I mean, you know this stuff. You know? Amazon's running servers that are, like, 15 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, but,

Zach Lankton [00:04:22]:
you know,

AJ O'Neil [00:04:22]:
from And and so, yeah, we just we got them super cheap. I think it was about $600 a server, $700 a server, pretty much more or less maxed out.

Zach Lankton [00:04:34]:
Yep. Exactly.

AJ O'Neil [00:04:35]:
And so so yeah. So we we paid less than the cost of what someone would pay for 1 server, and we got the cluster. And anyway, but that's Yeah. That's cool. That's cool. Yeah.

Zach Lankton [00:04:45]:
That's what it's that's where it's at right there. Get them on eBay. Host them yourself.

AJ O'Neil [00:04:50]:
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 2 projects I have left that I haven't transferred. And like you, running some client stuff there as well. Hoping to open it up to the general public as well, but wanna do it in an automated fashion Yep. When we get to that point.

AJ O'Neil [00:05:07]:
But yeah. Anyway, so that was cool, just to see that and, fellow Proxmox user.

Zach Lankton [00:05:14]:
Oh, yeah.

AJ O'Neil [00:05:15]:
Now the reason that we actually, have you on the show or that that Dan reached out to you, I'm I'm happy to talk about, you know, any of it, by the way. I think that's that's totally fine. But, you know, Dan Dan was thinking that ReZact was a rather timely framework to discuss. So among the sea of front end frameworks, now we've got ReZact. Tell us about Reasact.

Zach Lankton [00:05:39]:
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 React 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 and for anybody who has. But it's also like Svelte 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.

Zach Lankton [00:06:11]:
It's valid JavaScript or TypeScript in this case, but it transforms it into, you know, code that does more under the hood. So like Svelte will, you know, you you do a rune 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 Svelte, there were some things about Svelte that I really liked, and that is that whole create a variable and just assign to it, and it'll update where it is. But I didn't really like the authoring of the components themselves in that.

Zach Lankton [00:07:12]:
It had to be one file. And I know there's a whole host of people out there who believe that you're you should only ever have one component in one file. And they may be right. They may be wrong. I'm not gonna argue that. I just know that I like to have the flexibility if I want to to drop a separate component right in the 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.

Zach Lankton [00:07:52]:
There's not a lot of frameworks that actually give you for like example, for like Redux or any of these other, you know, global state management libraries. What I've come up with is a 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, JSX, in the UI, etcetera.

AJ O'Neil [00:08:36]:
So signals is a thing that is I 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 I I my background in JavaScript is node, and and I do, like, stuff 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 I I think we had someone that that had talked about signals before, but I 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 at 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?

Zach Lankton [00:09:32]:
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, in React, you'll reach for useState in your component to manage a piece of state. The but, you know, in, like, preact, they've got signals. And so you'll use useSignal. And Svelte has signals as well. Solid has signals. All these frameworks have signals. The fundamental difference between like React, where you can throw a useState hook in your component, is that anytime you update that state, it will rerender the entire component.

Zach Lankton [00:10:11]:
Whereas signals are designed to not require needing to rerender the entire component. They're designed to render or, update as granular as possible the thing that is in the DOM. For example, a text node. If you create a signal, assign it the value hello 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 that's that it's attached to in the DOM, as opposed to trying to rerender the entire JSX component. So that's really what I think the key difference is between, you know, like state in React versus signals.

AJ O'Neil [00:11:01]:
So how is this different from the old, two way data binding? Like, what Angular really had its heyday with?

Zach Lankton [00:11:10]:
So that's another really good question because I was thinking about this. I have this in re in React 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 a long time ago. And they're 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, in Resact. And so it's different in that it is a one way data flow under the hood.

Zach Lankton [00:11:51]:
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.

AJ O'Neil [00:12:01]:
So the thing that's parsing the code is looking for mutation and then creating a function that calls an update routine?

Zach Lankton [00:12:10]:
Correct.

AJ O'Neil [00:12:11]:
Okay.

Zach Lankton [00:12:12]:
So it's it has a look of 2 way data binding in that you can just create a variable and you don't have to do the updates, which you can actually. So resax gives you that ability to step in and say, you know, I wanna 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 in React that will update the state. You don't have to do that in React, but you can. And as soon as you do, it you will now own the the cycle of the update.

AJ O'Neil [00:12:46]:
Okay. So here, a signal it 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 with a dollar sign is gonna get transpiled into a signal container?

Zach Lankton [00:13:00]:
Correct.

AJ O'Neil [00:13:01]:
Okay.

Steve Edwards [00:13:02]:
So just out of curiosity, I come from the view world. And so with the rewrite from Vue 2 to Vue 3, one of the big, under the hood changes was using proxy JavaScript proxies. And so I'm just curious. You know, I've everything I've seen about signals, you know, and I'm not a real under the hood guy. I'm more of the top level, you know, making the UI type of stuff. It seems like 6 or 1 and a half dozen or the other. Is that a an accurate statement when you're comparing, you know, the proxies versus using signals?

Zach Lankton [00:13:41]:
I agree with that. I well and I'll start out with saying that when I wrote an early version of Resact, I used, you know, the proxies to 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 I went away from that, and now I'm not using proxies.

Zach Lankton [00:14:24]:
I'm actually just writing or transpiling the code into getters and setters and updates and subscribers and things of that nature.

Steve Edwards [00:14:34]:
Okay. Yeah. With the the two way data binding and one way data flow, I know, like, in your view, when it when you're in components, it's generally you have props to pass down, then you and emit event. You know, if you wanna change from a child docu parent, then you emit event, you catch the event, then you do your thing. But I know within state, you know, within using Vuex, 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 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.

Steve Edwards [00:15:15]:
And I do know, you know, that you you were talking about having to rerender the whole component versus just the particular variable, and what this does for you is exactly that.

Zach Lankton [00:15:25]:
Yep.

Steve Edwards [00:15:26]:
You know, if I change a piece of static, it's just gonna change the right mesh screen with no no update in play or no re rendering of the whole component.

Zach Lankton [00:15:36]:
Yep.

Steve Edwards [00:15:37]:
So and then I'll go down another route and this is you know one of my well beaten horses just because it's something that I use so much is I do a lot of that also with something called inertia. Are you familiar with inertia. Js?

Zach Lankton [00:15:50]:
Not very much. No.

Steve Edwards [00:15:52]:
Okay. Short version is it's sort of a glue level between your front end and your back end and you can plug and play your front end and your back end with, you know, on the front end you can use Vue, React, Svelte. On the back end you can use Ruby, Laravel, Node, whatever. And it basically just sort of a glue layer that sits in between the 2 and hijacks your post request and uses some headers, and then, you use all your route definition, everything else is 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 gonna pass this data back and forth. It's crazy fast and very efficient.

Steve Edwards [00:16:34]:
And then you have, you know, it has some helper methods in there, like what's called a visit route visit where you can do that. Just go, okay. I want this data from the back end. Here it comes. All I'm doing is updating 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 React and that you wanna be able to just update certain things without the full p page rerender because of efficiency and speed.

Zach Lankton [00:17:04]:
Yes. I well, there is a except for there is no server component at all. I'm not at this point, this framework is all client side rendered just like the old days of the original, like the way we would do React applications in the in the in the browser. So

Steve Edwards [00:17:20]:
you're basically depending on what standard, like, GraphQL or standard REST API from your back end that you're communicating with?

Zach Lankton [00:17:27]:
Exactly. Okay. 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 wanna play around with this idea that I have, and and that's what became Resact. And and I'll be honest with you. I've got a lot of mileage out of client signed rendered apps, even with re react.

Zach Lankton [00:17:49]:
I you know, and I know that a lot of people and a lot of the solutions that have been created today around Next. Js and server components and all that stuff, are solving real problems. They're just not solving problems that I've ever experienced.

AJ O'Neil [00:18:05]:
Are you sure they're solving real problems?

Zach Lankton [00:18:08]:
Well, I guess I'm trying to be nice about it.

AJ O'Neil [00:18:12]:
Yeah. I just I I'm I'm I'm worn. I'm very, very worn. It it it just feels like, you know, the the the idea, like, the the 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.

AJ O'Neil [00:18:42]:
Yeah. Yeah. No. This is like there is a middle ground that is is helpful.

Zach Lankton [00:18:52]:
I I I actually feel the same way. I feel like the pendulum just keeps swinging, and it's gaining momentum. It's not reducing a momentum.

AJ O'Neil [00:19:01]:
Yeah. Oh.

Zach Lankton [00:19:02]:
And 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. Js and server components. I've played around with it enough, but

AJ O'Neil [00:19:22]:
I just lament it because I'd like, I 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 in in terms of just when people don't have a clear conception of where things are separated, they will eventually, you know, put something in the wrong place. Yep. 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 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 Turing complete JavaScript code.

AJ O'Neil [00:20:05]:
Okay. Well, you gotta 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 build. So then then you gotta refine your hacks to work with ES build. And then they come out with next and then it breaks again. And so now in some of this code, I have like 6 lines of boilerplate on either side, and all it's doing is, like, it's like a a u m d type wrapper, but it's like I don't wanna 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 require, which causes it to not wanna obey the exports.

AJ O'Neil [00:21:02]:
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 or something like that. That's that's where I'm I you know, maybe there is a use case for it, but the 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, oh, yeah. I gotta do this. I gotta do it. Yep. But they didn't. It's like Ian Malcolm from Jurassic Park.

AJ O'Neil [00:21:46]:
Just because you could.

Zach Lankton [00:21:47]:
Yeah.

AJ O'Neil [00:21:50]:
Anyway, I 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?

Zach Lankton [00:22:05]:
You know, I I've never been a huge fan of template strings, and part of that is just because I, 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're they really like it. I just never found that as 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.

AJ O'Neil [00:22:34]:
Okay. Yeah. I mean, ostensibly, you could still write the tags right in the return. It'd just be instead of a parenthesis, you'd be using a tick mark.

Zach Lankton [00:22:41]:
Yeah. Yep. Exactly.

AJ O'Neil [00:22:43]:
But

Zach Lankton [00:22:44]:
now

AJ O'Neil [00:22:44]:
And and, hopefully, they come out with the triple tick, which will preserve white space the way that you'd expect it to.

Zach Lankton [00:22:51]:
Oh, yeah.

AJ O'Neil [00:22:53]:
So, yeah, if you right now, if you use the single tick, the 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. Yep. The triple tick spec is to make it, like, with the triple quotes and 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.

Zach Lankton [00:23:34]:
Would 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.

AJ O'Neil [00:23:47]:
Yeah. Because then then you almost need a transpiler just because you just you want your white space to look right.

Zach Lankton [00:23:53]:
Yep. Yeah.

Steve Edwards [00:23:58]:
So, Zach, I probably good idea, I think, here to sort of walk through all the stuff you highlight on the exact IO site.

Zach Lankton [00:24:05]:
Okay.

Steve Edwards [00:24:06]:
And, you know, if there's something else we missed, because I have some questions after, you know, perusing that and and, that what you're talking about doing. I think I get what you're shooting for, what you're trying to do, but I just wanna 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?

Zach Lankton [00:24:33]:
I guess we'd be getting starting into getting into, like, I think we've covered most of it, but, there's a piece that I guess I wanna cover a little bit of, and that is the farm handling aspect. And 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 in in React. And that is one thing that I strived to do differently in Reesact, 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 chain 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 text box, essentially. Right? Because if you, type in a text box that has an, unchanged event handler and you're not updating the state that's in the value, nothing happens inside that text box. Right? And that was just wild to me.

Zach Lankton [00:25:57]:
I'm like, these are browser components or, inputs, elements, whatever you wanna 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 gonna circumvent it. We're gonna catch your keystrokes. We're gonna update the state, and then we're gonna rerender the whole thing. And then we're gonna update the value in that input so you see the keystroke that you hit. And that has just driven me bonkers. 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.

Zach Lankton [00:26:34]:
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 on change. If you add your own on change, then it does. 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

AJ O'Neil [00:27:09]:
That's what it does anyway when you do on change in the browser in the first place.

Zach Lankton [00:27:14]:
Correct. Yeah. I guess I'm not a 100% sure how it works in the actual native browser. Is it actually blocking 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.

AJ O'Neil [00:27:36]:
So let's see.

Zach Lankton [00:27:38]:
Because you can

AJ O'Neil [00:27:39]:
It 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 hijack it in different places. So depending on what you're trying to hijack, you can either hijack it 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 they have to be handled within the 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 I don't remember where that has to get handled at.

AJ O'Neil [00:28:28]:
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, you know, whether that key press will get displayed or not.

Zach Lankton [00:28:49]:
Yeah. So that is that is correct. And, actually, as we've sitting here talking about it, I've been thinking about it. I'm like, yeah. That is basically what I I believe if you do a non change and you just hit event prevent default, I don't think the keystroke shows up. I think that's enough. So whether or not we're 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, 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.

Zach Lankton [00:29:31]:
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 to exact.

AJ O'Neil [00:29:51]:
Well, I 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 2 was 5, 10% better. And the m 3 is, like, another 5, 10% better, you know, 30% better on the things that they actually got wrong the first go around and were 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 do. So software has to get better. The software is where we can literally get tens of thousands of times more performance, especially, you know, in the web. Right?

Zach Lankton [00:30:48]:
Yep.

AJ O'Neil [00:30:49]:
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 wanna subscribe to a newsletter because you want to know when a product is gonna 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.

Steve Edwards [00:31:31]:
Yep.

AJ O'Neil [00:31:31]:
You know? And it it'll hand it'll do all the things, but people people basically you know, they have these components. And then instead divs. And then every single one of those events is being reimplemented in the component stack rather than letting the 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 reimplementing it in a way that is, like, literally literally prevents the business objective from from being fulfilled depending on, you know, the the 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? Nope. Most websites today, that won't work anymore. Nope. And and this is because of this, like, componentization and the hijacking and everything.

AJ O'Neil [00:32:31]:
So I see I I like, I love seeing in your example that it's like, hey. We're gonna use an input, like, a literal HTML input, and we're just gonna do type equals email, and that's gonna do stuff for us.

Steve Edwards [00:32:44]:
Yep.

AJ O'Neil [00:32:44]:
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, required as HTML, type as HTML, name as HTML, placeholder as 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.

Zach Lankton [00:33:12]:
Yep.

AJ O'Neil [00:33:12]:
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?

Zach Lankton [00:33:21]:
So in this particular example, I am hiding a lot. Right? Because, obviously, you're not seeing the label, but it 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. So 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.

Zach Lankton [00:34:10]:
And I think there's another piece where the validation without JavaScript anyway, it's limited. Right? Like, you do the type email and you get a lot. But if you wanna do anything more than stuff like type email, you gotta branch out.

AJ O'Neil [00:34:30]:
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 for putting in a regular expression that has some confines. But Yep. You know, like, you get regular expression side stuff. So I'm I'm particularly interested in the email example. Like, would I what behavior would be different if I used a lowercase I rather than an uppercase I on that input for the for the email example.

Zach Lankton [00:34:58]:
None. If you wanted to, Razak absolutely lets you just do a basic HTML form that will submit on enter. You can go all the way back to the original, just use the browser. In fact, Resact 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 a JSON 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 Right. A JSON blob.

Zach Lankton [00:35:34]:
You ship you know, send a request off to the server, get a response, do something, update the UI. That's all completely optional with Resact. You don't have to do any of that. 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 j your JSON bundle a JSON, JavaScript bundle that gets shipped to the client is just incredibly tiny. It's actually smaller than us. Well, Svelte 4. We'll see how Svelte 5 is.

Zach Lankton [00:36:08]:
They're claiming that it's even smaller than Svelte. They're claiming Svelte 5 is smaller than Svelte 4. So we'll see when that actually comes out how much smaller it actually is, which is impressive because it's already pretty small.

AJ O'Neil [00:36:23]:
So well, I I guess my number one question on that is or the 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 autocomplete 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 as 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 Resact using that same required, or do you have some sort of custom pop up that, yeah, I can edit the CSS and make it look different?

Zach Lankton [00:37:24]:
Yeah. No. We're we're not using the built in browser's validation display, if that's what you're referring to.

AJ O'Neil [00:37:31]:
Yeah. Yeah. Yeah.

Zach Lankton [00:37:32]:
Because it's so painful. It's so hard to try to make that look the way you want it 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, form inputs. 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.

AJ O'Neil [00:37:56]:
I I think that's a pity, though, because this is a luxury that Apple and Android developers get. You know, you you don't 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 Yep. 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 is a real pity.

AJ O'Neil [00:38:39]:
Like, I I agree. I agree that the the the validation pop up is not the ideal for every single scenario. It's not like 90% of people want this as as, like, the height of perfection. But I also the other way around, I just have a hard time seeing 90% 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 I don't really see that either.

AJ O'Neil [00:39:18]:
So I I get I get the argument for wanting to have it be custom, 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 I mean and also, this isn't even on the happy path. Right? I mean, you're talking about somebody types in a phone number wrong.

Zach Lankton [00:39:55]:
Yep.

AJ O'Neil [00:39:56]:
Do they need it to be Yep. In your company colors in order for them to understand that they need to fix a missing digit?

Zach Lankton [00:40:03]:
Yep. No. I I actually went down this path, with, 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, 90% of the time, these people are just gonna 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.

Zach Lankton [00:40:33]:
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. Alright. That's, I guess, how this is gonna go. And 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 Resact.

Zach Lankton [00:41:01]:
So it's like a completely custom from the ground up written validation and masking engine. And you can do

AJ O'Neil [00:41:11]:
Go go ahead.

Zach Lankton [00:41:11]:
Well, and you can do exactly what we're talking about as far as, you know, designing in CSS your error messages and how they display, when they display, how they display, all of that to your heart's content. But absolutely disabling the browser's native, you know, responses to those validations.

AJ O'Neil [00:41:34]:
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 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 it seems like that could work. If all we're gonna 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 United States. Most people, like, they might have in their heads, they're gonna scale the international, but they're not.

Zach Lankton [00:42:19]:
Yep.

AJ O'Neil [00:42:19]:
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 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 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 spacing.

Zach Lankton [00:42:54]:
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 number field.

AJ O'Neil [00:43:06]:
Oh, I I didn't even I didn't even notice.

Zach Lankton [00:43:08]:
Yep.

AJ O'Neil [00:43:09]:
Yeah. But then but then it's like, okay. Well, realistically, we're only going to be doing US, you know, email add or, phone number. So we could we could actually we could let that one slide that it's not gonna handle 200 different formats for for phone number because we're practical. Right?

Zach Lankton [00:43:29]:
Yeah.

AJ O'Neil [00:43:29]:
We're not we're not we're not having a delusion that we're gonna go plan at scale with our if the with 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, and American Express. So your credit card validator has the the 16 dots, and do the dots mean that it turns into an asterisk as they type or it stays a dot? Or what what does the dot mean there? It says mask and mask slots?

Zach Lankton [00:44:02]:
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 numbers. And then as you type, you'll see the space, you know, be inserted as you type.

AJ O'Neil [00:44:23]:
Okay. Now I'm now I'm trying now. Okay.

Zach Lankton [00:44:25]:
And then, you know and yeah. And so you see the min length is 15 and the max is 16. And I actually I actually work in payments, and it's all US based payments that we we currently work with merchants in the US. We don't work with international merchants. So we have been doing 15 to 16 digit, card inputs as long as they've been in business. And there has not been, there's never been a request so far from someone saying, well, hey, I need you to accept the 19 digit version or the 20 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, no. The the validation for the actual check will actually work with either, the 15 digit version for American Express or the 16 digit version for Visa, Mastercard, and and Discover.

Zach Lankton [00:45:17]:
The the algorithm that's used to basically validate a card number is very, very simple.

Steve Edwards [00:45:24]:
It's

AJ O'Neil [00:45:24]:
like CRC 32 or something.

Zach Lankton [00:45:27]:
Yeah. It's basically something along them lines. Yeah. And so it's not and that it's not even actually telling you that the card number's 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 to the card network brands and all that, and then they actually will return a response if it's real or not.

AJ O'Neil [00:45:47]:
So but the mask, there's I think there's 4 different no. 3 different formats for a credit card if I I I don't remember off the top of my head, but American Express Yeah. Starts with 5 digits.

Zach Lankton [00:45:59]:
Yep.

AJ O'Neil [00:46:00]:
Visa does 4. Visa, master, I'll do 4. And then discover is that I don't remember. Is it 4 or 5? Anyway, so the the 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 gonna mask it in a weird way that's unfamiliar to them. Right?

Zach Lankton [00:46:21]:
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 3. And it's like, if it's 3, it's American Express. And so we will update the mask to fit that format. When you as soon as you hit that first keystroke, you hit 3.

Zach Lankton [00:46:44]:
Now this example isn't gonna do that, but in our other fields that at work, that's how that works. You hit 3 and it goes it changes the format of the mask.

AJ O'Neil [00:46:54]:
So my my question there is when you when you look at a situation like this, I 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 a 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?

Zach Lankton [00:47:23]:
Mhmm.

AJ O'Neil [00:47:23]:
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 significant advantage to striving for this kind of template like syntax that, you know, it looks so good versus just, yeah, just do it in JavaScript 90% of the time?

Zach Lankton [00:47:48]:
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, 16 dots with spaces, is no longer mask equals 16 dots spaces. It's mask equals a signal. You know? And then you're updating that signal based on and now you've got a on change event or a non 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.

Zach Lankton [00:48:23]:
And then once I move, you know, beyond or or 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 idyllic simple example into the complex scenarios that you're gonna 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.

AJ O'Neil [00:49:09]:
Okay. Well, here's here's another thought that I just just thinking of. There's a 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 in 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 bounds 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 you can you you 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 1,000 or tens of thousands or 100 of thousands or an infinite number of ways that you could wanna do it.

AJ O'Neil [00:50:03]:
There's, I don't know, on the small end, like, 3 or 4 and on the big end, maybe a a dozen or 2. 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 or 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 of input, and it handles phone numbers as a 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 the mask the last 4? Or do you want or do you want to unmask the last 4? Or do you want to unmask the whole thing? Like, I mean, there's literally for credit cards, there's literally a PCI document that I mean, you know this because you you you know, like there's a PCI document that tells you what your options are. So you have a 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.

Zach Lankton [00:51:30]:
Oh, I would love that. Like, I think if there was a way to standardize this and 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 I don't know what that looks like. Like, how Well, no.

AJ O'Neil [00:51:51]:
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.

Zach Lankton [00:52:04]:
Sure. Yeah. I could easily create a, I 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 Rezaq. This is code that I could port to, and I have. It's actually currently existing in my work infrastructure code.

AJ O'Neil [00:52:24]:
God bless you.

Zach Lankton [00:52:25]:
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 here 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 it 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 1.

AJ O'Neil [00:53:33]:
I'm I'm sure we'd find dozens, but, finding, 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

Zach Lankton [00:53:48]:
Yep.

AJ O'Neil [00:53:48]:
That I think is not going to be as as popular as like an entire UI kit. Right? And that that's that's what I'm talking about. It's 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 in 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, pastes in 2 characters and then stops. And it pastes them in wrong because it has, like, the leading one. So it's, like, 180, and then it stops.

Zach Lankton [00:54:35]:
I'm dying. I hope that worked. Did it work? You were able to post in a number pay paste in a number with dashes, and that and that worked?

AJ O'Neil [00:54:44]:
I I didn't try. I'm gonna I'll try it right now.

Zach Lankton [00:54:46]:
Oh, yeah. Right now. I'm dying. Oh, I'm, like, curious to see what happens here. We're

Steve Edwards [00:54:53]:
on the edge of our seats waiting for AJ's copy paste test.

AJ O'Neil [00:54:59]:
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 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 Yeah. That I it kept it kept the the trailing 5.

Zach Lankton [00:55:41]:
Gotcha. Yeah. So there's some work there to be done.

AJ O'Neil [00:55:46]:
I mean no. I mean, that's good. That's, like, that's better than the experience of 99 point

Zach Lankton [00:55:51]:
scanning. Is so hard. Like, it is one of the hardest things to do right. And I'm not gonna sit here and say that I did it right because I don't know. I you we're talking about dashes and dots now, whether or not those work and pasting. And that's the first time I've ever thought to test for that. So and I yeah, It's definitely a very, very difficult thing to to implement, especially, like, from scratch in JavaScript.

AJ O'Neil [00:56:21]:
So with React, it it sounds like this is something that, you know, you're not necessarily saying, hey. I I think that this is gonna be the next hot framework. This is something that has personally brought you value. It's brought value to your clients, and that you you're not sure if it brought value to your clients.

Zach Lankton [00:56:41]:
Well, I don't have any clients that I've used the framework with. So I that's just so far, there's a this is a 0 user framework. I've got, you know, a discord channel where some people are 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 wanna 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.

Zach Lankton [00:57:12]:
I'm not. He's like, I want you to do 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, like, as far as I know, 0 users of this framework.

AJ O'Neil [00:57:26]:
Okay. Alright. So if

Steve Edwards [00:57:27]:
So it's because you wanna use async await then instead of promises. Is that it? Or

Zach Lankton [00:57:32]:
What's as far as the, like, yeah.

AJ O'Neil [00:57:38]:
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 to see what the market decides the value of it is. But it's I mean, it seems like it's high quality.

Zach Lankton [00:58:05]:
Thank you.

AJ O'Neil [00:58:06]:
So but what like, what's what's the moral of the story with this? You know, you you you created a framework and and then what?

Zach Lankton [00:58:15]:
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 Svelte or anything of that nature. I'm not that grandiose.

Zach Lankton [00:58:58]:
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.

AJ O'Neil [00:59:08]:
So what what what's the most valuable thing about this experience to share with our listeners?

Zach Lankton [00:59:21]:
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, you get a really valuable insight into the process. And you only get that if you try to build your own front end framework. And so that's what this started out as. And 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.

Zach Lankton [01:00:14]:
And it brings you a level of, you know, 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

Steve Edwards [01:00:33]:
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.

Zach Lankton [01:00:53]:
Yep.

Steve Edwards [01:00:54]:
So where you have so the gist is you have an underlying, say, a dataset or a value. It could be a scalar value. It could be a an array. It 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, 2 plus x, You know, it's gonna 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 gonna rerender rerender the value when something changes. So if you go to, you know, your page loads and it hasn't changed, then you're in other words, you're using a cache value. Almost is the way you look at it because Vue uses computed values, and that's exactly what this does.

Steve Edwards [01:01:47]:
I'm watch I'm, you know, reading this. I'm going, this sounds like a lot like a view computed value behind the scenes. Yep. But the overall gist I'm getting in is specifically specifically, if you look at the store's page, where you're talking about what you do with React as compared to Redux React. Right? And you've got, hey, set up the store, you create reactions in your reducers, you know, provide Redux, store, 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 friend frameworks have to implement other tools to do the same thing. Is that a fair statement?

Zach Lankton [01:02:41]:
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, you know, inside a component. The 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 use to create signals everywhere.

Steve Edwards [01:03:08]:
Okay. Yeah. It's I'm noticing that most of your your, your examples are in comparison to React. So, obviously, we talked about ahead of time about the naming of it's React. 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 React is doing stuff, so I'm gonna complete create a a more simple and more efficient way to do it. Is that was that the driving force behind this?

Zach Lankton [01:03:36]:
It's a bit of it's a bit of that. And I'd say because I've played with a lot of the frameworks. I've played with Svelte and Solid. And, unfortunately, I can't say that I've played with Vue as much. A long time ago, when Vue 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'd make me think of Svelte and how Svelte handled something.

Zach Lankton [01:04:08]:
And I'm like Yeah.

Steve Edwards [01:04:09]:
I see a lot of Svelte in here.

Zach Lankton [01:04:10]:
Yeah. And that was exactly the a lot of the inspiration was like, I I want JSX. I want function components, but I also want Svelte. And so that's really where this, you know, I guess, inspiration came from.

Steve Edwards [01:04:27]:
So why not just use Svelte? Why do this on instead of

Zach Lankton [01:04:30]:
using Svelte? In particular, Svelte, you know, doesn't really use JSX. It's using its own, you know, language, really. It's like a whole load.

AJ O'Neil [01:04:42]:
Preprocessor on that?

Zach Lankton [01:04:45]:
In Svelte or in React?

AJ O'Neil [01:04:48]:
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 strings and a couple of functions added to it. I could be completely wrong about that. I mean, this may be absolutely wrong, but I my understanding was, like, basically, it it's just doing string escaping for you.

Zach Lankton [01:05:13]:
So in this particular case, the transpilation so I'm using v, and it's using, whatever it uses. I'm not a 100% first in the whole underlying structure, but I've used created a plugin, 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 a variable. You know, it's actually looking at the, oh, AST 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 gonna do a setter here.

Zach Lankton [01:05:52]:
Oh, you're gonna read this value here. Oh, I'm gonna do a getter here. That's what the translation is. And that actually happens after the JSX gets compiled into, well, code that can be read by the browser. So it's like if from a step standpoint, Resact doesn't do anything until after the JSX has been, transpiled. And then the plugin picks up after that and it parses that code to look for, you know, these these, you know, dollar, you know, variables. And I think think I've got a couple keywords in here too that it looks for.

AJ O'Neil [01:06:31]:
But you but you you don't feel like that could be done in Svelte? You couldn't you couldn't just run a preprocessor step on Svelte and then have it run its processor

Zach Lankton [01:06:41]:
Maybe.

AJ O'Neil [01:06:42]:
After the

Zach Lankton [01:06:42]:
I I I, you know, I probably could, but then I'd have missed out on all the fun of starting from scratch.

AJ O'Neil [01:06:48]:
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 do a hello world framework or something like that. Yeah. You know, take that take that path and gain some of the I it it's maybe it's not so much. I you 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.

Zach Lankton [01:07:25]:
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 there I 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 kinda 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 a transpiler because that's already done.

Zach Lankton [01:08:11]:
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.

AJ O'Neil [01:08:45]:
Sure. Yeah. I I mean, I think that's that's fair. Alright. 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. Is there any last thing you think, man, I wanna get to this next time, but give people a teaser for this time?

Zach Lankton [01:09:07]:
No, actually, I I feel like I covered a lot, even more than I had planned and prepared to, cover. So I feel pretty good.

AJ O'Neil [01:09:15]:
Alright. Great. Well, then we will go ahead and head into picks, which is just where we, give us, a a a short or 15 minute long, snippet about something that we're into recently. And we'll go ahead and let Steve start us off with that. Steve, do you have some pics for us? Or

Steve Edwards [01:09:42]:
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're listening to the podcast, but I have 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.

Steve Edwards [01:10:11]:
She can't afford a Lambo. They just take a Uber. It's a long time ago. You know, I used to have a I had a dog. I had a a legless dog, and his name was Cigarette because every morning, I took him out for a drag. And then finally,

Zach Lankton [01:10:33]:
oh, where's my mouse going?

Steve Edwards [01:10:35]:
I'd like to say welcome to the plastic surgery addicts group. I see a lot of new faces here today.

Zach Lankton [01:10:43]:
Nice. Very

AJ O'Neil [01:10:44]:
good. Good. That one was good.

Zach Lankton [01:10:47]:
Yeah. And

AJ O'Neil [01:10:48]:
the dog one too. I you have a lot of good ones today. Yeah. I No. You have to be a good one. More used to it and my my expectation of quality of humor is declining, or or you're getting better, but I'm not sure which one.

Steve Edwards [01:11:02]:
I think it's just probably you're getting numb, AJ, is what it is.

Zach Lankton [01:11:06]:
I I liked it. I enjoyed it. I actually got some genuine laughs out of those. So, but I'm also a dad. I don't have as many dad jokes. I don't have any dad jokes to to to to say today, but that was fun.

Steve Edwards [01:11:18]:
Alright. That was a that's all I got.

AJ O'Neil [01:11:20]:
Alright. I will pick I did I mention last time that I've been listening to the Andromeda Strain?

Steve Edwards [01:11:26]:
Yes. I believe so. I remember that discussion from previous.

AJ O'Neil [01:11:30]:
It it's I I really did enjoy the book. It's it's written in 1969. 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 com computers being able to do more than they can. It's like it's it works. It it works. It's it's I would say that it's that it's 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.

AJ O'Neil [01:12:15]:
And in another 200 years, computers still won't be able to do those things, but people will still believe that we're right on the cusp. And the one thing the one thing about the book is that it just ended. And then I was like, wait. What? 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. It just

Steve Edwards [01:12:53]:
Sort of like the sopranos or that type of thing?

AJ O'Neil [01:12:56]:
Or I don't know. I didn't I didn't watch the sopranos, but

Steve Edwards [01:12:58]:
famous black screen where it just everything just stops?

AJ O'Neil [01:13:02]:
I I don't know about it. But Okay. Just the the the ending was completely unsatisfying because the book has all this buildup. 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.

AJ O'Neil [01:13:31]:
But that said, you know, Michael Crichton's cranked out a lot of books. A lot of them, pretty darn good. And in drama to strain, I I think I'd say is worth the listen or the read. And I I don't know. Hopefully I I think I spoiled the ending already by saying that it ends in a sentence. Because I'm just like, 3 quarters the way through the book. I'm like, man, this is a lot to wrap up. How are they gonna tie this all together?

Steve Edwards [01:13:58]:
They don't.

Zach Lankton [01:13:58]:
They don't have to. I mean, they don't.

AJ O'Neil [01:14:00]:
It's just like it's 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 3 week I mean, like, as a web developer or whatever, you know this. Right? You spend 3 weeks investigating a technology thinking that you're gonna switch databases and use the latest framework.

Zach Lankton [01:14:22]:
Yep.

AJ O'Neil [01:14:22]:
And then it turns out that all you needed to do was type equals email on the input field. So

Zach Lankton [01:14:31]:
Very true. Yeah. I, I'll check that out. I haven't read any Michael Creighton in all in a long time, actually. So, so I I think I'm due.

AJ O'Neil [01:14:39]:
I don't know if he's come out with anything a long time. I don't know if he's still alive. I don't know what his age was or anything, but Yeah. I I loved Jurassic Park. Although I think that they did the movie better than the book. Not that the book was not done well. Yep. John Hammond is a much more relatable character in the movie.

AJ O'Neil [01:14:56]:
And there's there's just a few things that, they're 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 the movie is better than the book in the Hunger Games. Like, I would say the movie was refined for Jurassic Park. In the Hunger Games, the movie's telling another side of the story that you don't get from the perspective of the narration. But, yeah, I I like I I like a lot of his stuff. I think it's I think it's done well. I I might pick up some more at at at some point, although I've got a backlog of, like, 20 books to read slash listen to. So I canceled my Audible subscription indefinitely until I can actually work through that stuff.

AJ O'Neil [01:15:37]:
But, anyway, why don't you give us a couple of your pick, Zach?

Zach Lankton [01:15:40]:
Well, I just 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 this 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 bell to anybody? I think it's relatively new, like maybe just came out, like, even this year.

Steve Edwards [01:16:09]:
Sounds I mean, obviously, I know who Jeff Daniels is, but, I haven't I think I've heard about it or seen it mentioned. I'm not familiar with it.

Zach Lankton [01:16:17]:
So it's basically he's a real estate mogul in, I think Georgia. And, you know, he's like this big big to do. He's got, you know, lots of real estate in this 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 freedom that, I don't wanna 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.

Zach Lankton [01:17:19]:
Was this side story of this lawyer and how he helped, this gentleman basically through, like some legal troubles. So I don't wanna give away too much, but, really good. Recommend it. I think it's, I think it's a fun watch. A man Is it

Steve Edwards [01:17:36]:
like an ongoing series, mini series type thing? Or

AJ O'Neil [01:17:39]:
No. It's based

Zach Lankton [01:17:40]:
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 Wolfe. So it's based on the book Tom by Tom Wolf named a man in full. So I don't think it's gonna be a continuing thing. It's a mini series. Okay.

Zach Lankton [01:18:01]:
So 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 go ongoing anymore. Like, I feel like I'm, like, already beyond season, whatever, 1, 2, or 3 of things that I wanna watch. And I'm like, I don't have time to catch up.

AJ O'Neil [01:18:21]:
I 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, like,

Zach Lankton [01:18:34]:
e Become the same thing. Like

AJ O'Neil [01:18:36]:
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 3 seasons by having them separate and then get back together again. And, you know,

Zach Lankton [01:18:48]:
it's there's

Steve Edwards [01:18:50]:
Yeah. That's sort of the, the 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 30 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 here it starts. Here it ends.

Steve Edwards [01:19:10]:
It's done. You know? And then they to be honest, then they do a whole new telenovela that's sort of like the previous one with different plot twist. You know? So it depends on your variation. You know? Well,

AJ O'Neil [01:19:22]:
there there's so many there's so many shows that could be great if they would just end them 6 or 20 seasons earlier.

Steve Edwards [01:19:32]:
Right.

AJ O'Neil [01:19:32]:
Like, give me 1, 2, 3 seasons. Maybe 4 is like a reprise or a bonus or a, you know, a year in the life, but don't don't give me 8 seasons. Like, just give me a good story.

Steve Edwards [01:19:47]:
Yep. Yeah. The one of my faves was on Amazon was the, John Krasinski, Jack Ryan series. Yeah. I loved those series. Those are so good. The third one is a little weak, but the first two were really good.

Zach Lankton [01:20:03]:
And they

Steve Edwards [01:20:03]:
were just, like you know, I think it was 8 episodes, start, done, end of the storyline. You know? And then it come back, and I think this last one is third one is supposedly the last one. That was great. I was hooked on those things, man. I'd be sitting at night watching them on my phone, you know, when I'm supposed to be in bed. But, yeah, stuff like that is really good. So Alright.

AJ O'Neil [01:20:24]:
Well oh, I should've switched the screen with Bob earlier. We were all chatting. Anyway, thanks for coming on. It's great to have you, and have a nice life.

Steve Edwards [01:20:35]:
Hopefully there hopefully, there's a a good reaction to this

Zach Lankton [01:20:40]:
episode. Well, thank you guys for having me. I really appreciate it.

AJ O'Neil [01:20:43]:
Yep. Alright. And to all the listeners, thanks for tuning in. Well, thanks. And, I I guess we'll go ahead and click the in stream button.

Steve Edwards [01:20:50]:
Alright. Adios.

AJ O'Neil [01:20:52]:
Adios.