Hey, folks, welcome back to another episode of JavaScript Jabber.
This week, on our panel, we have Steve Edwards.
You know, from a cold and rainy Portland, which is typical for this time of year.
A j O'Neil yo ya yo, coming at you live from a beautiful day in the shed.
I thought it was the purple room.
It changes every time, you know that.
No, it doesn't. It's always purple.
Well yeah, I mean it's obviously it's purple for those that can see.
Right. Yeah, he won't tell us.
Where he is, but folks just look at the counting records that he Healan's house. I'm Charles Maxwood from Top End Devs and we have a special guest this week, and that's Corey Brown. Corey, do you want to say hello and let people know who you are and kind of what your background is?
Sure? Hi, Corey Brown, I'm coming at you from Saint George currently, not where I regularly live. That's where I am right now.
It's supposed to be warm down there.
It's warmer than where I Yeah, it's warmer than up north, that's for sure, which is why we're here.
I have a friend that lives down there. I'm always so jealous.
It's it's love.
Yeah.
I I am a well currently I'm architect at a place called Omni. We are a GPM company, JP Morgan Company, and I've been in the industry for about fifteen years. I enjoy speaking and sometimes on occasion, arguing with people about childscript stuff.
Yeah, you picked a fight with our friend Dan and then he ran away.
That's right. Well it was either that or he had something else going on.
But you know, it reminded me of the argument and a Family Guy where the rich guy rolls up and he says, oh, Reginald, I disagree and peels off those kind of the extent of the argument.
Ouch.
Yeah. Yeah.
So anyway, so yeah, from what I am gathering, and it looks like AJ was part of the conversation on Twitter as well, and so you all can tell me where I get this wrong.
But there was a conversation.
AJ was suggesting maybe we do an episode on some of the less understood dom APIs, and then Dan asked the question, do React developers really need to understand the dom APIs because React does a lot of these things for you, and you said, yeah, they do, and he kind of disagreed and So the idea was you could come on and that conversation with you, and then he ran away because you're so intimidating.
I think it's weird, but it's.
Got to be. It's very a little bit of gray right there. Really, Oh, you rus really know what he's talking about.
That's right. You've got a real gray beard in the house, folks.
So anyway, let me know if I missed anything important there, and then if you or AJ want to chime in and give us a little more context.
We get going on talking about this because I think it'll be interesting. Yeah.
I think that's the sum of it. And had I known that you could get on this podcast just with a simple I don't think that's quite right comment, that would have done it a long time ago.
But no, it's good, all right. So yeah, so is there anything more to it? Did miss anything?
No?
I think I think that is the That was the conversation we had on Twitter. But you know, should I guess the premise of the argument is should dude react? Developers need really need to understand the dom is is react sufficient for your needs? I think there's there's a bigger question under that. More like, given the rise and the universality essentially a frameworks out there. The NILA jobscript
crowd has grown increasingly smaller. So given that you really a lot of people make the argument you really can't do jobscript work anymore without working inside of a framework. Therefore, do you need to know the platform upon which that framework is built or those frameworks sufficient to accomplish everything you need? Do you want to live in the abstraction or do you need to be able to dive down into the metal Sometimes, at least that's the way I am thinking about the problem.
The question, and your answer, it seems is obviously, yeah, sometimes you need to get into the metal. So do you have examples or do you have an argument for that?
Yeah?
Actually I had. It was interesting just a couple of days after that conversation, which made it sound like it was a it was a monumental thing. It was kind
of a passing thing. But with that said, just a couple of days later, I was working on a problem and just it was attaching a pop over a drop down and kind of anchoring it to a to an element, and I was refactoring something that'd done this, and the original the old version was using just pure react as much as React as they could, so using all the hooks and all that stuff. And even then you have
to you have to do some some event listening. Even when you're trying to go completely into React, you have to do event listening, so you ad event listener on scroll and and that sort of stuff. But in the refactor, I just ripped all of that stuff out and I did a very simple event listener on scroll and an event listener on on resize and use the same handler for both. And it was not The previous version had
a lot of bugs. It would not track well, it would drift, and when things things would get out of whack. Ripping all of that framework stuff out and dropping just down into the very simple I mean scroll eventlisteners and reset event listeners are not like new domain pies. They're super they've been around forever. But just leaning on those like fixed all of the bugs that had with it.
It is now buttery smooth. And it was kind of a lesson that these frameworks they're designed to do something that like a specific thing, and when you're doing what those things are designed to do, they work really well and you should lean into them, but they they aren't designed to do everything, and when you try to force that square peg into that round hole. For everything you try to do and you are not aware of your disregard the platform upon which it's built, which is designed
to do a slightly different thing, you can you over complicated. Actually, I was just reading this morning. I was rereading out of the tar Pit that that old article I can't remember the author's names. That's really about complexity, about the difference between necessary complexity and unnecessary complexity, and depending what you're trying to do with the frameworks, can introduce a lot of unnecessary complexity. And that's what I found. That's what I happened then was fifteen years.
You know, check I have to add the obligatory joke in here that this seems like a really overreaction.
Oh to this question.
Wow, there it is, But you know, I mean, so Corey, My background is I started out with PHP straight PHP World, and I got into droupil for a while and then Angular and View. I have never played with React myself, but to me, I'm like, my answer to this question is duh, yes, you need to know both. I'm just like, yeah, how would you not need to know the underlying basics? Of any given language. There's no way that any framework I think, is going to be able to do everything
that the underlying platform can do. And you know, I listened to as woke as he is. I still listen to Chrispherd Nandy quite a bit, and you know, I get his newsletter. He makes a lot of great points. You know, you listen to other podcasts and people talk about using the platform. You know, use the platform, use the dom APIs, use what's already there, and even in view and uh and uh Lara Bell and Drupel. You know, there's a lot of helper functions. There's a lot of
things that will do stuff. But time and time again, you just got to get down to the basics and use some of the basic tools. I mean, a framework's not going to do everything, and why should it, you know.
Yeah, yeah, and more than that, a few more things. I add a little bit of color to that. So the original the new one uses the new popover API. I don't know if any of you guys know of it or used it. It's fantastic, it's lovely.
I keep wanting to play with it.
Yeah, I've seen a lot about it, haven't had a chance to get down and use it yet, because that's a you know, that's one thing that javascripts had to do a lot of anytime of pop up, pubble or stuff with dialogues, modals, whether it's date pickers, you know, you name it, that's always something jobscripts.
I saw that was in the spec and I was just like, oh, my life just got better.
But oh it's it's a delight. And ninety percent of the code I was able to eliminate from the pure React version was just state management, which again goes back to the out of the Tarpet article where it identifies this primary source of a necessary complexity of state management. And you can just eliminate all of that. You do not have to worry about it. And so you have
the scroll handlers and the research handlers. But the thing that really reduced the complexity of it entirely was the pop over API, which is not a vailable it's not a React thing, it's a platform thing.
Right.
It reminds me very much of I mean, you guys, I'm sure you all remember the the left pad incident.
Comes up with eight lines or something like that. Yeah, the Internet.
But can you give people context because I'm sure we have listeners.
Yeah sure, so I okay, So I love jobscript I love the jobs community. I have been doing it for fifteen years. I have I've learned of the languages, but I have only ever been professionally paid to write JavaScript. And but one thing that the jobscrip community does, I think poorly or has done poorly is an over reliance on abstractions, overliance on libraries, overliance on on frameworks.
What is not just a JavaScript problem. I'm just gonna point that out. No, everybody does this.
Well there, Yeah, I think the some do it better than others, but fair but yeah, So what it happened is in this over aliance on on foremeworks, you know, the hyper hyperrization of don't repeat yourself. We have created libraries so we never have to write the same thing over and over. Of course, so I'm tangenting a little bit. The libraries end up all the overhead of importing it and do this all their stuff, end up writing more code sometimes then it would be just to write the thing.
In this case, that's exactly so. This library literally pads the left side of a string, so the beginning of a string with some characters that you give it right. Turns out that there has been for a very long time a native way to do this in JavaScript, but we designed a lot of people decide yeah, shocker, a lot of people decided, no, no, we're gonna use library because because this is going to be better tested. I don't really understand the logical.
Well, I think that pads start came after left pad it may. I think that pad start was one of the when they were calling it ECMAScript six where they were just before they went hogwild crazy, and they were
just introducing things that the language actually needed. That was around the time that pad start was introduced, and then of course that didn't get implemented by browsers until what you know, six years later or whatever, because they prioritized dumb stuff that we don't need over stuff that we actually do need.
In any case of the time, at the time this happened, pad start was has art had already been a jobscript for some time. So yeah, if if and this gets the problem of like transit dependencies and deep dependencies and stuff. A lot of people didn't even know that they had a dependency on this library. So what happens is this the owner of this library, uh, for reasons I don't recall, and history we'll probably forget, got upset and pulled his his library and at the time INPM allowed you to
do this. He just belieted it, and all of a sudden, everybody's builds in the entire.
Yeah, the internet world.
Well everyone said the Internet broke. The Internet never broke the builds. Everybody's build it would Yeah, well the pre release part of the web break. So nobody's site went down, but nobody could deliver anything anymore either. For a little while. They could figure this out, and it was it was a huge joke in the whole software community. Oh job ascript.
You know, they don't know what they're doing over there, which is probably something great true, But so anyway, so that's how it all went down.
Yep, as I recall.
Right, So the point you're making then is if people had been relying on the underlying core API of start pad instead of using the left pad library read, then their stuff would have just kept on work.
It goes, it goes deeper than that, even because to to AJ's point, if you it the if you look at the the if you ever looked at the code for left pad, it was very, very few lines of codes. Yeah, very simple, very straightforward. Anyone could have wrote this, but
we used the library instead. Instead of everyone writing writing it themselves, writing their own utility library, we used a third party library, which created a dependency on someone else, who, at their own whims could do whatever they wanted our our insistence on like outsourcing our code. This way that the simple code kind of created this problem. Everyone could have written their own left pad and then updated as they felt ready to to pat start when it came
into JavaScript. But instead it got very deeply, deeply deeply into these dependencies that nobody even knew was there. We don't keep up, we don't update our stuff. They didn't, you know, left pad didn't update there to use the native or anything like that. And so we got into the system where there's these blind corners of things that were relying on. We have no idea what we're relying on them, because we've outsourced even the simplest of stuff.
I can I clarify something here, because what you're pointing out is not just the people who like in their project said I need left pad right. It was a dependency of a whole bunch of the other library. So even if they were making the kind of decision that you're talking about where they're saying, you know what, something like left pad, it's simple. It's simple for me to write my own little library that does it, or you know, if I'm late enough, i can use the native JavaScript API that does it.
But I had other things that.
Were solving more complex problems for me that also relied on left pad. So even if I was making some of these better decisions, I still fell prey to this because my my other underlying stuff wouldn't build.
That's right, because because of a more of a community problem. I guess, uh, we we as a community have kind of fall into this and so yeah, uh, which which is why I do think that like dependencies come with a certain amount of cost, it's often very hidden that we don't we don't acknowledge, we don't recognize. I'm not saying we shouldn't have dependencies, we shouldn't rely on frameworks
or libraries. We definitely should. There are great things that come with them, But but to do so too often or without acknowledging that there is that there's a cost associated with that I think has bitten us as a community and individually several times, and we still haven't learned the lesson that maybe we should be a little bit more intentional about the the dependencies that we bring on board.
Right, So let let me summarize a little bit because I have some thoughts here too, but I want to make sure that we've kind of covered what you've already covered. So you've basically pointed out that you can use the dom APIs to simplify the path that your code takes and get more reliable results.
You've pointed out that.
Depending on somebody else's code can wind up causing you issues if they change things in a way that you
don't expect, including having the library go away. One thing that I've picked up on some of this, right, So I've I've learned not not I guess at the level where I was getting paid to do it, you know, I've learned angular, I've learned view, I've learned react, mostly because I was doing the podcast and I wanted to sound like I knew what I was talking about, because I at least kind of knew what I was talking about, and in those cases that I as I was picking
things up, and also with with my history with like Ruby on rails or some of the other you know systems or frameworks that I've used a lot of time. When you're learning them, they give you a way of doing things, and so you kind of do things the React way for a lack of a better way of doing it, right, And as you build those apps, it's often appropriate for you just to use those and not think too deeply about, Hey, is there a simpler way to do this or is there a better way to
do this? And so there's a lot of value in kind of doing the accepted happy pathway that the framework gives you, right. And I think this is where Dan is saying, you know, for a lot of developers, if they never learn deeply learn a lot of these dominpis, they're gonna be fine. They're gonna be able to write code that works. It's you're gonna be able to deliver working features.
Is this just I mean, is that wrong?
Or is there a certain point you get to where all of a sudden it's becomes really really valuable to know these APIs Or is there some other X factor that you know about that I'm not thinking of that makes the difference right that It's like it's like Okay, you're totally good using the react way until you have to do this or until this changes, or until your code is a certain size or whatever.
I think.
I think people in situation. Life is complicated, so there's no there's no one answer here. But obviously you can you can be productive in straight react or straight view or straight angular, whatever it is. You can get some stuff done, particularly if you're kind of a junior engineer.
But good get paid, right.
Right, exactly right. There's a there's an element of practicality there, immediacy, immediate practicality. But I'm reminded of my actually of my calculus classes in college. CALC one we spent an entire semester going over how how to do by hand like derivatives and summations and all this stuff. And it was yeah, yeah, yeah, it was so hard.
I'll get my mom on the show. She teaches this at the high school.
This is giving me nightmares.
But then I had I had the same teacher for first in CALC one, Cup two, and the second semester we went into CALC two. On day one, he said, okay, so last semester we learned all this stuff. Now I'm going to show you how to do that real fast, and in five minutes he taught the entirety of CALC one with some simple like do this, you know, move this down here and do this multip and that's it, and everyone grown. And he just got a kick out
doing that every year. You could tell because he taught the entirety of CALC one in five minutes in CALC two. But then he pointed out, like why did I why did we go through all this stuff? It's important to understand why and how we got to this point because I can just show it to you do this and it works, but you don't know why it works. But now you do. You had calkawan, you know why it works. You have you can now have inferences and understandings that
you wouldn't have had otherwise. And this is exactly the same thing when you when you jump into a framework and you learn the frameworkisms, the reactisms or the anbulisms, whatever it is, you can be productive. You know, the incantations to make to produce something, but that's what they are.
They're incantations. If you know the platform, if you begin to understand how is this thing built, what is it doing under the hood, it ceases to become incantations and it starts to become recipes and you say, oh, okay, cool, that's a cool bread recipe. I'm going to do this thing and create like an orange loaf or a sour dough or whatever it is. Whereas if you're just heads down this, you don't exactly know how bread is produced or how your application is, how it functions under the hood.
It's it's you're less useful than you could be.
Well you know, yeah, I mean this is like music to my ears, and I could probably talk for a half hour with examples of how all this is true, going from my days and literally in banking and tech support and anything. The more you know the platform you know, the more function the more the better you can do just because you know how things go underneath and you're not relying on layers and layers on top of things. But I think you know and not even when it's
when you're building stuff. The bigger issue that you're going to come across those when you're trying to troubleshoot. So if something breaks and you have no clue how it's functioning underneath, then how are you going to fix the problem. Yep, you know where are you going to look at? What
are you going to look at? I can, you know, vouch for any time I've been whether it's tech support, whether it's you know, being as a developer, and I've written stuff and I've had to go back and fix it, you know, right, I'm today, I'm you know, better in this day, and I'm going to be fixing some bugs in a in a out aplication that I have. But I know where to go. I know pretty sure I know where to fix it because I know how it functions underneath the hood. And you know the example I've
given before, not to belabor this one is language. You know, I'm a Spanish speaker, and to me, learning language came easy, but the way I learned it was learning verbs. Learning now is learning how verbs are conjugated, learning the rules
of the language. Instead of the people that amaze me, you know that can learn conversational They can come in and just take some you know, quote unquote conversational classes where they learn phrases and start of piece them together, but they really don't know the underlying rules and concepts of how those sentences are put together. So that's always been my tendency, but I mean just to validate what
you're saying. Yeah, anytime you know the underlying details and concepts of how something is put together, you're going to be much better not only at developing, but also figuring out bugs because bugs are going to happen if you're not writing. If you're writing, bug free, cod would let me know. And I want to know how you do it, because it doesn't happen very often.
So I want to jump in here because I feel like there's still a little bit of nuance or play within this argument, right, And I'm going to use fixing cars as an example, right, just because it's kind of a concrete thing that people understand.
Right.
And so when I married my wife, I knew how to change the oil on my car.
That was about it, right.
And her dad knows how to change I mean, pick a thing on the car, right, he can make it fixed. And you know, and so the first time our car broke down, he came up and we pulled it out and put it back in.
You know, we fixed it, We replaced the part.
And you know, I was proficient at making bolts go in and out right, and so you know I could I could open the clamps or whatever you know on hoses or you know. So I could do all of those things, and so for a lot of the simple things, I really, I really was okay fixing my own car, but the issue came in when I had to diagnose the actual problem. And in fact, I'm still kind of at the point where about half the time, if I run into a problem with my car, I call him
up and say, this is what's what it's doing. It's He goes, oh, that sounds like the whatever, right, And so then I can go figure out how to change it out. But a lot of it just comes from a deep understanding of how the car operates, how the engine works. But a lot of it also comes from experience, right. And so I'm hearing Steve talk about, you know, if I'm in this code base and I need a troubleshoot it, I can figure it out because you know, I know
how everything kind of goes together. And I'm just I guess, I guess the feeling is is, you know, and I see this. I mostly work in rails, and so I see a lot of people do the same kinds of things, right, and they you generally mostly use the rails APIs until you get you get to the point where they don't do a thing well, and then you kind of reach into the tool bag of Okay, now I'm into the underlying stuff, but I mean, you can go a long
ways with just what the framework gives you. And so I guess, I guess what I'm saying is is that And it sounds like you, Corey and Steve and aj We're all kind of of the mindset where it's like, look, I want to master this domain right. I want to be able if there's a thing to be done, I want to be able to do it right. If I run into a problem to be solved with JavaScript, even if I'm working and React or view or Vanilla or
you know. We did an episode where I talked about the framework I use, which is Stimulus and hot wire.
You know, I want I want to be able to deliver.
Whatever it is need it right and Stimulus and hot wire so lightweight that you have to use don APIs you don't really have a whole lot of choice. But the point is is that I think there are a lot of people that get by just on react right, and then they're the handful of don APIs that react kind of pushes you, Hey, we're not going to invent a better way to do this because this is kind of.
The way to do it. And so.
Anyway, the point I'm getting to is, I think there are a couple of reasons why you may or may not really deeply care about deeply learning some of these APIs.
And one of them is is.
A lot of people really are just comfortable showing up and just doing, you know, doing what it says on the REACT ten. And you know, they know, maybe they know react super duper deeply, and so they never really reach into that because they can either find somebody else to solve the problem for them that way, or they're not really driven to understand how all this stuff works under the hood.
And on the other hand, you know, maybe you just get people.
And I worked with people this way too, where I mean, whatever the bare minimum was to just get the job done was what they learned.
Yeah, And so.
I guess what I'm gonna ask next is is that, Okay, I mean, are you handicapping yourself Like I'm not talking like morally right, but are you really deeply handicapping yourself here?
Right?
Is this going to hurt you in the long run, or can you just get by doing that for the rest of your career.
Yeah, actually that's something I have thought a little bit about. So they're all I think software development is a little bit unique in the world of like work. Most people that I run into genuinely love what they're doing. Right, This is not normal. I think for most of the world, a job is a job for them. They go there, they are mildly depressed while they're doing their thing, they get it done, and they just are so glad to
clock out and go home. I mean, either that's not me, but but some people, most people like to live that way. They find they derive their life. They're satisfaction and joy outside of work. And I do too, to something said, but I do derive joy at work as well, and meaning and satisfaction. But there are still many people in software development, especially the ones that were kind of sold hey, go go write software, you make a whole bunch of money. And they want to go make a whole bunch of money,
and now writing software, they don't really love that. They could have done other things make a whole bunch of money. But uh, it's just it's just a job for them, and I think for those people that's fine, it's fine. Just go do your job, clock out, go home, and don't worry, worry about it, like no problem. But understand that that that just means you're going to be perpetually a mid level engineer. That's just you will. Whether you get paid more than that, I don't know, but you
you'll never really be better than mid level. And that is actually fine, because.
Okay, hang on, hang on, hang on.
So I just want to clarify, you're saying that you really can't be a high level I don't know what the term is senior architect level engineer without understanding the underlying don API s.
Yeah, I don't think you can because because I don't think you can. You mentioned before someone who really knows React, can they and just lives in that. I don't think you can really know React without knowing how React, without knowing the platform and how React works with the platform.
Yeah, there's there's no there's no such thing as a React expert that doesn't know about pad start. You can't, like, you can't be an expert and React and not know basic core APIs of JavaScript or basic core APIs of the dumb. I I. I mean, I guess maybe maybe you could be an expert in React and not know
insert adjacent HTML. But I actually find it hard to believe that either because to be an expert in React, you must have come against cases where React doesn't solve the problem well or performantly, and then you would have had to have learned insert adjason html.
I agree with you, but I think this is a case that people make, and I think a lot of people think they're getting by on it.
So well, I want to challenge the very premise, which is that that somehow you're you know, your laziness, or you're you know, you're just getting by, you know, not doing deep dives. I don't. There's so many things that I I it's so so to your to your talk Corey, when you were talking about the difference between something that's intuitive and unintuitive. I actually disagree with you on a lot of points that talk, but because I watched it once I got posted. But I agree with you probably
more than I disagree with you. And there's a certain amount to like, okay, which is more intuitive left pad or pad start. Now, in that particular case, I'm going to argue that left pad is more intuitive because pad start is directional based on locale. So if you're doing Japanese, then it's going to pad the top. If you're doing a reverse language and RTL language, then it's gonna pad
the right. But in general, yeah, pad start and pad pad left and pad start are and and for someone that is in one of those languages that's top to bottom or or right to left, then than pad start would probably be more intuitive. But in general, in general, at the face of it, without going into the nuance, is pad start or left pad more intuitive? Neither one is more intuitive. They're they're they're equally intuitive in terms of I want to in my language add some padding.
That's gonna be what I think the start is. And you're gonna pick left pad or right pad based on, you know, what your languages are, pad start or pad in based on whether you want to be at the beginning or there or whatever. But but there's not like, it's not that's one's more intuitive. It's not that one's more difficult to learn, Uh, you know, it's it's that
which one did you encounter first? And I think a lot of this stuff it's not a matter of well, isn't the framework just fine because it's not even an issue of the framework because if you're using the framework, well you should still be using pad start. Like there's nothing about React that has anything to do with pad start. There is a reason that if you're using React, you'd never encounter insert adjacent HTML, But there's not a reason
in React that you would never encounter pad start. Right, So next question, and so a lot of this stuff is just it's not a matter of well, do you have to be more of an expert? Not expert is going to go back to first principles and learn or maybe not first principles, but like an expert is going to get down to, okay, what is the thing when all the fluff is removed? I think that's that's a quality of an expert. But even if you're not an expert, it's not like, oh man, huh, I can't believe I
had to go on MDN. Can you believe it? Like instead of hitting up GPT or stack overflow, I typed MDN in my search career. Oh oh man, I got it, and I need some advil, you know, Like that's that's not what's happening. It's just a matter of what your muscle memory is, are you hitting Chad GPT first? Are you hitting MDN first? Now, granted a lot of the articles on MDN could stand to be improved because they kind of went back backwards a few years ago and
now they've gone forwards again. So I think MDN is is back on par with W three schools because they were better and then they got worse and now they're okay again.
But you know, so what do you think, Corey Steve.
I'm trying to suss out the the the question there. So, yeah, I agree with it. Sounds like you're making the argument that kind of like what I made before, that React or these other like UI frameworks are designed to do a certain thing. It's like, if you remember when React first came out there, they were marketing themselves as the the V and NBC. Right, they don't do that anymore, but at the time they were, that's what they were.
They were kind of marketing themselves as and by implication that means they don't do the M and the C. That's your job to under fan. We just do the V.
NBC being mod view controller.
Yeah, so they did the interface, they didn't do the data and they didn't interface the data to the view that was.
The top layer. They save view library. I think that's why I've always heard it described.
Yeah, I don't. I don't think that's an accurate description. It probably wasn't an accurate description at the time either, but certainly not now. But regardless, they were making a concession that we don't do everything, but we do do this thing. And all frameworks are kind of that way. And if you live in as long as the problem to be solved is something that the framework aims to solve, you can live in that framework and you don't have to to dive down. But to create an application, you
will have to do more than what the framework solves. Charles, you mentioned you do a hot wire stimulus and it's very lightweight, and therefore you have to learn DOMINPA. It doesn't it's not aiming to solve all the problems, react all the problems.
It claims essentially to be the c in MVC, and it leaves the V up to you writing HTML and the m up to your APIs and you can do those however you want.
Yeah, so, so in that sense, I think you know you're right. You cannot become an expert at your job, even if your job is to write React, unless you understand more than just React, more than just the framework that you're operating in, because your job. I don't know of a job whose whose definition would keep them only within the bounds of a framework. That just unless maybe you're working in a very batteries included framework like Rails or something.
Right, Well, even in the battery you said Rails, but even in the batteries included frameworks like Rails, you still frequently have to deviate from what the framework gives you, either directly or because it just doesn't have a piece of the framework that does the thing you need.
Well, addition is not part of Rails, right, string concatenation Actually I think st I think I think Rails did hijack stream cocttination.
A whole bunch with active support.
But yeah, but in general, in a sane language, you know the language, the framework isn't taking over edition concatenation. You know it's basic string and number support.
Well, active support was written for Rails, but it's mostly orthogonal. I mean, it's required by Rails, but you can use it in other projects without having Rails and give all the niceties it gives.
You, and now the rails or Ruby has UTFA by default active support doesn't hijack those things, right.
Not as much it it has it. It touches everything we.
We could we could talk about whether that's a good idea or not, but that that's not the show. I was us, Steve, if you had anything to add before I kind of push this to the next question I have on this then.
Not really, I mean I'm still a bit confused about the what the question that AJ said anyway, which is par for the course.
But I didn't ask a question, no idea.
That a common question, and it was it was effectively, can you know can you be a high level senior developer without knowing this stuff?
You don't think I don't think it's knowing it. I mean I pretty much said that up front. I mean, yeah, I think the general percentage that I can remember seeing, like for instance, going back to the jupil world was eighty twenty where the framework, the CMS whatever, out of the box is going to do eighty percent of what you need and the last twenty percent is what you need. You know, you're going to need to do yourself with
a little customization with some writing code. In this case, I think it could be you could translate that to say, React view Angular rails is going to do eighty percent of what you need by itself, and in a lot of cases maybe it's one hundred percent, depending on the simplicity or the complexity of what you're doing. But that last twenty percent, you're going to need to know how things work under the hood in order to be able to get to what you really need to do.
Yeah, just as a quick example of that, if you're writing in React and you're you're writing out HTML or GSX, one thing that doesn't cover at all is aria, Like you need to understand aria. You just that that's absolutely necessary. That's not React.
Nope.
Yeah, that's a whole can of worms where you get in to uh, what's the term you can believe disibility? Thank you? Accessibility?
Right?
Yeah?
And why yeah?
Yeah. And also just to be clear, like, depending on what your goals are in life, there's nothing necessarily wrong with never becoming a senior like engineer like go do your thing, man, do what makes you happy. And if if being a mid level engineer for you know, for your career get you the money you need to do it makes you happy by all means, go, you know,
do that. That's fine. But if if you're going to your manager and like I think I should be a senior engineer, I want to get paid like a senior engineer, well you're gonna have to learn some stuff outside of that framework.
Yeah.
The example I've used with a bunch of people is some people want to learn to code because they love it and they just want to dive into every piece of it. And some people want to learn to code so they can make enough to go live on the beach and go surf in the afternoon. And there's nothing wrong with either one.
Just know who you are. Yeah.
Okay, so it sounds like and I think AJ most directly touched on this, but let's say that somebody is you know, they accept the argument. Okay, I do have these ambitions for my career. I do want to be able to expertly solve these problems, So I need to start learning these dom APIs, and I'm also going to deliver the premise and you can argue against it if
you want that. A lot of times people don't learn these APIs because the framework does give you a way to do it, and so you just never become aware that the API even exists to do the thing. So how do people And you can tell me if I'm wrong about that as part of your answer, But how do people then go? Okay, I'm a React guy, or I'm a view guy, or I'm an Angular guy, and I want to deliver elegant, well written, well engineered solutions, and so I need to learn these do APIs? Which
ones they learn first? And how do they learn those things so that they can start to become this high level engineer.
Oh that's good. That's a good question.
And is my premise wrong that people aren't learning it because of the framework just does it for him.
I don't think it's that the framework does it for him. I honestly, I think it's I'm most familiar with React, and so I'll speak for React here.
That's fair.
I think most people listening probably do React.
So the ecosystem has solutions for it, so React doesn't. For instance, I talked before about using the popover API, and one of the reasons we started doing that is because we have a library in our application that handles pop ups and it is flaky as all get out. When it comes to tests, it does not perform well. There's all kinds of problems with it, and so that's why we're looking for more native solutions. But the reason it exists at all is because someone came in. I'm
a react engineer. I need this thing. Someone created a library to do this thing inside of the reacting ecosystem. All I need to learn is this simple little API for this library, rather than all this complex API for the dominant I think this is the conceptually what people get wrong. They think that the lower level stuff is complicated, this library has a much nicer API. Many times that's true.
Many times that's not true or not as true as people seem to want to think it is, And so you end up with this bloated situation where I'm gonna I'm gonna get a library that has a nicer API rather than learning the platform API. I think that's what tends to happen fairly often.
So, so what what should people be picking up first? And how do they make sure they're learning the right things that are going to move in the head.
Yeah, I wish they were a good, like simple answer to that. It's kind of reminded when people ask like, I'm just starting out as an engineer, what what books should I be reading? What sources should be reading? I'm like, oh, man, I mean there isn't a book that I used to have. I used to point people to, like you know, Jobs of the good parts. That's way outdated. I would not recommend reading that.
Now right.
There.
There isn't a compendium of you want to get great, here are the resources, Unfortunately. I what I tend to do now is point people towards resources like email, newsletters or podcasts or things like that where people are talking about stuff, and I send them to Honestly, ah, you mentioned Indiana. I send them to Indian all the time. That is the unofficial or maybe it's now the official platform documentation go that. I tell them like, look, you
always need to be looking for stuff. I will sometimes go to like Indiana and look at the eighth the list of hmail tags, just like what have I forgotten about and go through and just read them and say, oh, I told I didn't know that existed. I'm going to try to incorporate that in there. And this reminds me so I thought of this earlier when you were talking about something else. But one thing that is incredibly useful for understanding how things work or maybe what you should
be learning. Remember years ago, Paul Irish.
You guys know we've had them on the show. I think, yeah, so Paul, maybe not anyway, in.
Any case, years year ago he wrote or he made a couple of videos on the first one with ten things I learned from the Jquerry source code and what he did. He just did this little video where he opened up the source code for jquerry and just walked through it. And I was like, oh, this is cool. Let me tell you about what's going on here and what I learned about this, and it was it blew my mind of like, holy crap, this is amazing. I didn't kind of even it didn't occur to me to
do that. And I started kind of doing that more. I'm going to look at the source code, how are they doing this? How is this library that I like doing this thing that seems magical to me? And I figured it out and then take it a step farther and you know what I'm going to recreate? I recreated jQuery. It was crap. It was not performance, but the act of doing it like opened my mind widely to all kinds of new techniques and interesting things. And I think
that is a good exercise. I think, I think doing that building into your career. I do this. I also tell engineers that I meant to do this every day. Spend the first hour of your day on company time learning. Go read it, read some articles, go go build some throwaway thing, but spend that first hour learning something new every day. You The act of seeking out, I think is going to expose you to uh, to these kinds
of things. But I don't have, like I said, a compendium of like here are the things you need to know necessarily.
So we did an episode about five years ago with a guy named Karl Mungazi JavaScript Jebber number four zero eight, all about reading sorce code.
He was also a host on React around It for a while.
Right, So the whole I remember, and I can still remember doing this episode where we talked to him about reading source code and how to do it and the benefits of it and so on and so anyway, I put four zero eight if you want to listen to.
That, Yes, I think it's more about the practices you build for yourself as an engineer, less than the sources you turn to. The sources are good, but I think the practices helped to help give you those sources, I guess is a way I might put it, help you discover those sources because I think they change over time a lot.
I think one of the best things that front ends people can do to improve their their craft is to listen to people that just do programming and more importantly engineering and architecture outside of the front end space, because I think the front end space is assess pool, and the thought leaders in the front end space are oftentimes just people that have I don't know, really cool socks and like I don't.
But I would people off.
I don't know.
How they become these thought leaders, but so many people in the front end space they're not people. Let me rephrase it. You'll get a lot more out of listening to people like Rob Pike and Jonathan blow Casey Moritory, uh, you know, like listen to people that do game dev, listen to people that do server side dev, listen to people that do GO or rust or zig or you know, because most most of you know. Anybody that asked me how do I learn to program? What I'm gonna say
is here's a bunch of great resources for Go. Because goes a language you can learn in a weekend. You don't have to have previous programming experience to get into Go quickly. You can write actual real programs and go that uh, you know, you can write terminal games like tip tac toe type of stuff or whatever.
You know.
It's a it's a really great language. And once you learn Go in particular, then you go back to something like JavaScript and you're like, whoa, whoa, whoa, whoa. I don't need this ninety five percent of the language. This five percent does everything I need, and it's faster and smaller and easier to learn.
They used to say the same thing about JavaScript that you just said about Go. It's interesting. I a thing I've often said about JavaScript is JavaScript has within it this very beautiful and elegant language. If you if you stay within the bounce, it's a wonderful language.
And there's a whole lot of.
I'll take some issue with with I guess the way that you you positioned the in the front end space. I do think there is a lot of value that comes from many of them, I think, But what I agree, but I will agree, Yeah, There's a couple of points I would add on top of it, and that is that it took me. I had an experienced earlier in my career where I realized that even the most experienced
and knowledgeable people in the industry are just people. Like they're just and they're almost kind of They're making it up as they go in many the same ways that we are. They just have been doing it longer, and we tend to idolize the wrong word defer to them maybe too much at the expense of our own rational thinking. And I think we could do more rational thinking rational
thought there. But with that said, I will very much concur with you AJ on expanding your horizons beyond the domain space I mentioned before the seminal paper Out of the tar Pit, and I also mentioned before that there
isn't a compendium of resources. However, I have been thinking for a long time about put together a list of these like must reads going back to the beginning of computer programming, that are, like Quintin like thinks you really really should read because it's going to shape in a positive way the way you think about programming in a broad sense. So you know, you know, out of the tar Pit you have the the Orsons, cut Cards, the Beekeeper,
and Algae I always forget the name of it. You have many white papers from the seventies and from the sixties that are like mind blowing that they have they solved, they solved problems that we have today and we've completely forgot about it. I would, you know, point people to to Brett Victor and a number of his his presentations that illustrate some of that. There are some really kind of everyone should really be reading this regardless of what
you're programming kind of stuff. And maybe one day I'll put that together, but I don't have that with me.
So is the Beekeeper with Orsus Scott card House software companies die.
Yeah, that's the one. That's the one, and it's really short.
I put both of these in the comments on Facebook and YouTube, so yeah, if you're if you're looking for those, well, hopefully we get them in the show notes too, but they don't always.
So there's a yeah, I wish, I wish I had a longer list of uh a hand, but those are those are It is really amazing to go back to the fifties and the sixties and the seventies and read some of the papers that people wrote about software programming back then, and the elegance with which they solve the problems that the current problems that we have today, and you start to think, why is everything so complicated now? It doesn't need to be that way. It's kind of wild.
Yeah, so I think J had a question, and then we're kind of getting toward our time.
So yeah, so this this was something that you'd actually brought up, either in the two or in some of the pre pre chat email or something. But request animation frame, so that it's totally switching gears to a technical topic request animation frame? Do I really need to know about it? Is it really that important? How should I employ it or not? And as react using it behind the scenes?
Oh, that really really depends. I'll tell you what I know about request animation frame. I don't think I've ever actively used request animation frame. No, I may have once or twice, But it depends. It very much depends on the kind of programming you're doing. Ay, are you doing a lot of animation? You probably do need to know
that there's a lot. There's so much nuance in the kinds of things, and you can go so deep into one area when become an expert in that area, is such that you almost never touch this other stuff that maybe most other people do. And this is what a lot of.
So I was thinking. So I've I've been using it by default lately, like anytime that I'm going to be doing anything with a DOM, I'm doing it inside of a request animation frame. I might even do the calculation outside, but then I do the actual Okay, replace children, insert adjacent HTML, text content equals, like any of that stuff. I just shove all of that into a request animation frame.
And I was under the impression, which might be wrong, that that means that when it's inside of a request animation frame, that it actually is gonna get cued and batched by the browser and done all at once, rather than it cutting the browser's redraw. Because essentially, every time you do a dot text content or a dot ner HTML, well I guess not dot text content, well maybe potentially, but you are causing the browser to do a redraw.
So if you do one online five, and you do another one online six and another one line seven, then you're telling the browser to redraw three times. And I thought that the deal was if you use request animation frame. It's saying, Hey, anything that I'm going to do that's going to redraw, wait until this complete before you do any redraws, and that maybe maybe the browsers are optimizing that way when I don't use it.
Yeah, that's that's not quite right.
Actually good.
So if you do it outside yeah, no, if you do it outside the request animation frame. So we used to talk a lot about screen thrashing, you know, in the front of it. Yes, and that happens when you alternatively read and write to the DOM. So if you if you read and then write, and then read and the write and the read, then the DOM has to paint so you can read the new update and the
paint so you can read the new update. However, for a very long time, if all you're doing is reading, or if you have a batch of reads and a batch of rights, it will do those like in batches. You'll do the reads, and then if you have sequentially so rights, it will do the rights in one draw.
So it'll it'll do it all in one frame. Essentially, what request animation frame does for you is if you do it outside the request animation frame, it'll it'll do it kind of immediately, but if you do it in the request animation frame, it waits until the browser is about to do a paint anyway, and then we'll execute on that. And that can be really useful. However, if the what you're doing within that request animation frame takes longer than sixteen milliseconds to accomplish, you end up getting
screen thrashing again. It pauses the like it becomes jarring and janky, and so you have to pay close attention to the amount of time it takes to do those things. So you have to be doing all the you know, the performance testing to make sure you're you're staying inside of that's sixteen milliseconds.
Okay, yeah, all right, yeah, because that's that's something that I've just started using because I have heard about its benefits. I'm not they don't apply to the stuff I'm doing. I'm I'm but I don't know. Here's the thing here, this is the reason that my brain went to this. Okay, Angular, you could have one hundred items in a drop down list and change something. An Angular would take noticeable time to redraw those one hundred IDEs. I'm like, that is insane.
There's no way that's real now I think that the people that came up with those demos, I think they must have been doing something that was horrendously wrong. But I think they were doing something like writing each of the hundred items into the drop down list or I don't know. I don't exactly know how it happened. I just know that Angular used to get ridiculously slow. And again I don't think it was Angular's fault per se, but people using non angular patterns in Angular or whatever.
But it was one of the criticisms that drove React success was it was easy to do really dumb things in Angular, where simple modifications to the page would freeze the browser.
Yeah. Yeah that if you can, you can find the the weaknesses and just about any of these frameworks. So yeah, I remember doing Angular and the problem was always the dirty checking. If you're not managing your state well and you're forcing anguler to do the dirty checking all the time, then it's going to have super bad performance. And I ran to the exactly these problems. At the same time.
React with a virtual dog means that they can calculate off of the paint thread what needs to be painted, and then in one fell swoop, you know, paint as they do the reconciliation. That's kind of their their thing.
But you see, now you have things like use effects and all these hooks where it becomes very easy to use them poorly, and you can get the same kind of really bad performance, really jank experience, and taking a long time to accomplish what should be pretty simple work because you're just using these use effects in really poor ways. And I'm sure the same thing can be said of a view. I'm much less familiar with that, but I'm
sure it has its own situations like that. If you have these foot guns and all these frameworks need to have foot guns somewhere in there, that except well, I can imagine a few scenarios in which HTMX would fall apart, but is a pretty interesting.
Yeah.
Yeah, but again, the surface area on HTMX is considerably smaller than say a react or an angular, so.
That that's one thing to consider. The other thing is is that.
So I I'm not as involved in the angular community as I used to be, but they've rewritten like you mentioned that, try checking. They've written that like I don't even know how many times right, and made major forward progress on that, And so I mean That's one nice thing about a lot of the frameworks is they see the warts a lot of times as quickly as we do. It just takes them time to figure out how to make it work for people who are.
Using the framework.
But then at the end of the day, a lot of times you get that update or upgrade for free or for you know, a tiny bit of change when you update your framework. And so, I mean there are some really nice reasons to use a lot of these frameworks.
And you can see that happening right now with React as well with the React compiler. That is going to.
Yeah a lot.
Yeah, it's gonna make things a lot nicer for a lot of people. We're kind of toward the end of our time. I think I'm gonna push just the picks. The one follow up I have, and so maybe we'll have you back on Corey is.
I would love to get into.
Now that we've kind of talked about, you know, APIs, do you need to know them? You know, what are some of the trade offs? You know, where's that going to get you and things like that. I'd actually love to have you back on and actually talk about the dom APIs you think people should know, right and so you can give us a list of you know, a dozen or so, AJ can throw in the ones that he thinks. I'm assuming that most are the ones that
most people come up with on that list. You're if you give us a list of twelve, probably eight of them out of anybody's list are probably gonna be the same. So then we can get in and we can say, Okay, these ones are the slam dunks. These are the ones that I surprised myself by reaching for often that you know, most people wouldn't think of, but they just pay off. And yeah, then we can give people a direction if you're working in a react or a view or an angular start here.
Right, Yeah, that'd be fun.
All right, let's do it. Well, we'll talk to you after the show on how to line that up. But yeah, let's move into picks. Steve, do you want to start us with picks?
Oh, we're going to the high point right off the bat.
Huh all right, that's right. I couldn't wait any longer.
Right, Uh See, you didn't have any other external picks that I can think of right now, so I'll just go to the dad jokes of the week. I shall do. I'll do four today instead of three. So here is proof that the annual Missed Universe pageant is fixed. Every winner has come from Earth.
That's Steve.
Yeah.
My wife told me the other day that I should sign up for my company's four oh one k I said, not a chance. I can't even run a mile. That's right up Chuck Sally with his running and half marathon stuff he's doing. Man. Anyway, Now, from the moment when I first got married, from the moment I saw my wife's abacus had to I knew I could count on her.
No, you can't. Those beads don't move.
Right, that's true. And then finally, I've been seeing my psychiatrist for a while and he finally diagnosed me as a kleptomaniac. And I said, is there anything I can take for it? Those are the dad jokes of the week.
All right, AJ, what are your picks?
First thing I'm gonna pick is grug Brain dot dev, which is one of the most recent editions that I've added to Creedsaccraftsmanship dot com. It is I believe it's by.
I don't want to say who it's by. I don't want to give any bias, but I think it's pretty clear who it's by once you reach the end of it, because I think he says so, but it is if you've ever seen the grug brain meme, it's you know, like like big brain think multiple inheritance, multi layer system, very good, but grug brain know, grug brain too stupid for big brain inheritance. Grug brain used simple object and
get work done. It's a little bit hard to read because the whole thing is written in that style, which is, you know, it's great for a joke, but it's not good for an entire article. But the entire articles written that way, and I don't think there was a single thing I disagreed with in it, because yeah, I'm definitely
I'm definitely a grug brain dev. So if you think that you might be too dumb to understand all the stuff that's going on in web dev these days, you might find great relief in joining the geniuses of grug brain dot dev.
Well, as he says at the end, under the category of imposter syndrome, any young grug read this far probably do find in program career, even if frustrations and worry is always to be there.
Sorry.
Yep, another another pick is you know, we're talking about what's what's a good place to find material to learn. So I've been compiling creeds of craftsmanship. Uh. Most of the stuff that's on there has been on there for a while. Every once in a while I add something new and the most the most recent two things are the grug brain dot dev and then that it was actually the original talk that inspired can see Dodd's AHA programming that I can't let me go look at it
real quick to bring what the name was. But anyway, I add stuff to this and it's it's non denominational other other thing that it's all pretty much grug brain. But you know, it's it's not really favoring a particular framework or or UH language. It's it's pretty much just
the keys of success to becoming a great developer. Yeah, one of the one of the most recent ones, it's really old from twenty fourteen rails comp all the Little Things by Sandy met and that was that's actually cited in the UH the in one of Kensey Dodd's resources on avoid hasty abstractions. But I hadn't I hadn't put
it on there before. It was really good. There were a couple of things towards the end, I disagreed with uh, But then again, she's giving such a small example of her her toy project where she's implementing she starts to implement inheritance in it, which you know, I'm I'm definitely in the camp of inheritance is evil. But but maybe maybe there's a larger example where where there is an exception to an inheritance is evil that she she she she makes a case that it's not always evil. I think,
you know. Anyway, So there's that. And then lastly, I mean, we're talking about high performance jQuery alternatives. You've got to try aj query. Uh. It's been released on Twitter, the latest incarnation. Unfortunately, because it's now AI enhanced, it no longer fits in a tweet as texts. So I had to take a picture of it because now we've got that, we've got types in there. It's fully documented and yeah, it really really you know, ran it through chat GPT
too to make sure it's it's up to snuff. But yeah, and and you know, uncompressed, it's kind of big. It's like I don't know, uh, two hundred bytes or so, but but uh, you know, you you you g zip that down and deliver it. It's the best, the best thing ever, hot, hottest thing since since sliced bread. So you know, get it while it's hot. A j query three point zero point three, it's a big one, y'all.
A I to it. It should be a j P t query.
Yeah, that that one's taken.
That's already okay, just trying to I'm just trying to help, and I don't know, maybe you're not the aj behind it. Anyway, I'm gonna are you done? I was gonna just jump into my picks, and then I realized I might.
Have cut you off.
Now that was it. That was it.
So every year I go to a board game convention here in Utah in Provo. It's called Timpcon, and I wind up helping out with the hot games tables and teaching people how to play board games. I usually take Friday off and go play board games all day Friday too. This year, I'm not gonna be able to do that, but so I wind up learning like six new games every time. I'm gonna pick a game that I've already picked on the show because I know how to play it and we've been I taught my wife and my
kids how to play yesterday. It was funny because my fifteen year old was like, I really wantay, you know, because if you have fifteen year olds, you get it? Do you want to understand? It's like, I don't know, it's gonna be cool, and anyway we can miss her sitting down, play it right, It's like, looks forty five minutes.
Okay, over.
And by the end she was like, this is fun. So anyway that that's my testimonial for it. Like she was smiling at the end of the game. Of course, she also won, so that that might have helped too. My seventeen year old enjoyed it. My nine year old kept wanting to play. It might have been the deck building piece of it might have been a little beyond her. But we could literally just tell her, look, try and get all of the same color and get the highest numbers you can, and I think she would actually do
okay just playing that strategy. But effectively, what it is, it's it's a blend of capture the flag and war in a tournament style and and then there's the deck building component, right, and so you basically curate a deck and what you do is somebody starts, they play a card deck card capture the flag, and then they're oponent plays cards until their cards total equal to or more than the top card of the other players pile that's captured the flag, and then they capture the flag from them.
The cards in the other players pile go on to the bench.
You can stack cards at the same kind on the bench, and you have six slots on your bench. When your bench is full and you can't place another card on it, if you need to place another card on it, you can't, you lose. If you can't, If you run out of cards and you can't beat the other players.
Pile, you lose the round.
And then you get the trophy that's on top of the trophy pile on that field that you're playing on. And so it's basically a one on one. So if you're playing eight players, there are four one on one fields, and then you each have a schedule where you rotate to play against the other people and you play seven rounds. The two top scorers at the end of the seven rounds go on ahead to head for the final, and
whoever wins that wins. And so in the final, it was my it was me versus my fifteen year old and she'd beat me.
So anyway, it's it's super fun board game.
Geek says it's a one point seventy nine, so that's it's it's pretty approachable for the casual gamer.
The setup's pretty simple. There aren't a ton of pieces.
You know, you have different color cards that do different things, right, So that's that's where the deck building comes into play. Is like one of them say will say if this is on your bench, then you get a certain ability, or you might get a card that says when you play this, or you know, sometimes it doesn't even say when you play this, which means that if it's as soon as you play it or whenever it's out, it
does the thing right. And so I had a card that said, if there are any other purple cards on your bench, then this card has plus three power, right, So it was a one. But if I played another purple card and had it on my bench, then a four, right,
And so anyway, so that's the rest of it. Some of them let you collect points towards the end of the game because the trophies are worth points, but you also have a pile of just loose points and so some of them say, if if this card captures the flag, right, if it's the last card you play before you capture the flag, then you get points. So anyway, whoever has the two people that have the top number of points at the end of the seven rounds, they go head
to head and you win. You're probably wondering can you play with an odd number of players?
The answer is yes.
It has a robot deck, and so you're if you're playing against the robot, you play both sides, and so that robot deck has stuff in it, like this card is as powerful as the current round, so if you're on round one, it's a one, right, And so since your deck isn't strong, the robot's deck isn't as strong either, but he gets round six, and it's got some cards that before weren't giving you a whole lot of problems.
And now they are.
But you should have a stronger deck by then too, And so you just play the robot through and then the two players with highest scores, right, But if you lose to the robot, it gets the trophy.
Right.
So anyway, super fun, really enjoy it. I'll probably have we're doing six games at the board Game Conference, So for the next five or six weeks, you're gonna get a whole bunch of other ones. One of the other games is another version of Challengers. I just haven't played it. It's called Challengers Beach Cup. So I'll let you know when I learned that how that goes. But I'm imagining it is pretty similar to Challengers as.
Far as other picks go.
I've got a couple of other things. So I think Steve mentioned Chuck's half marathons or whatever. I just want to clarify I'm training for an iron Man. I'm gonna do it next year. I plan to break my body over a Saturday or a Sunday, depending on when the race is and right, and then I'll show up the next day for this podcast and you'll hear me talk going out of the puddle of whatever's left to me. But no, it's okay. So I've been doing a couple of things, and I'm just going to quickly shout out
what those are. I've been using training Peaks, and then I bought a forty eight week training program for an iron Man that just goes into training Peaks. It scenks up with my garment app which means it goes on to my watch and so I just tell it I'm doing the workout for today on my watch, and then it times me and does on my laps and everything. So that's that's pretty nice. I've also been doing some strength training I've been using.
I signed up for.
A Transformation Challenges what they call it, with a company called First Form and they spell form pH or M.
And man. Their stuff is just it's awesome and kick kick butt.
They do sell a bunch of supplements, right, so I wound up buying a bunch of their other stuff.
But their trainer has been terrific.
Any questions I have, She's walked me through all the stuff I need to learn and know.
It's just been amazing. So I'm gonna pick that.
I'm gonna put a link in YouTube and hopefully get it into the show notes. That's my referral link. Now I don't get paid for the referral link. I think I might get some free swag from First Form if I'm entered into a drawing or something. I think that's how that works. But anyway, I'm just putting it out there because it's been amazing, and if you use my link. Then you join my coaches. You joined under my coach,
and she's been amazing. So I just want to get you what I'm getting because it works and it's great. So far, I've lost like eight ten pounds and that's over like three weeks, two three weeks. But the other thing is is my gym has an inbody body scanner, and so I've lost like a dozen pounds in fat and I've put the rest back on and muscle and so I and I'm feeling terrific.
My diabetes is well under control. It's just it's been it's been a really good thing for me.
What are you type two diabetes?
Two diabetes? Yeah, so it's it's been awesome. I've been type two diabetic.
For like eighteen years.
So yeah, I know if I was to do an iron Man, they would measure my time in days instead of hours.
The course, after a while, Steve.
Right, I might get kid. Yeah, they'd be okay, step go home, you know. But I mean I could do the swimming really well, on the biking pretty get the running. They just have to follow my holes in the pavement, you know. That's how I'm heavy for you.
Yeah, the the bike is what I'm struggling with. I have a Wahoo trainer that I bought and it's it's been great, and I'll pick that next time and tell you what I bought.
And then there was something else that I wanted to shout out about. H oh yeah.
So this weekend I went to It was a retreat for faith based entrepreneurs. It was three days amazing stuff, big breakthroughs. You need to go and find the best link to kind of put you into the community that I connected.
With for that.
But yeah, I just got a lot of clarity on who I'm supposed to be and what I'm supposed to be doing. And I encourage people to just find if you're a person of faith and you're trying to be an entrepreneur, find people who are doing that. If you're not a person of faith and you just want to be a better programmer, go find people who are doing that.
If you're right, I mean, whatever your ambition is and whatever your identity is, go find that and go find people who are being excellent what it is you want to be that you have a lot of things in common with, Because I guarantee you if you get with those people and you go deep You're going to have some really really eye opening breakthroughs. So that's my pick, or those are my picks? Corey, what are your picks?
Yeah, so this one isn't my pick yet. But did you guys, did you guys hear about the circus? I understand it's going to be intense.
I heard that coming.
I appreciate that. It's my favorite. Uh No, my my pick is a absolutely shameless self plug. I mentioned at the top that I'm in Saint George. I am at a vacation rental that we recently bought and is now recently now ready for for renters. So if you are interested, and it's in this really cool community called Desert Color. There's this beautiful lagoon and it is fantastic. We have a condo. It is it sleeps seven, it's three bedrooms,
and it is available for rent. And I can give a promotion code that maybe we could put in the in the show notes. So if you want to come down to Saint George, man, this this is the place. This is the place.
Now are you bo.
George?
You're near what Bryce Canyon and Zion.
So yeah, we're not far from not far from Zion, not too far from Bryce Canyon. It's probably about an hour.
Oh, you're you're right in the corner on the border.
We're on the border.
Area literally, okay, yeah, so Lake Palace to the east, and yeah, it makes a bit of a drive.
It's as if you're.
Going to going to Tuacon out here. Yeah, it's real short. There's there's actually.
Concerts and in place performances.
I thought maybe it was that Hawk girl. Okay, no, not her.
There's a lot of a lot of arts out here, and there's surprising number of like state parks that are really really great as well that that arts Zion.
So yeah, but you're definitely within striking distance of Zion National Park.
Yeah, you're just southwest of there.
Okay.
Yeah, yeah, you're from the airport. So if you're flying in in uh, you know, we're real close to that.
There's a top golf right there too.
It's a it's a we call it bottom golf. It's a big Shots. It's a it's not top golf.
Oh, it's not top golf.
It's called big Shots. Yeah.
Yeah.
Well, my wife and I and my father in law, my sister in law and her husband, we go down to Saint George every year for the parade of homes and yeah, so we'd be driving past it every year and oh look it's almost done.
Yep. Yeah, and we just adore this community out here. And in a week and a half or so we'll be getting a hot tub here in our condos. So it's going to be even better.
Man, all right, good deal.
Yeah, I might have to pick your brain on how to buy one, because that's kind of my new dream is I want to own a bunch of real estate.
But anyway, they don't make money month of a month right now, not down here, not yet really, Yeah, I don't. Well, we'll see, but that's we don't expect it to. We're in it for the the equity.
Okay, Well, if people want to follow up and check out what you are doing, maybe in the programming space, how do they find you online?
Corey?
So you can find me mostly so I'm very quiet actually online I don't really get on too much. Kind of an accident. I swooped into too Twitter and made the comments that I did. But most you can find most of my stuff at three sixty five js Things dot tech. That's my website. I have all of my articles, my my talks, presentations slide decks up there, and that's probably at me on Twitter. If you want to talk, I'll respond to that, but.
I won't say what your email is, but I like it.
Well you can you can email me at Corey at three sixty five GSS dot tech. That's not the one that, uh, you're referring to.
But yeah, yeah, all right, good deal. Well thanks for coming, Corey. This was great, and yeah, let's get that other one book because I I'd love to dive into. Hey, you may not know that madam did this, yeah something the browser did this for you, So all right, well we'll wrap it up till next night, folks, max out