Join the 30-DAY CHALLENGE: "You Don't Know JS Yet"

Alex Russell works for Google on the Chrome team and is the lead of Project Fugu which focuses on Web Capabilities and Progressive Web Apps. Alex leads the JavaScript Jabber panel in a discussion of writing less JavaScript and focusing on performance and functionality on low bandwidth connections and low performance phones. Because accessibility is downstream, now, of performance, he argues that we need to focus on performance to make applications that give a good experience on lower end phones and connections.

 

 

 

Follow JavaScript Jabber on Twitter > @JSJabber

Special Guest: Alex Russell.

CHARLES MAX_WOOD: Hey everybody and welcome to another episode of JavaScript Jabber. This week on our panel, we have Dan Shapir. 

DAN_SHAPPIR: Hey, hey from Tel Aviv. 

CHARLES MAX_WOOD: AJ O'Neill. 

AJ_O’NEAL: Just crying tears. 

AIMEE_KNIGHT: Hey, hey from Nashville. 

CHARLES MAX_WOOD: I'm Charles Maxwood from devchat.tv. And this week we have a special guest and that's Alex Russell. Alex, do you want to say hello? 

ALEX_RUSSELL: Hi, hello. How's it going?

CHARLES MAX_WOOD: Now, do you want to just remind people who you are? We haven't had you on for a while. 

ALEX_RUSSELL: Yeah, I'm a software engineer on the web platform team inside of Chrome, which is a bit of a lie. I actually don't do that much engineering anymore. I kind of design stuff, but I lead our standards work and I lead Project Fugu, which is trying to sort of expand the footprint of what the platform can do. That kind of overlaps with my sort of long-term interests in progressive web apps and that sort of stuff. 

CHARLES MAX_WOOD: Gotcha.

 

A lot of times I just go back to the fundamentals and think about how I can make those things more automatic. The reason is, is because then when I focus on the fundamentals, I'm able to actually level up in all the other areas that I'm trying to learn. So I teamed up with Kyle Simpson to focus on the fundamentals of JavaScript. Kyle wrote the books, you don't know JS yet, and his getting started ebook goes over just the fundamental fundamentals, so to speak, of JavaScript. And we're putting together a 30 day challenge where you can actually level up on this stuff, get it down pat, and then you can go and learn all of the other things that you're doing that are based on these things. So if you go sign up for the challenge, you can do it at devchat.tv slash book camp. That was Kyle's idea. You can get the following as part of the challenge. You get daily training videos, which are worth about 150 bucks. You get daily exercises and homework, which again are about worth about 97 bucks, especially with the coaching that we give you around them. You get access to the private Slack channel, which is worth about 20 bucks. You get access to a premium podcast series that Kyle and I are going to record. It's an eight part podcast series where we talk through all the pieces of the book. You'll get three Q and a calls per week. And that puts you at about a $1,779 value. And what's great is you also get then the audio from the podcast, you get the video from the training, you get the experience from working and you get the visual reading learning from the book. So you're going to learn this in multiple ways. Once again, go sign up at devchat.tv slash book camp, devchat.tv slash book camp, and you can get it for $197. If you use the code JSJABBER, you can get it for 147 instead. So go check it out right now, devchat.tv slash book camp.

 

CHARLES MAX_WOOD: So we were chatting about what we were going to talk about on the show and you said you wanted to talk about writing less JavaScript. And I'm sure there are some people out there going, no, right. That's, that's what we do. That's what, that's how we make awesome stuff happen in browsers and other places. I'm curious, like what the, I guess what the pitch is on this and as far as why and what made you think about this? 

ALEX_RUSSELL: So I spent a lot of time working with partners, so that is, say, Google's partners and folks who are building sort of at the very edge of what the web can do. And performance has kind of ended up in the critical path for some large fraction of folks in a way that I was surprised by. Started working with teams that were developing the first sort of set of progressive web apps back in 2014 and 2015. And that experience was, unfortunately, something that we've seen a lot of, where teams would build something that worked pretty well on the bench or rather it's sort of on the on the phones that they were carrying. And then when we started to look at how they would actually perform for end users, even before we started talking about the features that they wanted to deliver, right? The shiny animations and notifications and, you know, being on the home screen and all that kind of stuff. You just sort of have to get to a level of baseline. This feels fast enough to be usable to make the experience that you're delivering something that users should want. And so sort of performance is at some level, the very front end of accessibility. So that is to say, if you can't get to it quickly, you can't access it. So all the other pieces of accessibility kind of are downstream of reasonable performance. And so this has become unfortunately a fixture of almost every partner conversation, wherein the devices that people have in the world, they're not the devices that developers seem to think that people have. I think this has a bunch of complex causes, not least of all, we're well paid. And a lot of developers aspire to kind of that very lux experience. And so they themselves live in that world. And, you know, Mac shipments in terms of total number of PCs are in the, you know, single digit fraction. As a total fraction of smartphone shipments, iOS devices are never really broken, I think 15 or 16%. Even in the US iOS usage, not even device shipments, which are user degrees higher than shipments. And iOS doesn't crack 50 percent, and all iOS devices are significantly faster than all Androids, just sort of as a blanket statement. So we have a situation now where the developers live in a bubble and are not really making common cause with most of their users. Outside the US, there are some markets where iOS penetration is much higher even, 60, 70 percent, for instance in the UK. But if you go to someplace like India, which is hundreds of millions of people, iOS might be 2%, maybe on a good day, wet. So most of the world doesn't live in the bubble, and the bubble is insulating us from doing a good job by users. And so that's sort of just sort of on the critical path and at the beginning of getting to delivering really great experiences. 

DAN_SHAPPIR: So true. You use, Alex, you use the term, I think, good enough performance or good performance, what would you consider to be good or good enough performance? 

ALEX_RUSSELL: We tried to dig into some of the literature on sort of user perception and user perception, you know, research is squirrely. There are lots of sources that will have kind of vaguely conflicting accounts. One of the things that sort of joins up those vaguely conflicting accounts has been a history suspension. So that is to say, what users expect is sort of what they will become habituated to very quickly, right? Like it's no surprise that the human animal is pretty good at getting used to a new set of norms. And so we, as users, get really accustomed to however something feels. And so variations from that are actually very sizable. You know, the old saw that, you know, you don't ever feel hot or cold just feel the difference between what your previous temperature was. So if you think about performance that way, question is, I think more accurately, is something relatively good or bad relative to your usual experience? And so on desktop, the web, the web kind of defines the baseline. Web usage is so high that people who experience a slow web page experience lots of slow web pages. And so it may not be a crisis. Web usage is actually relatively low, especially as a fraction of the sites and experiences that users interact with. And so the comparison point is native apps and how fast they feel. And so if you feel significantly worse, regardless of the absolute performance, the absolute speed, that relativeness, that relativity, I guess, to use a word, creates a disincentive to going back to the web. So Google, years ago now, did this sort of, I don't know if you're familiar with the idea of ablation studies, but the idea with an ablation study is instead of saying, if I make it this much faster, how much better will it be? You try and test the opposite and then try to understand the relationship between the forward and the backward movement. And so an ablation study was done where you just sort of add latency. You just make something slower by a fixed amount. And so it was an ablation study done to make Google search slower. And this has been repeated a couple of times now, I think not all of them published publicly, but it turns out that users who experience something slow, start using it less. So if it gets relatively slower than it was for them previously, they begin to use something less, and as a result of using it less, they will move their time or their attention to something else. Google Search isn't maximizing for attention. We want to get you to the answer rather than have you spend all of your time with us this is kind of replicable against a large number of experiences. So if the experience that you're delivering is relatively slower than something else, you should expect users to go to other platforms or to other ways of getting to information. 

DAN_SHAPPIR: If you use the native applications as a sort of a baseline for what you think the performance of web applications should be, which native application should that be looking at as an example of an application that provides good performance? 

ALEX_RUSSELL: It's worth thinking about the loop that users experience when they're trying to get to something. So I tap on an icon and then what happens next? Do I wait for five or six seconds for something to fall in or do I get instant acknowledgement that the system is doing work on my behalf? It's maybe if it's putting up a spinner, it's putting up a spinner that's 60 frames a second the whole time. Then as soon as the UI is available, if I tap or if I try to interact, it's consistently interactive. That loop actually plays itself out across all the interactions that you do inside of an application. Let's say I go to TikTok. If I go to the native app, it should start instantly. I should get splash screen, it should animate smoothly as it's loading stuff in, and then things should continue to animate quickly. When I tap on any button, it should respond quickly and when I start to scroll or interact in some meaningful way, it should do that without any delay. And so a lot of the art here about front end is in ensuring that, you know, like we've got a front-end frame that says 60 frames a second or it's free. That's kind of, if you think about it, like how do games work? Some people will go, well, games start really slowly. And I'm like, okay, that's great. But, you know, they will start, like they'll put something on screen quickly and they'll animate smoothly the whole time. Even the loading screen will have, you know, 60 frames a second animation and that never changes through the entire experience of a game, you will be experiencing something that is responsive to what you did or acknowledging what you did almost instantly, even if it's putting up a loading screen. So there are these big gaps between what the web tends to deliver and what our competition tends to deliver. And that reflects back on our platform.

AJ_O’NEAL: I think the worst thing that's happened for the web has been responsive sites that can hardly do anything and I can't access any of the settings or additional features. And now when I go to the web, I get a crippled web app that doesn't have any of the additional settings or features. And when I click use desktop site, it just refreshes with the same stupid mobile app. And it's kind of weird to me that like we're crippling the desktop experience and not really with the apps. I mean, I use Gmail I use, which Gmail is far better on the app than it is on the web. I'll give that. Facebook is almost identical between the app and the web. Twitter, almost identical. I mean, the main things on the web one are that I expect the additional things that I need to be there, and then they aren't. But I don't know. I often go to the web browser first, because it doesn't take 10 seconds to load. Because normally, I want an activity that's a five-second activity. I'm not going to spend six hours in this app. So waiting 10 seconds to do three to 10 seconds worth of work isn't worth it for me. 

DAN_SHAPPIR: I would just like to comment that, you know, speaking about the apps you mentioned. So Facebook happens to have like a light version of their client because they realized that their native client was actually way too heavy for a lot of the mobile devices out there. They actually implemented a light version that's specifically intended for emerging markets less resources, it provides a lighter interface. It doesn't provide all the bells and whistles, but it's a much smoother experience when you're strapped for resources. And with regard to Twitter, I have to say that I'm actually using the Twitter Progressive Web App, which I find mostly fairly good. In fact, they're nicer in a lot of ways than their actual native application, which I used to use before. 

AJ_O’NEAL: I think by far the thing that's damaging about web apps versus native apps is that web apps just suck it, allowing you to get what you want done, done, and you have to go into the native app for it to work. Like, and I have an iPhone 5S too, so keep that in mind. Everybody's abandoned the small screens, and so there's a lot of things where stuff doesn't load properly just because people are expecting that I have a seven-inch screen and I don't. So.