Don't forget to check out our links below! https://ndcoslo.com/ https://ndcconferences.com/
A good case can be made for why boring is preferable to exciting in many aspects of our lives. Yet, we're reluctant to apply this sentiment to the web. Rather, we're in a relentless pursuit of the exciting in this increasingly JavaScript-centric world of web development. A pursuit that, despite our best efforts, litters the landscape of the web with excruciatingly slow and inaccessible pages. As division brews over the roles of HTML, CSS, and indeed JavaScript itself, we need to ask if it's worth making the web boring again.
But why make the web more boring? Because boring is fast, resilient, fault tolerant, and accessible. Boring is the essence of unobtrusive designs that facilitate interactions rather than hinder them. When we rely wholesale on JavaScript to build for the web, we're inevitably reinventing things—things that can hinder or even fail people in unexpected ways despite our best intentions. In this session, you'll learn why building for the web with a greater emphasis on core technologies is far from boring, but truly rewarding and exciting work that makes the web more inclusive.
I am Jeremy Wagner, so a little bit about me, I'm a Web performance consultant, independent performance consultant I. Do on site work or in the case of the Corona Times or the after times, this is it's like this be said sometimes I work remotely as a Web consultant, but the work is still the same. I make websites faster for my clients need it. At least I try to. And I'm also kind of a general web tinkerer, I guess, like I like to put it in an author and apparently a speaker because I'm sitting here at NBC Oslo, which I got to attend last year, and just bummed that I can't be there in person in Oslo. It's a wonderful city and Norway is awesome, but we'll make the best of it. And I think this will be a fun talk. And if you do have questions, it'll be I'll be doing it. I'll try to do a Q&A in slack after the talk. But it may be very asynchronous. I'm actually preparing to go out of town after this or packing to do that. But I will try to get to your questions. It might be fairly late, but as always, you could go to my website. Here is Jeremy that codes. I have a contact form there. If you have a very specific questions. I didn't get you in the slack and you can follow me on Twitter at Malcorra. So, OK. This talk is the live version of an opinion piece I wrote earlier this year by the same name. So if you've read that post and you probably haven't, you might know what you're getting into. But before warned, there's not a lot of actual code in this talk. So if you're if you're wanting to see, like, code and that type of thing, you know, like something very technical and hard like that, please don't don't hesitate to check out some of the other awesome talks and the other tracks. But this is very much a philosophical kind of moulage thoughts and and opinions and sort of observations about the state of Web development today. And so, in any event, I hope you like it. So before I begin and this is this is a little hard for me because it's a little off the cuff, I can't begin this talk. Without acknowledging what has happened in the last few weeks. In the United States, the murder. Well, I know this is spread worldwide, but the murder of George Floyd and countless other black people at the hands of police is unacceptable. And I know we're at a tech conference. And we're supposed to be talking about tech, right? So. There may be some pressure to not be political, but the fact is that everything we do in tech is political, in a political is being political because it prioritizes the status quo over the discomfort of having to confront and dismantle white supremacy. And that is just one aspect of white privilege, something a privilege which I clearly have. So but these times demand that we have these uncomfortable, uncomfortable conversations and take action because the alternative is to stand by while black people are both marginalized and brutalized by systematise white supremacy. And so if you care about this, which I know you do, because you're here, you're you're with it, right? Like you pay attention to things, there are ways to help. And there's a couple. So one is through your your money, many of us in tech are fortunate and that we earn a good living. So if you if you have some money left over after you pay the rent or the mortgage and your Biddle's please donate to causes such as the Black Vision Collective or other causes that deserve our attention as well, such as Reclaim the Block and Campaign Zero to help find alternatives to the to the brutalizing institution enforcement in the United States. And there's also some reading you can do next on my reading list is this book by Ibram can be called How to Be an Anti-racist. And you might have heard it said that it's not enough to be not racist, that we need to be actively anti-racist. So I'm hoping that this book and others on my reading list after this can help me to better understand how I personally can be the person who can actively help to dismantle white supremacy rather than passively perpetuate it through inaction. And I'm hoping you can help others, too, because Black Lives Matter. I originally wanted to open this talk without boring story or an anecdote, but that would be boring, right? So instead, I'll kick off this talk and talk about an exciting thing and how that exciting thing ended up being so risky and destructive that it wiped out trillions of dollars of wealth. So most of you probably remember, you might not in the United States, but you might remember the subprime mortgage crisis, which played out between 2007 and 2008 and had an effect on the world economy as well. Before I continue, I'd like to assure you that this is a talk about web development and not finance, the subprime mortgage crisis was an entirely avoidable economic catastrophe that began with the creation of the mortgage backed security. The mortgage backed security is a financial product backed by home mortgages, it was created long before the crisis ever occurred to the way that it works is a big chunk of home loans get bundled up into this product, which investment banks then offer to investors. And it was generally considered a very safe investment. Most people don't default on their loans. This limits the risk, right? So while returns are relatively modest, they were dependable and so seems pretty boring so far. Right. Here's where it got exciting. When Congress deregulated investment banking in the 90s, investment banks got all excited and the lack of proper regulations allowed banks to offer high risk subprime mortgage loans and sometimes even interest only loans. And then on the investment side claimed credit default swaps, where investors could effectively bet against the US housing market, rooting for and ultimately profiting from the downfall of the US economy. And that is exactly what happened. As the Fed raised interest rates in an attempt to cool things down, adjustable rate subprime loans adjusted accordingly, which spurred defaults on a massive scale. And then markets tanked, taking the economy with them and all because investing wasn't risky or exciting enough already. This is a perfect example of when boring would have been preferable to exciting. If marks if markets and banks had been properly regulated and yielded boringly predictable turns, things could be quite different today. People who were set to retire would have been able to instead of having to rebuild their retirement portfolios, some people would have been able to keep their homes. If it sounds like I'm drawing a parallel to the state of modern web development, it is because I am, but I acknowledge that we are not hurtling toward a comparable crisis with even remotely similar consequences, but we are headed towards something. And the trend doesn't look promising. And part of the reason why this trend persists, at least I believe, is because we're not operating with sensible defaults. And more and more web development has become more like software engineering. And in many respects, this is a logical and welcome progression. But I sometimes wonder if we as Web developers are ready for all the responsibility that that entails. Because rather than evaluating each individual, each individual projects requirements in adapting our choice of tools to them, we tend to dive into what makes development exciting for us. And so to that end, what do we do when we start a new project? We tend to npm install a preferred framework. And then we might install a client side router or that framework. And then maybe even a state management library or the framework, of course. And before you know it, a project has started with an amount of overhead that's baked in until you decide to migrate away from it somehow. That's to say nothing of the code that you will write that rests on top of it. Your preference for what makes development more exciting or perhaps what I should say more convenient or comfortable has forced you to make tradeoffs that can make your app slower, less accessible and less usable. So when it comes to software development, there's a word that I think is very important and that word is constraints. Think of your favorite video games from your childhood, both Super Nintendo games, for example, could fit on a one megabyte cartridge, sometimes even in a quarter of that size. Yet and I and I know this point has been done to death, but it endures because it demonstrates how much can be done with so very little. Yet I don't think it fully acknowledges that the constraints game developers face at the time were far more fixed than ours now. And so when developers may console games, they knew every consumer had the same hardware. Those were the constraints. They were predictable and then they were static and fixed. Our constraints, however, make our job uniquely difficult. People access the web on a variety of devices with wide ranging capabilities such as this affordable but slow Motoki for Android phone. And this is to say nothing of the varying quality of the networks these devices access the Web through. And this is a reality which requires us to make architectural choices that are best for people, because while our tools are convenient and powerful, they do confer an external cost on users that we must acknowledge and attempt to redress in some capacity. And this is relevant because, for example, here in the United States, while many people live in large cities which are more likely to be well served by fast broadband and mobile Internet connections, there are gaps, even chasms, in this coverage that we must be mindful of. In this 2016 article by the MIT Technology Review, it was revealed that fifty eight percent of households in the Cleveland metro area with yearly incomes under twenty thousand dollars a year had no broadband Internet access. These are people who rely on mobile Internet connections, often with data caps to access the Web. Internet access is not a luxury, it is a right one that should be afforded to all communities, not just those that are affluent and statistically more white. And more striking is this passage in which Pew Research found that one third of Americans don't have an Internet connection in their homes faster than dial, and I doubt this has improved significantly since this article was written. The economic and infrastructural challenges haven't been sufficiently addressed to broaden and improve broadband access because as in so many areas of society which are classist and racist, however, in cities insidiously so, you don't divert money to improve the infrastructure of these communities to these communities the same way that we do to more affluent ones. And to me, this is one among many reasons to make web development more boring. And I can empathize with wanting to make web development exciting. It's a big reason why I started doing this stuff in the first place. And when I started, I wanted to do everything. My first experience with making webpages was in a busy week, Ed and middle school. Once I hit the limit of what I could do, I had a thought, which was a little happens when I opened this year, indexed that term in notepad by. And that thought clearly changed my life for the better. I think it's fair to say that I wouldn't be delivering this talk here at NBC Oslo if I hadn't done that. That propelled me down a path. Part of that was because the nature of the Web at that time felt so open and enabling to experimentation. Everyone in our industry has an origin story. And for many of us, that story begins with the making of the fan page for whatever thing we were obsessed with at the time. For me. That obsession was fixed on the popular first person shooter games of the day. The obsession itself was irrelevant, but it gave me an excuse to propel myself down a path of relentless and sometimes even reckless experimentation. I wanted to do everything, I mean everything. I wanted to put every last bit of new knowledge I acquired about making Web pages to work right away and then the most glaringly obnoxious way possible. I still laugh every time I show this slot. It's so excessive. So anyway, in my fervor, I was inspired to make countless garish sites with horrid color schemes, crappy animated GIFs, guest books that no one ever signed wearing that no one ever joined. And then just a little while later, there was flash. Oh, flat three iterations of my personal website were crappy to advance knockoffs or cosmetics and flashy animations, one out literally over any kind of sensibility. And like so many people who started building stuff on the Web when I did, my obsessions were just a conduit through which I developed my skill set. But what I didn't develop, and this is the thing that's difficult to learn only other than through time, but what I didn't develop for the longest time was discipline. And I didn't understand basic design principles, accessibility, performance, user experience or anything that might help me to make websites that anyone might want to use. And this is not to say that anyone's excitement for the medium is ill motivated. I was just inexperienced, but the work that we're paid to do requires us to build boringly usable things. Sometimes that work is the equivalent of building digital push brooms. They're ordinary as hell, yes. But they're also tools that help people accomplish tasks online banking, job applications, buying essentials. The list goes on. And so when our excitement for building for the web is coupled with our thirst for pushing it to do more all the time, we can inadvertently build heavy, unusable things that hinder rather than enable people to complete the tasks our work enables them to achieve. And so. To that end, many new developers these days aren't entering the industry with a decade of learning and experimentation under their belts or even a four year degree. Things have changed significantly. There are people who are both new to and really excited about building stuff on the Web and making a living from that work, and we need these people among us. They're going to be the next generation of developers that brings renewed fervor to this industry. This isn't an experience I can speak to, though, as my path was very different and so were the paths of my contemporaries, I didn't join a web developer boot camp and make a living off of my skills within a year. I had 10 years of unfettered experimentation before I started making things anyone would consider using. Not that it takes you 10 years to get there, but that's that was my personal path. It takes time and continuing education to develop certain sensibilities, though. And because employers favor skill sets that prioritize the fastest ways of building Web applications, that means they're going to hire people who know today's framework. And the fastest way to start getting paid after you graduate is to apply for jobs that match the framework based skills you were taught in boot camp. And so hiring in the industry has become this sort of oral borrus where employers want applicants with with a centered skill sets and consequently developers learn those frameworks to get gigs because hiring managers want to tick off the boxes and get the ship code fast and often. And so in this seemingly infinite loop, framework's become the scaffolding upon which we build our careers, and now this isn't the worst thing that can happen, right? Framework and library specific knowledge can propel you to learn their underpinnings. I never would have went into JavaScript as deeply as I have, if not for the awesomeness that was Jorquera in the 2000s and for all of all of the utility and usefulness it brought. But I believe in a sole reliance on these abstractions can eventually become a limiting factor in your long term growth. Unless your curriculum is sufficiently covered, the fundamentals or you struck out to learn them on your own, you'll always be reliant on the abstractions to do the work. And so front end development has been this way for at least a decade, and if you read the resume of any veteran front end developer, you'll quickly see that it resembles a sort of geologic column of skills this industry has always chased. What's so hot right now and we're set up from day one of our careers to feed into that. Arguably, the worst part of this is that our continuing education in HTML and platform APIs gets relegated to some day or worse after hours where you have to sacrifice some amount of work life balance just to keep up. And not every person has the time to devote in their off hours to do that kind of work. And in my opinion, we shouldn't compel them to, but rather enable them to explore and learn on the job. All of this is ostensibly done in the name of productivity, sometimes at our own peril. I believe this constant churn, as Andrew suggests in his brilliant post, is bound us to a cycle of never ending sight rebuilds and framework migrations that can seem counterproductive in hindsight. Because without careful consideration for which abstractions are truly beneficial for the purpose for trying to serve, being lashed to this wheel becomes a brutal affair where progress becomes difficult to sustain over the long term. But whether it was Jacoway then or react now, these tools are designed to make us more productive. And they do. If we were pressed to admit it, this constant churn is at least in part due to our desire to make work more fun and exciting. It's something I call laptop sticker culture for lack of a better term, and it's something I've been guilty of, where we're everything we do outwardly appears badass or glamorous. And if I didn't know, I would swear that some of us are on tour. And it's also why even in the year of our Lord 20, you will still event, you will still occasionally see job postings every so often with these superlatives like rock star or guru or ninja like should I be packing some hurricanes with my laptop when I go to work? But, hey, why shouldn't our work be more exciting? We're all propelled by our interests. And for you, that interest may be JavaScript and friends can be HTML, could be success or it could be the various abstractions of those technologies. But if you could for a second, put aside your interests and ask yourself what purpose you're trying to serve. When you build something for the Web, what are you helping? What are you helping people to accomplish? The varying answers we give to that question should first should form a curve around which we adjust our philosophy for how we build for the Web. Because if you're in charge of any remotely critical resource in the Web, your desire for a rich developer experience just has to take a backseat. People depend on the Web for more than just buying things. And commerce, the web is is a portal for many critical resources, stuff like job applications, public assistance, crisis intervention and other services that we tend not to think about until we need them. And when we need those things, they should be as fast as possible to facilitate easy access to those resources. Because. Ours is a job done by people or people, farmers might get excited about piping. But they also understand that their job is to ensure that the water gets from the main to the faucet the same as always, regardless of the layout of the house or any other challenges they may face in doing that job. Hex pipe confers a material improvement for both the installer and the end user without hampering functionality. And we consistently say the same thing about the conveniences that we rely. Data flows through pipes of sorts, but the environmental constraints imposed on us by the network, the devices people can afford to use and the social inequities that factor into all of those things demand our most careful consideration. Factors like network bandwidth and latency are evident, but others, such as server protocol and device capabilities are more subtle. And then more importantly, there's the person holding a phone or a tablet or behind a laptop, each of which is an individual case study capabilities and limitations that demand our attention. So knowing this. It's important we avoid one assumption, like the plague, that our conveniences always confer equal benefits for users. Your enthusiasm for virtual DOM frameworks probably doesn't benefit somebody who's been thrown out of their home by an abusive partner when they turn to the web to find shelter and resources to help. Someone trying to find public assistance, information or or apply for a job on spotty Wi-Fi isn't helped by your client side router. Our conveniences have a time and a place, and that time is not always every time, nor does that place always everywhere. And I'm not shaming anyone for their choice of choice of tools as someone who enjoys the tools that he uses, but to stress that simply using them won't do the difficult work of creating and maintaining good user experiences for you. And as developers are, ethical duty isn't limited to identifying and removing excesses in code. We also need to challenge excesses which may look nice and design cops that only serve to frustrate people and practice excesses in design and development are necessarily intertwined. Because every interaction you simplify, every boondoggle you can remove represents a benefit to the end user. So to me, that's a compelling argument to make things boring. Because the Web is frustrating when it creates obstacles for people. Obtrusive Nissim websites are the result of every project manager, designer and developer unable or unwilling to challenge ill-conceived business requirements, design decisions or architectural choices. Josh Clark wrote an article about design systems some time ago, and what struck me was his emphasis on the role of Oring in UX. He discussed how when he helped his clients to create better design systems, he stressed the importance of simplicity. The more common the problem, the better design systems should prioritize the mundane. And in a world where it feels like everyone wants to disrupt everything without considering the consequences. This seems like sage advice to me. Avoiding intrusiveness in design is the very is the excuse me, avoiding abusiveness in design is the very soul of designs that work best for people. And so without acknowledging that, we can only create fast, accessible and usable websites entirely by accident. A perfect example of obtrusive design was a little known visualization project developed by Apple's research division called Hot Sauce, which was an attempt at visualizing site maps for website. Instead of presenting this data in a straightforward way, perhaps as an ordered list, it was presented as a 3D spatial field. Now, to its credit, Hot Sauce was a novel presentation of this data, and it was a fun experiment. But people who used it considered it disorienting. No one really wanted to browse a spatial rendering of a website's hierarchy as if they were on the holiday. They wanted a boringly predictable way to access that information. Examples of obtrusive design as they exist on the Web are quite different now. I don't know about you, but I don't even like one hamburger menu, let alone three of. And so it's not excitement that produces patterns like this, but a sort of unwillingness or inability to address the unsustainable growth of an application over time. Eminently usable designs in architecture as a result when simplicity is the default. It's one of the iron laws, it's why Unstyled TML works, it's so beautifully solves the problem of presenting documents to the user that we don't consider all the careful thought that went into its jaw. Achingly boring presentation. Now, I'm not. Don't misunderstand me. I'm not holding a torch aloft and demand we transport ourselves back to nineteen ninety four. That would be absurd and it's antithetical to the spirit of progress. But I do think this ideal is something that we can carry into our daily work, especially when more websites are consumed as web apps. We can make apps more resilient by adhering to semantics, platform solutions and progressive enhancement. As it stands, we're accustomed to serving heaps of Divx burgers on silver platters of JavaScript that not everyone can access and all the places they may need. Accessibility advocates aren't lecturing you to use semantic HTML because it's so much fun you're going to pass out, but because it's well understood how people benefit from it. The built in functionality you get from those semantics allows you to travel later, you don't need to build or install accessible alternatives. Does this mean your choice of tools are in direct opposition to the goal of creating good experiences? I don't know. It depends on how you use them. It depends on the problems they solve for you out of the box. It at least requires us to understand the tradeoffs that we might be making if we use them. So we need to bifurcate our focus on what we learn. Yes, we should learn frameworks and abstractions. They're very useful, but we also need to learn the platform APIs that serve that serve as their foundation so that we can adapt as the wind shifts. The long term health of the web cannot be sustained if we ignore what the Web platform brings to the table solely for our own. So underscoring the importance of those fundamentals is the fact that we're wired to want things to be boringly predictable, we not only want it, we expect it, and we subconsciously demand it. When things are predictable, they embody the expected qualities of the essential. We do not want any surprises with the plane's landing gear as we come in for a landing, that is not fun or excitement that anyone can get on. This is an example of a critical fixture and some of what we preside over as developers are also critical fixtures in their own right. Those fixtures especially need to remain fast and accessible. Part of getting there necessarily involves using HTML and platform APIs to reduce overhead. And so. If your reaction to what I'm saying is to assert that this is morning work that users will find boring, then I must viciously retort with the emergence of reader mode features that exist in several browsers at its core, reader mode reader mode is just a boring mode toggle that strips away scripts and styles to distill a page down to its core content. People are so tired of grappling, stuttering, JavaScript laden pages that they will gladly strip away everything exciting to get to that crucial nugget of content more easily. And still, your mode won't work everywhere, and nor should we expect it to. Its intended application is for written content like articles, not rich applications. Solving human problems does require a human touch, after all. And so to that end, we are wired as human beings to want external consistency, which is when an object's function in a recognizable appearance is reinforced by other similar implementation. Imagine a house with no external consistency. We're turning the knob on the stove, changes the television channel. As Eric Bailey notes and an article analyst apart that he published last year, which I would highly recommend to you, browsers themselves are flush with examples of external consistency, and we would do well to ensure that we don't break those externally consistent behaviors. Now. I am fully aware of the danger of saying this at a Web development conference, particularly in a very JavaScript dominated landscape, but one of the most common subversions of external consistency in browsers is the single page application or. My personal inclination is to avoid building sites as Aspies. Now, this isn't because I hate them, but it's just that the behavior they replace is an established one. That browser's already do very well. And so when we decide to take on the task of implementing that ourselves, we're taking on a lot of unnecessary responsibility in most cases. Al browser's navigate from page to page is part of a specification arrived to after a deliberative process of debate and consensus. And in my opinion, it takes a whole lot of courage with just a dash of hubris to assume we can do this better than browser's have done over the last twenty five years or so. And. When a client side router is used, accessability may become a casualty in that there's a whole host of things that we end up reinventing or may miss altogether or may not be able to compensate for. In some cases, history must be managed. Tab, index and scrolling position must be accounted for. Navigation cancelling can fail. What happens if Gaspé if the client side router doesn't load for some reason and you don't have server and the list goes on and on? Even if we get client side routing just perfect, there's another problem that we then have to grapple. Which is when we neglect to send server generated markup in favor of rendering everything on the client, which is also computationally expensive, an app's contents are not only inaccessible if and when JavaScript fails, but loading performance suffers as well. We serve content from the server, sure, we lose some of the snapping this after the initial load, but we retain the external consistency that people have come to expect. And this is not to say that we can never use client side routers, that they're filthy, awful things. If you provide server side versions of all of your client side routes, people will have a way to access any part of your site from any contacts. And then if only the components that require stateliness on the client are attached to that server side markup through client side hydration, people will get a progressively enhanced experience. And that gives us freedom to try different things. Perhaps only the authenticated part of an app is an SBA or this is just something that I've been kind of tinkering with a little bit. Perhaps client side routing could be opted into as an app setting, ensuring that it only happens when people want it to. As opposed to assuming that it's a sensible default for them. Which brings me to my final point and eventually the end of my talk, but we're not quite there yet. No tool or any amount of automation will ever be a perfect substitute for a human being, which is finely honed over years of experience, solving human problems and solving human problems requires that you accept that humans have limitations either inherent or imposed. And it also requires you to accept that the tools you use can fail you and your judgment is necessary in those situations. Now, let me tell you another story. This is Stanislav Petrov, he was a lieutenant colonel in the Soviet air forces during a dangerously tense period of the Cold War. And when he was on duty in 1983, a brand new Soviet missile detection system reported that five nuclear missiles were launched by the United States and on the way to Russia and. Reason and no small no small amount of intuition, he was convinced that the system was wrong. In the moment, he concluded that five missiles was illogical because a US strike would have been all out, so he did not inform his superiors and therefore a retaliatory strike was never authorized. He turned out to be right. The system was wrong, turn it out to be sunlight reflecting on clouds above North Dakota, which triggered a false positive in the missile detection system. And while we'll never know all of the factors at the various levels of command in that situation and what how that could have played out, it's not unreasonable to speculate that his decision to disbelieve the tools at his disposal and trust his own judgment may have averted a global nuclear war. Now, obviously. No JavaScript engineer in this room will ever be charged with such a perilous decision. I hope not. I hope launching a warhead is not something that in just on JavaScript. But I think it is a great lesson about how the tools we depend on can still get things wrong. Some. And if that wasn't the case, every GitHub issues page would just be a ghost town. Thousands of stars, no issues, everything's perfect. So. It's on us to realize and own up to our responsibility to people, as well as how our preferences as developers and the needs of real people in intersect in a way that is mutually beneficial. Knowing where that intersection lies involves realizing that while while inaccessibility inspector can tell you what semantic elements you should use, knowing why those elements are preferable to a divorce suit is just as vital. It's also realizing that, yes, while you could install the layout framework, such problems are best solved by relatively new and widely supported CSFs layout modes such as flex box and grid. And in fact, if you want to create layouts and web pages that really catch the eye and push the boundaries far beyond the ordinary, you need to rely on these new layout modes. You can't just keep kicking that bootstrap can down the road, because not only is the overhead of such a layout framework onerous or potentially onerous, it's just not where the web is destined to go, nor will it allow you to access the full power of these new layout. And this is a side note, but if you're a JavaScript developer and you're in an organization, you're having trouble understanding this or understanding access, that's fine. Not everyone is is similarly able in their abilities. But there are people who do this work who work with success and understand these things. And they're called UI engineers. And if your organization needs one Aikawa, trust me, it's it's worth it. And so for all of my whinging about the evils of JavaScript and all the sinful excitement in it and its framework Bretheren bring, I firmly believe it has its place. JavaScript is great. It's given a lot of us a living, and I'm really thankful for it. But we do need to consider rebalancing our use of it against other parts of the platform. JavaScript is most resilient when we use it with progressive enhancement in mind, that is to say, when we build a baseline that everyone can benefit from and then just add that little bit of candy coating to enhance usability, usability further for those who can benefit from from it. We're not just building better user experiences, but more inclusive ones. And that, to me, is like the really good work that's worth doing, because exclusivity is not just something we should make room for at conferences, it needs to be part of our daily work from from front to back. And so if you care about the Web, as I know you all do, because if you're here, you definitely care, you'll come to find out that this approach to our work isn't boring at all, but really very rewarding. So we have two objectives as developers. One, work to make things better this week than they were last week and to continue our education to ensure the success of the first objective. And I genuinely, truly believe our work can never be boring so long as it helps us to deliver on these objectives in the spirit of making the Web faster, more accessible and therefore more usable and inclusive for everyone, everywhere. Thank you very much.