Hasty Treat - JavaScript Event Buzzwords — Sync, Concurrent, Defer, Blocking, Workers

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott, El Toroloco, Tolinski.

CSF.

Welcome to syntax in this Monday.

Monday, Monday, Monday, Monday, Monday, hasty t treat. We're gonna be talking about some JavaScript buzzwords that can send new developers, old developers, intermediate developers into a tizzy because they can just Be hard to understand.

Hey. I'm excited to get into some of these.

I don't necessarily know if they're buzzwords, but they're words that are sometimes hard to understand what they mean in JavaScript.

Yeah. Jargon y jargon.

Yeah.

So this episode is sponsored by 2 amazing companies today. I'm talking about FreshBooks and Sentry.

Now Sentry is the perfect place to see all of your errors and exceptions happen because they give them to you in a giant table that is really great to be able to be filtered or saved or marked as resolved or marked as ignored or do any of those things that you would possibly want to do whenever When an error comes into your site, you can also assign them to GitHub issues directly. Hey. Is there 1 person in particular who goofed this thing up? Hey. You can go ping them and assign it to them. If you say, hey, you, you did this. And you know how I know you did this? Well, it was introduced in this specific PR that you made. But, of course, you're gonna wanna do that in a nonblamey or judgmental way. You're gonna wanna be very nice about it. And you could do all of that over at century.io.

Use the coupon code tasty treat, all lowercase, and all one word. If you want to handle your errors and exceptions, track and make sure that your users are getting the best full version of your site like a pro. So thank you so much for Century for sponsoring. We're also sponsored by FreshBooks, the cloud accounting solution. I'm gonna Focusing on one of their features today, which is it's entirely a cloud based service, meaning that if your computer crashes, you lose all your files, you don't have Backups, we know how you are. You're not gonna lose any of this vitally important information because that would be a bad, bad day if you had to do your taxes Or you had to bill a client, and the information about all of that stuff was gone. So FreshBooks saves it all in the cloud. You can access it on the website And on the app, whatever it is that you need, don't have to sweat about it. Check it out. FreshBooks .comforward/ syntax for a 30 day, no credit card required trial.

Thank you, FreshBooks, for sponsoring.

Sick.

Alright. Let's get into doing some talking about Some buzzwords here. So we've got a whole bunch of them. Synchronous, asynchronous, multithreaded, concurrent and parallel, consecutive and waterfall, callback blocking, Async, defer, and lazy. So these are all words in JavaScript, and they all kind of sort of are in the same space of When do things happen and understanding what they mean and the implications of them is what we're gonna try to break down and explain in this episode. So the first one is, I think, we have synchronous and asynchronous, and these are words that are used both in programming, which Can be a little bit confusing, but, also, if you I like to refer to them in real life. So if you are doing something, synchronously in your work, It doesn't mean do them at the same time, which is really weird because if you think about synchronized swimming, those people are swimming at the same time, And I don't understand why it is. I've talked about this before. I even tweeted it out earlier, and nobody seems to know why it's not called asynchronized swimming.

But the idea with something being synchronous is that they are explicitly done one after another, and you cannot do the next thing until the first one is finished.

And the idea with asynchronous work is that You can start something. It will go off and do it and then come back to you when it is. So this is not to be confused with awaiting because awaiting kind of makes asynchronous Functions into synchronous looking, but, asynchronous means you you do something, you go off, and you can do multiple things at the same time.

So if you were, listening to music and preparing an email and watching a YouTube video, that's asynchronous work.

Whereas if you were to say, okay. I'm gonna sit down and write this email. Done. Now I'm gonna sit down and listen to this music. Done. Now I'm gonna go ahead and Do another thing. That would be synchronous work. So most things in the browser are asynchronous.

There are a couple older APIs, and we'll talk about what blocking means in just a second. But in general, most things in JavaScript are asynchronous.

However, you can Talk about, like, flow control and asynchronous functions. You can make them go one after another because that is often needed with, the await keyword, or a callback. We'll talk about that in just a second. Yeah.

So the next one is going to be a multi threads or just even the concept of threads.

And, I might need you to to give me a a thumbs up or a thumbs down on this one, but my understanding of threads is that it has s to do with how the CPU processes information, like how many, let's say, active Concurrent

threads of CPU processing you have. Does that ring true, do you think? Yeah. Yeah. That that makes sense. There's there's a A lot of languages that are multithreaded, meaning that you can spin off a parallel process Where something will work on something while you're doing another thing. So let's say you are converting a video From MP 4 to another format.

If you wanted to do that in a lot of programming languages, you would have to spin off another thread or spin up another thread, Put that work in that thread so that you don't block any other work, me maybe letting the users click on things and and whatnot in the main thread. So JavaScript for the longest time has been single threaded. There's a main thread in JavaScript. Well, also, your browser itself used to be single threaded for Every tab you had open. Yeah. That was a a thing for a long time where every single tab you had run on the same day. Was it was it Chrome in the first one that was that, like, Chrome's big selling feature? I don't remember when that came about, but I don't even remember that. No. I remember Chrome had some big marketing push about why Chrome was so much Stern, I I don't know if that's honestly why, but at some point here, modern browsers became a a one process or 1 thread per per site, f. Per instance, per tab rather than for the whole browser itself.

And that's why when you open up, like, system processes or whatever on Mac, you can see Chrome process 1, 2, 3, whatever, all the different ones that exist there. Yeah. And that that's great. So one

tab can't take all of your Processes from another tab. And JavaScript is still single threaded, but there is this idea of web workers, whereas things can Work in the background, and you can send off heavy duty work or or any type of work to a web worker, and it will do it for you and then come back when it's done. And that is how you access multithreads in

JavaScript land. Yep. And to clarify that you would probably only need that, like, If you're doing a lot of processing and you you want the page to remain responsive, right, because if you're basically if you're giving the CPU a lot of work to do And it's on the 1 thread, then that thread is going to get clocked up, essentially. It's it's going to not be able to execute as fast or as Responsive as it would if you were to fire that off into another process,

and then you can free up the current thread that you're on. Maybe we should move this one up a little bit, which is The next term, which is called blocking, you'll hear that word in JavaScript a lot. And blocking means that you're literally stopping other things on the page from running, which can do something as simple as stop some processing or make a UI unresponsive.

And in in general, most things in JavaScript are non blocking. That's actually why Ryan Dahl picked JavaScript for being a new server side language because it's very hard to actually write code where you can do blocking terms. So What does that mean? Well, there there's kinda 2 things in JavaScript when that describe when something is blocking. First 1 is called render blocking, Meaning that if you are loading a page and you have a script tag in the head of that file, what will actually happen is that The browser will download that file, and it will stop the actual page from the like, the content on the page from being downloaded and being parsed and being shown to the actual user. So that is referred to as blocking, and that's often why you'll see people put a script tag Right before the closing body tag, there are some other benefits to that. We'll talk about that with async and defer, but that is like, the first one is just render blocking. And then there can also be other things like, in Node. Js, there is, like, a bunch of methods that You can what is f s dot write async? What is it? Mhmm. Write file async. Yeah. Yeah. Write file async. So if you wanna save a file to JavaScript, they have f s dot write file, but then they have f s dot write file as sync. And that will literally pause All everything in the process that is running, write the file, and then when it's done, it will continue going on. And people use that write file sync because they don't like That blocks the rest of the thing from running, and that could potentially really slow down your server because somebody could be Uploading a massive file, and you could be locking up the server for incoming requests and and whatnot.

So that's another example of what blocking means in JavaScript. Word. Alright. Well, the next one is going to be concurrent verse Parallel. And you know what? I found a really good West Boss style metaphor for this one where they were saying you can imagine people waiting in line for a sandwich. Okay. We'll do the sandwich thing. Right? Because I know West West likes Oh, love a good sandwich metaphor. Hit me with this one. Well, okay. So you could think of it like this. You got a sandwich shop, And a concurrent, concurrency is when you have 2 lines of people waiting for one Entrance at the sandwich shop. You know, 1 goes, then the next goes, 1 goes, then the next goes, 1 goes, then the next goes, like a zipper merge. Right? Where written parallel, you have 2 lines for 2 registers at the sandwich shop. Each one is in its own line rather than You you having to go back and forth like that. And the reason being, again, this kind of even goes into the threads conversation because if you have a machine that can't do, multiple threads, right, then you have to do 1 then the other then the 1 then the other 1 then the other to have some sort of, You know, parallelism, where within parallel, if you have multiple threads, you can execute those at the same time. That that's an awesome

explanation of it because JavaScript is concurrent, meaning that it it when it starts and stops tasks, Meaning that you're adding an event listener. You're you're drawing something to Canvas or whatever. The actual starting and stopping of that is what is done concurrently.

However, the actual processing, the web API, writing to A Canvas element or handling a click event, those things can happen at the same time. So in Scott's example, if something was Concurrent.

Even though the person at the register is, like, taking your order and then taking the next person's order, they could be being worked on at the same time. But then when the sandwiches are done and the person at the register has to give you the sandwich, they can't give 2 sandwiches to 2 people at the same time. They need to give you what their sandwich and then go back and get the next one and then give it to you. That doesn't really matter In terms of, like, you writing an app, you probably don't necessarily need to know that, but that's, like, one of those things where if you If you say Java oh, I'm running these things in parallel with, like, Promise dot all, somebody will bark at you and be like, JavaScript's not parallel. It's concurrent, meaning that it will fire off request 1, fire off request 2. They will be being fetched at the same time, but then when they come back, it will handle them in the order that they are come back, not at the exact same time. So That's really the minor little different maybe, like, interview questions, something like that. Well, shout out to, Joe Armstrong who made that Little, stick figure diagram in 2013,

so shout out shout out to you, Joe. That's that's awesome. Love it.

Next one is just consecutive or waterfall, and that is one after another.

And consecutive work Can be asynchronous or synchronous, but they are both if you think of the logic in which one thing happens and then the next thing happens and the next thing happens, Most likely, you're doing that with asynchronous functions, but you're sticking the await keyword in front of them so you can do one after another.

Mhmm.

Alright. Next 1 is callback, which is a callback which you primarily hear about in JavaScript as a callback function. And a callback is basically, You could think of this pattern as, hey. I'm gonna do all this stuff, and then whenever all this stuff is done, I'm going to fire off a function.

And so you'll frequently see that as a parameter in a function, and this is a way to get around Trying to use a sync, await, or promises, and this is primarily the way that everybody waited for data before those things were either in the browser or existed as Internal libraries, and you now see callback functions while they still do exist quite frequently.

You primarily see them in, like, older programming examples for fetching data or something like that. Now you'll most likely see the same thing being used for async await, but you also see callback functions in array methods still To do maybe you're, like, looping over something to do something in a dot map. So you can definitely still see callbacks, but a callback is basically a function that executes after the other stuff in the function has been run. They're also still very popular in, like, streaming examples. A good example is the Twitter API uses, like, a WebSocket streaming.

Like, you you don't say give me all the tweets with Justin Bieber, and then when they come back, you say, alright. When you got a tweet, fire it at me. K? So whenever a tweet with Justin Bieber in it pops up, it will run the callback with a payload of data about that specific tweet. Same thing with, like, like, a buffer. If you're processing a very large file every single time that it has a chunk of data, it will it will throw that in a callback. So Callbacks, they're not deprecated, just not nearly as popular. And in terms of, like, flow control, they're very Much not used anymore, which is great. They used to be the primary means. Yeah. It's called callback hell. What is it? Callback hell.com? Something like that. That explains The problem because you would have to nest a callback in another callback and then in another callback. And then if you wanted to run, Like, 3 levels deep if you wanted to run 3 functions at once. Like, we didn't have the idea of promises, so you had to use, like, A third party promise library like Bluebird or something like that. And Yeah. I think there's Q. Was that one of them? Bluebird Q? I don't know. Yeah. I used A sync JS, which was really nice because you could say, like, run at most 6. Mhmm. So I had an example or run at most 10 every 2 minutes if you had, like, an API. I still use those. They've converted the entire library to promise based, and it's really nice because You can give it a list of, like, 500 items and say, just run 10 at the same time. Mhmm. And then as soon as one's done,

It's like, oh, I have 9. Let me pick another one off. You know? It's not just doing 10 and then the next 10. It's just saying, alright, at the at at all times, I'm gonna be running 10 of them, And that's a really nice library. It's called Async JS. Interesting. Yeah. I you know what? I I used Bluebird back in the day because some tutorial I used used it, and then that's the that's the one I got used to. And then Yeah. And then once once we got promises in actual JavaScript, I didn't touch them ever again. And then once we got a single wait, I almost Never touch promises now anymore. So you know what? It's funny because I always felt like promises were so similar to callbacks in the same sort of way, where, like, It's just like a slightly different version of a callback where asyncawait feels a little bit more of a a shift. Yeah. Like, the you're just taking the callback from your thing and putting it

Into Like, a a chained method. Yeah. You could you could chain them and whatnot. It was but it wasn't that much better, especially if you needed to get the data out of a Chained, you'd have to do a variable up top. I think await is just so much nicer. Yep. Totally. And for someone's gonna, like, say, prom I think await is based on promises. We know that. We have, like, 500 shows here. We know that.

Yeah. I I think anytime you're you're getting ready to tweet us anything, just assume that we know it. Okay. Just assume it because yeah. We we know everything. Right?

Close.

I'm not being facetious.

Okay. Next 1 is going to be the script tag async, which means that if you were to have a script tag in your HTML to load up some scripts, There's options there whether how you're loading these scripts.

And this involves, like, how the browser itself parses and loads that script. Because you if you just have a script tag And you tell it to load up a JavaScript file, it's gonna load up that script at that very moment.

But if you tell it to defer, It's going to wait until the entire page is loaded and running before going, and this can be ideal for, like, s. Script said don't need to be executed immediately.

You could think of this as like, oh, I have maybe I have like a that's something that fires when I click a button.

You know, I don't want the script loading to get in the way of the rest of the page loading. Yeah. You don't want it to block. You don't want it to block. You you want everything to load, Then you want your scripts to be loaded, and then, that way, the user can interact with them on their own own time, essentially.

And there's also an async, Which allows you to also not block, but it what's the difference between async and defer? I always need to, like, Google. There's, like, really good diagrams, anytime I need this stuff. Yeah. I always have to

I always have to go get it myself as well. Async will execute the script once it has, finish fetching.

The the important thing here is DOM content loaded. Meaning that if you got if you have a button on your page, Sometimes you need or a lot of times you need to wait for that button to be on the page before you go ahead and attach event listeners to it. When you pop the async Tag on or sorry, the async attribute on a script tag, it will just run it whenever it is done downloading.

Whereas defer Mhmm. Will Go ahead and download it, but it will wait until everything all the HTML is loaded in on the page of the DOM has been built before it actually runs. So At least in my case, most cases, I use defer, or I just stick the script tag near the closing body tag so you don't have to worry about that. Especially in my tutorials, I don't wanna have to wrap the entire application in DOM content loaded event. Mhmm. You can just wait

Explicitly for those things to load on the page. Yep. Yeah. And and you should also know, I mean, even in relation to that. So, like, what you were saying where you put the script towards the bottom of your page, that's, like, typically where they tell you to put things like Google Analytics. Right? Because they don't want you to To have Google Analytics to block the rest of your page loading. And so when you have script tags in the head or the header and if they're not Deferred.

Those will block, so you you do have to be careful with the order in which things are presented in the DOM because that's the order in which they'll attempt To be loaded for the most part if you're not using the tags.

I'm curious if Google Analytics embed Has a sync and defer on it. I'm gonna go into my Google Analytics right here.

Alright. So Google Analytics now tells you, copy and paste the code Into the head document, but it has an async attribute on the script tag, meaning that It will download it as it wants it, but it's not going to block anything on the page. And, also, they are not explicitly waiting or any DOM content loaded. And and the I think the way that they get around that is they just use a regular old array, window dot data layer.

If you push data into that array before the analytics has been loaded, Then it's simply just an array with data in. And I'm assuming in the Google Analytics code, they pick it up from there, and then they replace The push method with their internal ones, and they say, alright. Well, there was a couple items in here before we got going, which is pretty cool.

Alright. The last 1 on our list is lazy, which basically just means load it later. You know, you could think of this as, Like the lazy tag on images now or perhaps, like, you have a lazy load component in your front end framework that allows you to wrap things and Perhaps load it at another time. This is often used for stuff that very well may be heavy or even just is not important, and you want to load it later.

Say, hey, man.

You know this, like, tweets component you have that goes off and hits Twitter's API? Well, maybe, we don't need to load that on page load, and we can Wait a little bit till the user gets kinda close to it and then fire off an event to load it. And this is something that is again, it's very popular to do, especially for images Or heavier components, things that you just absolutely don't need. Lazy loading images now is baked into the browser, so, You know, this is definitely a concept that you'll you'll hear very often calling lazy loading is really just to prevent heavy things from being loaded

When the user does not need them. Sometimes, this is why I don't like when people, like, screenshot a, a website uses Twenty megs on their home page because often like, Apple is a really good example of this. Their sites are super heavy. Like, I just loaded apple.com, and it loaded 8 megs, but it's fast as hell. How do they do that? Well, what they do is they load at very minimum possible On page load to get to DOM content loaded, and then the lazy load in stuff that's beyond the fold or stuff that, like, JavaScript for clicking the buy button or whatever needs to happen a little bit later, and that's great because sometimes you do need Very rich media or very rich JavaScript, but you don't have to block the entire website in order to load it. Yeah. So we're not performance specialists, but this is kinda just, like, general ideas you can you can use when building a website when you're You wanna build something that's very, very media heavy or very JavaScript heavy, but you don't wanna, like, have the user sit there or throw up a loader or something like that. Generally, that's kinda how you can approach these things. Word. Well, these are some of the JavaScript jargon that you hear,

when you're dealing with the order in which or how things load.

And what would an episode like This b without a good sandwich metaphor, so I'm glad we got one of those in there as well.

Appreciate you bringing the sandwich to the table, Scott. I felt like, it was gonna get brought no matter what, so, you know, maybe maybe I should bring it this time. So thank you. Thank you for, Joe For making that that image for us. Alright. That's it. Thanks for tuning in. Catch you on Wednesday.

Peace. Peace.

Head on over Choose 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.