 So we begin. When we're building websites, we would love to use tools. I use something to watch my files. I use frameworks. I just use this mountain of tools. And the thing about tools is that typically they're like so far in front of the platform that we're building on. So I use a library to select DOM nodes, and that gets around the fact that different browsers have different implementations of how to get elements by IDs and classes. And I use things to compile other things, and it's great. But if you imagine your tools as a boat. Yeah, but you've got cars on the screen, right? Yeah. Just go to the next slide for me. If we imagine our tools as a boat. Oh, that's beautiful artwork there. Well done. OK, and the platform is this slow boat that's sort of behind. And this fast boat has an anchor, and it's kind of like just full throttle going ahead. OK, this analogy I don't like. You drop an anchor to stop the boat from moving, right? No, no, it's a sea anchor, you know? The sea anchor. Anyone know what a sea anchor is? Obviously a sea anchor, because everyone knows. We'll just tell them that. It's when there's a storm, you put the sea anchor in. It keeps you pointed towards the wave, so you don't tip over. Sea anchor. But you can still move the boat with the anchor down. Yeah, sea anchor. Right, OK. Tooling is the boat. Platform is the anchor that pushed your moving, got you? OK, all right. So in this analogy, which is really solid, if you ask me. Speedboat. OK, these tools are racing ahead. But the cool thing is this anchor, sea anchor, as we know, hashtag sea anchor, it's good. It eventually catches up where the boat was at one point. So the platform catches up to where the tools were at some point, and that's good. Yeah, and it can happen super quick as well. So we all know ES 2015, right? Yes? Yes. So a year ago, we would have been looking at something like this. So this is the feature set list across a whole range of browsers. I think the top one is about 68%, 69% of feature completeness in Edge and Firefox. So realistically, if you wanted to use this stuff in 2015, you needed something to compile it. Yeah, I mean, there's a lot of red. Yeah, it's not good. I'm a fan of the color red, but it seems like if I wanted to use arrow functions, ray destructuring, et cetera, insert, feature, feature, feature, feature, I would have had to use a tool that would turn that into ES5 or lower. Yeah, you wouldn't need a bay ball to just. All right, I got it. I'm in 2015. OK, that's the state of things. Now it's really nice. It's green. So now you're looking at well over 90% across all the browsers. So you don't actually need that tool that you had before. You can just run it in the browser now. Yeah, right, I can open up the DevTools console and type arrow function and be like, it just works. It just magically works inside of DevTools. I don't have to pre-compile. I use ES2015 or ES6 as it was known in 2015, which is weird. The issue was ES6. But I don't have to use a tool to compile. Yeah, that's the point. In the space of a year, we had one tool we had to use. We needed to rely on it, and now it's not needed. So my name's Matt Gaunt. I work on the developer relations team for the web. Can we do that again? I feel like I did not get to know you in that introduction. You didn't get to know my soul. Very boring. Can you do it again? OK, my name's Matt Gaunt. I'm from Britain. I like my tea in the morning with a little bit of milk, no sugar. Wait, milk? Builders' tea. Yeah, a little bit of milk. You put milk in your tea. But that's how you do it, Sam. Seems a little strange. Oh, strange. My name is Sam, and I like my tea in the morning just with nothing, just a tea bag. And I just like it where it's really hot, and then you burn your tongue, and then I'm really awake. So that's how I like my tea. I don't want to use the word masochist, but it feels right. No, you're just really jealous of my life hack. Super jelly. So this talk was something that Sam kind of concocted in his head to a certain degree. I'm here to balance it out, I think. Yeah. Yeah. So I can relate to this reality of web development. See, I don't think you can, but you're going to say you do anyway. So we're in this world with the reality of web development, and we use a ton of tools. You have your watch process, your compile process, et cetera, et cetera, et cetera. And things are fine. And this is how things have always been, just more and more tools. And so you're working on your project, and it might look something like this. Like I made a teeter totter, and I like this a lot, tools, platform. And every time we add a tool, we get further and further away from the platform. So you know, you're using a framework, and you're compiling your JavaScript, or maybe not JavaScript, some other language, two JavaScript, and you get an error in your code, and there's like a fog of war. I'm playing a video game. I can't see what's in front of me. It's just this huge call stack error. And I'm like, where's my code? Where did this error come from? And that's the thing. Like we add tools, you get further and further away. There's more abstractions between you and what you're actually trying to compile to, which is the platform. So it seems like a bad thing. Yeah. So the point you're trying to make is the fact that we have all these tools, and it's kind of abstracting away from the platform. That is the point that I said. But I'm glad you repeated it. Thank you. So the reason I'm skeptical of this talk was sound. And I use the word skeptical to be polite to him. You said something a lot nastier the first time, but that's fine. Skeptical. I like that. That's better. Skeptical of my ideas. Yes. Because I looked at the past couple of projects I've been making, probably for the past year or so. And when I look at that, the first thing I do is even take a Gold Bill process or something that I'm used to using in the previous project and moving it over into the new one. That's what I do. Or I'll take something like Web Starter Kit, which comes with a pre-built process. Yeah, you have the tools in there like to compile your JavaScript, to compile your SAS or something, and the responsive break points. But this is like the Web Starter Kit. So can I order this from a catalog and then I can build the web? You know what? If you send me a check, I will send you it in the post. Yes. So I can build the full web with this? Yeah, the whole web. I promise it'll be the web in a box. That sounds like an awesome kit. A little LED that blinks on top and everything. But this is how I start it. Wait, Matt, you have commits in this too, right? So are you just bragging right now? No. You're like, I'm selling yourself. You're like, my name is Matt Gaunt, and you should use my tool. I see. I see what's happening. That's a beautiful impression of me. Thanks, Sam. I worked on it. But the point I was getting to was, this is how I start it. I end up using these tools. I come to know these tools, and I come to love these tools. So this is just how I create projects. And to go back to the previous point of like Babel, you don't actually need it if you want to run something in the browsers today. And it kind of comes with this weird side effect, right? If you're going to pull in all these tools from the first thing and you run npm install. Well, that seems really fast, though. So that seems fine. Oh, this is gif time, by the way. This is about a minute and a half. And I've sped it up because I figured you didn't want to watch paint dry, right? Is that another module, gif time? Can I install that to speed up my npm install? I wouldn't be surprised if Cinder has a module out by the end of today. Gif time. Gif time. I like that. That's good. But this is the weirdest thing, right? We start our projects by installing half of the internet before we even do anything. And yet, you think of when we start the web, this is probably what we all know and love, right? Yeah, I mean, I remember this. I remember I think I got a book or something and I was like, I'm going to make a website. And so I saw that I had to open these tags or something's words. And then I said, OK. And then I had to look on the keyboard. I was like, OK, where's the hungry alligator and the not-so-hungry alligator? I genuinely hope you write a children's programming book. And that's how you explain it. Seriously, that's a good idea. So once I figured that, and then there was a slash that was the opposite, forward, backslash. But it looked forward. I didn't understand it. But I found it. So OK, I pressed that. I saved it. And then I went to my browser and I reloaded the page. And I saw my website. And then I could go back and type in some more alligators and then reload. And then I had this awesome developer workflow when I was like eight. Live reload, no tools. I didn't have to install anything. It just worked. And this was awesome. But as you pointed out, we're in a really bad state in comparison to this. That's a nice way to put that, bad. Yeah, sure. Terrible, maybe. It's a different way. Different. There we go. Sure. So that's the premise of Sam's talk. Yeah, he wants to get back to the eight-year-old Sam. So let's suspend reality for a moment, as I think any of my ideas require you to do. Yeah, you don't really live in the same world as us, do you? No. So we're in the suspended reality state, and we are going to go all in on the platform. All in. We're going to not use tools. We're going to just use these platform primitives, these really powerful things. Well, we don't even need to suspend reality to do this. Like, we've seen this kind of stuff happen in the past, right? Yeah, time and time again. And I think everyone can relate to, I know you want to be your favorite things, rounded corners. Yeah. Like, I had a sweet way of doing this. So it's 2004, and we are in the state of suspended reality, and I am your client, and you are going to make a button for my website. Obviously, Sketch existed in 2004, right? Well, obviously, vectors were so hot in 2004. But you'd start off, you make your image, and you're like, cool, I got my rounded corners. They're sweet. Then you cut it up, and you only need one corner, and then you've got the reproducible bit. Seems good. You do the right thing, and you create a sprite from it, because you want to be efficient with the reproducible. How many slices do you have in that? Like, nine slices, right? Oh, I don't do nine slices. That's too new school for me right now. But you've got to drop it on your page. Obviously, I'm using tables. 2004, yeah, that's what you've got to do. You've got your CSS sprite sheet. You pick out the bits you want, and it's awesome. It scales, and oh, look at it. All right, so you delivered your button. I'm not so happy, though, because I don't like that color blue. Can we change that to red? I really like red. That's fine, but I've got to start again. OK, while you're in there, I was looking at this on my phone, and it looked kind of blurry. So I think that my phone screen is better than my computer screen or something. So can I? Maybe your phone's broken. No, I think it's just more pixels. No? No, it works fine. That's fine. We've got pixel ratio. We can do some JavaScript fun, and then maybe make a second sprite sheet, and then we've got one for the one X. OK, and while you're in there, you know, like my users have been complaining they don't really know that they can touch on these buttons, so can we make it? So when you hover, I get a drop shadow, but then when there's a drop shadow, I'm going to use a bunch of different backgrounds. And so that background needs to blend in correctly with all these different colors. Can we make that work? No. How about no? How about your designer just doesn't force me to cry at night? Well, I am a great client. All right. Well, as the web platform sort of identified, people wanted these rounded corners. Yeah, and obviously, spec authors came and saw this, and it was a regular pattern, and it was painful. So they came up with a solution, right? It's CSS rounded corners. To go with the angry, the alligators. CSS rounded corners. That's what it was called? Border radius, but yeah, fine. It's not CSS rounded corners. You use CSS to run. Equals border radius. Border radius, right. So border radius kind of emerged. There was this desire from the community to be like, hey, we want to do these rounded corners. And then how do we as a community respond to that? Well, we said, oh, like flat UI is way in, so rounded corners are totally lame. Thanks for the present of the super awesome thing that's a little bit too late. But the point we're trying to make here is ultimately, there was a gap in the platform. Matt, did you draw that? Oh, yeah. OK, I'm picturing myself standing at the precipice of that gap. Yeah. And all I can hear in my mind is, please mind the gap when aligning from the station. I've been teaching him how to say that over and over again. I watched the videos. I got a lot of those. They don't have those in the New York subway. It's just kind of like, get off. Please mind the gap when alighting the trains. Anyway, there's a gap in the platform. We wanted rounded corners. It was insanely painful to do. So we, as the web developer community, do what we do best, and we made a tool that we found a way of doing it. That is a nice rubric. Did you draw that? I've got to say, my Photoshop skills, the day I made this, was top. OK, so we have this rope bridge, and the rope bridge in this case was Photoshop or some image editing program to do the slices. So as a community, we hear these tools and these methodologies how to do this. OK, I'm with you. Cool. And then we got board of radius. So the platform is providing us a nice road. Another bridge. That's a good bridge. Like multiple four structures. Platform. OK, the platform is like border radius. Great. Here's the solution. The platform came in. We didn't need tools. Things were awesome. I'm going to say, if you're sick of this analogy by this point, I just leave. No, I'm joking. I'm joking. But this is the point we're trying to make. And we keep on seeing this pattern over and over again. So let's say something else. Oh, SAS. Pre-processors. Yeah, because we're better to be a programmer than in your CSS files. Dude, with clients like you that want to make changes every five minutes, you can't blame us. So love you. So obviously, I still use SAS. I still love SAS for the fact that CSS variables and mixins and stuff, I need variables and mixins. And this is literally the penultimate reason of why you SAS, this bit of the top, background color green. It would help if this worked. Seems like you have a syntax error in your style sheet. Sorry. That's a terrible demo. There we go. It's good. I can't even do simple codes. But the point is, this is basically all I want it for, is a variable at the top that's just background colors. Whenever I want to change it, I can do. And then we've also got mixins, which again, I still love. That include rounded and then boom. That's just a mixin, so I can reuse it everywhere. OK, so you have variables and you have this idea of mixins, which lets you reuse chunks in multiple places. Seems like a good thing. So is this a gap in the platform? And there's a tooling solution. Wow. OK, I'm with you. So now we have CSS variables. The platform is caught up. So a variable just starts with dash dash, got background color red. And then at the bottom, we've got background. And we're just using the variable name. And the cool thing about this is we have JavaScript access to these variables, so we can change them on the fly, right? Yeah, and then it'll just change all of the references as you're going along. That seems pretty useful. And this is spec. This is in browsers now. Like, there's nothing going on here. It's just working. And there is also an early spec for mixins as well. So here we've got the rounded mixin. Super obvious what it's doing. But at the bottom, we can do atapply. And it's this atapply draft spec that's basically saying this is a kind of solution to mixins that we've been seeing from other CSS preprocessors. OK, but this is even better than what SAS was doing, because instead of inlining that code everywhere I use to extend, what this does is it just points a reference to that mixin, right? Yeah. So I can actually ship less bytes to my user, which seems like a OK thing to do. And PS, I just want to applaud you for your use of a pink color, because it's better than blue. I think there's something more to applaud here of the fact that I haven't enabled the web platform flag in this instance. It's on your machine that does it. Sorry, folks. This is actually in Chrome, believe it or not, but it's behind a flag, because it's a draft spec. But it's going to work. I still like it. It's nice. But again, the point we're trying to make is, it was a gap in the platform. We had these tooling. There's an off-ramp here, where we don't need to use it anymore. So I think people are sort of getting where we're driving at. Yeah, but OK, so I saw that I have some CSS things, but I'm a programmer, and I want to see some JavaScript things. You want to see some JavaScript? Yeah. OK, well, how about XHR? Can you write an XHR off the top of your head right now? Yeah, totally, I'm a programmer. I mean, you. Yeah, let's just do it. It's fine. I get it. You're challenging me. I understand the reality of web development, so XHR. OK, so let me just get into the headspace. OK, I see it. So we start with XML, all capital, because XML is capital. And then there's a capital H, then TTP. Capital H, the rest of the case. Request, OK, XML should be request got it. And then we pass the URL in. We need to open the socket. Open, you've got to pass in the get post, the URL. Then you need listeners. I don't remember what the listeners are. OK, I can't do it. I'm sorry, I forgot. OK, well, how would you do it? Well, I just use jQuery, like dollar sign.get, right? Of course you would, because, yeah. Man, I like that you quoted yourself. Well, it's actually a retrospective one. What I'm saying is jQuery, the number one answer on Stack Overflow. I just quoted myself. But wait, you didn't say the dash or the pound symbol or the asterisk? I hate you so much sometimes. But the point is, the Sam's Getting app is jQuery is super nice, because you can just do something like this. It's all awesome and happy. Yeah, so the community created these libraries that got around the craziness of that XML HTTP request thing. And they were great things like .get, .post. And then if you were really hardcore, you'd just use dollar sign.ajax. Drop down right to the bare metal. Dollar sign.ajax. I love that. The other side of this as well, and the main reason I say jQuery is the number one answer on Stack Overflow, is the fact that it's got tons of extra functionality as well. We can't knock it. Things like .map.each. Things that the JavaScript spec world didn't have until 2015. Well, but with each and each and map, they flip the iterator, the i, and the value. So you had to remember to flip it back when you were going in between them, right? But yeah, sure, sure. Why do you hate it so much? I'm just pointing out, like, you're saying wrong things. But anyway, jQuery solved a gap in the platform. It was a great tool. All right, so when does the platform come in? On the nice road? On the drive my car over? Let me drive it. Do you drive? Who here has heard of fetch, the fetch API? So the fetch is basically super similar to jQuery. So fetch, this is it. You're going to make a get request. Returns of promise, which means you can do some happy promising. And jQuery returned a promise, like a deferred thing. But it was like a promise. So OK, this feels very similar to what the community had come up with. We have a dollar sign.get. Now it's turned into a fetch that returns a promise that gives you a value that you have to call JSON or text and handle the stream. And then you get some value. OK, great. That's a lot better, because I can type fetch. I can't really type XMLHTTP request. Seems better. That's how I typed, just saying it. OK, this is great. But one of the main things to point out here is that with jQuery, you're kind of tied to jQuery, right? You rely on the dollar sign, if the dollar sign isn't there, everything goes, well, it just doesn't work. It doesn't go anywhere. So it's kind of this weird thing. We use jQuery, and we should, because it made our lives easier. But when the platform catches up and gives you something comparable, it should really be the preferable thing so your code just runs wherever you want. And since fetch is a JavaScript thing and fetch isn't a reserved word, we can just polyfill that and it should just work. But since we're talking about retro things, we're talking about jQuery, and I haven't used that in such a long time, I want to go further back in time. I want to go to the year 1997. Think, Sam, you would have been eight? Eight, good eight years old. I would have been about nine. I think I would have just got my Nintendo 64. I had it for a year. I was really getting good at GoldenEye by then. It was nice. You used to race me and Mario Kart on whim because you cheated by playing so much more before I got mine. Yeah, OK, so 1997, I'm there. I'm in that headspace. Awesome. And this was a time where everything was much simpler. JavaScript was used for sparkles on your cursor. Well, Brendan and Ike was like, oh, I'm glad you guys finally figured it out. JavaScript's true purpose was to add sparkles behind your cursor. I don't know how Brendan and Ike would feel about that, but sure. He's fine with it. But it was a peak for JavaScript at this point. Yeah, definitely the peak moment for me, at least. But some other people that were building websites were like, hey, these sparkles are really awesome. You know, it'd be even better if we fixed up, like, our forms so we don't have a gigantic table of input fields that I have to fill out and then hit submit. And then hopefully we don't get like 500 from the server because I filled the date format out wrong. Maybe we could give some feedback to users. There and then in the page, rather than just use it as a document. So what did we see the community sort of do? There was this desire from developers to have these kind of rich widget primitives. And so people came in, like, hey, I'm going to make jQuery UI. I'm going to make Dojo. I'm going to make YUI. And I'm going to create these primitives, these JavaScript primitives, but still, like, these really powerful widgets and knobs and dials that make the web awesome. It was ultimately something that every developer wanted. They wanted to be able to make these rich components because there was no alternative on the platform. I don't know about you, but I pulled in that date picker, I think, on every single project. I was like, well, I guess I'll pull in all of jQuery UI and the whole theme files and everything. And just I have a date picker, though, so it's worth it. It's awesome. It was a really good date picker. I'm pretty convinced this is still the number one thing that I'll see everywhere on the web is the date picker. But you love the accordion. You're like, I have an awesome website. That's actually the only memory I have of jQuery UI. It's just like, I wanted it for that accordion. That's sweet accordion. Your whole website wasn't accordion, actually. It was that good. But let's take an example of a Dojo component. OK, Dojo. So this was like, you could create a little counter widget with this. But what I find fascinating about this markup is that if you squint just a tiny bit, you can turn that into a web component. Done. All right, web components are this new thing, relatively new. And they're basically the platform's answer for these primitives, these awesome little components that give you lifecycle events like when I'm attached, when I'm detached, when an attribute changes, which is basically all you need to create something awesome. So we have created our fancy counter web component, which what I love about this is Dojo had this idea with attributes. And we would basically use the DOM and then progressively enhance the DOM into a component. And web components come in and says, OK, well, let's just make that standard. So you can define your own tag types. And you can just put in your DOM. And things are instantiated. And that's really good. Yeah, because ultimately it means if you wanted to share that component, you just share it. By someone taking on that component, they aren't suddenly taking on all of your tooling or whatever other decisions that you've made along with it. So the platform came in and standardized and created this new primitive for us. Yeah. So we're kind of in this scenario really for a lot of these tools. We have a tooling bridge because that was the first way we did it. It's how we showed we had a desire or need for something. And we have this platform bridge right next to it. The interesting thing is everyone's still kind of using the tooling bridge. Still, everyone is using the tooling bridge. When I started a project, I have a gigantic NPM script that I run and watches everything and compiles it and moves all my files around and runs Lint and reloads my browser. I have this huge tooling bridge. And I just sort of ignore the platform bridge because forever it never existed. So there's kind of this interesting dichotomy. Because if you take something like border radius, we had that tooling. It was so painful that we basically burnt it, right? I don't think anyone in this room would ever go to Photoshop just to get that effect. So we should be doing this for every single project that we start is going, do I actually need this tool or has the platform given me something equivalent? But since we're in this state of suspended reality, we're just going to take the platform bridge. Yeah. But there also comes another point of we're not in suspended reality, right? I have to ship stuff to people. All right. So if you're saying, I work on a real project, though, Sam, and what you're saying doesn't make any sense. I like how you're making me sound unreasonable for that. Well, yeah. That's the right way to do it. It's kind of a trick. I hear you. So let's take something like border radius. We all know that we've burned that bridge because, hey, guess what? Support's really amazing and it doesn't matter. But if we take some of the other things we talked about, so CSS variables, oddly enough, it actually has pretty good support in all the browsers. I think it's just IE and Edge that would probably be the one that would put me off. So now I need to worry about how do I support those browsers? Because if CSS variables don't work and I'm relying on them, that's not going to work too nicely for them. And then if you take something like Fetch, it's even worse. Like it's Firefox and Chrome that has it, none of the other ones. So I still need a solution for this stuff. And normally, this is the reason why we go for tools. We want that wide support, but at the same time, we don't need it in the browser we're developing on. But what I've noticed about these charts that I think that's interesting to take away is that Chrome and Firefox and these newer browsers have support for these features today, which means that as a developer working on my website in my developer workflow of 2016, title drop. That's good. See what you did. We can use these things. So in development mode, I'm just using these primitives, and I don't have any tools running. You don't need to compile anything. It's back to the notepad days. So what I think you're trying to say is this. Wow, that's nice. So a developer workflow should always prioritize speed. And what I mean by that is I want the experience that I had when I was eight of editing a text file, reloading my browser. It works. It doesn't get any faster than that. And when I ship to my users, I should prioritize correctness. But what is correctness really? What is correctness? Correct. And I would argue that your user doesn't care what framework you're using. Your user doesn't care what the underlying APIs and how they're working they care is, can I order my falafel on the website and get it delivered to my house? Does that work? Or does it not work? Yeah. The thing that I really liked about this slide was Sam was able to do the upside down question mark without actually glimpsing. He just kind of did it from muscle memory. Well, it's kind of my favorite symbol, because it's like the non-committal question mark. You don't know if the person is going to talk back to you, and you're like, how are you doing upside down question mark? So if they don't reply, you're totally OK. But if they do, it's like, oh, it was provocative. You gave me the weirdest look when you said that. I didn't like that. But luckily, we have tools for this stuff. So the idea of rather than jump through these tools the minute we're developing, we can actually just do it as a production step to give us this correctness that Sam likes to put it. So CSS variables. You can use something like CSS Next. And this is a super nice tool. What it'll do is it'll inline the CSS variable value that you've predefined. Or you can even make it do a fallback where it'll define first the value in just the normal hex color value, or whatever you want, followed by the CSS variable one. So when the browsers don't support it, it will just use the first one and ignore whatever else. So that way, you can still do the JavaScript thing. There's even a post-CSS transformer that you can layer on to give us that mix and support. Yeah, if you want to. Yeah, I mean, it's still experimental, but it's cool that it exists. Yeah, just as a thing, if you desperately need it. So that's kind of cool. So then we move on to JavaScript. So we've got Babel, which is basically going to take. Babel. Babel. No, no, it's Babel. It's Babel. Like, seriously, I've had discussions with Addy on totally tooling tips. It's Babel. No, no, no. No, it is. It's definitely Babel. It's Babel. But what are you going to do? You're going to call the creator of Babel? Yeah. What's that? Seriously, you doing this right now? Yeah. Only Castle Bastion. You know what you're saying? No, you're humble-breaking about Webstar kit. You're doing the same right now. Oh, I love Sebastian. See if I'll pick up. See, this is what happens when you try and call someone in London. They just don't like you. Well, I just need to switch my SIM card over to work. It's going to work. It's not. You're ready. Let's see. There we go. There we go. What are you doing? You actually doing it? Yeah, hey, Sebastian. Hey, what's up? OK, yeah, he's on the phone. So my friend Matt and I were having this debate. Is it Babel or Babel? Yeah, yeah. All right, here, just, I promise. No, it's not. Yeah. OK. It is actually him on the phone, sadly. I thought you were making it up. No, no, it's really him. OK, so Babel. Babel, right, sorry. Side track. I just needed to. Babel. Fine. You have problems with Babel, Babel, anyway. Don't you, Sam? I do. Oh, this is good. You took a picture of my tweet? Yeah, I did. OK. It was a Sage tweet. You even replied, so Sage. So Sage. I like that. OK, this is my issue with Babel today. We use these ES2015 transformers, and it takes all your code that's written using error functions, whatever, and it compiles it to ES5, regardless of what you're shipping to your users. Like, your users are using, imagine, like only Chrome in this hypothetical world. And we're still compiling everything, even though Chrome, you don't need it. And so what I like about tools like Auto Prefixer is that you can specify a range that you want to support for your CSS prefixes. And then slowly, there are less and less prefixes because all the browsers kind of standardize and things get better. So I want the same thing for Babel. Yeah, so prefixes, you'd go, like, I want Firefox, and I want to support minus two versions before the current stable one. So then it looks at the spec tables and goes, oh, we've really got feature support for that, and then it's all about fiddling with it. So yeah, if we could get this on Babel, that'd be pretty cool. Yeah, and I was talking to one of the guys that works on Babel, and he said he's working on it now, so. Awesome. That's great. So then things like fetch, JavaScript. It's a polyfill because it's JavaScript. OK, so that means that I can pull in this polyfill and I can use fetch in my browser and all my websites today. Yeah, so this one's from GitHub. It's super awesome. We've done a ton of different projects. There's also someone who's wrapped this for a Node module as well, so I'm pretty much using it everywhere now. It's really nice. And then web components. Yeah, just like we just talked about, this idea of web components, these primitives on the web that I can create that have life cycles and know when they've been attached and detached and I can run JavaScript and it's all isolated and beautiful, there's a polyfill and I can use them today. Yeah, just to check whether it works and then load it. Oh, well, that sounds really good. So ultimately, where in this scenario where we've got this massive tool chain and there's a certain degree of tooling fatigue where it's just like, great, the first thing I have to do is install all the stuff and then it kind of works and then if it doesn't work, then I need to go change something and then the configuration is broken or something else has happened. We want to change that, so... Well, right, instead of building with tools and using all of these tools to build our website and we ship all the tools to our user essentially, what if we would write using the primitives on the web and then what the users get is just a slightly augmented version of that, depending on what their browser supports. So it's like our tools become part of our deploy process but not part of our development process and there's this really interesting win that happens when you do this. If we write things using vanilla JavaScript, using web components and things that the platform has support for, that means that when I say, hey, Matt, I have written the best DatePicker ever and you're like, oh, cool, totally rad. I'd love to use that on my project. I don't know why you became Luigi, but... Yeah, you went really... I wanted you to be Luigi. But you can just pull it right in. You don't have to pull in my tool chain for building this DatePicker, like with Material Design Light. There we go. Yeah, so Material Design Light is... Well, it's Material Design built with SAS. So the thing is, if you wanted to take just the ripples from the button, that's cool, but certainly you have to take all the SAS with that to just use that one thing, which means if you're using less or stylus or something else, you've got two preprocessors rather than one. Whereas if it was in CSS variables, you could just take it as is, drop it in your web page, and you're done. Okay, so we build with the primitives on the web. Your code becomes portable across projects, which is awesome. You don't have to pull in extra libraries. And so then when we ship to our users, we add a slight tooling tweak to polyfill support, and that means everything works. So in a kind of roundabout way, you're saying, embrace the platform. I'm saying embrace the platform. Exactly. So when we embrace the platform, I think everyone wins. The developers win because the developers no longer have to worry about their tool chains during their development workflow. And the users actually eventually will get the most optimal solution because they're getting these primitives which are optimized at a browser level, not in a tooling level. And so the users walk away with a working website and a website that probably takes less bytes to function because you're not morphing everything just for the sake of it. Exactly. So thank you, everyone, for listening. Thanks.