 Hello everybody. I just want to start by saying how excited I am to be here and what a privilege it is to be up here. I've never been able to come to India before. I'm very excited to explore Bangalore. I'm only just going to be here in the city, but I hope to explore the city a little bit and meet a bunch of you afterwards. Thanks to the organizers for bringing me out. My name is Glenn Madden. That's me on Twitter. That's an artist's impression of my face. As I was introduced, I'm from Melbourne in Australia, which everyone just wears black, so I'm keeping up the uniform. For the last, say, four years, I think, I've been a freelance front-end engineer. That's sort of a job description that hasn't existed forever, I don't think, kind of front-end architecture, front-end engineering. I really enjoy working in that space. About 12 months ago, I started a web series, a screencast series called Front-End Center, which kind of taking some of the things I was working on as a front-end engineer and trying to make episodes about it, trying to make tutorials about it. I do a couple of episodes every month. I've got a bunch out on YouTube if you Google that, and then you can subscribe if you want at Front-End Center. But with those two jobs for several years, neither of which have a very kind of nine to five kind of vibe to them. That's allowed me to do a lot of open source work. Not as much as I'd like, of course, but I've been lucky enough to be involved with a couple of projects that have become reasonably successful. The first is CSS Modules, which I mean this is a React event. CSS Modules is fairly well known in the React community, but if you don't know it or haven't used it, it is a compiler for CSS to make things a bit easier to manage at scale. Star Components, obviously I'm going to be talking about more mostly today. It's a CSS in JavaScript library that started about a year ago, a bit over a year ago. The third thing, I'm not going to get much time to talk about it, but it's the project I'm working on a bit at the moment called React Snapshot. The reason I wanted to bring up all three of these is that they're all kind of connected. They're all kind of pointing in the same direction. While I'm going to be introducing style components a little bit today, I also wanted to focus on what that direction is, where all this is heading. What about each of the stuff that I've done kind of contributes to making the web a better place and all of the different opportunities for other areas to do the same? This is kind of what I want to leave you with, this idea that it's all actually getting better, because I think the React community in particular is very active in pushing the web forward, but it's pushing the web forward in a particular way. It can be a bit fatiguing if there's new libraries coming out every week, whereas if you understand them all just sort of in a sequence towards some ultimate goal, it can be a bit easier to reconcile. So that's kind of the road ahead. But I'm going to be introducing all of, basically I'm going to be talking today from the perspective of CSS and JavaScript, because that's where I have done all of my work, basically. I really only, I didn't learn CSS all that long ago. I mean, I've been programming professionally since about 2005, but I only started to really learn CSS in about 2011. And I've really loved it, so I've been doing it a little while, but I remember when I started using it and I found it such a challenge, and I still think it's one of the most interesting areas to be working in tech, because it requires both parts, well, two major parts of thinking, right? You need visual design style thinking, because CSS is ultimately a list of instructions for a browser to render something to a page, and then humans are going to look at it. So you have all of those things involved in rendering, but then it's still something you need to be able to write well and maintain. So it's still code, it's still engineering. And that kind of confluence of those two things I find incredibly challenging. So me, with more of an engineering background, I kept looking for ways to try to improve things, to make it easier for CSS, easier to work with CSS, making it easier for people who are more visual thinkers to do good engineering practice and people who are better or more from engineering background to produce stuff that looks good visually. So, and I kind of see that CSS and JavaScript is the area in which all of that work is happening for CSS at the moment. It's kind of the best place to be playing around with things. It's incredibly cooperative and productive at the moment. There's tons of libraries, and we're all borrowing and stealing ideas from each other. If you're not convinced by the merits of CSS and JavaScript, I encourage you to read this post by a friend of mine, Mark Dalglish. He's also from Melbourne, one of the co-creators of CSS Modules, who wrote quite a long post and has also given this post as a conference talk, if you prefer that, about the idea of CSS and JavaScript being this unified styling language. And to me, that's really where this is headed. So this is quite good, because for a long time, I think CSS and JavaScript had a problem, which is people saw it as trying to subvert CSS or trying to get around learning CSS. But really, it is just CSS using JavaScript. And so he identifies a couple of areas where that is really beneficial. And what's important here is not that anyone library is offering these things. It is intrinsic to using something like JavaScript to build your CSS that you get these benefits. Now, I don't have much time to go through these, but I'll just sort of introduce them briefly. So scope styles is the ability for a component to have CSS that definitely guaranteed doesn't touch another component that has CSS. One of the big problems with using normal CSS using global namespace. Critical CSS, if every component has its own styles, then only the components that are rendered need to inject their styles. And so you get something that's quite difficult to do with a traditional HTML CSS workflow. You kind of get it for free by attaching everything to components and running it through CSS and JS. Then you get smarter optimizations, right? So if you can take two components that you know aren't going to conflict, you can look at the CSS that they share and potentially hoist things into classes and rewrite things to make the best use of the CSS engine. Package management, obviously, we share JavaScript already. We share React components already. So putting the CSS inside the components and sharing them on NPM is a huge benefit. Something that's really difficult with CSS files on disk. And the last is non-browser styling, which I'll kind of come back to in a minute. So my talk is kind of road to style components, but really, for me, the road to style components is why would I do it? Why would I start working on one of these things? Why would anyone build one of these libraries? I mean, yes, you can see these benefits, but what is it about adding a new one? Why would you go for a new one? And I want to talk about that kind of, I want to talk about the design goals of style components, because I see them as sort of shaping the library, and it's a good way to introduce the library itself. But it also, these are design principles that I think are really important for all libraries that are all pushing towards this goal. So the first design goal, and this is kind of the basic level of any library, is that it establishes some best practice, makes some practice automatic rather than having to be a decision. So I kind of see the process of these things like everything starts with an idea, somebody has an idea that this might be a better way to do something. That kind of develops into a technique. Somebody writes a blog post about it. Somebody gets up on stage, talks about it, they give it a name, people start commenting on it, people start trying it. It gets better, and when it's better, it eventually becomes a technology. It eventually becomes implemented and becomes automatic. So everybody who went through the pain of learning it the hard way can leave behind a library that means the next generation of developers don't have to. It just works. What I find really interesting about this, the way libraries develop is the technology itself allows new ideas. I think the biggest one in the history of JavaScript is when V8 came out in about 2008, I think it was the first release. No JS would not have been possible without V8. All of the work that we do, every renderer from Angular to react to everything relies on the fact that JavaScript is fast, and JavaScript hasn't always been fast. And so things like CSS and JS is predicated on the work that React and other component-driven UI for others have done. So that's the area that I really interested in. And I think the big idea that has spurred a lot of this development in the web at the moment is this idea that we've changed what we consider as a separate concern. So we've changed the idea from, we know that the browser has to run HTML and CSS and JavaScript differently. And so the obvious kind of assumption is that we would code all of those differently. But if you talk to a customer or if you talk to a product manager or a designer, you look at a bug report, everything comes back in terms of, hey, the payment form didn't work or that button doesn't look right. They come in terms of functional components and their flaws and their features. And so what I see is moving to more of a component-driven framework. And I know I'm preaching to the choir here because it's a React convention. But it is about aligning your development workflow with the way you already conceptualize the UI. And so I love this slide. Christiano didn't invent the concept, but this slide pops up and talks all around. So thanks for him letting me use it. My favorite example, actually, the first time I heard of this idea of changing, aligning things around more like components, was actually talked by a guy called Nicholas Gallagher who came out to Australia and said, you know what, don't change the work you're doing. This is a few years ago before I was doing React or before most people work. Just change the directory structure. So put all your files and the CSS, all your JavaScript files and your CSS next to each other. And it's a really small change. You don't change from your library, you don't change your build system or anything. You just change the directory structure and you start to see some benefits. And to me, this is a really powerful idea because it shows you that in isolation, just the idea of grouping your concerns is beneficial. So obviously, from that technique, we have things like Webpack and React. Webpack makes it possible for a component or a JavaScript file to include a file of different type, of an SVG or a JPEG. React obviously gives us that fundamental component UI that we can use to construct everything. But importantly, given in their base kind of like in their basic version, they don't ask you to change that much. If you consider this, you have some CSS in a big CSS file and you have some markup in a big HTML file. And the only thing that links those two together is the fact that they share a classmate. React and Webpack says, hey, you don't need to change this CSS, just put it in a file for one, you know, for that component. And then you can use this component, right? You can build up this component that maps that bit of a markup. And you don't actually have to change that much to get this benefit, right? It's a very incremental step. You just need to change class name, but the whole existence of JSX is kind of predicated on making this transition easy for you. So then CSS modules comes along. CSS modules is, again, just a very gradual step. It says, okay, cool, now you've got your CSS files in small files, now you've got your components in their single purpose files, but you're still using these global names, right? You already know that you're in a headline CSS file, so why don't you use names that are more relevant to that local context, right? Every time you write a JavaScript variable, you don't have to name it, file one, underscore, blah, blah, blah. You don't have to worry about every other local variable and every other file, whereas for some reason people do with CSS. So CSS modules is really just about making your CSS local, and then you can use the PowerWebpack to wire things up. Again, it's very incremental change, but it has some big benefits because it bakes in this best practice of using small local components, local CSS. Style components is really just the next evolution of that. So style components is our fancy new website and fancy new documentation. The documentation is actually now really good, I can't take any credit for that. That's been a big team effort led by Phil. It's a good time if you haven't played with style components. It's a really good time to use it now. The library is really settled. Documentation is pretty good. Style components says, okay, you're already, you're already writing these small focused CSS files, these small focused components. Why don't you just do it in one file, right? Don't have a CSS file and a JavaScript file, just have one file. And so there's a couple things I want to point out here. The first is that you just import the library. Import styles from style components. This doesn't require a Babel change, it doesn't require a webpack change. It is a purely JavaScript runtime library. And then there's one mapping between the CSS that you were writing and the style components that you can write now. So instead of dot wrapper for a class, you have const wrapper, which is a react component. Generated by styled header, which is a factory that generates react components and attaches those two lines of CSS. Same thing happens with the next one. Instead of text being a class that's just, you know, sitting there next to some styles, now you have a styled component, a styled H1 with three lines of CSS. But what I really like about this example is what it does to your render method of your component because all of the noise is gone now. So previously you had the CSS modules using class names to wire things up, but you weren't actually doing anything. You weren't actually doing any of that. You were just kind of using this legacy way of attaching styles to objects, whereas now you have a different way, which is you create named objects, named styled components, and then you render them. So this components render method now just has wrapper, text, and text. You can see the nesting, you can see the content. So that was the thing I was trying to get to when I was working on the very first versions of style components is this API, where it's really clean in your render methods. So that's kind of the first design goal. And this is sort of like, this stuff isn't super specific to style components. Pretty much any CSS and JavaScript library does these to some degree. They're all concerned with encapsulating your components. They're all concerned with giving the opportunity to use semantic names rather than global names, and they collocate your styles. So now I want to talk about areas where I think style components differs from other CSS and JavaScript libraries, but also these principles I think are really important for other libraries, all kind of working towards this goal that I'll come to in the end. So for me, this is the idea of bringing people along. Because as I said before, CSS is a marriage of both visual and design thinking, as well as engineering thinking. And so the best people at the visual stuff may not be doing React right now. The people in your organization that are most talented about UI development may not have that engineering background. And so making things that are easier for those people to be involved rather than cutting them out makes the whole thing better. So I've got a question for you all, which is, who is using SAS these days? I know this is a React thing, so I'm not expecting all that many. Okay, a few hands. Oh no, quite a few actually. All right, so that was a trick question. Who is actually using version of SAS? Without the brackets, without the semi-colons. Yeah, virtually, maybe one or two. When SAS first came out, it was the version on the right. And these two are really similar to each other. It's a very superficial change, which is, you know, it's just making white space important, getting rid of some brackets, getting rid of the semi-colons. Whereas it took until SCSS, SCSS had the ability to take a CSS file, any CSS file, and rename it to .scss, and it would be valid SCSS. It was a superset of CSS, which meant that if you had all the CSS, and you had all these people who knew CSS, you could introduce them really gradually. And as a result, SCSS is by far the most dominant form of SAS in use. I think CSS and JavaScript is going through the same sort of thing. CSS and JavaScript, when style components was first being written, looked like this. This is the only way you could do it. And it's perfectly understandable for JavaScript people to look at an object. But it's a bit strange for CSS. You have some things like, you know, you have to wrap everything in quotes, which you don't have to do in CSS, except if it's a number, which is kind of weird. You have to use camel casing instead of kebab casing, which is better, kebabs are better than camels. You have to wrap some of the keys in strings, whereas other keys you don't have to. Again, it's very superficial change, but when you compare that to style components using a string, using the same syntax as SCSS, it becomes much easier for people to just pick up. Not have to look at them, not see the noise, just see the code. Start working. Makes it easier to port your components across as well. Because I have this idea that maybe the first time you're going to be playing with CSS and JavaScript, you've only got half a day. If you've got half a day to play around with it, you can spike it out. So the further you can get, the more interesting stuff you can do, the more likely you are to see the benefit, rather than getting bogged down in the syntax. So that was a very deliberate strategy on the part of style components to make it as familiar as possible. I think the real benefit, as I said before, is that if you design for people, if you meet people halfway, then you increase the number of people who can get value from your idea straight away. And you also get the benefit of their experience as well. So the more quickly you can get people using it, the more quickly you can get feedback from those people. And the more, you know, broader range of people you can get feedback from, the better your library is going to end up being. So the next principle I want to talk about is kind of goes against that, right? Because you could look at, you could just think the familiarity is the most important thing. And just try to design a new library that makes whatever you knew how to do before, and just generates new code for it. So classic example of this is like Google Web Toolkit, which lets you write UIs in Java and then rendered JavaScript. And I don't know if anybody still thinks that was a particularly good idea. This idea that if you're targeting a new platform, there's gonna be new possibilities. And so by following the path of least resistance, you can figure out when to keep the familiar code and when to introduce something new. So an example of that is if you've got a couple of buttons, primary and a non-primary button. Now, traditionally in CSS, you would add a class to the second one to differentiate it from the others. And that actually works in styled components just fine. We just don't kind of, this isn't the best way to do it in styled components because we're working with a React. And so we have props. And props are much more powerful than classes because props can be typed, props can be validated, classes are just strings. And here, the little magic that I'll show you is this props primary interpolation here. And so this is a multi-line string. Well, it's actually a tag 10, which means that we're able to take that function and delay it and execute it later when the function is created. So it looks like it's a little bit of magic, really. There's a bunch of little things happening behind the scenes to make this possible. But what it lets you do is think about code in the same way as what was on the left, but use a real JavaScript construct. The advantage of that is that now any kind of dynamism, any kind of dynamic changing in the CSS just uses JavaScript. So instead of trying to re-implement variables or mix-ins, functions, anything that I would have used in SAS, you can now just use JavaScript. And this is particularly good for people who don't do JavaScript but may have done SAS because they can learn one principle, which is the interpolation, and then suddenly you're giving them a way to start learning more JavaScript, which is a much more transferable skill. Of course, if you follow the platform, then the platform goes places and you can go with it. So we've already seen talks this morning about React Native. React Native is not something I've spent much time with, but because it offers the same API as React for the web, we're able to generate a style components version for Native. Something I want to mention here is that when Facebook released React Native, they went to the effort of implementing Flexbox for React Native. Now, Flexbox doesn't exist on a native device, but they implemented it in C, I think. And so you could use Flex terms to lay out your code to make things a bit more transferable. And it's that kind of effort that I'm trying to replicate with style components, which is you make it look like CSS, it's a bit easier for people to start using. So yeah, you can use style components for Native, no problem. After Native, there are other things like React XP by Microsoft cross-platform, React primitives. We have a Primitives endpoint, which lets us also do React Sketch app, which if you haven't seen, is a way for using React code to generate sketch components. Again, I don't know, I haven't used this myself, and I don't really understand where this is going, but we can kind of, as a library, because we're kind of very native towards React, we can follow it and we get all that benefit from it. So that's the third principle, is if you follow the path of release resistance, you follow the platform, you get all the benefits from it. The fourth and the final thing I want to talk about style components is zero configuration. Now, this is something that's very close to my heart. I have spent a long, long, long time configuring Webpack and Babel. I've lost many good hours and days. And it's worse than that, because if everything's configurable while it gives you lots of power, it means that every app is gonna be different. So you can't move between apps as easily if they don't share a common build structure. And there's so much complexity in your Webpack config that that can be a huge barrier to moving people between projects and bringing people onto your project. So I'd like to take this opportunity to shout out my favorite project in the React ecosystem, Create React app, because it offered an alternative. This is the first project, I believe, or the only project, I believe, by Facebook open source that they don't use internally. It is just for the community. And it was in reaction to the idea that these boilerplates are getting out of control, these complexities are getting out of control. So they took the effort to kind of become stewards of the community that they hadn't done as much previously and set a baseline of these are the features that should be in for a modern front-end stack. And it was really Create React app coming out that inspired style components in the first place, because I already had worked on CSS modules, which required Webpack config changes, and they didn't include that. So I wanted something that was 100% JavaScript, didn't require any config changes. Now we do have a Babel plugin, and it does offer some stuff like it increases, it makes it a bit easier to understand your compiled class names. It is important in some cases for server rendering, so we recommend it in all cases. And for version three, which is coming soon, I don't know when, it will improve performance quite a lot. So those are the things that you might want to use that plugin for. So just to recap, the things that are in style components that I think are also important for general library design are these four. And it's been quite successful. So we're now the number one CSS and JavaScript library. Support React and React, no problem. We're almost at 400,000 downloads a month, which is a really scary high number. We just crossed over 10,000 stars in GitHub this morning, but what I'm really excited about is that the project feels quite healthy in the way it's being managed. So 140 contributors so far, we've got this team of three behind it. Max and I started it last year, but it still is joined and become an integral part. So it's a good thing to use, you should go use it. The last thing I wanna talk about, which kind of is more broad than style components, is this idea that if you're going to be improving something, you're gonna be putting things in, you have to be aware not to make things worse. And for my purposes or any CSS and JavaScript purposes, you have to think about what you're doing to your JavaScript bundle size. The more you use JavaScript, the further down this kind of graph you get. And this is just parse times for JavaScript on a bunch of different devices. So we need a good strategy. And I think this applies to all React UI, not just CSS and JS, although CSS and JS makes it worse. That we need a better UI. I think the, I don't have a lot of time, so the golden rule for me is just as long as you serve HTML, you're doing okay. You can do as much of stuff, like you put more and more stuff into your JavaScript pipeline but keep serving HTML. Because HTML is what web native is. It's much more than just the content on the page. It's also the metadata for the browser, like the title, it's the resources. So the browser can be optimistically fetching these things that are probably gonna get used. It's the sharing metadata so that when you paste a link you can slack, it just works. All of this stuff contributes to a page or a web app feeling web native or not. And so rendering HTML I think is really important, just more, not just for performance. So there are a couple of ways to render HTML using a React app. Gatsby is a very popular static site generator. Next.js is kind of fairly new still about it's a server side rendering framework. Both of those are pretty cool. React Snapshot is the one that I'm working on. React Snapshot is basically like a static site generator that doesn't require you to change your code. You, it's basically you just run your React app in a browser and take a snapshot. Go to every page in your app, take a snapshot and then React will work as if it was server rendered. It's kind of like ahead of time server rendering. But that's a project that I've sort of been working on a little bit, I haven't had enough time to really launch it, but it's something that I think is gonna become a big part of it. And it's sort of it's this idea of being able to use JavaScript but still serve HTML is really important because it leads to this idea that you could invent something that doesn't have a downside, right? I hate this idea that we're always like everything you add is a trade-off because it's oh well it's good at this but it's bad at that. The idea is that when things really move forward is when there's really no downside. Everybody can use it and it's great. So that's what I wanna finish the talk with. Let's talk about the road ahead. Where is all this leading, right? And why are all these things important? I think for a long time we've had this idea that there are two types of projects in front end, that there are web pages and web apps. And really, while they might, things might feel like they're on a spectrum either more to one end or more to the other, how interactive they are, how public they are. Our tools don't lie on a spectrum. Our tools are really heavily bifurcated along this divide, right? So with a web page, it's a web native thing. It's gonna be static HTML or it's gonna be rendered from a PHP or Rails app. You might not use much JavaScript and if you do it'll be progressively enhanced. You'll take care with your meta tags. You will have a small build step maybe using Gulp or something. And it's very performance sensitive so you're very conscious about that stuff because people are deciding whether to use your site and move on. Whereas the kind of traditional web app is something that might be behind a login screen. So people are gonna wait until it loads and they're gonna be there for a while so you can render it all with a client. You can build it using React and you can not kinda worry about metadata or titles and stuff. And then you can have this really complex and really performant, excellent webpack config that does everything you ever need. And what this amounts to is making it quicker for you to develop features which is really important and that's kinda the most important thing for those kinds of apps. The problem I see with this landscape is that you can't share. You can't learn from each other. So when you come to build a new marketing page or a new static page or a different project you can't use any of those tools. And all the people who work on those pages they can't contribute to your React app. So when the React app needs more people you have these great people who know the web in and out but they've never learned anything. That helps them contribute to that weather. And it goes the other way as well. So you might be doing JavaScript. You might have people who are doing JavaScript apps for a long time who then move across and start doing web pages. And there are a bunch of things that they've never really considered about web native, HTML, SEO, meta tags, that sort of thing. So I think what the road ahead is the most immediate step on the road ahead is the idea that these two things can be combined. So you can use the same set of tools to work on any web project. And because you can render things to a static HTML page and you can even delete the React code out of that page if you want, then you should be able to consider one kind of tool set for every project. And that will help I think everybody kind of share. I think the new project for Mark, my friend back in Melbourne is to try to extend this even further to designers. So the designers and coders and all the different projects can all kind of contribute to one big code. It's this idea of unification of skills and a unification of platform. And so everybody can contribute to one set of development environment. And then that development environment can export things for the web, for native, for desktop, for VR, for everything, right? There's one kind of unified workflow. So in the far distance, I can see it's very hard to know what it will actually look like, but I believe it will have these things in place. I think it'll have all of those properties that I've tried to implement into my little piece of it, my little CSS library. It'll have these best practices. It'll be inclusive. It'll be able to do everything and be able to use it everywhere. And so that is all I've got. Thank you very much. I need to take lots of questions, but I would ask each person who asks a question to stand up because this is getting live streamed. And we wanna see your beautiful faces. Also, please make sure you hold the mic in front of you, like you're a jazz singer. If you hold it like this, we can't hear you. I'll also be downstairs in the workshop space during lunch if you wanna come ask questions one-on-one. How different is this from the glamour set of things? Glamour, glamourize? Yeah. Yeah, they do a lot of style components kind of thing as well. Yeah, it's one of the great things about CSS and JavaScript is that we, like because we're all sharing this kind of platform and we're all benefiting from the React ecosystem, it means that if some library implements something that looks nice, other libraries can take it and can put their own spin on it. And so there's really a lot of similarities between particularly glamorous and style components, but we have a slightly more restrictive API in order to force people down this way of conceptualizing CSS. Glamorous is much more, is a little bit more flexible, but it also forces an object syntax, which I think is a barrier to entry. But really, if you jump across to CSS and JS, most of the time you'll be able to move between them. So whichever is, you think is the best is a good choice. Okay, so like you talked about style components and glamour, right? The main difference I see in style components is that you kind of force the user to create a new component for each style, and which is for me a bit uncomfortable, but more importantly, I see that it adds an overhead in pastimes, especially which is a really large in mobiles. So are you like doing anything about it, or is that on the roadmap? Yeah, actually that's a good question because that's one of the most intrinsically difficult things about this methodology is, the reason things are broken out into a component is because I think it's really important to give those components names. So I want that render method to read really clear. And I think it's fine to use a name like wrapper or outer or thing or anything. Like it's better to put a name on something. It's better, it's more likely to be documenting what it's doing in terms of your CSS because a lot of time you do need expert divs, you do need X or Y. So the whole point of hoisting things into a component is around design for developers. Now that said, if you do have tons and tons of these things, creating these React components is a performance problem. In fact, the work that I've done so far on style components performance is that that is the problem. None of the CSS injection stuff or the parsing of styles or anything like that is actually that big an issue. It's creating all the extra React components. And so that's an area that I'm working on to try to look and optimize components that don't need to be a full component. So you can write them as if they are, but then the Babel plugin can just rip them apart. And so then they just disappear. So I'm not planning to introduce a new design to make it easier to write or different way of writing the components. But it's certainly within scope to just compile them away. So there's no performance impact. Yeah, that's an area of research at the moment basically. Hey, so towards the end, you talked about having a unified UI language or having a unified platform, right? And so I want your opinion on where do you see this going? Will we end up in a place where the controversial question of should designers code comes up, right? Or do you see, so basically my question is, do you see unification or new tools coming up? Do you see designers moving to more developing like react component world? Yeah, I had a question at another conference which was basically like, what are we doing to make it easier for somebody? Like, so if you say, yes, okay, designers should code, what's the first thing that they run, right? And there's no reason in my mind that that shouldn't be a single file that looks like HTML and CSS, but is really react components, right? Because JSX isn't any harder to understand than HTML and style components isn't any harder to understand than CSS. So the idea of building the tooling, so it's like, yeah, okay, the first code that you write, look, you know, it's the same as HTML, CSS, except it's using all these things behind the scene, which means when you have to make it a little bit more powerful, you can use all these tools rather than having to leave, right? And so I think the same thing will happen with design tools as well. There's this kind of merging of these things, knowing that a component is actually a really reusable piece. So the quicker you can be writing components, the better, but that doesn't mean you have to be writing code to do that. It does now because we don't have design tools that are good enough, but I think that convergence is gonna, it needs to come about through these new technologies, yeah. Thank you. Hi, the main like issue that I have to move to style components and things like that is, does it support vendor prefixes and like till how many versions that it support because we can do it very easily in webpack as well. So does style components support vendor prefixes? Yeah, we have the vendor prefixes turned on by default. There's no configuration at the moment and they probably won't be for a little while. We support down to IE 10, I think, which is the default stylus, which is our internal or so separate project, but it's what we use for CSS processing. So auto-prefixing is always there, but it's a dedicated set of browsers. Generally, what I've found is that if there is a particular prefix you need, it's better for it to be hard coded because if you have some component that has some weird behavior on browser to browser, better to wrap that in a component, have that line of CSS there, have a piece of documentation saying this is really important for IE 8, don't change it because it's a lot easier to break something just by changing a webpack config if you don't really understand why these prefixes are important. So a baseline of down to IE 10 seems to work really well and then if you need anything beyond that, yeah, you basically do it by hand. So is there any provision going to be there in the roadmap ahead to give the user the control over it? No, not at the moment. We just had this discussion about a week ago. I was arguing I wanted more control, but every time you introduce controls, the same thing, principle line, create, react app. Every time you add some control, you weaken the shared experience for everyone. And the idea with prefixes are, honestly, yeah, the base set of prefixes are annoying to do it by hand, but the specific stuff beyond that is actually okay. It's not actually that much, that difficult to just do it by hand because pretty much every order prefixes default setting is down to IE 10 at the moment, so. Anything else? Oh, one over there. Hey Glenn, thank you for coming down. That was a really good talk. I just had a very specific question with regards to React primitives. Do you see React primitives? Oh yeah, primitives, yeah. Yeah, do you see that being kind of the future of the reusable cross-platform UI that you're kind of speaking about? Yeah, it is, but I don't like it so much. So it's like, it's definitely on the path, but I'm not ready to start, I don't know, I don't know. I'm a bit conflicted by it. In the same way that I'm conflicted by the project, React Native Web, again by Nicholas Gallagher, which is that it feels like a little bit too much. Like I work on the web, that's what I inhabit. I know all of the problems with the web from my history, I don't know them all because I haven't hit them all yet, but I feel like the web is a special, kind of unique environment, and therefore I'm a little reluctant to start trying to abstract it away. React Primitives is probably, something from there will end up probably being better, but at the moment I'm not kind of ready to jump across yet. Just a follow-up. So is that fair to say that we won't see anything on the roadmap soon, like support for style components for React Native for Web or React Primitives? No, no, we already do. Through React Primitives, we can target React Native for Web. So if you're already using it, you can just use it. Is this the style components slash primitives thing? That's right. Oh yeah, thank you. Yeah, if that's not working, tell me else. That's supposed to be working. So how do we change other components style on hover of another component? Yeah, so this is something that came in in version two, so you can have components reference each other. I didn't put an example in, but basically in the same way that you would use a nesting rule, so within some component, colon hover, next component styles, you can do that within interpolation. You can use this class specifically. Yeah, you can use a style component in an interpolation and it'll just put the class name in. And so it'll work, basically. It's a bit hard to explain, but if you go there and you look at it and you try it, kind of what I'm going for is the first thing you try should work, because it's like you just put it in and it should just work. And it's really hard to try to build for that, but yeah, it does work. It's something that we added for version two because it's really important. The one thing I will say is that you should try to make the child component reference the parent, not the parent with the child, just as a good kind of practice. It's much worse if you have these components that reach into other components and change them. It's much better to be like this component. If my parent does something, I change. And that's like, we don't enforce that, but it's just a good rule of thumb. I think we have time for one last question. Hello. Hey Glen, that was a great talk. I just had one question. Is there anything in the pipeline to enable the poor CSS transforms on the style components? No, no. Initially we built style components using post CSS because it was the easiest thing. But even then we weren't allowed, we didn't allow it to be altered. My assumption is, and it's currently okay, is that everything you could have done with post CSS, you can do somehow better with JavaScript. Now we have all these new tools. Post CSS is very much kind of of the day of having a CSS file transforming it to a new CSS file. And that model doesn't work so well. So a lot of those post CSS transforms kind of have the wrong assumptions. There is one thing that I wanna put in that I haven't had a chance, which is right to left transformation. Which is, I've not actually run a project using it, but I've talked to a few people who have, and it's the sort of thing where doing it in the CSS pipeline is actually really handy. And doing it with changing every JavaScript thing to be an interpolation would be a pain. So that's something I really wanna work on. And then that basically, yeah, if there's other things that are really good in post CSS, it's better for us to port them than it is for us to enable people to transfer. So if there's something in particularly wanna use, you can raise an issue and we'll discuss it. Because then everyone gets it, which is good. Is that? That's it. Okay. Woo. Thank you very much, Glenn. Thank you very much. Thank you very much, Glenn.