CSS-in-JS — Max Stoiber

CSS-in-JS — Max Stoiber


Thank you. Just to make sure everything is working. If you’re called Michael and you’re in the
room, raise your hand. All right. Awesome. That includes my Mike check. [ Laughter ]
Thank you! Thank you! I love how one person raised their hand. That’s awesome. Thank you. So, I’m here today to talk about the past,
present and future of CSSinJS. Now, my name is Max. Like she said, I came all the way from Austria. I currently work at Gatsby. If you have troubles with Gatsby or issues
with it, please don’t come talk to me. I just started working there three weeks ago. Previously I was ate GitHub, another site
you may know. And I’m most widely known for creating a bunch
of open source projects like style components and React boilerplate and polished and some
others that you may know. I love open source. And that’s kind of what I’m here to talk to
you about today. What’s the problem?>>It’s extended. MAX: Okay. This should work then, right?>>That’s okay. MAX: apparently my mic check wasn’t successful.>>This one…>>Can I
MAX: There you go. What are we looking
>>I was a bit too keen. I really wanted to get off stage as quickly
as possible. I’m sorry for that. MAX: No, I don’t.>>So, he travelled out of state for the who
here travelled out of state for the conference? Oh, welcome to Sydney. It’s okay. It’s not Melbourne. Melbourne’s all right, weather’s okay, I guess. Yeah. Yeah, overcast. I don’t know. Like, you can maybe come back next week. It’ll probably be better. But who travelled out of country? Oh! Australia’s pretty good, I think, yeah, yeah. You guys enjoying it? Yeah? Ah, nice. Well, anyway. How are you guys going? Yeah. [ Laughter ]
Yeah. Yeah. Well, that’s fun. Yeah. Oh, unicorn Gaytime. Yes, we were discussing this, actually, like
for real. Look, I don’t know, there’s all the new flavours
of the Gaytime like the salt Gaytime. I don’t know, there’s the classic. To me, honeycomb, salty I don’t know. If it ain’t broke, don’t fix it, right? But, yes. But, so
MAX: All right, fixed up. Sorry about that.>>I mean, I’ve got so much more to say. MAX: There you go. I’m sorry, I’m sorry for kicking you off. [ Applause ]
Sorry about that. Anyways, I’m Max. If you want to follow me on Twitter, GitHub,
Instagram, mxstbr which is may more difficult looking than it is. My name without the vowels. Take out the vowels of my name, you’ll have
my handle pretty much everywhere. I’m here to talk about CSSinJS. First, I want to show you what CSSinJS looks
like. This is style components. We define a type of component that’s a style,
a colour, pale violetred. And we can now use this throughout the React
application and render a colour of pale violetred and 24 pixels. Watch the slides, this is a quick animation. The CSS gets hashed and a unique class name. You get a bunch of benefits. Specifically, there’s a couple reasons why
I like CSSinJS. The first one is confidence. I can practically add, change and delete any
CSS I want. And I know it’s not gonna have any unintended
consequences. Because every piece of CSS is bound to a specific
component. I know it’s only ever gonna change that specific
component and nothing else. That leads to very painless maintenance. I never have to go on the hunt for a weird
class name somewhere in my dozens of stylesheets that affect my component somewhere way down
the tree. All modify styling that affects that one component
is right there in line and that is all of it. And I know it is all of it all the time. There’s another very important point here,
which is because every piece of CSS is bound to a specific component, when I delete that
component, all of its CSS will be gone too. That means I never end up with a appendonly
stylesheet. If you have worked on a codebase with a not
well taken care of stylesheet. You can’t change anything about the CSS and
keep adding stuff at the bottom. Never changing anything. That cannot happen in CSSinJS at all. Whenever I delete or change anything, only
that specific component is affected. That is awesome for teamwork. Because not everybody in my team has an encyclopedic
understanding of CSS. Not all of them are experts at CSS. And by using CSSinJS, we avoid common problems
like naming collisions, weird overrides, specificity issues that might pop up. We’re essentially helping them move in the
right direction. This is particularly valuable if you have
a bunch of juniors on your team who are very unfamiliar with CSS. This way they’re essentially guided towards
the right thing. The next point is fast performance, which
some people might disagree with. I’ll tell you where I think CSSinJS is great
for performance. You can keep track of which components you
actually use. Which means we never inject more CSS than
you actually use. So, if you’re serverside rendering, the stylesheet
you’re sending over the wire is the critical CSS for every single one of your pages. No matter which pages the user hits, they
only get the least amount of code possible. It doesn’t get much faster than that. And then it’s also great for dynamic styling. If you have any theming needs. If you have any sort of multitenant application. Theming in CSSinJS is highly dynamic and you
can pretty much change anything at any point in time which is awesome. The big overarching point of CSSinJS is that
it guides you to the pit of success, right? It guides you towards the right direction. That doesn’t mean you can’t fuck it up. But you are gonna avoid a bunch of problems
that you might have had otherwise. So, that’s why I like CSSinJS and why I’ve
invested a bunch of years into building different libraries that are now pretty widely used,
like Style Components. So, at the moment, 60% of React installs also
install a CSSinJS library. Which specific one that is isn’t important. But almost twothirds of all React apps are
built with CSSinJS. And particularly, lots of big companies use
CSSinJS in for their design systems and for their apps. Which is great to see. However, this wasn’t always this way, right? And so, I want to go back a little bit and
talk to you about how we came here. It really started out in 2014. In November of 2014 two important things happened. The first was that Oleg from Berlin published
the very first ever CSSinJS library called JSS. Now, JSS was way ahead of its time. Way ahead of its time. To this day, the rest of us, the CSSinJS libraries
are picking up on the things that Oleg built six years ago, which is incredible. The other important thing that happened is
Ed that worked at Facebook on the React team gave a talk at a small conference in Washington,
D.C. called Nation JS. And he talked about how Facebook uses CSSinJS
to manage styling at scale. That talk blew up in the web Dev world. If you were on Twitter back then, that was
the only thing you would see for pages and pages and pages. All of them basically calling him a complete
idiot and what the hell Facebook was thinking. It was supercontroversial at the time. Now with the benefit of hindsight six years
later, we know that it’s worked out kind of well. But at the time everybody thought, what the
hell is this guy doing? And formidable apps had another CSSinJS library
that was slightly different than the others. What Radiant did is add inline styles. Rather than a class name, they were adding
the style attribute with the CSS in it. Now, if you have ever used a style attribute,
you know that you can’t do all the things you want to do with it, no media queries,
no CSS select, none of the advanced magic can be done with inline styles. Radiant tried to hack around with JavaScript,
and we know six, five years later, it was not the best approach. It was a great step otherwise we might be
on this approach nowadays. In 2015, Brent Jackson launched rebates. If you see him, tell him he’s awesome. Rebates is awesome. To this day, that great library that introduced
and popularized the CSSinJS components. You add props to like colour blue. In May of 2015, CSS modules by another person
in the room, Mark, and Glenn. It’s not technically CSSinJS but I’m mentioning
because they popularized outputting unique class names. The way CSSinJS and CSS modules hash through
CSS and use that as a class name in you’re never going to gets two class name duplication. If the class names are the same, the CSS has
to be the same. Which was huge and awesome. Modules, still awesome, still used by tonnes
of people. A couple of months later, CSSinJS. It never went anywhere and deprecated now. But they were the first ones to allow you
to write CSS’s actual JS in. And they made you write it in the JavaScript. It was very nice, but never picked up any
steam In October, we then got Aphrodite, it popularized
critical CSSinJS extraction. They were the first to realise that actually
because we know which components are used, we can just inject the most minimum set of
styles possible, right? Which was huge for that performance across
the web app. And again, can have Aphrodite was super awesome,
still today. Still used by tonnes of people. In June, Robin Fishman announced the style
being a function of your state. Like React popularized a view being the state. With fella, you could update based on your
state, which was huge and works well with the React way of thinking about state. In July, slow pie then announced Glamour. What he did is he dug deep on performance. And there’s this very obscure DOM API. And you’ve probably never used called insertrule. And with insertrule, what we did before was
we just injected a style tag into the DOM and set the text contents to whatever we wanted
the CSS to be. What they found is we could use this insert
rule API to insert CSS into the DOM much quicker because we skipped the DOM and went straight
to the CSS. That was huge for performance. Glamour nowadays is deprecated and recommends
other libraries now. It’s honestly still an awesome library today. In October, GSX style was launched, 2016 now. Where they essentially took the rebase CSS
components API and went even further and added practically the ability to write any CSS as
props on a component. Again, GSX style still awesome, still being
used, great library. In the same month, I got on the stage at ReactNL
in the Netherlands and announce with Glenn Mattern style components. We had this style.div API. Which hadn’t existed. Style components, still awesome, super best
library ever. Just use style components. Forget about the others. I’m not sure why I’m talking about the others. Just kidding. No, style components is still being developed. I use it but, you know, just saying. I’m just kidding. Two months later, Ryan who built the CSSinJS
at the start announced styletron. He works at Uber. It popularized outputting atomic classes. Atomic CSS has a class name for CSS top zero,
and colour blue. It takes the normally win CSS and compiles
it down to atomic CSS to limit the amount of CSS that’s output and give you even more. And then the style JSX into style GSX. They mimic a style tag. You can write it in the React tab and take
the class names and make it unique. It is unique. You’re writing CSS how you’re used to. And then style GSX comes along and makes it
all unique and fixes it all for you. In March of 2017, almost half a year later,
we got Astroturf. And Astroturf was the first CSSinJS to make
this concept of composing and writing your CSS in JavaScript. But then they extracted out to a static.CSS
stylesheet that you extract as a file. It works better in some. And then at PayPal, glamorous. It was style components that had sort of taken
off at that point and we only allow you to write CSS as strings the way you’re used to
writing CSS. And so, glamorous went ahead and it took that,
but had the same style and API but let you write CSS as objects because they preferred
that. Glamorous is no longer maintained and other
libraries are recommended. But it was a superawesome CSS and pushed all
of us to support CSS as JavaScript objects. Then in May of 2017, style components v2,
but the important part isn’t style components. It’s stylus. There’s a guy in Africa called Fhi Sultan. He built a CSS parser in JavaScript that is
supertiny, superfast and superreliable. It’s called Stylus. We switched to it with v2, which essentially
cut our bundle size by 90% or something. And made us more performant. And now all the CSSinJS use stylus. All the performance benefits wouldn’t be a
thing if it weren’t for Stylus. I’ve never met him, but I want to give him
a hug because he is incredible. Then in July, we got Emotion, also by Mitchell
and Kai. Mitchell is in the audience. We have lots of CSSinJS people here. Just realised. That’s awesome. Emotion really kicked off a huge performance
competition. At the time all of the CSSinJS libraries were
like, yeah, sure, performance, it’s cool. We like performance. And then Emotion came on to the scene and
was like, we’re 10x faster than everybody else. What are you doing? Why aren’t you this fast? To their credit, everybody has gone much,
much faster now. We’re at a point where everybody is the same
speed, everybody is superfast. But at the time, it wasn’t the case. They kicked the community in the butt and
were like, you guys got to work on this. You’re slow, we’re fast. And then we got linaria and extracted it into
a stylesheet even further with the components API. Still awesome, still being used. Then a year later, Emotion v10. They introduced the CSS prop API. You can put the CSS prop on any element that
you write, and you just write your CSS in there which is an awesome API and that nobody
really thought of before. And then again, almost a year later in June
of 2019 we got Theme UI. Also, Brent Jackson, still in the audience. Theme UI really took this concept of theming
and took it a step further by adding interoperabilities and popularizing this idea of sticking to
a theme shape to interoperate with any given component. Now, as I’m speaking about all of these libraries
here, you’ll notice I love all of them. I don’t care which one you use. All of them are great, right? This community, from the outside, might look
like we’re all constantly bashing each other and hitting each other over the head, but
all of these people, we all collaborate with each other all the time. We’re pushing to invent new APIs, to get faster,
to talk to people and realise what they want. It’s awesome. I’m so glad to be a part of this awesome group
of people pushing the web forward. Now, that’s cool and all. But what’s the future? And the answer is, I don’t know. If you look back at the timeline, you might
notice that over the past two years, it’s been kind of quiet compared to before that. Not really that much has happened. We’ve gotten two big new releases. And obviously a bunch of minor versions. But really nobody’s come up with any new ideas. We’ve sort of stalled a little bit. In 2015, ’16 and ’17, it was constant. Everybody had a new innovation it felt like
every week. It was awesome. The reason I’m standing up here and giving
this talk, is we need you to create the future of styling React apps. We’re not some kind of magic people who invent
stuff. Right? We just had ideas. If you have an idea. If you think you’ve got a good plan for how
you could make styling your own React app easier, build it, share it, show it to me. I want to see. We have reached a limit, a plateau, and I
want us to go further. Now, it you do actually sit down and create
a CSSinJS library, please do that and send it to me. I want to take a look at it. I’ve got a couple tips for you. This applies to any open source project, but
I’m really talking about CSSinJS libraries here. There’s a very common progression with CSSinJS
libraries. They start out with making it work. The first Style Components version was a horrible
hack. We took postCSS, a thing that should be run
by Node, and we made it run in the browser. And we used that to compile the CSS down. The first version was a horrible hack, but
it proved that we could make that API work. It proves that API could be a thing. And what we did then was we shared it, we
talked to people, we got feedback, we listened to the problems with it, the people that were
using it. We kept improving it. Then the next step was that we made it right. The first version, we got some of the APIs
right. But some of the APIs were kind of bad. And so, we’ve progressively changed them and
moved them to better APIs that give us certain other benefits. So, the next step was that we made it right. And then the third step was that we made it
fast. That was when we started focusing on performance. Looking really deeply into all sorts of optimizations
and kicked off by Emotion and made it super-fast. And I feel like open source projects should
start off this way. There’s no point in overengineering the library
and spending months of effort if it’s not the right API anyway. And the only way to figure out if it’s the
right API if you share it. And people come back and say, this works superwell,
I don’t mean this part. And you engage in a conversation. That’s how you make a great open source project,
right? That leads me right to my second point. Share early and share often. Share that hackie prototype that you whip
up. Share that horrible code. Nobody cares. The first version of Style Components was
a mess. 200 kilo bytes, it was massive. It was badly architected. Did it matter? No. We were trying to make it work. Trying to share it to see how to make it right. It didn’t matter. We share would early and we shared often. And that’s why we got so much feedback and
that’s why style components is as good as it is nowadays. We shared early and often and listened to
the feedback that we got back. And a third and very important point that
many people miss is you have to document all the things. And I mean all the things. When we initially launched Style Components,
I spent way for had time on writing the documentation than building the library. Because if you don’t have documentation, nobody
is going to use your library because they don’t know how to, right? You need to document all the things. And whenever I look at open source projects
that have a readme that says, npm source library. That’s it. I just go, what are you doing? Like, nobody is ever going to dig into your
source code, right? People just want to solve their problem with
your library. They don’t care about your source code. Document all the things. All right. So, to summarise, please build more CSSinJS
libraries. If you have an idea, talk to me about it,
I would love to hear about it. And if you do end up building an open source
project, make it work, make it right, make it fast, share early, share often, and document
all the things. Thank you. And I hope you’re going to have a great conference. [ Applause ]

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *