Video details

You Don't Need All That JavaScript | Stuart Langridge


Stuart Langridge

This presentation was recorded at GOTO Chicago 2020. #GOTOcon #GOTOchgo
Stuart Langridge - Member of the Web Standards Project's DOM Scripting Task Force, Podcaster, Developer and Author
ABSTRACT JavaScript is your behavior layer; the way to add interactivity to your sites, to provide a slick and delightful user experience, to make everything fast and easy and clean. But at some point everything changed: the tail started to wag the dog instead and development became JavaScript-first. We'll talk about how you maybe shouldn't rely on JS as much as you're told to, and some practical strategies for how to build sites without reaching for a JS framework as first, last, and only tool for making the web [...]
TIMECODES 00:00 Intro 00:30 Performance 02:54 Availability 05:56 It's unnecessarily difficult 08:33 Why? 09:41 After the fact 10:18 Loss of control 12:57 Control loading 13:26 Demo 14:33 Solve actual problems 18:31 HTML is smarter than it used to be 20:36 The leading edge
Download slides and read the full abstract here: #JavaScript #JS #Frontend #HTML #Programming
Looking for a unique learning experience? Attend the next GOTO conference near you! Get your ticket at
SUBSCRIBE TO OUR CHANNEL - new videos posted almost daily.


Hi, my name's John Language, and I'm here to talk to you about JavaScript specifically that you don't need all the JavaScript you've been told that you made. I promise. And I'm here to tell you about why. First of all, let's talk about performance. Let's talk about forms on the Web. Why is it important? Well, Zack Leatherman tested a client. Rended reacts by displaying one of his tweets against an HTML site, also displaying one of his oh, no, hang on, no software that he tested. It reacts by rendering a single tweet against an e-mail page, rendering every one of his 27000 tweets, eight point five megabytes of e-mail, which was rendered faster. Let's let Zach speak for himself. But first, meaningful paint time. It turns out that I react site rendering one tweet render slower than eight point five megs of HTML, rendering 27000 tweets. Another example where we shop from terminal training Jaspin. He was building a syntax highlighting code highlighting thing for his blog to display. He was working on in a nice readable syntax highlighted form. And what he said, what he discovered was that if he did think rendering the highlighting on the client with JavaScript, although he was transferring stuff in a different way, if you send this if you did syntax highlighting on the server, you're sending more HTML, but he still renders faster. And overall, you actually sending less stuff, you're using less bandwidth because browsers are really, really fast rendering HTML. They're not really fast rendering JavaScript. It is tempting to be honest with you to outsource a bunch of the work from your server that you have to pay for. You have to maintain your Ramonet. It's tempting to outsource that to the world's largest distributed computer, which is the web. But if you do not, the work doesn't double what you're just making everyone else do it instead of you. You making them all the way each once rather than you just doing it one time only on server. And frankly, they're doing it on computers, which are a lot worse than yours. Half the time they're doing it on phones and phones are rubbish. Alex Russell, head from Google says the takeaway from this is you literally can't afford desktop or iPhone levels of JavaScript if you want to make a good Web experience for anything other than the world's richest users. But performance isn't the only reason why we need to care about this. There's talk about availability. Some of you may have seen this statistic that one point one percent of people weren't getting the JavaScript enhancements on a page. This is from GD's the Government Digital Service. And that makes you think, well, you know, here it is. It's like this, that one percent. Yeah, it's sad for them, but they're not a big part of our business. They're not a big part of our customer base. I feel sorry for them, but they're not really our target audience anyway. Right. It's got some effort to make our Web app available to everybody and it's just not worth the business time to do so. We've got a certain browser baseline and you have to meet that. All right. We've got priorities. We've got a backlog. Maybe we'll do it next time. Yeah. Here's the key point. It's not like this, OK? What you was the proportion of people that didn't get the JavaScript because they have JavaScript turned off or because they're using a browser that can't cope with it is only a small percentage of the people who didn't actually get the job get most of the people who didn't get the JavaScript you're serving should have done so. Some of you might have seen this. This is a page called Everyone Has, just by which I believe and it gives you a whole bunch of reasons why your target may not have actually worked at a time when it should have done so. ISP Block JavaScript. Have you have you been to an airport and found that it blocked in know while the judge was loading? I mean, go through and look at the whole page. But the whole point is that it's like this. It's not one percent of people who always don't get it and 99 percent of people who always do it. One percent of business, almost all the people don't get your JavaScript should have done so. They're not browsing with JavaScript turned off. They're not browsing with links. They know WAP phone on a 2G connection. They you in a salad bar or in a hotel room with the weird hotel Wi-Fi or they're on a train and they've just gone into a tunnel. They're waiting for the phone network to wake back up. Worse, it might actually be like this actual real people, if they experience this. And does your site work without JavaScript? If it doesn't load for some reason, if one of the jobs involved as opposed to just work, does it progressively enhance and fall back to working anyway? Or does it just give you a spinner for ever and ever and ever? And if someone gets that. If they ask a developer, then they'll say something blah, blah, blah, although it's obvious hit refresh or toggle my phone into airplane mode and back out again a whatever the actual people are urged, the work timestamped didn't work. And then maybe they'll hit refresh. But then the second time, the next day they come back. Maybe it doesn't work then and they'll start saying, why isn't there a native app, why can't I use. And they'll go and use one of your competitors. Right. And then eventually they're all gone. Maybe you won't do this because you understand the difference, but actual people generally don't. But there's a more important reason why I think you don't need this job and that is building for the modern web is unnecessarily difficult. But if you look at this list of technologies and things that your maintenance time, can you keep up with all this stuff? And it's not just me saying this, but increasingly there seems to be a sense of fatigue within our industry. Just when you've got a handle on some new technology, something else new comes out to replace it. How do you a be overwhelmed by the choices that come to modern developers? The complexity of building something is so great in a product simplicity that it puts people off. You've got sacks of different JavaScript dialects. They use TypeScript and installing NPF and these things. They do help solve some shortcomings with web technologies. But at what cost? I'm talking about a web of invisible dependencies. And if you don't recognize some truth in that, then I can tell you that most of your colleagues do. I think anyone claiming that they don't feel this level of complexity is to some extent deluding themselves and turn to the people next to you and ask them to turn to the you know, next time you're talking to someone on a video call in your team, ask them if they feel this when they may be your head and that. And in that case, you should spend some time bringing us up to date because it's really confusing for a lot of people. In that time, I could have broken out an FTP program, a notepad, a Belleci in H.M.S. House and just uploaded it and it would have been easier to maintain in the long run. That's the key point here. There were two arguments given all this, that much better sites for users, that it saves developer time. And so with more stuff can be developed over either of these. Actually, true. And I'm not trying to overwhelm you here with similar quotations. But then he said these all these people who have been quoting here, there are notable, smart, motivated people they work professionally on and wave and for the web. These are people to look up to. They certainly people that I look up to and they're feeling overwhelmed. And I bet you filicide in 2007, I stood on stage in London and said that increasingly people were building links in their pages, which were JavaScript dependent, and they looked like this. They were XML http request and using Microsoft XML htp. And I said, well, you should be given a link if you want someone to click on something good. No, I don't think they did. This does you've linked that built into the platform. Right. The Web platform does this for you and largely I'm gratified to say people are blessedness. They're not currently building stuff with XML, HDB request that, but they're not using Linux that what they're doing is these things that. Right. So overall, the JavaScript just now, it's a react component. But why are we doing this? Let's take a step back and ask why. There are good reasons I'm not throwing bricks here because people are stupid. People have made this decision for good reasons. OK, so just think about it. So you've got things like computer reuse and this is really useful. You've got the idea that you can build up a library of components that you successively use on different sites. All the other people have developed for you and so you don't have to re implement them yourselves. And that's really handy. You've got a consistent starting point when you're building an application. Each new app starts in the same way. It's got the same things in the same places, and that increases your team's Spirit of Things velocity in building new things and getting up to speed. You can also apply some organizational structures, not some random pilot by e-mail either directly, but you're actually applying some software engineering principles. As our industry comes out of the Dark Ages and we become the engineers that we claim to be, the sort of thing is a good idea. You can start applying best practices, thinking about best practices and these are all good things. But to make these things look after the fact rationalisations, it's not. We wanted all those things. And so we invented frameworks. It's we've invented frameworks. What do we get out of it? Here's the list of things. I think the reason people started inventing frameworks is this. In the old days when you could link in a page, what it would do is it would start loading the new page and it would blank out screen. So you clicked on the link page White and a new page load, remember, because the Internet was slower than collections were slower that and so the next page would load. But what that actually meant was that you had this real sense of a loss of control. You lose control over the user experience. You click on the link, it goes right to the browser. The browser then loads a new page and then when that new page loads, you then get control back again. You, the developer, now get control over the user experience again. So there's this big gap in the middle where you can't do anything. What you do is wait until you get called back by the browser when your new page layout. And we as developers don't like that loss of control. We as designers don't like that. We try and we are correct to not like it. One of the most important discoveries of the last 20 or so years has precisely been the design. The user experience is a critical part of what we do and giving up that control over the user experience every time someone clicked on the link was a problem, right? We don't want to give people these blank screen after they've clicked on something. We want to be able to mediate and control that experience. And what people learn from this is the page loads are bad because page loads mean loss of control and because page loads bad, they must be avoided. So you say to yourself, well, what if instead of the browser loading the entire page, what if I did? OK, so I want to avoid this loss of control. So I'll circumvent the browser during the landing because then it's got control and I haven't. Instead, although myself, I'll use explanation to request fetch these days to pull the data off the server and then I'll put it in the page myself. OK, so that way I'm never handing off control to the browser. I've got the control over the user experience the whole time. And then you say, well, that's great. But if I do that, then I pull up untraced, my life is over and I put it in the page. But a lot of the e-mail that I'm putting in the pages of it that way, and that seems very wasteful. So you invent the virtual door. So that kind of change isn't as wasteful because you're only updating the bits that have changed. And then you say I but if we put a new page off the server ourselves and then put it in, then the euro doesn't change because you've not actually done a navigation use pretending to do navigation. So you invent the HTML History API and using client side routing. So you know the route yourself, rather than having to browse a Web server, do it for you. And at that point you are a framework. You have invented a framework once you've got all these things. But the key point here is that it's a pyramid. So it's all one thing built on the next, but on the next we've got this stage. We need this so that sure. The weaknesses in it. But building another thing and then short weeks is not by building another thing. So it's a permanent thing built on the net, but it's a pyramid based on one single point, one tiny point which is page loads about and we must avoid them. Why if you control the experience of new page loads without having to implement page loading yourself. This is what Portal is for this portal. This party, basically the portal is an iFrame that you can navigate into. So here's an example from what you can say. iFrame comes up and then it's clicked on and it activates and the oil changes and that's not being faked by the actual history API. You're actually navigating into that portal in whatever state it's in, into that. So here's a very quick demo, CMC here. I bring up a page click and it creates a portal just like an old friend. And then I click to activate it and we actually navigating the URL changes because you've actually navigated into that thing. And here's the code and the code is hardly anything. All right. There's better think it's just it's just like real life. Create a portal said its source activated them. But of course, we've got control over this now. So you can activate it when you want. You can do something in between creating the portal and activating it. So, for example, you could animates it. So if I click here again, you can say I've got I create the portal and then I activate it. But now what happens? It zooms up to fill the page first and then we activate it. And I didn't have to do anything special. That's not a magic portal specific API. A portal is just an element in the page, so it's susceptible to the same CSS transition and transform stuff. But every other element is so we just zoom out with the standard. There's a transition and then when the transition finishes with transition and event handler, then we activate the portal, no problem at all. So it's not an actual problem instead of a toy example, but a real problem that needed solving it and see how this might help. So imagine you've got a documentation site and down the left hand side you've got the list of different sections in the documentation. The right hands are the main part. Page shows the particular piece of documentation that you've clicked on your left hand side. OK, how do you build this? So one obvious ways, do you think? Well, what's the all the separate pages? OK, you got a bunch of separate HTML pages and each one's got a copy of the table of contents on it. Clicking on one navigates to another page. It's completely static. HTML performance is great, so it directly adds three barely need a web server. No problem at all. The problem with doing that is that if you scroll the left hand pane down in order to get to something later the documentation and then click on the link. When the new page loads, the left hand is no longer scroll down. OK, and what that means is people lose their position in the documentation. It loses where they are up to. And that's unfortunate. There may be those of you who are as old as I am who think, well, well, frame sets for isn't it? And the that there is no 1999 anymore. The problem with friends is if they don't change the URL, so a frame set will go out in the browser bar will be the URL of the frame sitting on the other page you're looking at. So if you share this particular bookmark, it will bookmark page. You actually looking at. OK, so maybe we could use an X prefix, do a whole single page up, just get this and you know. Yeah. In theory but all the reasons why you don't I mean seriously, just for this tiny one little thing, we're going to use a whole they've got the whole page, but we actually load a whole JavaScript library, open view and load the whole library and everything just to do this. This is massive overkill. And those of you are JavaScript developers of a bunch of Hathaways doing this and the Huckabees are currently how they're doing. I click on the link and then he stores the current scroll position in local storage and then get a page load. It looks in local storage and if there's a value in there that it scrolls its left hand back to that position and then you. Okay. I mean, the problem is you just sad to mean surely we can do better. And one way we could develop this is with portals. So you spoke of the Postmus, what you did when you click on the link, we override that link with JavaScript. When you click on the link, create the new page in a portal and then post message the current scroll position to it. That new page in the portal, then scrolls is left hand side to that and then called back to the main page, say, okay, we're done, at which point you then activate the port. OK, so very brief demo of this. You say here I've got the page, I scroll down to the left hand side click and that moves me to the next page and our scroll position. Left hand pain hasn't moved and that's great. And that's the beauty of this, is there's no code in the pages particularly, but this is all completely, progressively enhanced. So if you've got portal support, then we just use it. If you haven't got portal support, then it's just a link. And the reason this works is that you've got two different activated pages at once. This is the first time in the history of the text files somewhere where you want you've got access to not only the page that you want, but the page that you're going to at the same time before. And this is what caused that loss of control. You are either in the page you in or you click the link, which you no longer the page you're in. You're in the process of loading the page that's coming. Now you have access to both so you can manipulate the page you're going to before you go there. But without having done them already, most of the time, perhaps you only want to add some sprinkles of interactivity to an existing page. The majority of websites aren't and don't need to be single page apps. And it's not me saying that each react, saying their reactor has been designed from the start, the gradual adoption and you can use as little as much reactors you need. That's a direct quote from reactor own website. And part of the deal here is that I used to be smarter than it used to be. I does a lot of stuff now that used to have to be Web components, a bunch if you ask me questions in the eye and in the question section. But ask about scrolling Snapple, about filter disabled and these the responses. It's not that any of these things are super revolutionary. Is that Obama that would have required a whole bunch of JavaScript enhancement of downloadable components. They might be Shakeri components recently that reactor components or their view components or whatever else which are the framework you use that pure web components. But what about that? If require these things and now they don't because they are built into the Web platform. But I'm not saying don't use JavaScript. This is important logo. I think I'm set up. I love JavaScript, its programming language of the web. It's brilliant. I read books about it. I love it. I do talks everything. Don't avoid it. Just don't necessarily let it run everything. How does it all say here's mentions exactly this point that it's stupid to go miles and miles away? I make myself a lot like a lot more complicated to avoid JavaScript and it's just you just use a little bit, no problem at all. Stay in touch with the parts of our industry, the fresh stuff, but stay in touch with all of it, not just the latest thing in your favor, but the latest moves in H2 out, the latest moves in and the latest moves in JavaScript. Fight the right fight. There's a whole bunch stuffies needs fighting again, especially right now. But we need standing solidarity with one another, with the rest of the world. Don't use your energy fighting the Web platform. The great thing about standards is they take a long time to take. It's not great things is worse than how stealth, but they take a long time to do for a reason. Something gets into the web platform, you know, the it's performant, it's accessible. It works correctly with right to left languages. You know, there's a whole bunch of stuff which needs to be done as part the standardization process, which doesn't have to be done if you want to put our Web component, because you can say, oh, yeah, there's no way we want to have languages or. Sorry, you know, we'll fix that in the next place, the web platform doesn't have that luxury, but this does mean that if you're building stuff as components, building stuff with frameworks, that you have a chance to be ahead of what the Web platform currently provides. And you definitely should use that. But ask yourself, do you do you need it all the time? Are you constantly ahead of the Web platform? Use the extra stuff if you need it. But if every time you build any project for any reason, you say, well, we need a framework because we're ahead of the Web platform. Really? Do you want to see that for like a login form? I'm not necessarily the truth. It's valuable what we do as an industry. We we've got the power to bring knowledge to the whole world. We can connect people together when they want to be connected together. And it's the greatest repository of information there's ever been. And I want to keep it that way. That's what I think is important about the Web. So thank you very much, wanted to be sure and I wish Charles.