In this episode, we’re talking about Responsible JavaScript. What does it mean for code to be responsible, and how should we approach projects differently? I spoke to expert Jeremy Wagner to find out.
Show Notes
Weekly Update
Transcript
Drew McLellan: He’s a technical writer, web performance nerd, developer and speaker, currently working at Google. He’s written for A List Apart, CSS-Tricks and Smashing Magazine, and is the author of a new title, Responsible JavaScript for A Book Apart. So we know he’s a skilled technician and communicator, but did you know he wants circumnavigated the globe on a standup paddle board? My smashing friends, please welcome Jeremy Wagner. Hi Jeremy, how are you?
Jeremy Wagner: I’m smashing. How are you?
Drew: I’m very good. Thank you. I wanted to talk to you today about this idea of Responsible JavaScript. Is this some sort of new approach or technique, or are you literally talking about using JavaScript responsibly?
Jeremy: I’m literally talking about using JavaScript responsibly. So per the HTTP archive, we’ve seen a nearly 58% median increase in the amount of JavaScript downloaded by mobile devices from roughly 290 kilobytes to almost 500 kilobytes in the last year.
Drew: Wow.
Jeremy: So when I talk about using JavaScript responsibly, it’s a user first sort of approach to say… to critically evaluate what is it that we’re building and is the goal of what we’re building served by modern web development practices, so to speak. And I guess that’s kind of a… maybe not tongue in cheek, but I wasn’t taking a jab at modern web development, but one byproduct of modern web development is that it’s very easy to add dependencies to projects. Everything is an MPM install away and every MPM install has a cost, that cost varies. But what we do see is that in that HTTP archive data, the 95th percentile… meaning the 5% of experiences that are the slowest… or not the slowest, but that ship the most JavaScript, that has risen in the last year by about 875 kilobytes to about 1.4 megabytes.
Drew: Wow.
Jeremy: So it’s a tremendous amount of JavaScript that gets transferred and it has both loading performance and runtime performance implications.
Drew: So you mentioned performance there. It seems like the modern web experience from sort of my point of view is like 10% HTML and CSS and 90% JavaScript. And there has to be sort of performance considerations to that. I mean, you talked about out sort of the amount of data we’re transferring, but there’s other performance considerations on there with having a lot of JavaScript.
Jeremy: Right. So having a slow internet connection and you know… where I live in the United States, if you go far enough outside of a major city, it gets kind of difficult depending on where go… to just cope with how slow the internet can be in sort of these rural areas and is significant upon of people live in areas like this. And so the loading performance aspect of it is already challenging enough when you start shipping megabytes of JavaScript, but you might also be dealing with somebody who doesn’t have an iPhone… like an iPhone X or like an iPhone 13.
Jeremy: They might just be on a feature phone or just kind of like a budget Android phone, just trying to navigate through life. I mean, think about things like online banking, unemployment assistance, or other government assistance, portals like that for applications. Online learning, there’s just a lot of places where excessive JavaScript can really have a detrimental effect for people who might not be fortunate enough to live in large metro areas or even in metro areas that are not well served by broadband internet and those on slower devices. I kind of think as developers, we have this tendency to look at… we buy MacBooks or these high end devices, and we sometimes don’t really see where these issues can arise when we overuse JavaScript.
Drew: And sort of as you mentioned there, sometimes it’s the individuals who have the sort of stand the most to lose by not being able to access a service who get penalized by this sort of thing. Those people without fast data connections or without very capable devices are sometimes accessing services that mean everything to… it means everything to them that they’re able to gain access. So it becomes almost a humans rights issue in some ways.
Jeremy: Yeah. I mean, we tend to see web performance get framed in terms of business value. I was a performance consultant for some e-com and like a major food company, a major e-com… like a store, like an electronics outlet and it’s very tempting to do that, right? Because when you work for a business, I mean, obviously you want financials to be healthy and web performance does play a role in that I think. I think there are a number of case studies that prove that out. However, there is that human aspect and even for businesses, like say like grocery stores and that kind of thing. Yeah, they’re revenue driven. They want to have healthy finances and so web performance is part of that, but they’re also serving a critical need, right? Like you have to eat, right?
Jeremy: And like some people might be home bound for one reason or another. They might not be able to easily just get in a car. They may not have a car. So they’re relying on these services in order to get sustenance, but more than that, assistance if they need it and especially like crisis intervention and that type of thing. I don’t think it’s terribly farfetched to say that a partner who has been abused and thrown out of their home might turn to their smartphone and, and hit Google to try to find a portal for crisis intervention and assistance. And JavaScript kind of can get in the way of those types of goals and to serve those human needs. When we have a tendency to lean on it just a little too much.
Drew: I mean, we’ve, we’ve seen a sort of glimpse of that over the last 18 months or so with COVID and people going into isolation, and as you say, needing to order groceries to be delivered. The web becomes a lifeline for them at that point. They’re feeling under the weather, not able to leave their accommodation because they’re isolating and they have to get food and they have to get essential supplies. So yeah, it’s an ever increasingly important part of just everyday life for us all, I think.
Jeremy: Exactly. And going back to the sort of device story, Tim Kadlec wrote an amazing piece a couple years back, I think it was two years, maybe it three years back, but it was called Prioritizing the Long Tail of Performance. And when you look at that… so in web performance parlance, we kind of talk about lab data versus field data. And lab data is like when you’re running lighthouse or you’re throwing a website at a webpage test to see how it’s doing. Those are all really useful tools, but when you look at that field data, you really start to get a larger picture and a larger view of who your audience really is. And in this article, Tim Kadlec talks about what it means to prioritize the long tail of performance. Meaning all these devices that… are maybe not as beefy and as powerful as the devices we as developers may have.
Jeremy: And the idea behind that article is that if we can focus on that 90th or 95th percentile we’re… and improve that experience for those people, we’re building a faster web for everyone, including those on fast devices. And attack a data point on that in the US and this is just from like statcounter.com. Something like 28 point… around 28% of people are on an iOS device that this tool captures. And around 21% of them are Android. And Android tends to represent a good chunk of that long tail of devices, because Android’s not monolithic. Multiple device manufacturers make Android phones, but to kind of contrast that with the world, because the world is more than just the United States, it’s around 16% of people who use iOS and around like 41% of people who are on Android. So it really does pay to prioritize those slower or potentially slower experiences.
Drew: I read in your book about device thermal throttling, which isn’t something that I’d really ever considered before. What are the concerns there?
Jeremy: The concerns there, and I’m not like an expert on microprocessors by any means. I’m just the web developer who probably writes a little too much, but… so the idea behind thermal throttling and this exists in all systems, not just like phones and tablets, is that a microprocessor will… when it takes on excessive workloads or really just workloads in general, the waste product of that work is heat. And so devices have ways of mitigating this. Like your laptop has both a passive and an active cooling device.
Jeremy: So like a passive cooling device is like a heat sink or some kind of heat spreader. And the active portion of that is like a fan to more efficiently disperse heat. Some like custom PC builds might use like liquid cooling, which is sort of a more relatively extreme example, but a mobile phone doesn’t have that because where are you going to really fit a fan in all that, if portability is kind of your thing, right?
Jeremy: So in order for these devices to cope with these heavy workloads, they may artificially reduce the speed of the processor, like reduce the clock rate until that device enters a state in which that clock rate can be raised. And that has implications because if you’re chewing through tons and tons and tons and tons of JavaScript, you have like these big chunks coming down the wire, well that kicks off processing, right? So it’s a lot of processing through evaluation and parsing in compilation and then execution. And if you’re doing that with like a megabyte or two of JavaScript, and you have a lot of other processes going on in the background like different tabs, that type of thing that, that can put your state… that raises the likelihood that the device may enter a thermally throttled state, which means that it will be less capable of taking on that extra work.
Drew: So it’s a sort of a negative feedback loop. Isn’t it? You give the device lots of work to do. It gets very hot and then is less capable of actually executing that work because it’s having to throttle back.
Jeremy: Right. And again, I’m not a microprocessor expert. I’m sure that if, if, if an engineer who was really intimately familiar with this, could probably correct me on some of the particulars, but the general idea is that yes, as that environmental pressure increases, the device is less able to cope with these heavy workloads until that pressure decreases.
Drew: so we’re writing JavaScript for the entire sort of spectrum of devices from latest Apple M1 Max is the new processor, isn’t it? Laptops all the way through to devices that barely have enough sort of working RAM to render a webpage. But the web didn’t start off like this, younger listeners might be interested to know that we used to build interactive web experiences without any JavaScript at all. Our big, heavy framework’s going to be our undoing.
Jeremy: I would say that frameworks have a time and a place and those who sort of read excerpts from this book may get the idea that I’m anti-framework. And I’m definitely critical of several frameworks, but they do serve a purpose and it is possible to use them in a way that preserves a good user experience or can result in a good user experience. But what I don’t think we do enough of is sort of critically evaluate these frameworks in terms of how they harm… run time performance, right? So the type of stuff I’m talking about, where if you click a button, and it takes the device like a second maybe two to respond to that input, because there’s so much going on in the background. You have third party JavaScript stuff like gathering analytics and then you have like other things running on threads.
Jeremy: And that if you don’t critically evaluate the runtime performance of a framework, you might be leaving some opportunities on the table to better serve your users. So a good example, I always like to use is react versus pre-act. I’ve been kind of banging this drum for a while. I did an article for CSS-Tricks a while back that profiled a basic click interaction for like a mobile navigation menu. And it sounds trivial, but what you find is that across all devices is that react delivers on better runtime performance, but it has basically the same API. There are differences, there are some tad differences and stuff that can be papered over with pre-act compat, but that simple… and I shouldn’t say a simple choice, but that choice, that fundamental choice can be the difference between an experience that works really well for all users or at least most users, or an experience that only works well for some. Hopefully that made some sense.]
Drew: I mean, with all the frameworks and build tools, they seem to be getting better all the time at doing things like tree shaking and optimizing the bundles that they ship and how they’re then delivered to the browser. When using big frameworks, is there a tipping point you think where you are writing such a big application, so much code of your own, that the framework is enabling you to ship less code because of all of its abstraction?
Jeremy: That’s kind of a difficult question to answer. One aspect of that is that the framework itself represents an amount of code that you can never optimize away. So having like a thin framework, like pre-act or any number of like… Or like spell for example, that that helps a lot. But the problem that I’ve seen and I think the data from the HTTP archive kind of supports this point is that it seems that anytime we have these advances in microprocessors and networks getting faster is that we tend to consume that gain, right?
Jeremy: We tend to just kind of be on this treadmill where we never really advance. And I don’t know, like I’m not clairvoyant about what the history of… or sorry, what the future of frameworks looks like. I’m sure that there are some efficiency gains that can be gathered. But what we see in the field in terms of how much raw JavaScript is like… just the raw amount of JavaScript is being used. Doesn’t tell me that this is a problem we can kind of automate our way out of. I think we have to… we have to be human beings and intervene and make decisions that are in the best interest of users. Otherwise, I don’t see us getting off this treadmill, not in my career maybe, but I don’t know.
Drew: In the book you talk about websites and web apps and how understanding the difference and which one that you’re working with helps you choose your strategy for how you develop and optimize. Tell us a bit about that.
Jeremy: That is a really good question. And I write about this in the eponymously titled article I wrote for A List Apart called Responsible JavaScript Part One, which is kind of the prelude to this book. Is that we sort of load a lot into this terminology. Like as a technical writer, I see the two get used kind of interchangeably. What I see is with websites, the implication is that it’s sort of a multi-age experience, right? It’s a collection of documents. Now a document… those documents may have embedded functionality like these little islands, as the term lately has kind of been, these little islands of functionality that enable people to get things done.
Jeremy: But then there’s like web apps and web apps sort of have this connotation of native app like functionality. So we’re talking about single page applications, we’re talking about heavy amounts of JavaScript to drive complex interactivity. And there are times when the web app model makes sense. Like for example, Spotify’s a good example of this. That works better as a web app. You wouldn’t really want to try to use that or design that as a multipage application. Like a traditional web site, but I think it’s not a sustainable default because when your default for every project is to say, “Well, all we need to ship a single page application, like a client side router and a heavy framework and offload all of this processing of rendering from like the server onto the client.” I think that that is where you start to reach a point where you’re excluding users albeit unintentionally, but excluding them nonetheless.
Drew: Is there a big chasm, do you think between the people who take the approach of we’re going to publish a website and it may have whatever interactive functionality and those who say, “We’re a software company, we’re making a product, a software product and our platform that we’re going to deliver it via is the web, rather than native applications for multiple platforms.” Is it likely that they’re approaching the problem in completely different ways? Are the considerations different depending on your outlook at that point?
Jeremy: That’s a tough question. So-
Drew: It was tough for me to say.
Jeremy: I would say that a company that… so a good example would be like a news, right? They’re well served by the sort of website model, because it literally is a collection of documents, articles. And the people who develop those experiences are probably going to have a different skillset than say a company like Spotify or a company that has like a large web application like Envision or that type of thing. And so yeah, I think they’re going to come at this from different angles. The way I’ve kind of looked at it is that there’s a segment… or at least this is how I perceived the web development community at large is that there is a segment of people, of web developers who came from non-traditional software development backgrounds, right? And I’m one of these people, I was tinkering with the web when I was kind of like a kid, right?
Jeremy: Like in middle school and doing stupid fan pages for all like the video games at the time that I really liked. And I never had that sort of computer science education. There are computer science concepts that I’ve picked up along the way. Then there’s also a segment of developers, especially I think that have come around in the last five to 10 years who approach this in a more computer science oriented way. And I think that’s going to… those differences and experiences are going to lead each of those groups to draw their own conclusions about how best to develop for the web. But I think the only way that you can really… That you can sustainably develop for the web is to critically evaluate what it is you’re building and to try to align around an approach that best serves users of those products. And that’s sort of where the website and the web app models kind of sit in my head when I evaluate these things.
Drew: Yeah. It interesting. I mean, in the book, you actually cite some of my work. Thank you very much. And my choice of boring technologies on noticed basically PHP Apache and a sprinkling of hand rolled JavaScript can create a very snappy user experience by default, without needing to do any particular optimization. I think that makes for a great user experience for the front end visitors coming and viewing content on the site.
Drew: But actually, I kind of feel like that environment for authoring content sort of the flip side, once you’re logged in and your publishing stuff on the site. I think it suffers a bit from being built with a website approach, rather than a more sort of JavaScript heavy web app approach, so much so that I’m thinking… or perhaps it needs to be both. I need to continue publishing the front end in nice static HTML and CSS and tiny bits of JavaScript. But the backend where I want to provide a content authoring experience maybe a different technology choice would be better. It’s quite interesting because it doesn’t always have to be one thing or the other does it? It’s not a binary choice. It’s more of a spectrum, would yous say?
Jeremy: Yeah absolutely. And I think we’re starting to see more discussion in the community about web development being a spectrum like that. To just be straight up for people who might be interested in my book, it definitely comes from the website side of the spectrum. And again, because I feel that that’s always like a good default. If you don’t know how you want to build something, it’s probably best to try to build it in a way that minimizes the use of JavaScript and minimizes pushing more work onto the client. That said, I think that noticed is an excellent experience. I think that these well worn and sort of really “boring” technologies really work well for the task at hand. And it does so in a way that’s like kind of open and enabling for the developer, right?
Jeremy: You don’t have to have like deep knowledge of like… of state management stores or state management frameworks to really pull these kinds of things off. And I think that noticed is well served by that particular approach. But to your point, I think there are opportunities in any website to move closer toward the middle of the spectrum without going all in on all client side routing like heavy like frameworks that manage everything on the client and that type of thing. I think the island’s approach is starting to explore what that looks like. And I’ll admit, I’ve probably have unintentionally done some of the islands type thing. I think we have for quite a while, we just haven’t really put a name on it. But I think now that we’ve kind of identified that as like maybe a midpoint, we might start to see web experiences that deliver on a good user experience, but are still more interactive. Hopefully that wasn’t terribly meandering.
Drew: It sort of harps back a little bit to the days when we would embed an island of Flash or-
Jeremy: Yeah.
Drew: Something in a page where this is our little interactive section, and the rest of it sort of flows around.
Jeremy: Yeah Like Flash, oh my God, three iterations of my personal portfolio out of college were really crappy to advanced Flash knockoffs and like hover effects. And that stuff was really, really fun. And I miss it sometimes like there’s a whole just wealth of content that’s just going to kind of disappear because we don’t use Flash anymore. And that really sucks, but in a way it was kind of the precursor to this sort of islands thing that we’re talking about. Which is you could just have like a static webpage and everything, but then you would have this really richly interactive experience just kind of like plopped right in the middle of it.
Drew: For a long time, progressive enhancement has been considered a best practice way to build web experiences. Is that still the case, do you think?
Jeremy: I would grant that it’s probably… not probably I would grant that it’s more work to do progressive enhancement because in a way, you’re kind of bifurcating your development experience. You’re trying to deliver minimum viable functionality of a website in a way that the server can handle sort of like these key interactions. But then on top of that, you’re saying, “Okay, well now I want to facilitate this interaction to be just a little bit more smoother with JavaScript.” I still think it’s a viable way to accomplish your goals with your website or your app or your product.
Jeremy: But what I would say is that I would never recommend that every single interaction on a website has to be facilitated by this synchronous navigation sort of pattern. So like a good example might be your checkout page for your econ website should definitely have a server route. You should have a server route to add things to the cart, and then you should be able to sort of sprinkle on just enough JavaScript to make that a little bit more delightful so that things can be a little bit faster and more asynchronous.
Drew: When it comes to measuring performance. We hear a lot about core web vitals, mainly from Google. Are those really the benchmark up that we should be measuring against? Or is that just what Google wants us to think? I now appreciate this might be a difficult question that you started working at Google.
Jeremy: Yeah, yeah. You know, so I’m speaking for myself here. I think that web vitals are… the initial core web vitals are a good attempt at defining what parts of the user experience are important. I do think that metrics such as cumulative layout shift and largest Contentful paint start thinking about the experience in ways that we really hadn’t started to quantify. Before particularly cumulative layout shift, because if there’s ever been a moment where you rage tap it’s because a button likes to move around the page or something. I mean, I think that that’s a helpful thing to measure it. It is imperfect. And I think anybody who works on core web vitals would agree that improvement is desired in some of these metrics. There are other metrics that I don’t necessarily agree with entirely. Like first input delay is a metric that is kind of difficult to put a pin on.
Jeremy: I think it’s really useful, right? Because what you are literally saying is we want to measure the delay and interactivity on that first interaction that the user makes, but it does lack a little bit of context, right? Because some… a lot of things can affect it because it doesn’t necessarily always tie into JavaScript. First input delay could represent the delay that’s incurred by focusing form field, right? That type of thing, things in HTML. I think those metrics… such metrics like first input delay can be… they can be beneficial if you can contextualize them with things like entries out of the long task API, element timing, and those types of things. I ultimately think that the future of core web vitals will prove out that it will be helpful and instrumental in measuring what makes a good user experience. That that’s my personal opinion.
Drew: I guess it’s, it’s one of those things that you can always measure against yourself, measure your own improvements or whether your experience has got worse if your score changes, not caring so much about the traffic lights, but caring about what you know about the context of your site and how a change has made an improvement.
Jeremy: I think that metrics such as cumulative layout shift are excellent, but they too could benefit from a little bit of improvement. As it stands, cumulative layout shift, mostly measures layout shifts that happen during load. And as we know, when a user visits a page and lands on a page that layout shifts can occur at any time, right? So there’s definitely work I think that that can be done to improve how we observe of that kind of phenomenon, for sure.
Drew: I think layout stability is one of the things that’s actually a little bit more difficult to achieve when you’re working with progressive enhancement. Sometimes when you load a server rendered page and then begin enhancing it in the client, there can be a danger of creating that sort of layout shift, can’t there?
Jeremy: Absolutely. And that’s kind of where hydration of components becomes kind of tricky because the dimensions of that component may change for any number of reasons. Like there could be content present in the client side component that just doesn’t render on the server because of state that isn’t evaluated until it’s executed on the client. It’s an extremely difficult problem. I’m not going to sit here and pretend I have like the silver bullet for it.
Drew: I wanted to talk a bit about sort of dynamic of imports and code splitting, both being different techniques for the problem of downloading and executing a huge bundle of JavaScript upfront at the start of the experience. Is there a risk of over optimizing with making lots of small requests, particularly on simplest smaller projects, or is it something that they’re absolutely no harm in implementing sort of from the outset preempting that you’re going to have these problems? Or should you be waiting until you actually see performance problems before thinking about those sorts of things?
Jeremy: So I would recommend the tail end of what you just said is a good way to lead in with this. We shouldn’t try to prematurely optimize unless of course those optimizations can be achieved very quickly and easily, but if it takes a lot of effort to optimize early on, when there aren’t really a lot of performance issues, I would argue that code splitting is probably something that doesn’t have to happen. You can probably just load that functionality up front.
Jeremy: But for example, I talk about this in the book. If you have a high value interaction that is driven by a large piece of JavaScript, and to me, a large piece of JavaScript could mean 20 kilobytes because over the wire that’s compressed and that could end up being a 60 kilobyte chunk of JavaScript. Then if you can pull that out on the main bundle or any of your myriad of bundles, your site might be shipping, you’re going to help startup performance.
Jeremy: But in the book, I discuss a technique about perceiving when… or at least attempting to perceive when the user might make a high value interaction. So the example I use is a chunk of JavaScript. That’s used to validate the contents of a form because HTML form validation is great, but it’s also not styleable, and it’s pretty straightforward. There’s not tons of flexibility for things like, type equals email, right? It evaluates it a certain way. However, that validation of the form on the client is really helpful because we can also style it. And we can align the appearance of that validation to be closer to what the brand aesthetic is or what the aesthetic of the website is. And so in this example, what I did was, is I said, if a user focuses… even just focuses any of the fields in the form, that’s the point in which we preload that piece of JavaScript.
Jeremy: So that hopefully by the time, and I would hope because it takes a little while to fill out a form that the network has enough time to pull that down so that when the dynamic import is called, it can just hit the cash to get what has already been preloaded. It’s something I’ve been working with a little bit here and there, and it’s difficult to do in all situations. Like for example, you can’t do this reliably all the time on hover because some devices don’t have a fine pointer. They have… they’re… it’s tap inputs, right? So a hover occurs at a different time than if you had a fine pointer, for example.
Drew: One aspect of responsible JavaScript use is thinking about how we consume our users, available resources, be that sort of battery life or data allowance, if they’re on a data plan. Are there techniques that we can lean on here to, to help us think about those things?
Jeremy: Yeah. So currently, or at least historically from the last… I don’t know exactly when this feature shipped but Chrome for Android and there used to be a Chrome extension thing for this called Save Data. And what you would do is if in your settings, in Chrome for Android you would say, “Reduce data usage.” I forget exactly what the label is on the check box, but you check it, you turn it on and what that does is it sends this signal as a request header. And it’s a request header that’s called save data and it only has one token and it’s just on. Because if it’s off, the header just doesn’t get sent. And you can… on the backend, at least, you can look at this header and you can decided, “Well, do I really need to send the styles and the JavaScript for this carousel or can I render this differently?
Jeremy: Or maybe you start thinking about stuff outside of JavaScript where maybe you send lower quality images. There’s a lot of opportunities there to reduce data usage. This is evolving though, save data is still around. And I think it will be for the foreseeable future, but now we’re converging on a media query called prefers reduced data. So we have stuff like prefers reduced motion, prefers color scheme, it’s sort of in that vein where I anticipate that these will be operating system level settings that we can make to say, “I really want websites or apps to use less data with this signal.” And you can match it on the client side, with the prefers reduced data media query using match media in JavaScript.
Jeremy: So then you can use that in JavaScript to say, “maybe this functionality isn’t the most important thing. Maybe we don’t really need to load this associated video embed if the text serves the purpose.” That type of thing, but it also converges with the save data header, at least this is what I observed is when I turn on the save data feature in Chrome for Android, the prefers reduce dat: reduced media query matches, but it also sends save data so you can still act on this on the back end or the front end.
Drew: That’s nice. So in a sort of app context, you might feel.. rendering a big data table, you might only return some very key columns. Out of that, the most commonly referenced, rather than the full data and really sort of reduce the amount of that’s sent over the wire.
Jeremy: Right. Or you might say… you might pull APIs less frequently in JavaScript, that type of thing. It’s kind of a hack need phrase, but it really is limited to your imagination. There’s a huge space where I think that concept can be applied to deliver better user experiences. And I’ve used it with a client of mine in Wisconsin. In rural Wisconsin it’s just like… it is an internet dead zone. Like it’s so difficult to… I don’t know how people cope with how slow it is. Maybe it’s just because of my data plan and I might be roaming or whatever, but I’ve used this to some effect to say, “You know, maybe they don’t need this carousel.” Somebody who’s just kind of out there in the sticks who… there’s a lot of farmland in Wisconsin, but there’s also like a lot of forests and somebody might need some work done in logging, right? It’s a logging company. And so maybe all of these images, aren’t really crucial to that user experience. And they really just want to get to… the phone number or whatever it is, and they want to get to it as fast as possible.
Drew: One thing many of us do is write JavaScript in sort of new shiny versions of VS script and TypeScript sometimes, and then use build tools to transfer that down to older syntax for browsers that encounter out in the wild. In some ways that feels like an excellent practice because we’re building a code base with nice more modern clean code. In the case of TypeScript, perhaps more reliable code, less bugs. But are there consequences of doing this transpilation process that we might need to be aware of?
Jeremy: Anytime you take a new syntax and you have to transform it so that it’s more broadly compatible, that’s going to generally… I have not done this comprehensive audit of all features, but generally I’ve observed that, that results in more JavaScript. And that makes sense because for things like default parameters on functions, which are well supported by the way, and probably you can ship… I think you could probably just ship that on transpile and be fine, but it’s a good example. When that gets transformed, it has to inject a lot of helper code in the function to look… to evaluate those defaults, right? So you get that equivalent functionality.
Jeremy: Now, JavaScript is evolving all the time and I think for the time being, we’re going to be coping with transpilation costs. And it definitely does have an impact. When I worked with an e-com company, we were able to reduce several of their bundles for their pages, anywhere between 10%, maybe even 5%, in some cases, to sometimes 30 or 40% when we used a technique to transpile two sets of bundles, right? I talked about this at smashing comp. The name that got kind of got tacked on it was differential serving where you say, “I’m going to generate these transformed bundles for older browsers and serve it to them.” And I’ll generate a different bundle for users on modern browsers or evergreen browsers that will be smaller because there will be less of that transpilation overhead. And when we use that, there was a measurable improvement in the user experience. And there were signals that that engagement was better when we did this. That said, differential serving is an interesting thing because IE11 is kind of now like fading. It’s taking time, but it’s fading.
Jeremy: But Matt Hobbs who works for the UK government. I think he works on the NHS website. I think, don’t quote me on that Matt. But he sent me some data that showed that there was still a fair amount of people who were still on Internet Explorer and not just internet or 11. Like there were some columns or row in this data rather, that showed that some people were still on like IE6 or IE7. And so you have to evaluate when it makes sense to do something like that, because it is a lot of extra work and it takes a lot of effort.
Jeremy: In the case of the NHS or literally any government service, I would say that it’s virtually a mandate that you have to preserve a level of functionality that serves literally everybody, because you don’t know where they’re going to be accessing the web off of, right? The constraints we develop for are incredible, it’s really, really hard. It’s thousands and thousands of different types of devices and I think it makes a in those cases, but maybe not so much for your regular web app, right? It just depends on what the purpose is.
Drew: So keeping on top of the browsers that you need to support and the features that you need to transpile and keeping your configuration and your build tool up to date is… becomes quite important.
Jeremy: Yeah, for sure. This is sort of the more technical part of how you set up tool chains to do this, but… evaluating what your user base looks like is very important, because if a browser kind of falls out of a certain threshold of usage from significant to relatively insignificant, that might be the point at which you decide to evaluate, “Hey, maybe we need to bump things up in our browser’s list configuration, so that we’re transpiling bundles to be smaller since we don’t need to ship those transforms anymore.” But it is kind of like another added step. And one of the approaches I talk about in the book is that you can write your JavaScript one in a couple ways.
Jeremy: You could decide that your style for using JavaScript will be to rely on older language constructs that are natively well supported. Like I think constant let are supported back to IE11. So it doesn’t preclude you from using those types of things, but it allows you to ship less JavaScript. Whereas you… or you could say like the alternate approach might be that you are going to write JavaScript for newer browsers only, and accept that a segment of your users may not have functionality. But again, that depends on the purpose that your website is serving and whether or not it’s crucial, right? Or infrastructure.
Drew: The web platform is moving on that at magnificent pace, it seems at the moment and there seem to be all sorts of things being added to CSS. For example, that offer capabilities that we previously have to lean on JavaScript for. It is one way to use JavaScript responsibly to just not use it and to lean on native browser features instead?
Jeremy: I think that also works for JavaScript itself where it makes sense to use an API directly rather than an abstraction of it. Definitely do that. But certainly in the case of HTML and CSS, there are things we can now do or will be able to do in CSS that we just don’t need JavaScript for. So an example of this would be… what’s the word for it? Truncation of content, right? That’s something that we can do in CSS. Whereas I’ve been in situations or in projects where I’ve seen libraries or a library get downloaded that does that. And we don’t necessarily need to really do that anymore because CSS can handle it.
Jeremy: Or we have access to these layout modes now where we don’t really need. If we invest the time to learn these layout modes like grid, we don’t really need to fall back on layout libraries to handle these things for us. And we can develop these experiences that are unique. And what’s great about that is with layout modes like CSS grid, if they’re abstracted, it kind of reduces what you can do with them, because you are only able to take advantage of what the abstraction offers. And if you really want to build some eye-catching layouts that really like push the boundaries of what’s possible, I always like to point to Jen Simmons, her experimental layout lab homepage.
Jeremy: I don’t know how you would achieve a layout like that if you abstracted it into its own sort of layout library. You almost have to use it… I would think more than almost, you would have to use CSS grid directly in order to accomplish something like that. And that is like zero JavaScript and it’s incredible and it’s really neat. And I think the web in general would benefit more if we leaned more heavily on CSS and other core web technologies, as much as we do on JavaScript, probably not possible, but one can dream.
Drew: So the book Responsible JavaScript is out now from a book apart. And I really like it, it’s full of very practical information. It’s very to the point, you know? There’s not filler. It’s not like reading a recipe online where you have to hear about a trip to Peru before you get to the nitty gritty. It’s just like it’s all straight in there and it’s all very nicely written. Was it a challenge to put that set of information together?
Jeremy: I’ll have to ask… if this is the case, but I Think Responsible JavaScript might be the longest book that A Book Apart has put out, but I would have to go and reach into the closet for my copy of a responsible responsive design to see if I beat out Scott Gel on that, because that was a bit of a book, an awesome book, by the way, it was challenging I’m… As your listeners can probably guess I’m sort of a naturally verbose person and, and, and recovering, trying to like be more succinct, but we really packed in as much as we could and kept it as straight to the point while still trying to retain some, some light lively pros. So it didn’t like sound mechanical, but the result was that the manuscript is like 42,000 words. So it’s a book, it’s a chunk of words and we had a great time working on it. People at A Book Apart were fantastic and, and really setting up those guardrails so that we would be successful.
Drew: And it’s very much a book that you can sort of dip into various parts. You don’t need to read it cover to cover, to gain loads of helpful information. You can just sort of find the bit that’s relevant to the problem that you’re facing at the moment and dive in there. So I think that’s really great about it. So I’ve been learning all about Responsible JavaScript. And what have you been learning about lately Jeremy?
Jeremy: Kind of an ongoing thing that I’ve been doing since it came out is messing with the CSS paint API. I really like the paint API. I mean, it’s kind of always existed in its own…. like in its own way, since like the canvas 2D context has been a thing. Because that’s… for those who are unaware, the CSS pain API is a way in which you can embed a 2D canvas context and parameterize it and control it with CSS, which opens up a lot of really interesting possibilities, like you can animate things that you couldn’t previously animate and that type of thing.
Jeremy: And recently I’ve been doing a blog refresh. That is… I’m a huge Final Fantasy geek, like Final Fantasy II I just replayed and so, there’s like 15 of them and 16 is coming out sometime, but it’s kind of a retro field. So I’ve been using the CSS paint API to generate a random over world using different tiles. So there’s like rivers and stuff that like run through and grass tiles and trees and that type of thing. And parameterizing that so like if the user visits my website in dark mode… that paint work will be rendered as though it’s night. It’ll just have like kind of an overlay on it and that type of thing.
Jeremy: But the painting API is amazing. I got to give a shout out to Tim Holman. He, I saw him at JSConf Australia and he did a talk about generative artwork. That was really just, it really like got me interested. And then Sam Richard, in that at CSSConf the day before talked about the CSS painting API, when those two things came together for me, it was just like, “Wow, this is so cool.” And so I actually did a thing called Paintlets! It’s a Paintlets.Herokuapp.com if you visit and Chrome and you have to, unfortunately, because it’s not super well supported yet. You can see like a bunch of different, random artwork randomly generated artwork and.. yeah, I’ve just… that’s what I’ve been into, sorry. Long tale on that.
Drew: Amazing. That sounds great.
Jeremy: Yeah. Yeah.
Drew: If you, dear listener would like to hear more from Jeremy, you can find him on Twitter where he’s @malchata and find his writing presentations, videos and projects on his personal website, jeremy.codes, Responsible JavaScript is available now from A Book Apart. And you can find more information about that at responsiblejs.dev. Thanks for joining me today Jeremy, did you have any parting words?
Jeremy: Just go forward and build for the web the best way you can and try to keep the user in mind. That’s kind of my mantra and I’m hoping that this book makes that stick a little bit.
(il)