INIT

Episode 12: A Framework for Understanding Frameworks

Published: Tue, Jul 25, 2023

(Auto-Generated) Episode Transcript:

Seth Whiting: Hey everyone, I am Seth Whiting. I am a programmer from Portland, Maine, and I've been writing code for about 10 years now. And I'm Jake

Jake Pacheco: Pacheco. I'm a barber from Augusta, Maine, and I've been writing code for about 12 weeks

Seth Whiting: now. Alright. Yeah. So last week. Last week we talked about you getting into react this week and it's that's a big task.

Yeah. Yeah. It's

Jake Pacheco: oh, I into react. Dabbling in this extremely difficult massive

Seth Whiting: quest. Yeah. But I think I think it's, I think that you're ready for it. It's just gonna feel like, a fire hose for a while. Yeah. But. Hopefully like a fun one because every, for every like line of react code that you write, you're getting four or five times the value of every line of just like vanilla JavaScript that you're right.

And, that's just me making stuff up. But it's, no, but all I'm saying is you can do a lot in, a lot less, time. Yeah.

Jake Pacheco: I was watching a few videos about it and stuff, and like reading a bit about it and it was basically explaining just that it's like you can it's

Seth Whiting: how did they put it?

Declarative.

Jake Pacheco: So like you can declare something and it will like, fill in the gaps for you, is my understanding of it, or help you fill in the gaps so it's not, you don't have to write as much code kind of a thing. Is that correct at all? That's

Seth Whiting: I don't Yeah, you can it, yeah.

You could de I wish, I definitely do more with less code. Yeah. I don't like full disclosure to everybody listening to this. Yeah. I don't have a computer science degree. This isn't what I went to school for, but I just went to a bootcamp. So a lot of the like high level like terminology and stuff is I'm still learning it.

I have learned a lot of it, but I'm still learning a lot of it. So what declarative actually means, I don't really know. Yeah.

Jake Pacheco: My understanding of it, and give me a second because it's it might get a little muddy again. Yeah. He didn't go to computer science school. Neither did I, and I've only been doing this for 12 weeks, so good luck explaining this.

But my understanding is there's two different ways of creating a almost like I, I wanna say function, but like functionality with something. And one way is to just declare the thing. And the, it does background voodoo to make it happen versus it being like you have to teach every little bit of the thing.

For the actual program to work. They described it as if you were to go to an artist and tell them, Hey, I want. To build a or I want you to paint a beautiful landscape. Then it'll just, they'll paint a beautiful landscape. They can fill in the gaps. Whereas the other way is if you go to a five-year-old and say, okay, paint a landscape. Okay. So over here you're gonna have trees, and over here you're gonna have a lake. And over here you're gonna have mountains. And my understanding is react kinda helps you more declare things versus having to write down every little piece of every little thing. Is that, does that sound right?

Seth Whiting: That's

Jake Pacheco: Like the, or am I talking about something else?

Seth Whiting: The analogy part makes sense. I just don't I still don't really I'm not really grasping the declaring part of it, but like that analogy of I want you to paint a landscape, and then it just like paints the landscape or whatever.

That sounds like the analogy that I gave Yeah. A previous episode where it was like, Hey, you're building a house. Like we have all of these prefabricated, like parts to the house which ones do you want? And then you can just slap 'em together. Yeah. So yeah. Yeah. Your, I feel like your analogy is perfect.

Yeah. Yeah. It's way better than the painting one, so Yeah, definitely.

Jake Pacheco: Screw the painting. The painting's awful. Yeah. Whatever idiot is No, it's a guy. The guy's actually like teaching

Seth Whiting: designs,

Jake Pacheco: But yeah. No that, now that you say that and you're reminding me, I'm like, oh, that's what he's talking about now.

Yeah. Yeah. It's the same exact thing as this. Okay. So I, I guess just maybe because. I don't know. It was said by more than one person. Now it's like clicking. Because which is very much how my mind

Seth Whiting: works anyways. 'cause somebody else said it. Now you get it. Yeah. Thanks a lot, Jake, Seth, I say thank you every time, Seth.

I

Jake Pacheco: love you and I appreciate you and let's leave with that. But yeah so I guess in that, going off of what you said about how it does make your life easier and makes it so you don't have to write quite as much code. And it seems to me also like that you don't have to, I mean we talked about this quite a bit last time too, but not only do you not have to write so much code, but you also get to get away with only writing in one file sometimes, or I.

If you have we talked about it last time, that you can attach other files, so like we use the button analogy or whatever you

Seth Whiting: wanna say, or and having

Jake Pacheco: it be, so you can use one line of code to do multiple different pages or work in multiple different pages. That was one thing that I wanted to talk about also was I heard that

Seth Whiting: V

Jake Pacheco: is really good for,

Single page applications, and I wanted to know the definition of that.

What do they mean by that? Does that mean that literally I can only have one page? No. Or what, how's that? How's that?

Seth Whiting: Yeah. No that's a great question. The single page applications are a very big topic in web development, where it used to be that when you're writing, like back in the day, p h b was like the way that you.

You've made like dynamic, adaptable, functional kind of like pages. And with p h P, everything is server rendered, server side rendered, which means that all of your markup and everything, like if you have data coming in from a database, all of that data is plugged into your, like H T M L basically on the server.

And then it just gives the browser the full webpage be before, before it ever gets to the browser. Everything is plugged in there and it's like a full webpage that, that the server gives to the browser. Nowadays, the standard for web apps especially not necessarily websites, but web apps.

The standard is a single page application, which means you just have one page that kind of rules them all, and then you are basically switching out the content on that page via JavaScript on the front end. So like you're just rendering one page, and then when you go to another page, like it looks like you're going to another page, but really you're just ripping out one page and spitting in the next page via JavaScript.

So everything is happening in the browser, everything's happening on the front end. Huh. So instead of and the big difference there is that the page doesn't need to reload every time you go to another page. So if you go to a website like any like WordPress website where it has usually it'll be like a homepage and then there'll be like an about section on the website and then like a contact page on the website, things like that.

If you click on each of those pages, the whole site is going to refresh. Okay. And it's going to have that little loading circle in the, yeah. The like tab of your browser. Yeah. It's gonna like load. Yeah. And it's gonna take a second for it to reload. And because it's basically building that whole page for you on the server, and then it's, once that server delivers it to the front end, then it will show you the page.

Yeah. With single page applications, you don't need to reload the page so things can at least look like they're happening much faster. Yeah. And in, in many cases, they are happening faster. Yeah. But instead of having everything be like plugged in and fabricated on the backend and then delivered to the front end it's, you're calling out to an a p I endpoint and like you're switching out the markup via JavaScript on the front end.

Everything's happening on the front end, and you're just grabbing the data and everything's being plugged in on the front end. So that's when you get like loading circles on the actual page like loading circles or nowadays it's common for things to be like lines on the page, just like it's called like a skeleton loader.

Where it's if you have a Facebook post, you know that the Facebook post is going to have somebody's like avatar, like a circle photo in like the top left corner of it, and then like their name and then some text. So what they do is they have just a blank circle that's like gray and then a gray bar for where the name goes, and then gray bars for where the text goes, and they just look like they're loading because it's like a Grady.

Yeah, I know exactly what you're talking about. Yeah. So hopefully other people know what I'm talking about. Yeah, so that's basically the front end has already loaded, like the page is already there, but instead of everything being like plugged in on the back end and then delivered to the front end, It's the front end is already there and you're just waiting for that data that is going to be plugged into to those parts.

So like your avatar picture and your name and the content of that post are being fetched on the back end. And just that data is coming from the back end to the front end. And then it populates into Yeah, the front end that it has been there the whole time. Huh,

Jake Pacheco: interesting. So it's literally just reaching out for data instead of the whole page basically,

Seth Whiting: is the idea.

Yeah. Yeah. Yeah. And and like the, I think, like I said, like the biggest part of it is just that the whole page does not reload. Like your browser doesn't reload a whole page. Yeah.

Jake Pacheco: So it's, it, so I guess with that, when you say that, does it mean that it's just able to reload parts of the page that it wants?

Or, yeah, so you can, because like when I press like a home on the on Facebook versus when I click on someone else's name or whatever. Does it just grab data and fulfill the page with their name and their information?

Seth Whiting: Yeah. Yeah. Huh. Yeah and that's

Jake Pacheco: something I didn't, I guess I didn't realize that at all.

Yeah.

Seth Whiting: It's really just like, where does the loading happen? That's what it comes down to. It's do you get to the page first and then wait for things to load? Or do you hit the button, wait for the little loading circle on the tab, and then everything just shows up at once? That would be the server side rendered experience. Yeah. And then the single page application experience is you go to the page. But you have to wait, for things to load and, but you're like, have a, you have a visual indication, on the page itself. Yeah.

That things are loading.

Jake Pacheco: That's interesting because now that you say this, it makes perfect sense because when you look at like the top of a Facebook, of your Facebook application on a website, like it's like on your computer or whatever. Like a lot of it looks like, your task bar or whatever you want to call it, everything looks the same.

It's just, yeah. Filling different information in there. And then I was like thinking, I was like, okay, so is that how it is with a lot of them? And then I'm like going through a bunch of different things and like it's, yeah. They all have that kind of thing. Like it's, it always looks like it, it's always has like there's going to be a similar piece to it, and then there's just information that's fulfilled.

It makes it feel like you're going to different pages, but it makes sense. It's a single page.

Seth Whiting: Ah, yeah. So like often you'll have the top bar thing and then sometimes you'll have a sidebar. Yeah. Sidebar. That always stays there, yeah. It's always there.

Even when things are loading that has already loaded once. Yeah, that's, it doesn't need to loads just staying.

Jake Pacheco: Yeah. Huh. And is that why they divide it up into like different windows? Or, yeah. It must be like why they would divide it up into different windows in React and stuff is like so you can like, okay, this is, this part is just going to load this sidebar or just this header

Seth Whiting: area or whatever. That's why you would divide it up into different files. If that's what you mean into different files. Yeah. Okay. Yeah. Like different components. Those would all be components.

Components, I guess

Jake Pacheco: is what Yeah. Yeah, that's what I was thinking. Yeah. Yeah. Okay. Huh. Interesting. Yeah. That's new knowledge now I know what the difference between,

Seth Whiting: Yeah. Okay. But that's not specific to react, just no.

Jake Pacheco: That's for a bunch of different things. Yeah.

Any single page application, right? Yes. Yep. Yeah. Which can be written in

Seth Whiting: other things too. Yeah. You could write it in vanilla JavaScript if you wanted. Interesting. Without a framework or anything yeah.

Jake Pacheco: Yeah. But it seems pretty much like everything's leaning toward this way of single page app development, or what

Seth Whiting: do you think?

Yeah, that's been the standard for a while. But and for a while, since I've been developing, so it's like over Yeah. Over 10 years. Yeah. But but there's like with Next jss there for a while they were doing server side rendering and that was like a big thing like that.

What made them different. Yeah. But I feel like I was looking into it more recently and they've moved away from that a bit. And now they do what's called static site rendering. Yeah. Which, so on for server side rendering, you have everything. Plugged in together.

E everything is put together on the server and then delivered to the browser. Yeah. With static rendering, you actually grab the data, like while the site is being built. So it's called at build time. So when you make a single page application at least with like a framework like React, you will write everything in JavaScript but then everything gets compiled down to like HTML C Ss, S and JavaScript.

Yeah. And when it does that it's going through like a build process and there's like a compiler that goes into effect. And so when you do that, you just run a command on your command line or it that happens in the server. Yeah, but that's called build time. And then so with server side, or sorry, with static rendering it actually reaches out for the data via the a p i endpoints and stuff, and plugs it in and everything gets like fabricated plugged together and everything.

And then just sits there until somebody requests it. And instead of it being plugged in when somebody requests it, it happens before anybody requests it. So it's just like an instantaneous thing. The fastest webpage that you'll ever see is just one that's written in HTML and css and it doesn't need to load anything.

It's just like already there. Yeah. It's, yeah. So basically that's what they're trying to do is like everything is already there and you can do that. With your single page application, but with next, basically it wouldn't make much sense to do that because if you have like user generated content, then it's gonna be changing all the time.

And you would need to keep like fabricating page after page. Yeah. Every time somebody like updates their like, information Yeah. On any given page. So what they've done is they have it so that it statically renders all of the stuff that is not going to change. Like the header?

Yeah. Yeah. Or the sidebar, all of that stuff. And as soon as somebody reaches that page, that stuff just shows up like instantaneously. Yeah. And then, just the sections that need to load load. Yeah. Yeah. Yeah.

Jake Pacheco: That makes sense. Yeah. Huh. So it's doing. A lot of stuff, but more in the backend, which makes sense.

It's next. Yeah. Interesting. So is there any, I guess a question would be like, is there any superiority to that or is it mainly just like on a need to build basis kind of a thing when it's no, this makes the most amount of sense because we're dealing with a lot of whatever traffic or something.

So you wanna do that? I don't know w why would someone do that over building? Just react like a React single page

Seth Whiting: app? Yeah. So if you're doing just like a React single page app, then. Like without static generation basically. Then you're going to just wait a wait a little bit for

Jake Pacheco: anything to show on page a few milliseconds or a second more.

Seth Whiting: Yeah. Probably like a second to two seconds. Yeah. Just like a blank page or just a loader Yeah. Kind of thing.

Jake Pacheco: Yeah. So it's almost like it's almost just a flex if you write it in with next Jss next jss static.

Seth Whiting: I wouldn't call it a flex. So what I'm talking about is like just it's like they made a choice, this choice to present a better user experience.

Yeah. Yeah. Because it, it feels better psychologically to have something there than nothing. Instant.

Jake Pacheco: Yeah. Yeah. Yeah. Huh.

Seth Whiting: That's interesting. Does that make sense? Like the static, so basically No, no added stuff or Yeah, server side rendered stuff or static generation. So like server generation versus static generation versus just like everything happens in the browser and you have to wait for it kind of thing.

Yeah.

Jake Pacheco: Yeah, it makes sense. What I mean by the whole like flex thing is that so with building houses, people go for like a an a well building efficient houses. 'cause I've researched that there's people go for a three a c H 50, which is three air changes per hour, right? Like at 50 Pascals, which is basically 20 mile an hour winds outside.

And then if you wanna be like, crazy. Gotta really go for it. Like you can get, try to hit like a one AACH 50, which is a really tight house and you have to have like ventilation and stuff. But

Seth Whiting: yeah. So this is talking about like how well your house is insulated and like how much air and how in and out.

Jake Pacheco: Yeah, exactly. Exactly. Without any windows or doors open, obviously. Okay. But there's people that go further than the one A c H 50. And what I meant by it's a flex is like in that it is a flex. It's oh man, you got it to 0.25 A C H 50. That's like the tightest house ever.

Yeah. And I don't know. I guess in my mind I'm like, if I have to wait like. One second for a page to load. And maybe I'm aging myself just because it's I remember when pages used to take

Seth Whiting: Yeah. 35 minutes, 30 seconds plus. Yeah.

Jake Pacheco: It was wild, yeah. So if you have like your whole page and you're just waiting for one part to fill in for two seconds and you're like complaining, it's oh man, that's goofy.

You know what I mean?

Seth Whiting: But

Jake Pacheco: I do get what you mean with user reaction to it is oh my word, this is instant. Yeah. And that's really cool. 'cause I do get that. And some people, I think we've all been there where you click something and you're waiting and you like click it again to see if it's actually doing anything.

You keep clicking it and then you opens

Seth Whiting: Six pages and stuff. Yeah.

Jake Pacheco: But yeah. So I guess that does make sense where it's like it the user Enjoyment matters to to a certain point. And I see why people would do it that way. Just so it's

Seth Whiting: yeah, no, this is right.

The best we can do it in way user experience. A k a UX is like a very Yeah. Very important thing to especially people who are making things for developers, like they Yeah. You don't wanna if your like product that you're making for developers is like, has a worse user experience than a competitors Yeah.

They're gonna choose, user experience is really, it's like king for developers. Yeah. It's like that's the thing that basically if you're working on a project and it comes down to this feature is going to slow down development, I. Like 50% on the project, like not 50%.

It's going to add, like 10 extra hours to the project, but the user experience is going to be better for it. Yeah. You're pretty much always going to you, you should probably, at least put it on the list, to do Yeah. At some point. But it's it's important to like address, like anything that you identify as oh, this could be a better experience.

It's pretty important to like, address all of that.

Jake Pacheco: Try to focus on those things that you could increase a better increase user experience. Yeah, that makes sense. And it actually it, like it just clicked when you said it. I find that a lot of things. How do I say this? A lot of softwares or just things in general you might do on your computer.

A lot of people will give something a horrible review because they don't understand how things work in general. So like for instance, I have these Samsung wifi speakers. And pretty much within a year of them coming out, they like, they almost stopped making 'em entirely. They sound beautiful.

Their wifi, they came out at the same time as Sonos one, because their user interface is better. Hands down. I, I've, but I was like, okay, these were like, $500 per speaker. 'cause they're, again, for an audio file, they're incredible. And, but they're a pain in the butt with wifi.

It's it's touchy. It's, if you don't set it up perfectly or if you have The wrong I don't know, it inputs for your wifi connected to it or anything. Just anything is wrong. It doesn't work. Just flat out doesn't work. Yeah. And and the app was incredibly slow that they had for it.

And it wasn't getting updated, so people were just miserable with 'em. So they were selling 'em for $50. Yeah. So they were like incredibly cheap. So I was like, I'll pick up a few. And I can deal with software stuff. 'cause like I've, I just nerd out about software stuff. So I guess when you said that, it like clicked to me, it's oh Jake, this isn't a big deal for you because you're into that kind of thing.

I'm into like troubleshooting and trying to figure out why the heck this isn't working and stuff. And it also clicked, 'cause earlier today I went to log into Udemy on my phone. To watch some videos on React and And it was like, yep. Do your email and stuff. And I like clicked my, sign in with Google and it didn't work.

And I was like, okay, weird, whatever. So I just typed in my information, my username, and then I went to type in my password on my phone and it go, it like flashed real quick, my Samsung password thing. And then the keyboard went away and I was like, oh, oh, okay. And I'm like clicking the password button and it's just not it just keeps doing the same thing and getting rid of my keyboard and not letting me sign in.

And I'm like, okay, I guess I'll just go to YouTube even though I bought this thing. You know what I mean? Thing. And it's, yeah, that whole thing you said about developers like using it, it should be usable to them and they should like enjoy using it through it. I was like, oh man, that was like kind of nail on the head for that.

'cause I was like, that's, I. I can't do anything from my phone to fix

Seth Whiting: that. You know what I mean? Yeah. I was more talking about like next versus like V versus like create React app or something. If one of them gives you tools that will make you present a better user experience to your end user, then you're gonna wanna choose that one.

You know what I'm saying? Okay. I get what you

Jake Pacheco: mean. Yeah. I get what you're saying there. Yeah. Yeah. But yeah. Regardless, it made me think of that. Yeah. Yeah.

Seth Whiting: I was like, what the, but that's, that's a good example of just like bad ux,

Jake Pacheco: yeah. But you come across that a lot.

Like I, again, like I've come across it so many times where people like hate an app or hate on something, and it's Because the UX is a, or the UI is a pain in the butt to work with. But it's it does its job really well. But it's a pain in the butt to work with. And how do you get past that?

You know what I mean? Yeah. And I guess that's what shows if you're a really great developer and that's no knock on Samsung Sure. They have a lot of things going on, but it's just it is one of those things where it's it really matters in some, yeah. It can make or break.

Again, this was probably something they invested quite a bit on. And then for the UI to be the failure point, like it's Yeah. Can

Seth Whiting: make or break it. Yeah. Yeah. While you were describing, all of that stuff, you used the word miserable, like a lot of their users were like miserable.

Which is interesting. Yeah. Because there's a tool out there called Sentry, which is a it basically, I. Tracks whenever your app, like crashes or people run into like errors and stuff? Yeah. If you've ever run into a 4 0 4 error on, on, yeah. A website or whatever, there's a bunch of other codes, like 500 and 400 and whatever.

But basically if anybody runs into any errors on your application, you wouldn't know that unless they like reached out and told you Yeah. But sent makes it so that if something errors out, it will send you like an error report, like over the air, like through the cloud. Yeah, and they have something called a user misery score, which is basically like how long things are taking for people to like access on your site.

Like, how long are the page loads? How long are these components taking to load? That kind of thing. And the longer something takes to load the more like upset people are gonna get, yeah. Using your software, yeah.

Jake Pacheco: I can't even I can't tell you how many people, like we joked about it tonight with our application that we have for booking at the barbershop.

There's so many people that will come in and be like, yeah, I couldn't get the app to work. And. It's frustrating because it's just if you're booked out, like entirely, like

Seth Whiting: your day's booked then

Jake Pacheco: it'll show that you have no availability. It means I have no availability.

And they'll be like, yeah, I said I couldn't find anything available for you. And it's that's 'cause I'm booked. It's available. It's an incredibly frustrating thing. I had one guy the other day that came in and he is like the your app's not working. I'm like, oh, okay, what's not working on it?

And he is I can't download it. And I'm like, that's not the app. I'm like, gimme your phone real quick. And it was an iPhone and I'm like, touch and go with using iPhones anyways. Like I, I'm, I just don't know. I don't use one every day, so I don't know. But like I go to the store and I find our app and like I click it and it just like loads and isn't downloading and I was like, That's not our app problem.

And then I go to another app and try to do it and it doesn't download that one either. And I was like, yeah. I'm like, it's not,

Seth Whiting: It's

Jake Pacheco: but it just it must be frustrating being in the development seat and like, when you have created a good app and, everything works.

And when people are still frustrated by it because of their own, I'm gonna say it, stupidity, because I've just come across it so much. I've come across it so much where people can't figure out I, I don't, I'm not good with computers. Yeah. And it's no, you're just a dingbat.

You're just like, you know what I mean? I'm not saying like I'm a genius 'cause I am not. Yeah. But I'm just saying just.

Seth Whiting: Try, oh, I can't

Jake Pacheco: find that. It's yeah, but you're not trying yeah. Yeah. I imagine that would be a frustrating thing.

Seth Whiting: As it, it would be frustrating if we got to the bottom of the problem and it just ended up being that the person like wasn't using it. But usually, yeah, usually when might be a natural problem, tells me something's wrong. I like panic because I'm like, oh crap. Something's actually wrong.

Yeah. 'cause things go wrong every day, and yeah. If it is just them being dumb, then it's actually probably less frustrating. It's more oh, thank God it's not me. Yeah. Yeah. Because

Jake Pacheco: then you can also work on what's a possible fix to make it dumb people can use your thing.

Seth Whiting: Yeah. Like that opens down to ux. Yeah. Exactly. That's the user experience. It is if you are not communicating what your application does without you like telling people what your application does, then you're not making it clear enough and you need to rework how the application works.

Yeah. Does that make

Jake Pacheco: sense? And in a sense. Yeah. Yeah. It makes perfect sense. And in a sense, at that point you have to be like, because it must be a bit tricky, I'm starting like five different sentences. Sorry, everyone. But it must be a bit tricky to step out of like a developer's mind and go into layman mode Yeah.

And be like, okay, is this intuitive? Does this make sense that this would

Seth Whiting: be here? You know what I mean? And that's a really good skill to have as a developer is like being able to see things in like a non-technical, yeah. Viewpoint.

Jake Pacheco: Yeah. Because like you can make the greatest app in the world and give it to all your developer friends, they could all say it's amazing.

And then, yeah. And then it gets to a normal person and it's ah, this

Seth Whiting: is too much. Yeah. Depending on who your audience is, Yeah. If it's built for developers, then, then you don't really need to, you're in luck as much, but like most things are built for the general public who Yeah.

Don't know how code works and Yeah. You can't expect them to know how Yeah. Code works. Yeah. It'd be when

Jake Pacheco: I'm recording this, I'm using,

Seth Whiting: Audacity.

Jake Pacheco: And just trying to make it so my audio file didn't end up being a 1.2 gigabyte audio file for an hour long thing.

In the beginning was like, tricky. I had to Google it and yeah. I figured it out, but it was just like it took me a while. Yeah. You know what I mean? To figure that out. And I was just like, I, that's no bash on audacity. It's for people that are actually like, good at these types of things, like recording things and stuff.

But but it is a thing that I was like, huh,

that

Seth Whiting: could be easier. But also like applications like that where it just does so much, yeah. Yeah. Where like you could teach a class on like how to use audacity, yeah. Or like shop. Yeah.

Jake Pacheco: I remember I tried to use Ableton once and it like, I was like I'm in too deep.

I'm in too deep. Yeah. Yeah. It was like I was swimming in a pity pool using magic's music maker, and then I jumped into the ocean. Yeah. And I was like, I am. I don't know. There's sharks in here, right?

Seth Whiting: Yeah. So like there, there's A fine line or like a delicate balance there yeah. And sometimes the answer is do less. Yeah. You know what I'm saying? If you want people, it as simple as you can a thing. Yeah. And that's, yeah. Makes sense. There's there's a company called 37 Signals that wrote a book called Rework that I haven't read, but I'm gonna talk about it, anyway, but they made a application called Basecamp, which is a project management software that their whole thing is it doesn't do everything that every other project management software does.

And we did that on purpose because we want people to just use it and not have to think about it when they use it kind of thing. Yeah.

Jake Pacheco: Yeah. It's like a singular app for a singular purpose kind of a thing. Yeah. Is that kind of the I, the, yeah. Which makes sense. It's what we were talking about with the removing the ums out of all of these, and I'm gonna say a few more times before I finish the sentence, but it's like that, where it's like, you wish you'd just have an app that would just do that a little bit, you, I could do it in Audacity, but it's gonna take me a while Yeah. To do that. Yeah. You know what I mean? Yeah. It makes sense that it would be nice for, to have a purpose built app for something that if they're gonna use a full application for only one thing, like so many times, then have it just do that one thing.

And then it's just simple. But yeah. Also I got, yeah, there's definitely, I. A place in the world for those Ableton users in the world that know what they're doing with that deep probably incredible pile of features,

Seth Whiting: Yeah. Yeah. And then if you get into the nitty gritty of it, if you familiarize yourself with the deep features, then, you can create like amazing work and everything.

But there's also the fact that you could do good work without, not yeah. I don't wanna say 90%, but the 20% of the features that like, are the most like used Yeah. Are good enough to make something really good. Yeah. Learning a language like You really only need to know, like the most used like a hundred or 200 words in Spanish in order to get around Mexico.

Yeah. And yeah. Be okay. Kind of thing. Yeah. I'm sure that's not a hundred percent accurate, but Yeah.

Jake Pacheco: No I get exactly what you were saying. 'cause yeah, I was like talking about that today to one of my clients. I was like, it seems 'cause I was talking about like the difficulties of learning programming.

Or like the difficulties that I've faced with it faced. And it just, the, I've used the I've said it before where it feels like a mountain like Everest. It feels like massive. And when I talked to you about like how long it's gonna take to learn it, and you're like, ah, five years.

And it was I get what you meant by that, as in like the. To get to a point where you're like, yeah I got this. This is fine. But I guess it's the difference between being fluent in a language and being able to go to another country and get by just fine. Yeah. There's a big difference between those two things.

Yeah. Sure. And I, at first I took the five years thing as you're not gonna have a job in this for five years. But now I'm looking at it more at year three I'll probably know enough so I can be like, no. Like I, I'm pretty comfortable getting a job

Seth Whiting: and whatever. Oh. At the end of year one, you'd be like very qualified to be like a junior dev on, yeah. Some team where they expect you to be learning on the job, yeah. That thing. Yeah.

Jake Pacheco: Yeah. That's awesome. And that's what I assumed after I thought about it for a little bit. Yeah. But yeah, at first I was like, oh man, five years. I was like, yeah. And in my head I did the I, I.

Worked it out in my head and I was like, you know what, Jake, the five years is gonna go by regardless. Might as well learn something cool in it. You know what I mean? Yeah. But then I was like, oh, he probably means to be absolutely fluent to the point where or not absolutely.

Because I don't think that there's actually un absolutely fluent in coding. I think that it's it's just, it's almost trying to learn Russian. It's yeah good luck. Good luck learning it all. Yeah. It's like you can't really know it all, so it's and stuff is changing so fast all the time.

That it's but you'll know how to roll with the punches of

Seth Whiting: that at that point anyways, I assume. Yeah. The five years is more just like where you get like the confidence to say I, I'm not like a junior dev anymore. Yeah. I know what I'm doing enough to like, Build an application and know, that like I'm doing it, yeah. Second guess myself every step of the way and yeah. All of that kind of thing. Yeah. But I don't know, like I, that's the five year mark is definitely not a hard and fast. Yeah. Yeah. It's just milestone. It's just like a yeah. Yeah. What you would think it would probably take.

Yeah. Yeah. Yeah. And I think and I said before, like I think that, so the five year mark was like my, yeah. Experience. Yeah. And like I said, I think that could have gone faster had I not taken that little hiatus from app development and done, like WordPress development. Yeah. I think that like that.

Took me away from app development, so I wasn't learning all of like the ins and outs of like, how, like basically like front end to backend communication and like how to create an a p i and how to consume your own API on the front end and all of that kind of thing. Step that is only applicable to, to application development.

Yeah. So it, it could have it, it probably could have been faster. Yeah.

Jake Pacheco: I feel like I remember I know, I do remember us going hiking in Freeport and you saying like me just talking to you about your job and like what you're doing lately and stuff, and you saying that I'm doing like a lot of like webpage stuff right now, but I really want to get more into like web app development and stuff.

And like you, I think you had a freelancing side gig that was doing some app development for a startup or something, and you're like pretty excited about that. You're like, that just gets me more excited than the like just making webpage Yeah. Or working in WordPress or whatever. And I remember you saying that, so it's cool that, Hey, you got there.

You know what I mean? And that was probably like, that was

Seth Whiting: what, like four or five years ago or something? Yeah. Probably. That was little while ago. Yeah. Yeah. Yeah. Yeah. Cool. You got to it, right? Yeah. I, and I had actually done that before the WordPress stuff. And like I knew that, I liked that.

Yeah. But I took the WordPress stuff out of necessity 'cause it was like I needed a job quickly. Yeah. They were available. But but yeah, like I wanted to do application development at the start and I, I actually got to do that at the start and then went away from it for a bit.

And the whole time I was like, I want to get back to that. Yeah. And then eventually did get back to that. Yeah. That's probably like when that was happening. Yeah. Yeah. I

Jake Pacheco: remember you. Yeah. Yeah. I remember it. And it was like it's just, it's cool to see now, like you're like, doing what you wanna do.

That's dope. Yeah.

Seth Whiting: Yeah, so so all of that is to say if I didn't, if I didn't work on the WordPress stuff, it maybe it would be like three and a half, maybe four years. Yeah. It still would've taken a lot of time Yeah. For me to feel like, I, and I guess the point that I was talking about was like the point to where I could look at another developer's code who like was working with me on, the same thing and know that I basically knew more than them.

Yeah. Yeah. And like I, it is like I knew enough to know that I knew more and yeah. Up until then I probably would've even if I like. Was in the like throes of the Dunning Kruger effect where I'm like, oh, I, I know so much. I wouldn't have, I wouldn't have been like, actually sure that I, what I was looking at was like, yeah.

The work of somebody who knew less than I did, if that Yeah.

Jake Pacheco: Yeah. It makes sense. Yeah. You even if you had known more than the person, you didn't know enough about, like almost how code was written to be like, yeah, this code versus that code is, yeah, there's a difference. Yeah. There's a big difference.

You'd be like, oh, they just wrote it that way and I wrote it this way. That's fine.

Seth Whiting: Yeah. Instead of yeah. And one is not better than the other, or yeah, theirs is probably better than mine, but I'm still good, and whatever. Yeah. I don't know. But but yeah, to get to the point to like, where I can see code and I can, know pretty quickly okay, this code is better than that code and for these reasons and all of that Yeah.

Kind of thing. Yeah. That's, it's

Jake Pacheco: cool in a way that's a thing that like, you can actually, see two different like sheets of code and be like, oh yeah, this one's better than that one. Even if they're doing the same thing. Yeah. But it's but is it like how it was done, like a thing?

Yeah. Like it's, because I view that with like cars for me. I'll see a car and I always say it's all about execution with a car. It's I've seen a lot of car builds that look great from 20 feet away. Yeah. And then you get up close to it and you're like, oh, and they did it like that and they did this like that.

Yeah. And they, why would they do that? Like that? There's a better way to do that.

Seth Whiting: And

Jake Pacheco: it's the difference between, a kid who walks up to a car and is just that's cool. Versus me who like di can dissect it visually and be like, oh, they should've done this and oh, they ruled their fenders wrong.

So now that it's cracked and good job yeah. Yeah. Yeah it's just cool that exists in coding a bit too, where it's at a certain point you're like, no. Like I can dissect code and be like, nah, this is an okay way to do it and it gets the job done, but here's a better way that they could've done it.

And if they wanted to really go ham, they could've done it this way and they would take time, but it would

Seth Whiting: be better, yeah. Yeah. I So and to let you in on like one way that you can tell that somebody is better than another. Is this concept of dry code, have you run across that at all? No, not at all. So DRY is an acronym. It stands for Don't repeat Yourself. So basically the whole principle is like if you have a bunch of code that does the same thing or looks very similar you very often can eliminate doing that same thing over and over.

You very often can just be like, oh, let's just automate this or yeah. And the way that you would do that usually is just Putting something in a loop. So basically it's, yeah, I was this block of code could just be, some data that you loop through and then just plug in the data to the markup.

Yeah. Yeah.

Jake Pacheco: I was gonna say you could use it as like a, or, I was getting ahead of myself, like obviously, but 'cause that's what I do. But but I was thinking, oh, is he talking about like today I was working with you have a I guess a set of strings and then you can use like a map, filter, something like that to go through the set of strings and add different things to it or whatever. Yeah. So it's, rather than writing this person equals this person equals this, like or anything like that, you could actually just have it so it, it's. In two different sets of code pulling each person and pulling each tool that they use or something like that.

Seth Whiting: And

Jake Pacheco: instead of having to write that person every single time that you want them brought up, or every tool when you want it brought up, you have to write it,

Seth Whiting: Write it out entirely a thing. So yeah. I think so. So if you

Jake Pacheco: like it loops through a bunch of words and pulls out whatever word you wanted versus just writing out the words themselves,

Seth Whiting: individually, a thing.

Yeah. Yeah. It could be like that or basically if you have and I feel like I use this example on the last podcast or the one before that or something. If you have a list of reptiles and they're in like a card that's can we have this?

Hard layout. And what I mean by that is just like a white square on a page that has like rounded corners and it has a look to it and maybe it has like a shadow on it. So it looks like it's raised off the page, like a half an inch or whatever. And yeah, that would probably be way too much.

Yeah, like a quarter inch, that two millimeters. Yeah. Yeah. There you go. Yeah. So it looks like that and then it has like a photo and then the name of the reptile and then like a description of the reptile all within that like card. And then you have yeah, 15 of those cards stacked on top of each other and you just scroll down and see, the card for each reptile.

Yeah. Like you could write the markup for that 15 times, or you could just have a photo. A name and a description in a, an array of objects. So you have an array with like photo colon and then the u r L for that photo, like wherever that photo lives. And then name colon, and then the reptile's name.

Yeah. And then description colon, and then a string of, like A paragraph Yeah. Of text and then just loop through that array. And then have your whole markup with like divs and paragraphs, tags and header tags and image tags. Just within the paragraph tag, you have a placeholder for that reptile's name or that reptile's description.

Yeah. I don't know if I said header or paragraph. The header would be the name paragraph. Yeah. I got you.

Jake Pacheco: Yeah. Yeah. And you're just referencing back to that to Yeah. The original function that you had written with those

Seth Whiting: that array and everything. Uhhuh instead Uhhuh. And that's like a very simplified, like simplistic example of dry code.

Yeah. Where it's yeah, you're not writing the same thing 15 times. But there's also instances where like you have and I feel like I touched on this before as well, where it's like you have a table component and you use that table component in 15 different places on your app.

Yeah. But in certain places it looks a bit different. And instead of having, two or three different components, Like table components that do pretty much the same thing, look pretty much the same way, but are like slightly different in areas. Yeah. You have just one component that has like a prop that you pass to it.

So just say this is this component with like variant, like big or variant. Yeah. Small

Jake Pacheco: or whatever. Yeah. And then we were talking about a button before when we were doing it, right? Yeah.

Seth Whiting: Is that, yeah. Yeah. I think at some point I had talked about a table, but yeah. Yeah.

Basically it's just if the table has a footer to it that has like the, like total number, summed up at the bottom or whatever. Yeah. And then in some places it doesn't, instead of writing two components, the code for two different components, one with a footer and one without, you just have Includes footer, true or false, and then you show the footer or don't Yeah. That kind of thing. And that's also pretty simplified. It get, it can get like pretty complex where it's yeah. Oh, I don't know if it's possible to write this in one component, but Yeah. Usually it is if, Yeah.

If you really know what you're doing, usually it is. Yeah. If that makes sense. Yeah. Which

Jake Pacheco: must be, yeah. That must just be a cool point to be at. I'm smiling right now and sparking because it's that must be cool to be like, oh yeah, that I know how to do all these

Seth Whiting: You know what I mean?

That's, if something seems, if something seemed impossible to one developer, And then, but the other developer is oh no, it's totally possible. I've done this like maybe two or three other times. Like that's what the point where okay, that developer is the difference you're talking about.

Yeah.

Jake Pacheco: Yeah. Huh. That makes sense. So might that be the similar to what that book was about? That clean code book was probably about, was about

Seth Whiting: like they definitely code on dry code, Yeah. Yeah. It's probably like a very overarching theme of the course, but I'm sure that they go like much deeper than that.

Yeah. Yeah. That makes sense. Huh?

Jake Pacheco: So it's So that's our goal is to get there. Yeah. Yeah. So to you all in five years now, maybe,

Seth Whiting: who knows? Hopefully let's get into React Land for a bit. Yeah. Like you, you like just barely dipped your toes into like in introduction to React this week. Yeah.

Like what what kind of stuff did you like get into? How, I don't know, like how are you, how deep? Yeah. Not how deep, but I, I know that I wouldn't expect you to like in one week get very far at all, but did you get to the point where like you were looking at React code and like you probably did at some point before this anyway, but yeah.

Did. And do you, did you notice anything about This is weird or unfamiliar, that kind of thing. Yeah, it's

Jake Pacheco: so some stuff is familiar you're still writing some, like arrow functions and stuff like that. Which is cool. What are they called?

Props. That's something somewhat new to me. Trying to understand that entirely. It seems that it question actually, because I was watching a video, but it was a little bit I felt that it might've been a little dated, but are all H T M L bits under props, or is that not, or is that not a thing?

You know what I mean?

Seth Whiting: I'm not sure what you mean by bits is the only thing

Jake Pacheco: like when I do, when I write H T M L in JavaScript am I like writing prop and then doing whatever H T M L stuff, no. Is that like a a call to arms of Hey, I'm. HTML now? No, it's, you can just

Seth Whiting: write it straight up.

No. So like, when you are props are basically like in react nowadays, especially, every component is encapsulated in a function. Yeah. It used to be that you had to write it in a class, which is Okay. Basically just like a different way to write. I don't wanna say a different right way to write a function, but they're very similar and yeah, class just works a little bit differently.

But nowadays, since I think like 2017, 2018 or so, I'm not sure about those dates, but they introduced Functional components is what they're called, which is just components that you write within a functional, a function block as opposed to a class block. And along with those functional components, basically the way that they were doing things with class, they gave you tools to work with within classes.

But they only worked within classes. So they took those bits and separated them out and made it so that you could work with those kind of type of things. They're not the same, they're a little bit different, but those type of things, they made them accessible via functional components in the form of what they call hooks.

Okay. So hooks are just like little bits of react code that they provide for you that you can use within. Functional components basically. Okay. So that all of that is to say basically when you're working with React nowadays, you're usually going to be working with functional components, which are just a function that returns markup.

Yeah, it returns usually returns markup like 99% of the time it's gonna return markup. And exceptions to that rule are like when you're writing your own hook you can write custom hooks in, in that case, you can return pretty much whatever you want, but that's, confusing.

You don't need to worry about that right now. Okay. When you're writing functional components, you say, like constant like table. Equals, and then parentheses and then arrow, and then curly braces. Just like you would write a function, yeah. And it returns your markup. And that markup is written the same way that you would write H T M L.

Huh. And the at, when you write pon table equals parentheses, arrow curly braces. Within those parentheses, you can pass props. Yeah. There arguments to the function. Like they're okay. Their parameters, arguments, props. Yeah. Yeah. They're pretty much the same thing. It's just okay, you're passing.

I, I didn't know that. An argument to the function. Okay. So are people. And so when you pass something, so like you can pass like a prop called data. That data can be like an array of objects that you plug into your table. Okay. Huh? So if you have a table component, you have a page with a table component, which is just written like an HTML element where it's like angle bracket and then the word table, and then then you like close it out like an H M L element.

But within the, like right after the word table, you do space data equals, and then you'd pass it that array of objects. Okay. In the form of a variable. So it could be data equals curly brace data, or it could just be like, data equals ta table data, or data equals like, Reptiles, whatever you called your data.

Yeah. You'd pass it to the data prop. Yeah. Or whatever you called the prop. You could call the prop table data if you wanted to, but when you pass it through to the function, like when you're actually writing the function, you would within the parentheses, access the data by whatever you called it.

Like table data or data Yeah. Whatever. Yeah. And work with it within your component. You could take that data and then within your component you would open up like a diviv and then you could map through the data and write those like card components that I was talking about earlier.

Jake Pacheco: Yeah. I know exactly what you're talking about. Or I think I'm wrapping my head around it

Seth Whiting: anyways. Uhhuh. Huh?

Jake Pacheco: Interesting. Yeah, I was just curious about that. Today also I was working on 'cause Code Academy has an app for your phone that is pretty useful just for like practice and stuff.

It's like flash cards and stuff. And I was just seeing going through the practices with writing React Code. Java in React JavaScript and React. What do you say? What do you say with that React code?

Seth Whiting: Do you Yeah. You could say React code because it's okay.

You're writing you are writing JavaScript. Yeah. You're writing it in the way that React wants you Okay. To write it. So Yeah. Yeah. It's code that will not work outside of React, yeah. So it's React. So it's React code. Yeah. Okay. Cool.

Jake Pacheco: But yeah, I was writing it in there and I think that this is a thing with.

JavaScript also, but I just wanted to refresh your course and make sure that it is basically it was having me had odd number. It had a what's it called? We were just talking about them, not a string, but an array. Of a bunch of different numbers. And they were all odd numbers and it said, let odd numbers equals

Seth Whiting: this.

And then

Jake Pacheco: it was you had to figure it out to make it so it gave you even numbers

Seth Whiting: and

Jake Pacheco: basically, so you double the odd numbers and make that happen. And then, console log even numbers and it would show that. And I thought I could write it because it gave you times two there.

And I was like, okay, so can I write this Cons like odd numbers. Even numbers equals even numbers times two. But it was actually written numbers times two. And sometimes that kind of thing throws me because it was never declared as anything. Numbers wasn't, but it just knows numbers is a thing or something, it knew that numbers was in there even though I didn't it wasn't declared as numbers. Does that make sense to you at all?

Seth Whiting: No.

Jake Pacheco: Yeah. It threw me for a loop, man. Like I got it wrong like 15 times before I was like, how is it numbers? And then I finally clicked numbers and it was like, yeah, it's numbers.

Seth Whiting: So no it was never, it, there was no code anywhere that said constant numbers equals, equals this, yeah, whatever. No, yeah. Or let or var or anything?

Jake Pacheco: I not that I saw, I wish I had screenshotted it. I might be able to find it, but it was like, and I'll probably just send it to you later and then we can talk about what happened.

Uhhuh but let me see real quick. I

Seth Whiting: might actually be able to find it. So there there, there are certain things in JavaScript that they just give you which is like pretty confusing. I remember being really confused. And it's the same with any language. It's like they give you built in functionality with the language.

Like keywords, basically yeah. Date, if you're working with date, the word date is like a reserved word in JavaScript. So like you can't name something. You can't name something date with a capital D because it's oh, that already exists. Like that. That's a part of JavaScript, yeah. Yeah. And there are certain other words like for, it's like a for loop or if that's it, if statements. So it's it gets confusing when you're just starting out. What is something that I, or some developer that I am working with declared myself or their self.

Yeah. Versus what is something that is just inherent to the language itself, yeah. Because there are certain words that like, yeah, do things in the language and you have to know what each of those are or like, yeah. Not what each of them are, but you, when you run into them, Sometimes it's not immediately clear that oh, this is not like a variable that somebody declared somewhere.

This is just like part of the language. Yeah. Yeah.

Jake Pacheco: And that's exactly what I'm talking about. Yeah. Is what it seemed to me what happened was like, it's no, you just had to know that this actually means something. Without it having to be declared. Yeah. And maybe I got the syntax wrong when I said it, but it's just, it's, and I couldn't again, I'm gonna try to dig deep and try to find it, but it was just like, yeah, no worries.

It frustrated me. Yeah. To no end. I was like, why isn't this going through?

Seth Whiting: Yeah. Yeah. But yeah, it's, I remember running into that a few times for sure. Like when I was starting out and the more you run into it, the less you'll run into it. Because like of course, you familiarize yourself with the language, you familiarize yourself with, like the terminology that they give you out of the box and Yeah.

You know what's there and what's not. Yeah. I'm sure there's stuff out there that I still haven't run into, but I haven't run into a scenario like that in years, yeah. It's, I got it all out of the way. Yeah.

Jake Pacheco: I get that. So yeah, it was that kind of threw me for a loop.

No, it's not a loop at all. But

Seth Whiting: Whatever.

Jake Pacheco: That's a joke. Get over it.

But yeah, that, that kind of threw me a little bit. I. And yeah, I went to another video today and it was about just trying to understand all that like v does and stuff. And it ended up being another tangent against that other coding thing, the, other. The other one.

And I was just like, but it, it seems like at least YouTubers don't like that other one for some reason. I they said what is, what's is it S W C S W something?

Seth Whiting: Something like that.

Jake Pacheco: Yeah. They, this kind of automatically adds that to your code if you want, or to your project already.

And the other one doesn't or something. Yeah. But yeah. What's the significance of

Seth Whiting: that? I, yeah, so that's I'm pretty sure, and I'm not like don't quote me on this. Yeah. But I'm pretty sure that is. You remember when I was talking about how next does like static generation and it, the whole thing with static generation is that it plugs things in at build time.

Yeah. So that's like when things are getting compiled into htm, L and c, ss s all of that kind of stuff. What I'm pretty sure SS WC is the compiler and, okay. So basically it takes your, all of your JavaScript and all of your J S X in particular, which is the way that you write your H T M L within JavaScript.

The markup is called J S X when you're writing it with React or a couple other select frameworks. So when it's compiling all of that to ht m, L and C SS. And the JavaScript bits that are not related to the markup it's going through like a whole build process and it needs to read all of that code and parse out okay, this is the H M L, this is the c s and this is the JavaScript and it goes through all of that stuff and spits out, a package for you at the end of it.

And that process is pretty like intense, like it's a lot to do. Yeah. Yeah. And it's just like your computer working for a minute and then spitting something out at the end. And I think I remember reading that I. S w c was written in a language called Rust, which is super hyped right now because people are using it a lot because it's so fast.

Like the language rust is very fast. Yeah,

Jake Pacheco: I've heard a few things about it, but not a lot.

Seth Whiting: Yeah. A lot of people are like rewriting a lot of the stuff that they have written in Rust just because it's way faster than the previous iterations of whatever they were working on.

And because of that, because s WC is written in rest and because basically it. From what it seemed to me, it's like a very fast compiler. So okay. When you start the build process, it finishes in a much shorter time than it does with Create React app. Okay. And it may do some other stuff like the hot reloading stuff that I was talking about.

Yeah. Where like when you Yeah, it's pretty sweet. Yeah. That kind of thing. I don't know. I am totally just like speculating here, but it may do things like real time things as you're developing way faster than create React app as well. Okay. Yeah. Yeah. But I don't know. And the, like I said, this is all speculation.

We're on un

Jake Pacheco: uncharted territory here.

Seth Whiting: Yeah. Yeah. But I do know that like I said, I. Basically like Node itself was completely rewritten and I think it was Rust. And the guy who wrote Node basically rewrote it all and called it Dino, which is just like a an anagram of node.

Okay. Yeah. So like the letters are mixed up. Yeah. So Dino is like a replacement for Node written by the same guy. He is. Node wasn't good enough. I'm, redoing it. And I think it, it's a lot faster because it was, I think it was written in rest, but Basically if your product was written in Rust, nowadays people are like, Ooh, we gotta try it out, huh. So I don't

Jake Pacheco: know. Yeah. A thing. Interesting. Yeah. Huh. So Russ is a newer thing that like, people are getting into pretty heavy. I don't, is it is that considered backend or is that what would you consider rust? I, I don't, I'm not, it's not clicking in my brain.

If it compiles to rust, then does that make it like a father language or a mother language where it's like superior to all of the other stuff? You could just write everything in rust.

Seth Whiting: Yeah. Again I'm not a computer science graduate or anything. Yeah. Yeah.

Just I'm just curious about that. In my own, like cursory research basically sir is listening to me right now and it's annoying me go away. I don't know why. She's a creep. Alright,

Jake Pacheco: thanks Siri. I shut off Bixby. You have to shut off Siri, man.

Seth Whiting: Yeah, so from my like cursory research I had I was just researching like languages in general and there are things called compiled languages, I think, and then interpreted languages.

JavaScript is an interpreted language. And then there's another kind of category on its own which are like languages that run on virtual machines basically, which is like Java. It runs on the J V M, which is like the Java virtual machine. But anyway, interpreted language is. Are languages written on top of other languages and JavaScript and P h P and Python and Ruby, like, all of those are written on top of C Rust is not it's own thing.

And it was so Rust is not also, there's a language called Go that was not written on top of anything. So basically it's just it doesn't need to be translated ever. And when you're when you're running in an interpreted language, I think it like translates on the fly, which slows it down.

And when you're running in a compiled language it. You need to compile the code, I like, again, I'm just like, yeah, this is like spitballing. This is me researching it for not a long time, but because you don't need to interpret it ever on the fly. It's just like what you write is what runs and yeah, it runs fast.

And there are other certain things about certain languages where there's something called memory management where yeah. You allocate just enough space in the memory of your computer for something to like work. Yeah. So if you're working with a a string, If you know that nobody is ever going to write a certain string, like never going to write like a tweet over 140 characters.

Like I'm not talking about tweets at this point. I'm talking about this is just like a Yeah, an example like tweets used to be only 140 characters. So in theory you could only, you could have it so that it only allocates 140 characters worth of space in memory. And because of that, like you, your program is gonna run like way faster than if it's just if it's just not guessing, but if every variable has an unlimited amount of space, then like it, it's just going to take up a lot more space than it needs to.

Yeah. I don't wanna say unlimited. I'm sure that there is a limit in every language, but that limit is like huge. So yeah. Yeah. So if your application only takes up like a fraction of the space that another application like takes when it's all said and done, when it's all written, then it's just gonna be like, it's going to seem like instantaneous compared to Yeah.

Compared to something written in a language where it

Jake Pacheco: has to compile and it has to do a bunch of stuff. Yeah. Yeah. So I guess that leads me to the question, why doesn't everyone just like, why don't people like learn just that? Yeah. Like why, and

Seth Whiting: I'm curious. Yeah, no, that's a good question.

Jake Pacheco: And or is it just, 'cause it's easier to

Seth Whiting: learn all this instead? So JavaScript is like way easier than rust. For sure. Just like objectively it's way easier than Russ. Yeah. But JavaScript is the only language that will run in a browser natively. Yeah. Yeah. And not to confuse you, but in the past, like five years or so, something has come up called wasm, which is what's called, it's short for web assembly.

So the W is for web, and then ASM is for assembly.

Jake Pacheco: Yeah. That makes so much sense. They really love their Yeah, they love that, don't they?

Seth Whiting: They do that a lot. Yeah. But basically like every language compiles down to what's called assembly code. And that's if you're on a Mac. It's going to be, like the assembly code that runs and is interpreted by like the Mac software.

Yeah. Or not software, but like hardware, like it's yeah, it's public. So it's like assembly and then it goes down to like machine code, which is like binary, but Yeah. Assembly is like the base of the base before you get to just ones and zeros. Yeah. Where it's allocate certain memory and then move Yeah.

Certain bit of memory over here and it's Yeah. Instructions that a computer can read. So basically they, they made web assembly, which is like a version of assembly code that will run in, in browsers and they made that like accessible so that you could. Run essentially like whatever language you want on the browser now.

Yeah. The difference though, between that and JavaScript is that you don't have, you don't have access to the markup. So you can't manipulate the markup on a page. You can't manipulate the C Ss s or the h html. You can just like run calculations and stuff. So if you really needed to, you could get input from a user and then run calculations on it.

Get input from a user with JavaScript and then send that off to Rust or Python Yeah. Or whatever you wanted. C And then yeah, it's runs those calculations, then gives it back to the JavaScript, and then JavaScript then gives it back to the HTML or whatever. So that's we will not be doing that at any point.

Jake Pacheco: No. I was just curious 'cause it was like it always seemed to me that way that everything 'cause right now my understanding is like the language you're currently writing gets compiled down to this, which gets compiled down to this, which makes it so now it's this and then it's binary and that's how we get an actual image on our screen is like certain pixels are turning on when we tell them to. But it's just what a wild ride the code goes on to. Yeah. To get to the point where I actually have a thing on my screen, which is I don't know, I'm still not entirely convinced aliens haven't created this at some point, but that's just me.

A human comes up with this, come on. Like they're geniuses. I don't know. They are

Seth Whiting: geniuses. Yeah. You go, it's a law man. You gotta go back to

Jake Pacheco: the, to. Imitation game or, yeah. Like that. Yeah. Yeah. Beautiful movie

Seth Whiting: if you haven't seen it, but yeah. It's a great movie. Yeah. But what was his name?

I'm totally blanking on Alan Touring. Yeah. Alan Touring. Yeah. My, but even before him. Yeah. ADA Lovelace, who is credited as like the first software developer I think, or like computer programmer I think is what they Yeah. They attribute to her. She's a woman who is genius among geniuses.

She's yeah. Crazy smart. And wrote like books or at least like letters to a a guy who like made machines like Alan Torrin's machine, but like before him. Yeah. And like a bit simpler, but she was like, she saw what people were doing and she was like, had Decades worth of like foresight into what they could eventually do and was like spot on, and it was like, yeah.

Just crazy. So Wild

Jake Pacheco: man. Yeah. Like it's, yeah, just because, I'm excited to be where I'm at even right now. Just because it's like I'm starting to understand or starting to grasp some of how any of this works and stuff. Just because that is the thing that got me into it in the first place is I really enjoy like I really love knowing how something works.

Something that seems like almost incomprehensible. And I think that computing is one of those things, like to the nth degree I've never come across something that like, blows my mind the way that I. Computers do, honestly. Yeah. And maybe it was because I didn't have my first computer until I built one at 17 or 16 or whatever it was. And just being like, okay, so this just does all this. And like how does, how do these parts make it? So now I have an image on my screen and stuff, and now like understanding, like even just that little bit where it's like a bunch of levels to it, where it's it goes all the way from ones and zeros all the way to what we see here on our screen and stuff that's kind of earth shattering still. But yeah. To bring us back around to react and stuff.

Seth Whiting: It's,

Jake Pacheco: I guess another question I have is, why isn't there a learning path that just teaches, or, I think I already know the answer, but I'm gonna ask it anyways. That just teaches hey, here's just start.

Lemme react. You know what I mean? Because it's like that's how you're gonna be writing things when you're writing and react. But I guess my assumed answer is just that react is what's cool now to use but it's probably going to change again in a few years or whatever.

And you still are going to need the fundamentals of JavaScript. And it's like almost learning Latin before you learn like before learning all of the Latin languages or

Seth Whiting: something in a way. Yeah. And honestly like the kind of like track, like the learning track that you were just talking about is like the one that I wanted you to do, but basically like I, I was trying to get you.

To react as quickly as possible. Yeah, because I knew that once you get to react, like you'll start to be able to just make things much more quickly and like just produce stuff. Yeah. But I also knew that if you just jumped into React, you'd be like, okay, here's markup that I have no idea what that even is.

And then here's like the JavaScript stuff that kind of like interacts with the markup and I have no idea what this JavaScript does. That is, yeah. Yeah. And then here's like the CSS part of it that like I like, if we, if you didn't have an intro to like those three things, then trying to tackle them all at once would just be like, you wouldn't understand that they are even separate things, yeah. And like you wouldn't understand that They're independent, but work together and whatever.

Jake Pacheco: Yeah. That makes sense. And that's what I assumed was that it is just no, like you have to understand the separateness of it. Understand how it's all working together a thing.

Yeah. It's just interesting to me that there's not like a, I guess there is in a sense, but it thinking and not talking I that there's not just like a program that kind of does exactly what you're saying, where it is fast tracking you to react. Like for instance, that web development bootcamp thing that I have on Udemy I was looking on it and I was like, oh, I wanna go through some react stuff.

And I had to scroll for a while to get to the section where they start doing React. Yeah. And I was like it made me like, scratch my head a little bit as far as I'm like if that's how you are writing most applications and everything I'm surprised there isn't something where it's like a program or something that's Hey, we're gonna build this, so right now you need to learn this, these are functions, this is what it does and stuff.

In JavaScript, you might write it like this, but right here you're gonna write it like

Seth Whiting: this and this is how you're,

Jake Pacheco: I don't know I was just I don't know it was just a thought I had where I was like, huh, I wonder why they don't like, what, why there doesn't seem to be a fast track just to get to this point.

Yeah. You

Seth Whiting: know what I mean? I don't know. Yeah. And I,

Jake Pacheco: but I guess it's where you,

Seth Whiting: if I were to make a course. I think I would probably do what you're talking about where I would just start you out, like making an application, like just a simple application that does stuff and have you be completely confused as to what am I actually writing right now?

Yeah. What am I doing? And then go back and explain like the parts, like this is the markup part of it, this is the, logic part of it. This is like the part of it and yeah.

So yeah, so doing the thing and then explaining how you just did that thing, I think. Yeah. And like maybe that's a good way to do it. Maybe that's a bad way to do it. I don't know. Maybe, I don't know. Re if you're learning on your own and I'm not there to teach you that.

Yeah. Be with you the whole time, which is what you're doing. Yeah. I think it makes more sense to understand the very basics of each of those, like three things and then do Yeah. The kind of like less basic things. Yeah.

Jake Pacheco: No, that, that makes sense. So basically learn what all of these things are doing in general and then go right into actually creating the thing and understanding like, oh, when I write style anywhere or whatever.

It's pulling up c s

Seth Whiting: Yeah. And stuff like that. Yeah. Yeah. That makes sense. Yeah. It just took us 12 weeks. You gotta go

Jake Pacheco: to get there. Yeah. Yeah. It just took us 12 weeks to get there. Do you have to

Seth Whiting: go? No. Not quite yet. She was just asking if she, if I wanted her to save some food for me.

Oh darn. Kind of her.

Jake Pacheco: Yeah, I I've been sneakily eating pizza while I'm doing this podcast, which is super professional. Yeah, that's what you

Seth Whiting: get with Jake. No,

Jake Pacheco: but I, but yeah, I was I was wondering that, and I think that you have described that and I'm sorry, Seth, if sometimes like I do bring up something and be like, oh, I had this thought, and you're like, yeah, I talked about this five episodes and five episodes of

Seth Whiting: coaching.

No, like it, we cover so much ground every time, Yeah. There's no way that you would retain all of it and like fully understand all of it. It the first time that you heard it, yeah. Yeah, it's repetition is key to like understanding. Yeah, I really wish I could, a phonographic

Jake Pacheco: memory.

Yeah, it'd be nice, but that's not where we're, where it's not where we're at.

Seth Whiting: Yeah.

Jake Pacheco: But yeah I guess that's where I'm at with React right now. This last week, to be honest, I didn't study a ton. I just have a lot of stuff going on with work. Just been working. I upped up my hours a little bit just because it's tax season and also I have a lot of money coming out to build the house currently.

So that's that's kinda, taken precedent over everything else. Yeah. As work tends to do. But yeah,

Seth Whiting: the thought some weeks will be productive and some won't in that. Yeah, exactly. That's the same as like on the job as a developer, yeah. Some weeks you just won't be able to focus at all.

Yeah, because it, that, that's a thing that I have found for sure. And it's probably like I have a severe case of undiagnosed A D H D, but like it you with development, you can't just do it. Like it's not something that you can like multitask or anything.

It's like you, you need to like really. Be able to focus and if, like I have a lot of distractions in my life and some of them are like self induced or whatever, and some of them aren't. But if like you, you need like clear long chunks of time, in order to like actually produce something.

And yeah, that's yeah some weeks you don't really get those chunks of time and other weeks you do and like you're you feel like super productive in other weeks just like you. Yeah. You don't,

I'm

Jake Pacheco: curious when you sit down and are like working and go into code and stuff, are you, how long do you sit down and work for. In one setting without taking like a break because like sometimes like my my brain is burning. You know what I mean? I'm like, oh my word. Like I am like fizzling out.

Is it not that It does it do, does your, coding fatigue not happen to you as much now that you know exactly what you're doing for the most part? Or is it still pretty prevalent when it at a certain point I used to like, I call it like getting lost in the sauce, when you're like when you're like cutting hair and sometimes you just have to step away from the haircut and look at it, and then you come back to it.

Yeah. And that's a matter of like 20 seconds or something with that, but like with coding, it feels sometimes Some days I want to code all day. And I'm like, yeah, I'm gonna get after it and stuff, and I'll like code for an hour and a half and I'm my brain's burning. I'm like I can't think anymore. It hurts. Yeah. Is that something that you run into anymore or is that or did you used to, or do you currently or?

Seth Whiting: Yeah, it's, so it's I can, it's, I can't really give like a yes or no because it's there, there are like several different like modes that I like get into where if I have a small problem that like I, I know beforehand what I'm going to do and how I'm gonna do it, then I'll just, do it.

And it'll take like a. 15 to 30 minutes. Yeah. And then I'll just do it and I'll commit it and push it up and to be like, saved on like GitHub or wherever. And then I'll like, take a break and whatever. It's, yeah. Because like pretty much it's rare that I will complete something and then not take a break.

And I don't really know. There's not really a reason for that. It's just when you have a good ti time to take a break. Yeah. Take a break. Yeah. But then there are other times where like I have like a big thing that I'm working on, but I know how to do it and I know how I'm going to do it and everything.

And it's going to be like just Something that I can just like breeze through, but it's gonna take time where I, I just need to produce the thing and that's all I need to worry about is just like starting it and finishing it. But I know that it's gonna take like a good, like four hours to do.

Yeah. I can sit there for four hours and just do it, yeah. And that's that's th those are like the mo more enjoyable chunks, I think. Yeah. Yeah. Because you know

Jake Pacheco: what you're doing, you know your path, you know how to get there. It's just gonna take a

Seth Whiting: little while. Yeah. It's Ooh, I'm gonna do this thing.

It's Ooh, I get to do this really cool thing and I know how I'm gonna do it. Yeah. And I'm like I can get excited about it enough to just sit there the whole time and do it. Yeah. And then there are other times where I have a similar type of pro problem, but.

I, I know mostly what, like how I'm going to do it, but there's still like a question or two that I need to like solve as I'm going. And those those are the things that like, okay, I have this like long chunk and like this task that is not necessarily ominous, but it's just like I, I know that I'm actually going to have to like, think I can't just be in the zone, the whole time Yeah.

Doing this and those are the things that I will often like, take a break and then come back to it and be like, I think I need to go to the bathroom or yeah. Oh, I think I need to like, eat something. Or oh, I feel like I should probably take a quick nap and then hit this with a fresh mind or, yeah.

Yeah. It's yeah, it's just the things that are like easy to like, procrastinate on. Eventually you do it and yeah. Those are like not enjoyable the whole time, but when you're done with it, you feel good about it because yeah, okay. I solved a problem that like I wasn't sure about, but now I'm sure

Jake Pacheco: Yeah, it might've been having trouble with yeah.

Yeah. That makes sense. Yeah. I was just curious if that's, if that whole like yeah. 'cause that's it, what you described is exactly how I feel like sometimes. Where I'm just like, oh I should eat food before I code. Oh, I should do a thing. Because it's because it's the uncertainty, the I don't know a hundred percent what I'm doing, so it's it's hard to strap down and be like, okay, here we go.

Yeah. You know what I mean? Yeah. Yeah. And it's hard sometimes I end up just defaulting to watching videos about stuff. Where, and that's not where I wanna be. I wanna start working on stuff, but also I need the knowledge, it's one of those things, but I was wondering if that was like a thing that you run into as far as brain fatigue or whatever you wanna call it.

In the beginning, was it when you ran into that or felt like procrastinating? Did you like just reach out to anyone? Hey, I'm having trouble with this. Is that like how it is as a junior developer? Yeah. You can reach out and be like, Hey,

Seth Whiting: When I was starting, like when and this is, this may be like specific to just me when I was starting, I didn't have anything else to do. Yeah. And like I, I didn't really I don't think that I like procrastinated much. I just hit my head against a problem over and over until I got it.

And there, there were other developers that I knew, like my friends who I could reach out to if I was like, stuck. Stuck and I just knew like I, I'm not going Google isn't helping me here. Yeah. And I like need, I need to know this. Yeah. You're spinning your tires a thing.

Yeah. And that was like pretty infrequent that would happen. It was just like, for like pretty big big at the time. Problems. Now I'm sure like I, if if somebody reached out to me with the same problem, I would be like, oh, I remember that. Yeah. But but yeah and that was like, I think it's, it was more like indicative of the time of my life where I was just like, just out of college and like not doing much else kind of thing.

Yeah. Yeah. So yeah, I just like focusing on work. Yeah. Yeah. I feel like I, I just didn't really stop. Yeah. But yeah, I could never do that now. Yeah. Yeah. I just have so much other stuff going on. If something, if I try to start working on something and I run into an issue I'm just like, Yeah.

I can't keep going. Yeah. Like I just have to Yeah. Yeah. I can't waste time. I don't have the time to waste,

Jake Pacheco: yeah. Yeah. That makes sense.

Seth Whiting: Yeah,

Jake Pacheco: that must be but it also must be nice 'cause nowadays, like versus, 10 years ago, even I'm sure there's more information on the web and stuff about all of this.

So it's if you do run into a really difficult problem, you usually find an answer for it, probably on Stack

Seth Whiting: Overflow or something. I've gotten way better at finding the answers to things too. Yeah. Yeah. I'm

Jake Pacheco: sure. Yeah. Yeah. Yeah. Can't wait to get to that point. Just, yeah. Honestly, I just can't wait to get to the point where I know what to search for.

You know what I mean? Yeah. To okay, I have this problem, I wanna make this what do I look for? You know what I mean? Yeah. Yeah. I'm excited about that. But yeah, I'm gonna continue watching some of the videos. But also I am going to do, like you suggested, and just swap back over to code Academy.

Yeah. For their react course. Like I said, I was doing some of their stuff on my phone today their review and practice questions. And I was getting some of the stuff and and some of the stuff was really intuitive. Like I, I was like, yeah, this was written very similarly to JavaScript just maybe a few more words or something, but it's, it was very similar to just normal vanilla JavaScript.

But yeah, there's still, I'm, there's so much to learn yeah. Yeah, and I think honestly, I think,

Seth Whiting: If I were to like advise you in any direction, like I would say like only watch the videos if like you're, if you don't have access to I. Code Academy. Code Academy.

Yeah. That's what I figured. Just do write the code, yeah. Go through the tutorials, write the code, and like I said last time, I think if you get to a point where like you learn something and react and you're like, oh, that was cool. And I can think of, I, I can see how I would use this in like my project that I'm working on, like the reptile like thing.

Yeah. Keeper app. Then, if you feel so inclined, go just like dabble in that on, yeah. On the actual app. But yeah, I would. And maybe you learn better with videos. I don't know. But if it were me, I I know that my style of learning is like the tutorial, like actual writing, like doing the thing.

Yeah. My learning style. So yeah. Yeah. I can't say with a hundred percent confidence that's the path for everybody. But for me, that, that would be like what I focus on, it works for you. Yeah. Yeah. Yeah.

Jake Pacheco: Yeah. And that's, that is gonna be my main focus is I'm going to get through that.

Yeah. Like I said, today when I was at work doing stuff, it was on my phone, so it was like yeah.

Seth Whiting: Yeah. Okay. Yeah, and that's where I'm at. I'm sure like the phone experience with K Academy is probably pretty bad. It's just multiple

Jake Pacheco: choice basically a thing. Yeah. Yeah. So it's it works and it's good for practice.

I'll definitely say it's great for practice 'cause that's, it helped me a lot with the JavaScript fundamentals and stuff, but but I think

Seth Whiting: that to start, it

Jake Pacheco: really helped me going through the Code Academy course and it gave me the excitement of oh man, like I did the thing,

Seth Whiting: Like for the JavaScript stuff.

Jake Pacheco: Yeah. Exactly. That's what I'm talking about. Yeah. Yeah. But I will say Not tomorrow night, but Friday night me and Chelsea are planning on coding for quite a few hours, nice. We're gonna try to keep those wheels greased and

Seth Whiting: see your show, come on the

Jake Pacheco: journey with me.

Sweet. But yeah. Yeah, hopefully, fingers crossed. But yeah, I'll let you go. And as always, appreciate anyone who listens. Thank you. And thank you Seth. I appreciate your time.

Seth Whiting: And Thank you. Yeah, just thank the listeners. Keep swimming. Yeah.

Jake Pacheco: Keep typing. Yeah,

Seth Whiting: that sounds weird. Even more you're like un unfocused, like off weeks, don't get discouraged by those, it, it would be give yourself.

Grace, cut yourself some slack, yeah. And just keep keep at it. Next week is another week and, do just, resolve to keep with it. I would say. Yeah.

Jake Pacheco: Yeah. For me, I'm definitely running into that where it's like I get frustrated and then I get frustrated that I'm procrastinating.

I feel myself procrastinating. But it is never, the thought never crosses my mind to stop. I'm like, I'm not just gonna stop this. I want to continue and just, it's not that, like I said, that I'd be so disappointed in myself if I stopped, that definitely not gonna happen.

So yeah, just gonna keep going at it and I hope you all do the same and yeah. Yeah. As always, thanks. If you, if anyone needs help or wants to. Mention or have us talk about anything in spec, like specifically just yeah, e email us or leave us a comment on whatever this is on, if that's an option.

Yeah.

Seth Whiting: Yeah. Cool. All righty. All right. Thanks a lot. Talk to you next time. Thank

Jake Pacheco: you. Talk to you later.