Explained - Buzz Words and Concepts

Boss and Scott

CSD. Welcome to Syntax on this Monday.

Hey, c treat. It. We are going to be talking about JavaScript buzzwords again.

Things that are really simple at the surface, but people can make them more difficult by Giving them scary sounding names or really talking about these things in a way that is a little bit more, I don't know, complex than the concepts actually are. My name is Scott Talinsky. I'm a developer from Denver, Colorado. And with me as always is Wes Hey, everybody. What's up, Wes?

Not too much. Ready to rock to talk about some buzzwords, things that are hard to understand. Last Episode went over well, so we're back with a couple more. We're back with a couple more. Well, let's talk about 2 of our sponsors today before we get started, AppRite and Sanity.

AppRite is the self hosted back end as a service platform that provides developers with all of the core APIs required to build an application.

It's a really neat project, and you get really cool admin tools as well. You get collaborative tools. You get Lightweight SDKs that make development friendly.

It's, it's cross platform, so you can use it basically anywhere you Could really want I mean, this thing is just truly spitting out an API for you. So if you want an API, you could just host it up on AppRight.

It's highly secure, so you don't have to worry about security, which is always a pain when you're writing your own API.

You get access to store your information in a database.

You could authenticate

and manage your users so you get roles and sign in methods. You get storage for things like storing files. Yeah. They got everything. They got everything. This is a new sponsor of ours. Right? They've got they've got it all. We've had a lot of people ask about App. Right? And then they just They rolled up in the inbox. Say, hey. We want a sponsor. They got, what, databases,

authentication, storage, real time? Good on the list. Yeah. Databases, often users, storage, functions, geo and location, console, privacy, security, and a whole lot more. So check it out. They have a really great little interface. The whole Whole thing is is really super nice. And on top of all that, Wes, it's open source, and it's free to self host. So if you wanna self host this thing, you can self host this thing, or you can host it with them.

They're a developer first company. So if you wanna self host this it. You don't have to be locked into anywhere. You can throw it up on your own server, maybe a Linode server perhaps. So head on over to it. Appwright atappwrite.io.

Thank you so much to AppRight for sponsoring.

One day, we'll make Entire application only sponsors.

The only sponsor application. That'd that'd be a lot of fun, actually, because our sponsors are so wonderful.

Yeah.

That'd be great. Another sponsor of ours is Sanity. Sanity is the content platform for your application. You're gonna wanna check it out. Send it's really cool because you just you sign up and you can tell they're a developer focused company because the first thing that they do is they tell you the NPM install to Scaffold out all of the code. It's really great. You create all your content types, and you can do relations between the 2. But they also have a An amazing editing UI called Sanity Studio that is totally you can totally customize it. You can write your own components for it. They have like You can do like revert changes. It's just a really high end, very powerful editing UI. You got to check it out. Sanity. Iosyntax.

Thanks CS. To Sanity for sponsoring. 66666

sick buzzwords.

Let's get on into it. We got, I don't know, 5, 6 different buzzwords here, and Scott and I are going to attempt To explain them, the first one we have here is called a this is the word I always say wrong, schema.

How do you say it?

You know what? I don't I it's I think you've ruined me. I never had any issues saying this word until we started this podcast, Yes. And now I like it. Like, I have a little thing Schema. Whispering in my ear. Schema. I say schema like I'm going schema ing, because I don't wanna deal, Yeah. I don't wanna deal with the whole schema thing. Schema. I say schema schema. Yeah. Like Matt Skiba from Alkaline Trio. Well, there you go. Yeah. So a schema is not something that is

built into Like JavaScript or or any language per se, but a schema is generally a way to define it. What your data looks like. And most popular, you have a schema in well, you you have a schema in a database, but you could also have Sanity has a schema, and it's how you define what the data types are and, what the fields are and what each type of field is. So generally, it's really nice to define data structure and inputs and outputs and often Things like authentication and role permissions.

Those things are generally defined in Some sort. I love it when schemas are done in JavaScript or TypeScript.

They are often done in JSON or any of these other languages that are not computed, but just kind of definite. What are the what are the other

schema definition languages? YAML? YAML. That's the one. Yeah. Yeah. I I like it when they're in JavaScript and most recently it's so funny, Wes. We didn't we did an episode, and somebody mentioned Zod. And then we saw that Zod on air had a bunch of downloads, like, a ton of downloads, and we're like, what is Zod? And when we were looking at tRPC, And then I've gone from what is zod to I'm using zod in production in less than a month here. And so So I have a lot of thoughts there, but Zot is is is one of these things that exist to do that joy. There's, if you ever used Mongoose, it. Typically, you develop a a schema in Mongoose. Anytime you're kind of working with your data to define that shape, perhaps you wanna validate it, perhaps you wanna parse it, Perhaps you wanna get those types spit out for that thing. If you have data, you typically have a shape for it, you know, and it helps to have a schema in many different ways. But a schema, again, is just The shape

of that data, what that data looks like, and what those types are essentially. Oh, there there's also a whole thing called the c s d l, a schema definition language.

And one of the big ones that we forgot is GraphQL is Is this schema definition, especially if you are using something like Apollo or whatever, you define your types and what each of the types are in,

In the GraphQL schema definition. Yeah. You use the word schema in GraphQL 20 fourseven.

Yeah. It's, it's one of those terms where it just kinda is everywhere and it means a little bit it's kinda like the the API. You know? Like API means a whole lot of different things in a whole lot of different areas. Yeah. Totally.

Next step is promises.

Promises is a feature of JavaScript, But it's also a concept here. And, typically, the the whole thing about promises is that when you're writing your code And your code can sometimes go off and do something.

And a promise is Like the word is kind of defined, it's a promise that it will do something.

I promise you, I'm going to go to the store, and I'm either going to bring back bread Oh, I'm going to bring back, an apology that says they were all out of bread.

So that's what a a promise is. A promise is something that you're You're promising that this is going to resolve with something. So here comes asyncawait or .then or any other way to resolve a promise. That Essentially, I've gone to the store.

I've gotten my bread, and I've come back. And here I have this bread for you. But while I'm gone at the store, While I'm gone away, you can go do whatever you want.

I'll just be at the store. So you can go do whatever you want in the house. Us. I'll be at the store. I'll be back. Okay? I'm promising to return. I promise. Yeah. I promise. I promise I'll come back with bread, or I might come back and say, oh, they are actually out. Yep. That's a good one.

So sort of along with that, we have these 4 words that get thrown around, asynchronous, synchronous, parallel, And concurrent.

And the reason why we have promises in JavaScript is most things in JavaScript are asynchronous, Meaning that you say go get bread.

But that function does not hold up it.

The rest of JavaScript from running. Like Scott said, I you could go do what you want. I'm going to go do something else. And it. When you do something asynchronously, you can just fire it off and keep doing something else, while that Is working while Scott's going to the store to get bread. So that's what asynchronous means.

And then the opposite of asynchronous is synchronous, meaning that you do one thing after another. And there are some things in JavaScript that are synchronous, like, the prompt Confirm and alert boxes are synchronous. Meaning that if you throw up an alert box, you're literally not able to go to the next line of code underneath that until somebody dismisses,

that type of thing. That's like somebody saying, I need to know this answer really quickly before I go to get bread. I need to know the answer right now. You cannot do anything until you tell me this answer. That's the other one.

I was thinking about how we went to Ikea this weekend, and both Costco and IKEA sell hot dogs. Yes. And you go to Costco, you go to Kia, you gotta get a hot dog. And it used to be so brutal us. Because you would have to stand there, wait in line behind 14 other people, and and just wait. But now what they have is they have self order checkouts where literally everybody can go and do their order at their own time.

And then when your hotdog is ready, they will they'll call your name. That's kind of the callback portion of that. And I was just thinking about, like, I love asynchronous work.

Same thing with an an email. Email is asynchronous. You send off an email.

Hey. Could you get me this PDF? And then you go about your the rest of your day.

And then that that PDF will come back to you at some point in another email. That is working asynchronously.

Whereas working synchronously would be You literally walk over to the person that is, needs to generate the PDF. You you ask them, hey, can I have this PDF? It. And then you just stand there frozen

until they give it to you, and then you you keep going on. And, obviously, there's a lot of wasted time where you could be doing other things at that time. Man, this is This is all knocked a lot. This this idea that you're just talking about is unlocked. Like, a big realization is that, like, so many companies have recently leveled up their experiences it. By offering a promise to do something. Oh, it's a callback. It's a call. I promised Starbucks today that I would go pick up my coffee after I ordered it on my phone, and then Starbucks cannot worry about the line. They could just do it whenever they can, and then I just show up and grab my coffee. That's so great. It's true. And you think about that, that the other people on the other end of it are working asynchronously as well. Right? Right. Yeah. They don't have to stand there

and wait for you to figure out,

do I want the Polish hotdog, or do I want the all beef hotdog? You know? Do I want the mocha choco Latte, or do I want the kichi k g I I I latte?

There's 2 concepts that go along with asynchronous and synchronous, Sorry, there's 2 concepts that go along with asynchronous, which is parallel and concurrent.

People often Say that, asynchronous JavaScript is done concurrently. It's technically not because JavaScript is single threaded So it will just do little bits.

It'll be like, oh, I'm I'm making a hotdog. I'm pouring.

I'm pouring the the I'm pouring a coffee. I'm getting a bag. You know, it just does a whole bunch of different little pieces of work.

So that is doing things Concurrently, parallel would be doing them literally at the exact same time.

And JavaScript doesn't do things in parallel unless CS. You use a web worker.

And a web worker would be like, I'm gonna get the hot dog.

My coworker is gonna get the coffee.

We're gonna do these at the exact same time, and when both of us are done, then we have resolved our promise to give you your lunch.

This is wonderful.

Okay. Let's move on from the async and promise based stuff, and let's talk about, here's one. The DOM versus the shadow DOM versus page HTML.

So these kind of concepts can get conflated.

So with the DOM, the DOM is the browser's interpretation of your HTML, and it's put into essentially a JavaScript object.

That's why it's called the document object model. Right? So essentially, you have your HTML. It's parsed by JavaScript and put into a big old object that includes all the methods and everything, all the information about your HTML.

The Shadow DOM itself is essentially a DOM that is hidden behind a component.

And you might think that it's always components that you write that that becomes the Shadow DOM, but, really, the browsers had Shadow DOM components for a long time. We've just never been given access to write them ourselves.

For instance, You have things like the select list or you have a the range slider. Those are all made up of smaller elements, but when you see them in HTML, You see the parent element exclusively.

So the shadow DOM is called the shadow DOM because it's swept under that rug of a component that is not essentially it's not like a a React component, but it's a component that the browser understands as being a self contained thing. And this can encapsulate CSS.

It can encapsulate, state. It can encapsulate a lot of things, but it's essential Yeah. Yeah. It's essentially a self contained thing. Oh, the page HTML, I was going to say to contrast all of that is just HTML. It's the HTML structure of your page. Nothing more, nothing less. It's what you're looking at when you author HTML. Yeah. It's actually funny is Whoever initially made a Firebug

or the elements panel, the elements panel shows you the Dom.

And the DOM is actually just an object like Scott said, but somebody figured, let's just put angle brackets around it so it looks like HTML.

That sort of clicks for everybody because they are. I wrote the HTML. It's get parsed into this. And, the page HTML is what gets loaded, But the dom is what gets updated over and over again. Things are loaded, things change, you click buttons and whatnot.

And finally, the the Shadow DOM. One good example I really like is the HTML 5 video player or input type of range or anything like that. You know, there's buttons, there's controls, there's How much you've you've scrubbed so far? How much is loaded? All of that stuff is technically just it's literally h t l and CSS under the hood. CS. It's just been encapsulated into its own component, like Scott said. And you cannot usually, you cannot access those things unless they surface an API for the Shadow DOM via JavaScript or CSS.

Totally. Next one we have here is the difference between methods and functions.

Methods are functions, and technically, all functions are Methods as well. I think so in most cases. And I'll tell you what the difference is that methods live inside of an object. So console dot log, The dot log is a method that lives inside of the console.

Alert is just a function. It it doesn't live inside of anything. However, it it kinda technically also is a method because it's window to window. Yeah. Yeah.

That's why I said I think everything Kinda is. Maybe not in Node world and Web Worker world and whatnot. But the difference between the 2 is generally Not much, except methods are often bound to the object that they live inside or the class that they live inside. So Video play. Play is a method, and it's bound to a specific bound means that it's sort of tied to A specific video. So when you call that dot play method, it knows which video to actually play or pause instead of just You having to pass it a specific instance.

That's really the only difference there. Yeah. To to go back to the food, it's the difference between sandwich dot make and make sandwich as a its own stand alone

thing. Yeah. And they could be like, you can write You can still write functions that do stuff to a specific thing.

They either just have to be explicitly bound with call bind apply, Or you have to pass in an instance of a sandwich so that it knows which ones which one to eat. Then that's where we get into functional programming

Territory or op object based object oriented programming. Right.

Next one is props.

Props is a word Who coined props? That's why I want to know. Props didn't give them props.

Oh, yes. Okay. Me too.

I I would think that whoever figured it out is just thinking properties

of an object. Right? Sure. Yeah. Props is very clearly short for the word properties.

And you have essentially a component based system. A prop is any data that is passed from 1 component to another.

So props, which I don't remember really thinking about props until React. I don't remember thinking about Props necessarily in Angular. I remember, like, scope,

but I don't necessarily remember thinking of props as the word props. No. There was that. React. What was the a word that people used, in Angular world where a directive.

Oh, a directive. Yeah. Oh, yeah. Because component the component based workflow wasn't Something that people used immediately in Angular, which, people forget that, like, a long time people weren't writing components or directives in Angular, until Some, you know, thought leaders came out with some talk saying, hey. Everybody should be using directives a whole lot more because they're pretty powerful.

So either way, You have props, which is essentially a way to pass data from 1 component to another.

It's usually represented in an HTML like way of having This is equal to maybe an object full of data or maybe a single value, and and that's largely can continued through all modern frameworks, whether it's Vue, Svelte, Solid, React. Any of these frameworks are all calling it props. Although, what's interesting enough, Wes, is that in the latest version of SvelteKit, They refer to the data that's passed from server to component as just data, and they don't necessarily refer to it as props. It. Interesting. On that to be interesting.

Props props has just kinda become the way of calling these things so you don't take a step back and say, Okay. Props is just short for properties.

Okay. Like, there's there's nothing really that explicit about props that makes it. It's just kind of Come the thing that we all call it because of React, probably.

Yeah. Yeah. I think so. Last 1 we have here is this This is something that I asked on Twitter, like, what are things that you never understood for the longest time? And if someone said, HTTP requests are stateless, What does that what does that even mean? And what that means is that when you send a request to a server, you go to a URL And then you visit a 2nd time or you send that request from another computer, there is no state maintained Between those 2 single requests. Right? And every single time that you send off a request, It's as if the server has no idea who you are. You can get around those things by sending along additional info with your requests, like Sessions or cookies or tokens, anything like that. That is sort of like, I am making this request.

Here's some information about me, and the server can then look that data up.

But every single time you make a request, it's not like, oh, I remember who you are.

That has to be implemented on the server. Nice.

Yes. I don't have anything to add there. That was great. Beautiful.

Alright. Well, that is our words, Buzzwords and concepts explained. Hopefully, you enjoyed that, and, we will catch you on Wednesday.

Peace. Peace.

It. Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player Or drop a review if you like this show.