Hasty Treat - Developing for Slow and Spotty Connections

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 web development treats coming in hot. Here is Wes, Barracuda, Bos, and Scott, El Toro Loco, Tolinski.

Welcome to Syntax in this Monday, hasty treat. We're gonna be talking all about developing for slow or spotty Internet connections. Because we all know that the web isn't always the high powered gigabit speeds that sometimes we get to develop on in our fancy offices.

And a lot of times, people are using with slower, worse Internet connection. So we're gonna be talking about some of this stuff, how we can combat this, and just some general ideas. My name is Scott Tolinski. I'm a full stack developer from Denver, Colorado. And with me JS always is Wes Bos.

Hey, everybody. Hey, Mike. Can you get a hey, everybody? Yeah. Yeah. Wait for that hey, everybody, Wes. Hey, everybody. I'm excited to talk about this because ever since the pandemic hit, we, went and bugged out our cottage. And we have several sources of Internet up here, and they were all awful.

Like, they're okay. I'm happy to have it, but there's a lot I've learned about developing for slow connections just from using the Internet on a slow connection for the last 2 months. There's sort of a lot that has made me think about this. So we're gonna go through some things that you as a developer should think about because especially, like, I see this as well as when people are developing locally. Everything loads instantly when it's local, so you don't even think about this. Exactly. Right? So many of these things we don't think about. Now this episode is sponsored by a company that's going to help you fix the things that you didn't think about when you didn't think about them and they broke. And I'm talking about LogRocket at logrocket.comforward/syntax.

You're gonna get 14 days of this service, which what it does is gives you a screen recording of what the user did to break your site. You get to see mouse movements. You get to see clicks. You get to see network requests and error logs and all of those things that you're used to having when you encounter a bug in your own local environment. But now you get to have them in your production environment with actual users using your site. It's a really amazing service and one of the best ways to really understand why these things are happening on your site. So thank you so much for LogRocket for sponsoring. Now let's get into it. Slow connections. And and it's Sanity. Wes, you're in a slow connection right now. In fact, the last few episodes, it's been really hard to talk because

Internet's been cutting in and out. Yeah. There's a couple different types of slow connections. There's slow upload speed, which generally isn't a huge issue unless you are trying to do a Zoom call or something with somebody or trying to upload a large file. There's slow download, which is probably the one that most people complain about. And this is not just like you have a slow download pipe, but it could be lots of people using the same connection. Your kids are watching a show. Your partner's on a Zoom call, things like that. It quickly gobbles it up. And it's easy for us developers who usually have very fast connections to forget about these types of things, especially, like I Node, Scott, you have what, gigabit connection at at your office right now? Oh, you bet I do. So that's, what, one 1,028 megabits per second, and I'm over here on 0.6

megabits up. I never get a thousand, though. I I usually get, like if I'm wired Ethernet, I'll get, like, 700. You know, CenturyLink? They're it. Yeah. Only 700.

And I had to call CenturyLink, and I was like, listen. I'm not getting the speeds I paid for or I'm paying for. I'm only getting 700. They're just like, okay.

They didn't do anything to fix it.

So that's great. But it's still better than what I'd get for Comcast from the same price. So, you know, there's only so much you can win. Lucky. There's also high latency,

which is when the time it takes for your Wes to go from one place to another. And even if you're sending the character r from me to Scott, there still will be a however many millisecond delay in between each of them, and latency can be introduced by any number of things.

So latency is 1 and then intermittent connection. So this is something that even if you live in a large city, you may run into because, like, maybe you're ducking into the subway really quickly. Maybe you are in between 2 buildings. Maybe you're in a building with a metal roof over top of it. There's all kinds of things that can cause your connection to go in and out, especially on mobile, and designing interfaces that account for all of these different types of connections is is pretty important. And I like, I said to this already, I don't think a lot of us think about it. And even I I tweeted it out, like, what are some things you need to think about for slow connections? And I got, like, 1 reply, and it just goes show that most of us aren't there. I I'm guilty of this as well. We're we're not thinking about what happens when this the Internet pipe, is not as fat as we think it is. Yeah. You've gotta have that pipe to get this stuff,

going really well here. You know, it's Sanity. I the other day, I was thinking about this because my Internet connection, what happened? It it went out. My Internet connection wasn't connected. And I was working locally, and my site was still loading. Actual site, like, the 1 on the Internet was still loading, not the local environment. And I was thinking, like, wait. Is my Internet out, or did I just write this site correctly so that it works when the Internet's out? And sure enough, it was just Sapper and the service worker. It just worked out. I was just like, It's really nice when you don't have to think about it in this stuff, and it just does it. But I hadn't thought about it, and that made me think made me feel really bad for not thinking about it because it was a really nice experience when the site still worked offline. Yeah. Absolutely. That's maybe that's the first one is install a service worker that will cache your site so that when

your user is is offline, they're still able to see it. So I think about things like maps or an address lookup if you're trying to go somewhere. Or I think another thing we don't think about is people who have limited data plans on their phone. Mhmm. Mhmm. If the person has run out of data and they've got 6 months till the that resets, then what do you do? And if somebody's trying to look up an address and then go to that place,

having that data cached offline and and still viewable even if they don't have data on their phone is key. Yeah. It's only, like, so helpful for LevelUp tutorials because, at the end of the day, we rely on video. You can't have that video served offline unless the user previously downloaded it. Yeah. So, like, there are some situations where it's just not a great solution for offline other than making the vital information available, right? I actually took the service worker off Wes

because, a, it's scary to launch with a service worker because Yes. You can get into this place where you goof something up, and that goof up is cache. And then the person has to load the page again and then look at the cached version, and then they have to reload it again. You could code something in there to hard refresh it and whatnot, but the user will still get it. And then I've seen plenty of people get into a situation where they can't unregister their service worker for whatever reason. I intentionally turned it off because they didn't wanna launch with it. And now that the launch is done, I'm probably gonna turn it back on just so, like, if someone wants to read a blog post. I don't have a service worker on my own course website just for the same reason Scott says, but it would be kinda cool. Like, I always wonder that. Like, what's the limit to caching stuff in the browser? Like, could I cache a couple videos

so that someone could watch them from the course platform but when they're on the subway? Yeah. I don't know. It's in it's interesting. That's why I make all my videos available for download for people who Yeah. Me too. Internet connections Node JS gonna be great. So do you wanna talk about this loading UI section of this? Yeah. Where there's a lot of things around loading UI. And if your data is taking longer than an x amount of time to load, then, of course, you're gonna wanna show some sort of loading UI. Now there's a lot of different ideas and opinions on loading UI and perceived speed of loading. I know skeleton screens, which is sort of just like a version of the actual layout, but they're typically, like, gray or dimmed out or not the actual content, but it's in the layout that the actual content in. Skeleton screens are super useful for getting that perceived loading time up. But in the same regard, if the loading time is faster than a certain threshold, then those are going to actually make the perceived loading time slower. What are your thoughts on skeleton screens versus a loading spinner versus, you know, just thinking or whatever, blank screens?

The skeleton screen is probably my favorite just from being on slow connections because Yeah. Otherwise, your face was just a white page. You don't know if it's broken or if if you need to refresh it to try again, at least for something like YouTube where it just shows the skeleton screen. And, also, like, when those finally do load in, then the whole page doesn't rejerk itself over and move content up and down, which is really frustrating.

So big fan of that. Also, it's good to not show those loaders or skeleton screens right away because, like, for a lot of connections, you're gonna just be showing them for half a second, and then that's frustrating for the user to see that. And like Scott said, it shows faster perceived. So that's what React Suspense, if it ever launches, is going to do. It's going to allow you to control how long to suspend a component before it then shows a loading component, and that's gonna be be pretty cool. Like, if you're dynamically loading a React component or or tree of components

via dynamic imports using React loadable or loadable components, you can always have that threshold as well to say, like, show this loading component while these ones are being pulled in from the network.

Next, we have just showing a UI when something is happening.

I've noticed that there's a lot of websites that don't show loading UI for things that they assume will always happen. So the the biggest one for me is when you're you're filling out a form, and the form will automatically show United States and all of the states, and I wait to switch it to Canada. And, generally, the way that I I get to Canada is I tab over to the country form, and I hit c three times because it goes Cambodia, something else, and then Canada. And every time you hit each one of those, it tries to find the version of states or provinces in that country, and a lot of those are loaded in on demand. What I've noticed is that there's a lot of websites that don't show any loading UI. So, like, I I click Canada. Is it doing something, or is it not? And I sort of sit there for a couple seconds waiting, and then sometimes it's broken because I hit c 3 times.

It fired off 3 XHR requests, and now they're coming back at different intervals, which and we'll talk about that next. But just showing some sort of UI, and what I found really frustrating is a lot of checkout fields just throw an entire spinner over top of the entire form and disable the entire thing, which is so frustrating because, like, while that's loading, I can fill out other fields if I want to and just sort of, like, disabling the entire thing really sucks. So that that was a really bad experience that I got a few times in the last couple weeks.

Yeah. That's interesting. I don't it's not something I've ever dealt with being here in the States, and that's, yeah. No. That's the thing JS, like, you never dealt with that switching country

bug ever because forms just default to the US, and you can just go ahead and select your state. But little frustrating things to the rest of the world Yeah. Sometimes go unnoticed.

Same thing with often, places will ask you for your state and then your country because that's the way that JS written on a piece of mail. But for for everyone outside of the states, they have to tab down to the country, change it, and then tap back up to change their province or state.

That's annoying.

We have, account for XHR failures. So one frustrating thing with fetch is that we haven't, for longest time, had a way to cancel fetch Wes. The we now have a board controller, which is great, but a lot of devs, myself included, don't account for XHR requests being Vercel.

Because, like like I said, if you hit the c key, it starts fetching the provinces for Colombia.

Mhmm. And then I hit it again. It starts fetching. Now the 2nd request is going, and you should kill that first request. And that's almost never an issue for developers working on the website because it's either local or they're on a fax connection. The other thing is, sometimes your request will break. You fire off a Wes, and then your connection Node, and you think it's still going. But if you open up dev tools, you'll see that that thing had then failed.

So it's important, and this is why state machines are so good because you should never get into a situation where it's just like you're assuming that it will either come back with an error.

You're assuming it will come back successfully.

But if you in that catch of your XHR Wes or of your await, then you should catch that and then set the state to there was an error or retry it or something like that. So it's Mhmm. Important to think about those worst case situations. Even though you think like this will probably never happen, it it does happen. Yeah. And then finally, the last 1 I have here, for today, we're gonna split this into 2 different hasties because it's getting a little tasty. It's getting a little tasty.

They're still working. So if you are doing, like, a large upload, this is another thing is if if I wanna upload a 6 or 7 meg image, it might take 15 minutes for me.

And you don't know if it's stuck and if it's broken or if it's just still going. And sometimes these loader bars are so small that you have no idea. Or, like, in a lot of cases, Twitter, Instagram, these upload bars, they're so fake. Like, they go to 90%.

And then if it's not uploaded by that time, then it actually just waits there. So it doesn't actually give you any sort of feedback as to whether the file is still uploading. So just giving the user some sort of if it's just a percentage that it's uploaded or some sort of like, hey. We're still uploading it. Don't worry. Just leave me open or or whatever. Come back in 10 minutes, and it should be uploaded. So some sort of time out that after 3 or 4 minutes, you can give the the user some sort of feedback.

Yeah. Because that is this is the absolute worst. I was just waiting for my time machine back up to finish, and it was like, oh, the the progress bar is completely full. But, you know, it still says it's backing up, and the gigabytes is still increasing. So why why are you not letting me know, you know, what the actual percentage or if this thing is actually doing something I need to be concerned about or whatever? I had to go and run a terminal command to see what Yeah. Time machine was even doing. I and Node to to see that it was actually moving the files. I was like, okay.

Why don't you let me know about that? Right? It's true. Like, I should be able to have access to that granular information like Backblaze Wes I use that. It tells me literally how many files are left. And even if it's, like, 400,000 files because I npm installed something, it tells me exactly how many files are left. And that's such good information because I can just look at it for 3 seconds and see that number change, and then I go, oh, okay. It's just being slow. Yeah.

So let's wrap it up here. In the next, Casey, we'll do talking about images, TypeScript, and CSS, video, how to test for slow connections, what to do with connections that go in and out, like, what do you show on your app. There's some event listeners you can add there, and then a couple little tricks for CSS and font loading as well. Cool. So I'm excited for that one. That's gonna be another tasty hasty.

Yeah. Alright. That's it for today. Thanks so much for tuning in, and we'll catch you on

Wednesday, but also Monday to finish this one up. And then also Wednesday after that and then also Monday after that. And then also Everyone Monday, Wednesday. Wednesday. You there. Yeah. Peace.

Peace. Head on over to syntax.fm for a full archive of all of our shows, and don't