 Hello. All right. As you can see, this is a very serious talk. So yeah, my name is Steve. This is if you would like to talk to me. This is a good venue to do that. And as Alex mentioned, I am a senior front-end engineer at Sengrid. Basically, if you've ever gotten like an email receipt from Airbnb or Uber or anything like that, we sent it to you because sending one email is very easy. Sending a billion of them is very hard. I work, that's predominantly an API. I work on building a front-end for people who aren't engineers to be able to use it. If you know anything about HTML emails, it is definitely trapped in the 1990s. I make HTML tables all day for layout. So I consider myself something of a subject matter expert on this. But yeah, we're going to talk a little bit about the year 1996. Just to kind of like re-get into the right frame of mind for 1996, I thought I'd do it in just a quick tour of the year. So first of all, the most popular phone at the time did not have a headphone jack. That was very important. We walked around looking for digital pets that we could collect. We spent a decent amount of time neglecting those digital pets. We cloned a sheep. That was cool. We also cloned the beetles. But our greatest scientific achievement of the time was this. The secrets of which have been lost to time and we're no longer able to recreate. But this was definitely a thing. And in 1996, I was building a website. I was building a Mortal Combat cheat code, or I guess fatality website. And it was a modern web application. It had a bunch of animated gifs. It took like three minutes to download. It autoplayed media without the user's permission. So effectively like a 2017 app. But like 10 years before, or 20 years before, it's time. And so you'd be like, why does anyone need to build a Mortal Combat cheat code? Aren't there enough of those? One, I was 12, cut me a break. Two, let's all think about that the next time we want to write a medium think piece on JavaScript fatigue. All right. So we built this site. And the site itself has been lost to time. I couldn't find it anywhere. Unfortunately, it did not get saved in that big rush to save as many GeoCity sites as possible. And frankly, I don't remember the URL anyway. I did, however, do some research to find websites of the era. To kind of remind us what it was like back then. So this is a site about Doom. But effectively, my Mortal Combat website looked pretty much exactly the same. Just to kind of give you a sense. Some other sites that existed at the time. It's very hard to find bigger images because screens were a lot smaller. This is Papa Bob's place. I'm not sure what the serpent as divinity means, but unfortunately it's a screenshot, so I couldn't scroll. Yes, you do. You do have a web page. You also have a Cushendo MIDI file that auto-played. Very cool. And so when I built this page in GeoCities, the way that I styled the page looked a lot like this. Right? We take the body, we have a background color, we go ahead and set the color of the text, so on and so forth. Obviously, black background, white text as you do. And then if you wanted to do anything else in there, you would style those tags as well. You laugh at the marquee. It still works. That is modern Chrome right there. It still works. And, I mean, again, some of us have moved on. This is code I wrote last week to make a button in HTML, email so it would render in certain email clients that I will not name. So some of us still live this life. But it became time. You know, the click counter on the website had hit 100. Thank you, mom. And it was time to restyle the web page, which meant going through and changing each and every one of those tags. A feeling that could best be described using stock photography. Luckily, there were frames, so stuff like the sidebar and the navigation bar only had to change one page to fix those. Again, you're like, oh, frames, that's cute. It still works. Cool. So at the time, like CSS and even JavaScript style sheets were a thing that we're brewing, but I certainly was not aware of them at the tender age of 11. So most of what I would have to do is go through the tags and restyle them one by one. But you can see that there was this growing frustration with this technique as a way forward for the web. And so there was this idea of style sheets that were brewing. And it turns out that style sheets, the idea of a style sheet, was included in the original version of a browser by Tim Berners-Lee, or as you might know him, web developer. And there were a bunch of different ideas for how we go about this kind of kicking around. A bunch of people thinking like, hey, this idea of how our page is structured and what it means should be somewhat different than how we style it. And we were kind of getting towards this need for a different way to figure out what the page looks like versus how it's structured. So here's Robert Reich, who had one of the earliest proposals for what a style sheet language might look like, was kind of arguing at first the need for his existence. And so in this proposal, what he did was he kind of put together a first stab of what this might look like. So as you can see, this is clear. Everyone understands this, right? That is finding all the H1s, setting the font size to 32, and its weight to bold, and putting a vertical padding of one something before and to something afterwards. And this was basically, the reason that it was so terse is because we had 14.4K modems and we didn't have any build tools so we were effectively our own Uglifier. Like these days, we have many different ways that we would solve this problem without having to type it by hand. I don't know what this image means. I found it, I stared at it for seven straight minutes and decided that I would suggest all of you to it to help me parse the actual meaning of this image. But these days, we have build tools that handle minification for us, but then an initial proposal, like the ideas that we would do it ourselves to kind of save bandwidth. And there were a lot of ideas in this initial proposal that were kind of cool, right? Like there was the idea of a link tag, where we link to a style sheet. But there were no concept of classes or IDs. It was changing H1s, paragraphs, anchor tags, and the such. There's no talk about cascading yet or how exactly that works, which is a problem that would need to get solved eventually, as we've seen. And a new style sheet, if you put a second style sheet in there, it would replace the previous one. There's no way of like, because there's no cascading, no way to kind of reconcile having multiple style sheets affect stuff. The Viola browser actually kind of under the hood had a first stab at a style sheet language, right? Implemented. It wasn't exposed to developers, or even to the user, but there was like new ideas kind of happening in there at the time. And that one looked kind of cool. You can see it has like a little bit more of a lisp like feel to it with the parentheses, and you can see we can nest stuff in there. We're starting to get the feel of what we normally think about with style sheets at this point. You could do cool things like continually nesting different selectors, so you could style the ordered list and then each level of list items below that, right? Which is not much different than when we think about it with SAS, right? This is like modern SCSS, the same like basic idea re-implemented in that case. And so we have this idea of like users being able to set what a page should look like, right? And that still exists in a lot of browsers until someone throws a like reset.css in there, and then it doesn't anymore. But a lot of browsers, since this is Netscape 4, had the ability for users to define like a rudimentary style sheet for how the page would be displayed. This is still actually true in Firefox as well. And that was true up until Mosaic came along. The team behind Mosaic had a much different viewpoint behind like how users and maybe even authors, right, which is still like not really a thing yet, what input they should have in being able to style web pages. So I'll read a quote off a slide to you, because it's good. In fact, it has been a constant source of delight for me over the past year to continually tell hordes, literally, of people who want to strap yourself in, here it comes. Control what their documents look like in ways that would be trivial in text, word, or every other common text processing environment. What do you like to tell them is, sorry, you're screwed. So needless to say, Mosaic, not great support for style sheets. And they're kind of like this idea that we're talking the third person at this point. We've moved on. We're now talking the third person. That the idea of allowing a language to style a web page, a style page separate from HTML, was actually crippling the web and the way we think about front ends. So the role of stylesheets and should it be part of our HTML or JavaScript or something along those lines was definitely a source of argument and tension from the very beginning. You can see Safari actually lets you pick a full stylesheet that you can pull in as your default. So if you want comic sans everywhere, like these slides, that is the thing that you can do. So the initial conversations about whether or not stylesheets belong on the web was thinking about users being able to control what a page looks like in and above what the browser vendor decided it should look like. It wasn't until a little bit later in the conversations that we started thinking about a third party, the page authors themselves, right? And so this idea that maybe the person who designed the page should have some kind of say in how it looks, right? Or at least give hints about how it should look in that case. If the user had a stylesheet, well, then they could override that or maybe their preferences would also be taken into consideration, but that the person who designed the page might also want to have some kind of input into this. Now, that's questionable whether that should have happened. This is a web page I designed in 2005. So taste is really subjective. Arguably, I shouldn't have been allowed near a stylesheet and this would have been better for everyone. So right now, as we start to think about this, there's a proposal called Cascading HTML stylesheets. So now we've got some words that are sounding familiar here. It wasn't CSS or JavaScript stylesheets just yet, but some of the idea of how we might think about we've got these three parts, what the browser vendor thinks the page should look like, what the user thinks the page should look like, and now what the author thinks the page should look like, right? And we should be able to not necessarily have the last word as authors, but definitely have some kind of say or opinion in it. And again, not everyone agreed with this, right? The idea that you have to learn a separate language for styling a page seemed not OK to some people. So the Cascading HTML stylesheet proposal was also really interesting. So you see you're getting a little bit closer to what we normally think about. What I would like to point your attention to on these slides is on that first slide, you see that 40%, right? And you can notice the 60% right after that. This was a way to define how much we cared, right? How much weight our preference should have over the user's preference, right, to kind of like strike that balance, which kind of like looking back at this like over 20 years later, it seems to like add like one more layer of complexity on top of everything, but definitely kind of an interesting concept. The other thing I would like to draw your attention to here is this idea of some kind of logic in our stylesheets. You can see like a pair of turneries in this proposal of like, so I guess if the page is older than three days, we're going to make it a pale yellow just like the paper aged or faded or something. Cute. And like some idea based on like the height of the page and we'll use a different stylesheet, right? So you can see this idea of a little bit of like logic, which is kind of going to be a recurring theme today. I just kind of like want to like point you towards right now. So there were a whole bunch of solutions to this problem. I have about 30 minutes to talk about it. So we're not going to talk about DSSSL or any of the other like kind of like contenders. We're going to talk about two different solutions to the problem at the time. CSS and JavaScript stylesheets. JavaScript stylesheets never got an official logo, so I concocted this one, and it didn't feel fair to take a modern logo for CSS to use this comparison, so I found the literal worst logo for CSS I could find. And these are going to be the kind of two that we kind of talk about and compare and contrast. So JavaScript stylesheets looked a little bit like this and you can see that we have a style with a type is text JavaScript and we can kind of find the classes and set it to a given string. This is actually taken from the official proposal to which people have questioned who picked the class punk and why it was a bright green. These are asking the important questions that need answers. I'm not satisfied with the answers this thread got. JavaScript stylesheets were implemented in Netscape Navigator 4 and only in Netscape Navigator 4. But let's not talk so much about JavaScript stylesheets. Let's actually look at some examples. It's not often you get to use ridiculous transitions like that, so you're going to have to just indulge me for a little bit. I'm doing a 90s theme talk. I get to kind of use a lot of comic sans, bright colors and ridiculous transitions. Sorry, not sorry. So this is going to be the page that we work with. And some things to point out is that we've got the style tag up here. And instead of a style.css, we're pulling in a style.js. We're saying that the type is text JavaScript. This is what the page looks like. Yes, I went on eBay and ordered a Netscape Navigator 4 CD. That totally happened. So this is a real page. Let's go about thinking about how we style it. So we can take the document global object and it's got a tags property where we can find the h1 and set its color. Here we can set it to red and you can see, look at that. It's amazing. I wrote JavaScript and now the style is red. Cool. We can set the font size to 24 pixels. And then the font size becomes 24 pixels. We can also just use the number. One thing I'd like you to think about as we look at this is what parts are very similar to what we can do in CSS. And we'll talk a little bit about why that is a little bit. Document being like window was global in this case. So you could actually just say tags.p font size 24 and that would do effectively the same thing. We could also set variables. You're like, I know modern CSS. I can set variables. Very cool. This was 1996. So bear with me here. Where we could set the font color of a given thing to blue. And we can play around with classes. And you have IDs, which we could like, you can have an ID and set the color to cyan. You can find all the classes. If we looked at the HTML for that first paragraph, had the very semantic CSS class of first. We can find all the first classes and find the paragraph tags and set them to red. There's little things that we can do here. We don't have all of the selector goodness that we used today, but we've got some options. We're going to play around with a little bit more. But we can take that variable and we can set it. And then we get this lovely web page right here. All right. There's some other cool things that we can do because who doesn't like non-determinism in their stylesheets? So here we'll get a random number. We'll round it up to either one. With a truthy or down to zero with his falsy. And based on that, we will set the color to black, which gets you a slightly different page. Took a little bit for the video. But as you reload the page, you could get a black or a white one. White, black, white, black. You don't know. It's different every time. Even better is we can get some user input here. Like, we can ask the user what they want to see. So things like, unfortunately, confirm and alert, work in stylesheets as well in this case. So here we'll ask the user if they would like to enter into the night mode, or into dark mode in this case. And the user can go ahead and refresh the page. They'll get prompted if they hit OK. They're in night mode. And if they hit cancel, they're back in regular mode. So we can have user interaction change the styles dynamically at runtime. This is going to be a theme that we kind of hit on. All right. Here, like, you can, if all that, like, document.tags.p. That color is too verbose for you. One thing that they kind of mentioned, the spec, is using the width operator in JavaScript to kind of, like, change the context and scope so you can, like, shorten things up a little bit. There's also this contextual function, which then allows us to find, in the second paragraph, it's basically the idea of, like, having multiple CSS selectors, right, and kind of getting a little bit more granular with that. We would use this contextual function. And now we can get all, in the second paragraph, all of the spans with the class important and set their color, or all of the everything with their class of important and set the color to red. And that works, as we'd expect. Really interesting, responsive design wasn't a thing yet, right? Like, mobile devices weren't running web browsers in 1996. But because we had the full power of a programming language with this idea of being able to evaluate the world at runtime rather than at compilation time, right, we could effectively implement responsive design. So here we can see that it's blue over a certain number of pixels, and as we, as eventually if I can, like, get to the edge of the page and we shrink it, we can turn it to red based on the width. And we can implement effectively responsive design in a web browser in 1996 before responsive design was a thing because we had the full power of a programming language. And that is very cool. Neat. So happens when you move slides around when you jet lagged. And like, I think there was a lot of excitement even up until 1997, right, this idea that we can change stuff based on user interaction or the state of the page, right, which is, we got some abilities to do that in CSS like a decade or so later, but there's kind of a very cool thing that we can do early on. So that was some, like, real coding with a real browser. We're also going to look at some fake coding. Because it was a proposal, there are things in the proposal that in my experience with Netscape in a VM that I could not get working, but we'll kind of talk about. One of which is this dynamic evaluation. So you could write a function, and I don't know where the function keyword is there asking, like, how did he write a function without a function? I don't know. This is lifted from the spec. I couldn't get it to work with a function keyword without a function keyword. But you can see that based on the current color of that selector, right, we could, like, define other things. If the color was set to red, we could change it to blue in the font style italic. And so based on, like, the current state of this given element or class or ID, we could change other things about it, right? I couldn't get this working, but it seems like a very cool idea to kind of be able to have some introspection to the current state of the style and be able to make other choices based on that. And you could use that pretty much anywhere, right? So you could write the function and just evaluate it, and, like, it would do different things in these contexts depending on what that tag was. Specificity was still definitely a thing. So you're not out of the woods on that one. Sorry. And we'll talk about why that is in a second. But the same exact rules of specificity for CSS applied to JavaScript style sheets as well. So CSS was kind of, like, being developed at the same time. Internet Explorer 3 being the first one to do it at all and 4 kind of taking it in earnest. But it did get standardized as a W3C specification, right? The JavaScript style sheet proposal was just that, a proposal. It never actually got officially accepted, which meant Netscape was in the place where they could... They had to, like, CSS as a standard now, right? So what would happen in Netscape is you could write CSS or JavaScript style sheets. In Internet Explorer, you could only write CSS. So if you are a web developer targeting both platforms, you are wise to write the CSS in that case. And this was pretty much already, like, the final nail in the coffin for JavaScript style sheets. Even Netscape's implementation of CSS was really just, it was subtly broken because it was really just a facade over the JavaScript style sheet implementation, which is why a lot of the rules and specificity and all that stuff applies, like, it was pretty much, by the time it shipped, it was already effectively dead, right? So it shipped in Netscape 4 and it was gone in the year 2000. In Netscape 6, it was no more. You couldn't run it anymore. And I think there are a lot of, like, missed opportunities, right? As we look at the way that we've styled pages over the last 20 years, there's a lot of things that we keep, like, running back to and thinking about. We think about, like, we brought in Modernizer, right? And we could, like, figure out, like, feature detection rather than trying to, like, set our CSS properties in just the right order with vendor prefixes and all these things and fallbacks. Like, we had this idea of, like, fallbacks and CSS, like, hey, detect if you can support Flexbox and then use Flexbox, otherwise, do this other thing. It was, like, if I stack everything in just the right order, maybe it'll work, right? Also, this idea of, like, polyfills, right? That we could, like, fill in different behavior. Here's an example that I tried out in Netscape where I could effectively write my own ViewWith property, right? Or function this case. It worked as one would expect. Like, you could theoretically, again, like, you could, there were no vendor prefixes at the time. But, like, the same way you might have written a SAS plugin in 2006 to kind of, okay, Moes and O and MS and WebKit, right? You could theoretically have done that with a full programming language in the browser, even though you didn't need to because it was 1986, there were no browser prefixes yet. And so there's a lot of very cool things that we could have done over the last 20 years with this. And kind of just, like, blue sky solutionaring, this idea, like, think about, like, async await and fetch. Like, could we have dynamically, like, imported other styles and think along those lines if we had the full power of the JavaScript programming language in our styles? Could we base on, like, in Netscape 4 you couldn't actually modify the DOM yet. That was not a thing that you could do with JavaScript. But if you could, what would basically happen basically? You could, like, take a look at user interaction events and change our styles based on that. So there's a lot of cool things. And some of these are, like, yeah, I can do that now in CSS. But keep in mind, CSS has had, like, an extra, like, 21 years since then to figure out some of this stuff. And this is something that was pretty much, like, frozen in time in 1996. But what's really cool is some of the ideas in JavaScript style sheets have, like, occurred over and over and over again. This idea of using, like, conditionals or variables in our styles. That sounds familiar, doesn't it? We can even use variables and custom properties in CSS4 now. Like, that's a thing, right? These are things that, like, we had ideas for even in the early days of styling our web pages that even if they didn't ship originally they've been coming up over and over and over again. We've been trying to figure out ways to have them in our page. The problem with, like, SAS and less and even, like, post-CSS is that we're forced to make a choice. We don't actually get the choice of compile time or run time. That cool example that we saw where we picked a random number and changed the background color of the page, that's really cool except that you go to build your stylesheet and whatever that number turned out to be when you process that SAS or that post-CSS into a stylesheet, that's the number it's always going to be because you're not doing it at run time, you're doing it compile time. And I think as we look at things in the way we write JavaScript, right? Like, we're looking at stuff like prepack, right? And, like, ways at compile time to do interesting things in JavaScript, I think the opposite is true for CSS, right? We do everything at compile time in CSS and being able to do stuff at run time, I think, is also a kind of very cool thing. And I would argue that the closest that we ever got to, like, run time styling would have been jQuery, right? This idea of styling and, like, being able to, like, tell other things about the page. We do have some abilities built into the browser, right? It's not like we have no run time introspection to how things work. There is this thing called the CSS object model. And what the CSS object model is, it's a way to, like, figure out what the style sheets loaded on the page were. And it's kind of got this structure here where we've got document.stylesheets and that will give you all the style sheets that are loaded. It'll then, like, you can go through that and, like, get the style sheet list and then the style sheet and then you can insert rules dynamically and get the rule list and delete rules and modify them and all sorts of really fun stuff. It's a little bit, like, problematic, though, because if you look at this, like, if you look at line seven right here, you can see that we kind of have to know. If you're querying or parsing of the style sheet, you kind of just have to know where a given rule was and hope it doesn't move and or anything works, which is why we don't actually use this all that often. It exists. You can go into the browser right now and try it out. It'll work. But, like, actually implementing anything, like, cool is really hard. So here we can, like, dynamically change the background color of a page. And again, so defined, given, like, a button style, this would be the code I would have to write to find it. And again, it's hoping that it is the first thing on the first style sheet and we can begin to modify it, but that's not kind of giving us all, like, the power that we need. Right? If we think about the DOM, we have a whole bunch of ways of querying the DOM and traversing the DOM and modifying the DOM. There's a DOM parser built into the browser where you can just give it some HTML and it will build, like, a DOM tree for you that you can modify. These things don't exist with the CSS object model at this point or with CSS, but it would be really cool if it did. Cool. And, like, there's a bunch of problems. You don't get errors with the CSS object model. It drops things along. Anything it doesn't understand just doesn't do anything with. It's effectively, at this point, kind of hard to work with. And it's symbolic of the challenge that we face as front-end web developers where we took this text-based document viewer from the early 90s and decided, hey, you know what would be cool? To build, like, the world's largest distributed application platform on top of it, right? And so we're constantly finding out what are the things I'm not supposed to be able to do in the browser and then figuring out clever ways of doing them and then a lot of times, like, paving the road behind us in order to do them. And, like, our craft has evolved in, like, JavaScript. You think about, like, what writing JavaScript was, five, 10, 15 years ago. It was, like, it was basically you memorize this, like, set of secret tricks that would, like, make things work. You knew that January was the month of zero because why not, right? December, the 11th month, everyone knows that. And we, like, begin to, like, oh, we'll have an iffy and that won't pollute the global scope. And, like, there were these, they weren't, like, given to us by the language. They were, like, tricks that we, as a community, came up with. Right? And eventually we got better about this. We entered strict mode. We had the ability to lint. We gave ourselves better, like, primitives for dealing with things. We, like, went from no ability to have modules to, like, four different styles of writing modules and getting into fights about them. Very cool. And I'm going to show this slide a few times. And I think this is the cycle and the flow that we go through building kind of advancing the web platform, which is we start doing things that the platform was never meant to do. Then we come up with, like, weird, this one weird trick to do whatever that was and make it happen. We find a way to automate it with build tools and eventually we improve the platform itself, right? We can write callbacks and then we kind of come up with a promise abstraction. But eventually we give ourselves, like, async await and give ourselves just better, like, general tools for doing these things. Another quick, like, blast from the past to show, like, how these ideas and some of these things that we've wanted this platform keeps showing up. ECMAScript 4, which notably never saw the light of day, had this cool thing called ECMAScript for XML. I'm going to show you a screenshot of it and inside in your brain just tell me what you think it looks like. I'll pause. Dramatic pause. Right. This is an idea that we had in, like, 1999 for how we might, like, define markup in our JavaScript seemed super familiar to me, right? And, like, it looks like a certain framework. And we thought about, like, this idea of breaking our user interfaces up into components. And we basically figure out how to isolate everything. We have just these unique components. We put them on the page. Nothing shared, no polluting of the global scope and stuff along those lines. And that gave us the ability to do a lot more advanced user interfaces with a lot less spaghetti code. But it led us to this new enemy, right, that didn't jive with that way of thinking. And this idea that, like, it caused many JavaScript developers to go, CSS is broken. Right. And not CSS is broken in that floating something to the left is way harder than it needs to be. But the fundamental paradigm of how we styled web pages was broken. All right, some of the common complaints are that all cells are in the global scope. It's tricky to figure out dependencies. Dead code elimination is hard. So on, so forth. Like, who knows if something got mutated later? Unclear, right? And I definitely, as, you know, kind of being in the craft myself, started to, like, try to, like, I definitely just resonated with me. But, like, one of the things I tried really hard to do is any time that I find that I believe something, as a JavaScript developer, understands whatever the other thing is better, doesn't seem to agree with me on to question if I'm actually right. Right. This is a little, like, graphic by Nicole Sullivan. I will not say the CSS sucks. I will admit my own discomfort with the problem space. Started to think about, like, maybe I don't really understand the problems that CSS is trying to solve because people who are experts in CSS weren't saying the same complaints that I was. And as a person who started as a JavaScript developer in, like, the heyday of, like, let's do everything in Ruby, right? I saw, like, a familiar pattern. And I asked myself whether or not we're falling into the same trap that a certain programming language had to deal with only, like, three, four, five years ago. Right. And I'm pretty sure, like, it is the same pattern as, like, we've come to, like, higher-class problems that, like, this is now the same. And, like, everyone told us we couldn't build web applications in JavaScript. Some of them have, like, since we're counted on that. But, like, it's still, like, I think we've, at this point, like, an application to do has been built in JavaScript. And we started out with, like, fun ways to work around JavaScript. So the answer to all of our problems is CoffeeScript style sheets, obviously. But what we did was we improved the platform, right? Which means that you can use whatever framework you want and you share from the benefits through the JavaScript programming language, regardless whether you're a React developer, an Ember developer, or a Angular developer. So this refrain that CSS is broken, right, is, has its counterpoints. And, yes, CSS has its words to words clearfix, but who amongst us doesn't. And the thing that always makes me think about, like, some of the philosophies behind CSS, is looking at CSS ZenGuard, where you take this markup, and you can make it look like this, or this, or this, or this, or this. Right? And this ability to have, to separate those styles, you couldn't do that if everything was, like, isolated to every component on that page and baked into it, right? Yes, you could take that component and move it around, but you couldn't restyle the entire page. And that's something that we risk losing if we kind of, like, move too far into, like, let's do all of our CSS in JavaScript. Right? And in ZenGuard, yes, we have, like, the application I work on is a React application, and we use a certain amount of CSS in JavaScript, right? But we also have a backbone page, right? Our main, like, dashboard is backbone. The main website itself is WordPress, right? If we pigeonhole everything into a certain, like, style of our components, we can't share that across all of our different platforms, right? And we don't get the advantages of this cycle, right? We end up having a React solution for this, and an Angular solution for this, we don't get to share the code. A lot of these problems get solved with build tools, right? We can style int, we can use immutable CSS to make sure nothing actually changes in our sheets, CSS modules for a little bit of, like, isolating, and even, like, the web component spec solves a lot of these problems. But, yeah, compile time versus runtime, and I think that's the kind of very interesting thing to have in this case. It's like, a lot of those tools are still compile time tools. And the best part is thinking about how do we improve the platform itself? And I think a lot about the extensible web manifesto, which is basically this idea that if we have features that explain what's currently going on and give ourselves primitives to be able to, like, polyfill more of the platform and let developers, the same way we do stuff with Babel now, to have that with the way we think about it. We don't, like, basically, when we wait for CSS Grid, it's like, it's here or it's not here. Yet, a new feature comes out in JavaScript. We've got the primitives available to polyfill it in Babel or something along those lines. And that we have a process where we can see the things move along like we do in the TC39 process of things moving from stage 0, 1, 2, 3, 4. It'd be awesome to have that for JavaScript as well. Sam talked a little bit about how we could solve this problem. There's currently a working group working on this thing called Houdini. And the idea is to kind of give us all the parts that we can't really touch right now. We talked about the CSS Object Model, which is our partial JavaScript access to what's going on in style sheets. There's a lot of things we have no insight and no control over whatsoever right now, which makes it very hard to do these things. Luckily, there is a working group trying to fill in these things. But the thing about all this work is that, like, unless we as developers are really excited about it, there's not, like, a giant motivation for browser vendors to implement it. So it's on us in this room to become very, very passionate about this and very excited and push the browser vendors to implement a lot of the work that this group is doing. So JavaScript style sheets are short-lived, but a lot of the ideas are, you know, have reoccurred over and over and over again. And it's very easy to think as we look at ECMAScript for XML or JavaScript style sheets that we're just, like, spinning in circles with the same idea over and over again. But I would posit that we're actually doing a cartwheel into awesomeness as we keep pushing the platform forward, revisiting all ideas and figuring out with new perspectives and new ways of going about things, how we can implement them in the platform. So the moral of the story is we're, again, taking this text editor from the 90s and turning it into a distributed platform. We're doing it with the best tools that we have right now. But there's exciting work happening to give us better tools. And it's our job to kind of be involved and push those things and create the platform that we want to see in the world. I just couldn't help myself. And so what I believe what we're with is to rather than work around the limitations of the platform, let's push to create a better web platform, even if it means looking at the things we have in the past and improving our tools rather than trying to replace them with the most easily available thing. Thank you very much. I really appreciated the aesthetic of those slides. So a couple questions from the audience. If today's talk is about JSSS, what will your talk in 2037 be about? Wow. That's a really great question. Probably about JavaScript. We'll be doing everything like WebAssembly. When we write all of our apps in CSS at that point, we can just talk about the JavaScript programming language and remember it fondly. Fantastic. One last question before we move on. How and when does the browser execute or evaluate the JavaScript style sheet? So one of the fun parts about trying to figure this stuff out, you don't have a console in Netscape Navigator 4. The only way you can debug code in Netscape Navigator 4, and this is how our ancestors did it, they would try something, the whole thing would not render anymore, so you take that code and you copy and paste it into Chrome in 2017, see the error that you made, and then paste the code back into Netscape Navigator 4. So that's the most insight that you have at the time. That's how people did it in the 90s. Very nice. Thank you so much. Let's give them another round of applause.