Moving on From Runtime Css-In-Js at Scale

Rate this content
Bookmark

In this talk, Siddharth shares the challenges his team faced with optimising runtime css in js (styled-components) for performance. At GitHub, there are about 4000 React components that contain styles, Siddharth dives into the reasons for rethinking styling architecture, the challenges faced and lessons learned by migrating a big application.

29 min
02 Jun, 2023

AI Generated Video Summary

This Talk explores the evolution of styling architecture, dynamic theming with style components, and optimizing style updates. It discusses the challenges of CSS migration and the choice between JavaScript and CSS native tooling. The Talk also touches on CSS tools and libraries, including Tailwind CSS and CSS in JS major libraries like MUI. The importance of picking a stack based on team members' strengths and the use of namespacing CSS for conflict-free dependency trees are highlighted.

1. Introduction to Styling Architecture

Short description:

Earlier this year, I found myself thinking about components, styles, and the amount of JavaScript needed for rendering. Assigned the task of figuring out the styling architecture for Primer React, which powers GitHub. The challenge was that any change would have cascading effects on all of GitHub. Let's explore how we got here and the state of the styling infrastructure.

I have a lot of slides, so I'm going to be very quick about this. Earlier this year, I found myself thinking about components, thinking about styles, but also thinking a lot about the amount of JavaScript we needed to render our styles. I was going on this spectrum of JavaScript on, we should have very little JavaScript to do our styles, do we actually need a lot more JavaScript to do it? I just spent a lot of time just tilting in this one line.

How I got there was, I was basically assigned this task. Which is, figure out the styling architecture for Primer React. What is Primer React? Primer React is the design system that powers GitHub. I'm Siddharth. I work on the design engineering team at GitHub. This was one big, it's funny that we call them epic, because it was kind of an epic task. And before GitHub, I used to work at all of these companies and for the last six years I've been basically working on design systems and component libraries. Fun fact, just like React, I also started my career exactly 10 years ago today, so thank you for that. I appreciate the balloon. Thank you.

All right, so, back to the moving slide. And why this was such a confusing task? Because when I was trying to figure out the styling architecture for Primer, it ended up being the styling architecture for a lot of React at GitHub. Any tiny change that I make would have cascading effects, get it? Cascading? Effects on all of GitHub. And that's a scary thing to do. So let me first talk about how did we land up in the space that we are.

This is not just GitHub. This is mostly the entire styling infrastructure. Think about it. It's 2015, and this meme just came out. This is that old. The best movie of all time, Mad Max, was also released in 2015, and Drake gave us this extremely cool song. Internet Explorer 11 was still around. Edge wouldn't be released until later that year. Which also means things like CSS variables that we take for granted now weren't actually supported in much except maybe like Chrome or new Firefox. I think Firefox is the first that implemented it all the way in 2014. Different times. You require very little JavaScript to get your styles done.

2. Styling Architecture Evolution

Short description:

You write your style like this. This is a button component. You put your colors, put your padding. With a little amount of JavaScript, you could nest your styles and compile them out to CSS. React introduced the concept of defining components in different files and creating a dependency tree between them, allowing for smarter bundles and elimination of dead code. CSS modules further enhanced this by creating a one-to-one relationship between component JavaScript and CSS, enabling efficient bundling and dead code elimination.

You write your style like this. This is a button component. You put your colors, put your padding. You see a lot of hex codes, pixel values hard coded over here. This isn't as nice as you'd like it to be, but there was some tooling that existed.

I put it on like slightly more JavaScript because you have to use Node.js and the compiler for JavaScript is written in JavaScript. With a little amount of JavaScript these are the kinds of things you could do. You could nest your styles and have slightly better DX and then you could compile it out back to CSS.

The other thing that you got was variables. You could define these variables in a single place, which is huge for our design systems. And then in our components you could just use those variables. So when React came around in 2013, and then when we started using React, you would use it something like this. You have a button component and it uses the class name. And then you could use this button component in another type of page.

The nice thing that we just did, by defining a component in a different file, and then using it in a new file, is that we've created this relation. We've created a dependency tree between components. And that helps us create smarter bundles, eliminate dead code. You get a lot of tooling from that. But the same kind of tooling doesn't really exist for... Or didn't really exist for CSS.

This class that is coming from button, there wasn't really a good way of knowing which file does it come from. You would just have to guess and bundle a lot more CSS. That of course changed very quickly with just a little more JavaScript with CSS modules. So you could configure CSS modules, you could basically fake an import, is what I'd call it. Because there is no actual CSS import that's happening this way. But we are creating a dependency tree. So now that your CSS dependency tree matches your JavaScript dependency tree, you get this really nice one-to-one between component JavaScript and CSS. And then you can bundle them together. You can tree shake them, you can eliminate dead code very quickly.

The next interesting thing that gets to is even though you have variables in Sass, wow, I see your eyes, I'm sorry about that.

3. Dynamic Theming with Style Components

Short description:

Theming is not just about light or dark mode, it includes different types of color blindness and other themes. With Sass, you would have to generate multiple theme files. However, with JavaScript and style components, you can define classes with JavaScript variables in the middle of CSS, allowing for dynamic theming.

So when you have to do multiple theming, and theming is not just about light or dark mode, theming is there's light mode, dark mode, there's different types of color blindness, same goes for dark mode, there's dark dimmed, so you have a lot more themes. And with something like Sass, because these variables are compiled out at build time, not on runtime, you basically have to generate a lot of theme files for each one of them. So you would have your component library in light, you would have component library in dark, you'd have component library in Teletopia, so you end up creating all of these combinations. But with a little more JavaScript, we could actually do this on runtime with something like style components. Because JavaScript already had variables at that point, CSS didn't. So you end up in something like this. Where instead of writing class name, you define your entire classes with style components, and it kind of looks like CSS, but it's not CSS, and you get JavaScript variables in the middle of CSS. So you get a lot of nice things. You can refer to your theme and this theme can change on runtime and propagate all across.

4. Theme Provider and Style Overrides

Short description:

Some of you might already be using this style. You can wrap it with a theme provider. Adding additional colors can be challenging without a way to check if they are defined and applied. TypeScript helps catch errors and provides autocomplete. Customizing components with style components can be a lot of work and diverge from the original source. The SX prop or CSS prop allows for inline overrides, merging default styles with overrides. It provides type completion and offers features like nesting and linting. The success of this approach has led to thousands of presentational components on GitHub using the SX prop, causing some challenges.

Some of you might already be using this style. And you can wrap this with a theme provider that takes care of the rest. So something that's interesting is if I add this additional color, I kind of don't really have a way of knowing is this first, is this the right color, is this color defined? Second, is this color going to be applied? I kind of have to write this, render into the browser, see if it works. It probably is just black, so I right click inspect element, and that's when I get to know if it's the right color.

So we add a little more JavaScript and we type script. And with type script now what you get is you can type your theme and then you start getting the red squiggly line, which tells you that this property, FGHover, is actually not even defined on theme, so that's not the right thing to use. And then you can fix it. The other thing, if you haven't noticed, is I kind of messed up somewhere in the slides where background color is just, on hover, it's just pointing to the button background and not the hover background, and with theme, because now you control your theme, you control your styles, you can actually type them smarter, and it can give you smarter errors. For example, border color, I'm using button.bg, which is not actually a valid style, which is not actually a valid color variable in our component system, so we can give you these errors, like, this is not the right one, maybe you meant button.borderColor. Same goes for hover style, it says, HellasPentaCast, a type, themeColorBackground is not assignable. You have to use hover background. And because you have TypeScript, you have a compiler behind this, you also get features like autocomplete, which help you pick the right hover backgrounds.

So customizations are still interesting. This is the default, or the recommended way of customizing components with style components, where you wrap the button component in a style and then you can add your additional styles there. So something like this is nice, but it's also kind of a lot of boilerplate, it's a lot more work. I'm not a big fan of this style because it kind of diverges from the button. You'd have page button and then other thing would use the page button and you kind of get further and further from the original source. So, with just a little more JavaScript, this is team UI's logo, but team UI, system UI, this class of libraries made this syntax popular which is the SX prop or the CSS prop. And with this prop what you do is instead of defining a new component you define your overrides at this component usage level. So it's kind of like an inline tag but it's not, it compiles it down. So what you end up getting is something like this where your button styles are the default styles and then you merge them with the SX overrides styles that are provided. And of course you type the SX so you get the same type completion even in the application with the overrides. So pretty, pretty nice API, pretty cool. So we've gone from less, like very little JavaScript to a lot of JavaScript. But we've kind of got a lot of features along the way, so there's things like nesting, variable steaming, but there's also linting, import dependencies. We have a very opinionated autocomplete that we can configure which would be harder to do without JavaScript. So is that the success? Like is that what we wanted? I guess so. But of course things come with tradeoffs. So it's been such a big success that there are about 4,000 presentational components on GitHub which have the SX prop just for style overrides. And which has caused success problems, like shampoo problems.

5. Optimizing Style Updates

Short description:

Big style updates are slow. So when you have a lot of styles that need to update on user behavior, the updates take a while. Collecting styles for SSR also takes a significant time. And by significant, it's like 10 to 15 percent of the server render time. And then streaming and suspense make it more interesting, because now you have to time your style updates very, very smartly. So looking at all of these updates, I started thinking about, OK, a lot of these problems are about, when are the styles injected? And maybe I don't need to do it on runtime. Maybe we can compile these styles out. So I added another feature right at the end, and I wanted to solve it with just a bit more JavaScript. So it could be a Babel plugin that reads the AST, looks at the styles, and then compiles them out into CSS files.

Big style updates are slow. So when you have a lot of styles that need to update on user behavior, the updates take a while. Collecting styles for SSR also takes a significant time. And by significant, it's like 10 to 15 percent of the server render time. And then streaming and suspense make it more interesting, because now you have to time your style updates very, very smartly. So looking at all of these updates, I started thinking about, OK, a lot of these problems are about, when are the styles injected? And maybe I don't need to do it on runtime. Maybe we can compile these styles out. So I added another feature right at the end, and I wanted to solve it with just a bit more JavaScript. So it could be a Babel plugin that reads the AST, looks at the styles, and then compiles them out into CSS files.

6. Exploring Other Solutions and Native CSS Features

Short description:

So I looked at other solutions first. Vanilla extract and Atlassian compile are two examples. Vanilla extract allows you to write styles in a CSS.TS extension, while Atlassian compile matches the style components API and compiles styles into .CSS files. However, there are nuances with compiling styles out, and using these solutions can restrict your JavaScript set. GitHub.com uses SWC instead of Babel, which led me to consider writing a Rust plugin. It's important to consider the familiarity of teams with JavaScript, TypeScript, and Rust tooling. Many CSS features are already widely supported, such as CSS variables, theming, nesting, and container queries. There are also native CSS solutions for linting and imports, like Tileint and PostCSS.

So I looked at other solutions first. So vanilla extract is a good example of this, where they ask you to write your styles in a CSS.TS extension. So you're writing the same object styles, but these can be compiled out, and you get the type safety, all of the nice things. I'm slightly short on time, so I'm going to skip the boring parts. This is boring.

Another nice solution is Atlassian compile, which matches the style components API more and compiles your styles out into .CSS files, so that the users just get CSS files. So a good example of this would be take all of this code, put it in a CSS file, and then put the class name back. That's kind of what the users get, that's what developers author, this is what the users see. Kind of nice. Of course it's not perfect, there are some nuances that come with compiling styles out. One, your authoring experience is slightly worse because JavaScript is very composable, you can do a lot of things, but if you want them to be compiled out, your JavaScript set is restricted to things that can be compiled out. And that can cause confusion, that can cause weird APIs to make that happen. I have a very tiny proof of concept of this, it's called CSS-out.js, it's a Babel plugin, if you want to see the, it's like 50 lines of code just to see how it works. It's on Github, this could be a good introduction to it.

So, success, right? Now this should definitely work. We have our styles, we can compile them out, and the tiny thing that we ran into is that GitHub.com, the one most of you use, actually doesn't use Babel, it uses SWC. And that's when I discovered that if you go far enough on the JavaScript spectrum, you actually end up in Rust, where a bunch of bundlers like SWC, Parcel, they're all written in Rust, and then there are things like efbuild which are actually written in Go. So I found myself, if I have to write a plugin, maybe I should learn some Rust and write a Rust plugin so that we can use with SWC. And that really scared me. So there are 4000 presentational components, but they're across 20 subpackages, and 20 subpackages in a lot of teams, and all of this complexity that we're asking people to overtake, 20 different subpackages in multiple teams, they have very different level of familiarity with this entire JavaScript, TypeScript, Rust tooling. So we often talk about the right tool for the right job, but I think there's an asterisk there. It has to be the right tool for the right job, for the people who need to do that job. So my perfectly compiled stack might be a really good stack, but if it doesn't work for the people that need to use it, is it really a good stack? And I also realize it's not 2015 anymore. And a lot of these things that we got from moving on the spectrum, a lot of these are already getting there. So for example, CSS variables are already part of the CSS spec and widely supported. Theming is already there. There's a proposal for nesting that's supported and some browsers were coming to more. There's container queries that are becoming a very wide spec. Similarly, there are solutions for linting and imports that are more native to the CSS world. So for example, there's Tileint for linting, and PostCSS can give you CSS-module-like features very easily.

7. CSS Migration and Intelligent Developer Tools

Short description:

We can use less JavaScript now that CSS has become more JavaScripty. There is increased diversity in JavaScript bundlers, but code editors are leaning towards VS code. Tailwind and Shopify's Polaris have smart extensions that suggest classes and CSS variables based on your theme. Implementing this intelligence in developer tools is challenging but valuable. There is no good open source library for this yet. We need to move our presentational components from SX to CSS. We can refactor them one by one or use tools to make the migration easier.

So it looked like we could probably use a lot less JavaScript now that CSS has become more JavaScripty, more variability. The only thing that we don't have here is an opinionated autocomplete and there are some good examples of this.

Oh shit, I missed something. Okay. So there is an increased diversity in JavaScript bundlers. There's parser, ESBit, SWC, etc. But the diversity in code editors is actually going the other way around where VS code seems like the default option. Even online browsers like Code Sandbox or StackBlitz also use VS code under the hood to make it possible. If you can support VS code, you can make a big part of the developer population happy. So that's the direction I started looking in.

Tailwind does a really good job at it. Use the extension, they use a language server to understand what you're trying to do, look at your theme, and then suggest classes that actually match your own theme. That's very smart. Similarly, this is from Shopify's Polaris. So Polaris is Shopify's design system, and they have an extension which uses something similar to suggest CSS variables in CSS that are actually part of their system. So again, you can have very opinionated, you can see it's not just suggesting everything, it's suggesting shadow because it understands that you're trying to use it in box shadow. Which I think is very cool. So I tried to play around with this as well. It was surprisingly hard in the wrong ways and easy in the things that I thought were hard. And you can actually get very opinionated things, you can also get lint errors, where it can stop you from not using the variables that the design system team doesn't want, but actually use the ones that we do want you to use, even if the values are the same. So there's a lot of intelligence that you can bake into your developer tool. There is no good open source API, open source library to do this yet. So if any of you want to be popular, have that GitHub Star fame, this is a free idea for you. Finally, right, that should be it. Now we're using CSS, we have the tooling for it, this should definitely be enough. Almost. Remember I said we have 4,000 presentational components that use SX? So we kind of have to move all of them to CSS so that we can use this new tooling. And one way to do it would be, let's just do it one at a time, refactor it, let's ask teams to do it, deprioritize users, deprioritize bugs, and prioritize migration to CSS. Or we could use some tools. So remember this magic thing I showed earlier which you can do with a baby plugin and decided it would be hard to do it for so many different bundlers at the same time.

8. Developer Step and Naming Challenges

Short description:

We could do it one at the developer step instead of the build step. TS Morph is a library that allows you to write transformers that can change your code based on the TypeScript AST. It's not an automated migration, but an automation-assisted migration. Should you drop CSS in JS? It depends on your specific circumstances and needs.

We could do it one at the developer step instead of the build step. So there's a very good library called TS Morph. It basically looks at the typescript AST and lets you write transformers that can change your code. So it's pretty smart in the types it gives you. So depending on the type of the variable, it could be a JSX opening element or a self-closing element, it can differentiate the two, you can look at the JSX attributes, and then you can get very smart with it.

So for example, the first one is pretty easy. If it's margin 10, then I know that I have to pick this up, put it in a CSS file, and put a class name here. But then because we're using an entire typescript compiler, we also have the option of following variables around. So for example, if in SX, you're passing base styles, you can actually trace these variables across multiple files and compile the value from there. Similarly, if you're calling a function, you can find the function definition and from the function definition, return a class instead of an object style. So you can get really clever, really wild with something like this. And that's how I'm hoping that we would migrate those 4,000.

Now, the one thing that computers are not so good at is naming things. Even though we have a lot of context in the file, you can use the file name, you can use a component name. A lot of the class names actually ended up looking like this, where there's a wrapper container stack and then a hash at the end of it. And that's the thing that computers are not good at. I guess they are, but I don't know enough AI to be good at it. So it's very, the code that is generated is not very maintainable in the long run. So the way I'm looking at it is, it's not an automated migration. It's an automation-assisted migration. And that's the way to do it. You run your command, it gives you some code, you review it like a developer would, and then if you like it, you might suggest some class name changes, and then you ship it. I will be raising a seed round because it says automation-assisted, and that qualifies as AI. You can meet me in the Q&A after with your goods.

So the final thought, should you drop CSS in JS as well? It depends. So if you find yourself somewhere on this spectrum, and you're thinking, we've got way too much... Wait, this is not the slide. If you're on this spectrum, and you think, we're happy where we are, we don't have the performance problems that this guy talked about, all our developers are very good at JavaScript, we don't really need to bother, then stay where you are. It's a happy place to be. I spent a lot of years here, I was pretty happy.

9. Choosing Between JavaScript and CSS Native Tooling

Short description:

If you have a team that is very good at JavaScript and tooling, and you want to improve your developer experience, go with JavaScript. But if you have a mixed team with different skill sets, go for CSS native tooling. You can achieve a lot with minimal JavaScript.

If you have a team that is very good at JavaScript, very good at the tooling, and you would like to invest more time in improving your developer experience by actually improving the editor, improving your plugin system, then definitely go more JavaScript, that's where most of the fun is. If you're like me, and you find yourself in a place where your team is very mixed, a lot of designers, developers, different skill sets contribute to the same codebase, then I'd recommend go all the way to the left and use CSS tooling, CSS native tooling, it's kind of really good now. You'll be surprised at how far you can get with very little JavaScript.

QnA

Q&A on CSS Tools and Libraries

Short description:

That's my talk. We have a few questions coming in on the slide. The first one was what are your thoughts on panda CSS? Never heard of it. No opinion. Sorry. What do you think of tailwind CSS? It's a very promising idea for us. There are certain aspects in component land where if you have a component library and you want to add overrides, it's very hard to do it with just class names. Because the order in which you give class names to an HTML element doesn't really matter. And that's where we started shying away from it. Because we were really on the path of we don't want to runtime solution.

That's kind of it. I'm going to do that again because I spent way too much time on this slide. And that's all. That's my talk.

All right. So we have a few questions coming in on the slide. People see you as an expert opinion on CSS and the different CSS tools and libraries. So I've got a bunch of different ones. So we're just going to go and you're going to give me some of your thoughts on them.

The first one was what are your thoughts on panda CSS? Never heard of it. No opinion. Sorry.

So maybe later on in the speaker Q&A they can come and show you and we can find out. Yeah, I'd love to. And then we've got another one. What do you think of tailwind CSS? This one you expected. Yeah. Yeah. Definitely. So we explored as part of all of like the exploration for this project, I explored tailwind as well. And less tailwind specifically, but more the idea of a utility style CSS which also has very good tooling. And it's a very promising idea for us. There are certain aspects in component land where if you have a component library and you want to add overrides, it's very hard to do it with just class names. Because the order in which you give class names to an HTML element doesn't really matter. What matters is the order that they show up in the CSS. And if you distribute it all across a big application, you can't really control the order. So you need some runtime CSS to make sure you're deduplicating these class names to make that happen. And that's where we started shying away from it. Because we were really on the path of we don't want to runtime solution.

CSS Tools and Libraries

Short description:

Because we were really on the path of we don't want to runtime solution. I showed it to multiple developers. Some developers said I love it, and some developers said I hate it. This is not a tech conversation anymore. The cameramen are having a little CSS problem. Another question that has come up is what are your thoughts about CSS in JS major libraries like MUI, struggling within service side rendering? Should we come back to CSS modules? Or will libraries evolve? That's a very good question. There is a path for libraries to evolve and play really well with service side rendering, suspense. For libraries like MUI, I'm really curious of what they're thinking. If I could rewrite prime from scratch, I would probably go CSS first because we have a lot of really, really good CSS developers. Picking a stack based on the team members and their strengths is important. Critical CSS is quite a solved problem with CSS in JS. The idea of each component file having a CSS file tied to it is invaluable. The dependency tree is something that's going to stay for a while. I often get exposed to new developer tools that I really want.

Because we were really on the path of we don't want to runtime solution. The other thing was I showed it to multiple developers. And some developers said I love it, and some developers said I hate it. This is not a tech conversation anymore. So we did not go that way.

Awesome. I think the cameramen are having a little CSS problem. They're like, put the spot there. It's like a grid. Center and a div. But we get there in the end.

Another question that has come up is what are your thoughts about CSS in JS major libraries like MUI, struggling within service side rendering? Should we come back to CSS modules? Or will libraries evolve? That's a very good question. There is a path for libraries to evolve and play really well with service side rendering, suspense. There is a direction there. I do feel like there is a murmuring that is happening of like maybe we don't go that way. And maybe we rewind a little and go to CSS. So for libraries like MUI, I'm really curious of what they're thinking of in terms of I'm sure they find themselves on the same spectrum where they could go a little more JavaScript and actually start building bundler plugins for all of these different bundlers, or go the other way around and drop or compile out runtime CSS altogether.

Now that makes sense, that makes sense. Now this next question, hindsight, is 2020 and if you could rewrite prime from scratch, which stack would you use? If I was starting today, with the team I have today, I would probably go CSS first because we have a lot of really, really good CSS developers that are really smart designers as well. So I would go there, and I feel like we're at a point where it wouldn't be so much of a tech decision, like because I compared all of these, made all the pros and cons chart and it kind of just came down to, this one looks prettier, so I would say skillset is how I decided today.

I love that as well, picking a stack based on the team members and their strengths as well. Good readership, good readership. We've got another one, what are your thoughts about critical CSS as it's quite a solved problem with CSS in JS? Yeah, yeah, it is. I think one thing that we would definitely stick, like the only thing that we're taking from CSS in JS world is something like CSS modules, and even though we might do it with CSS, but the idea of each component file has a CSS file tied to it. And then as you compile your JavaScript tree, you can also attach your CSS tree on top of it. I think that's an idea that's invaluable and would stick around for a very long time. And that also helps you solve for things like critical CSS, tree shaking, knowing when to delete code. I think the dependency tree is something that that's going to stay for a while.

Nice. One thing I also love about watching developers give presentations is I often get exposed to new developer tools that I really really get jealous of and really want.

TypeScript Extension and Namespacing CSS

Short description:

Someone asked about the TypeScript extension used in the slides, but it was just Keynote. When it comes to namespacing CSS, it depends on the context. Library components like Primer button are not namespaced, while application components with specific names like wrapper, stack, and container are namespaced to avoid conflicts. This allows us to have a conflict-free dependency tree using CSS modules.

And someone's asked, what's the TypeScript extension that you're using? The TypeScript extension for? I think it was in your slides, but your slides in the code editor in your slides were using the TypeScript. Oh, nothing. That's just Keynote. Good design. Good design. That's just like, I typed and I drew the rectangle to get the TypeScript thing. Yeah. Styled it so well. All right, we'll do this one as the last one.

What about namespacing CSS, something that styled components are delivering already? Yeah, I think it's interesting because it kind of depends. If it's a... We're kind of partitioning this half an hour implementation where the library components, we're not namespacing them. So you might get something like a Primer button. And that stays the same across the stack. But something like an application component where things like wrapper, stack, container are actual legit names, those were namespacing because we don't want any conflicts. So the same dependency tree that we get, we also get the ability to hash these and have them conflict-free with that. So something like CSS modules. Thank you, Sid. Everyone give him a round of applause.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.
Remix Conf Europe 2022Remix Conf Europe 2022
37 min
Full Stack Components
Remix is a web framework that gives you the simple mental model of a Multi-Page App (MPA) but the power and capabilities of a Single-Page App (SPA). One of the big challenges of SPAs is network management resulting in a great deal of indirection and buggy code. This is especially noticeable in application state which Remix completely eliminates, but it's also an issue in individual components that communicate with a single-purpose backend endpoint (like a combobox search for example).
In this talk, Kent will demonstrate how Remix enables you to build complex UI components that are connected to a backend in the simplest and most powerful way you've ever seen. Leaving you time to chill with your family or whatever else you do for fun.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
DevOps.js Conf 2024DevOps.js Conf 2024
163 min
AI on Demand: Serverless AI
Featured WorkshopFree
In this workshop, we discuss the merits of serverless architecture and how it can be applied to the AI space. We'll explore options around building serverless RAG applications for a more lambda-esque approach to AI. Next, we'll get hands on and build a sample CRUD app that allows you to store information and query it using an LLM with Workers AI, Vectorize, D1, and Cloudflare Workers.
JSNation 2023JSNation 2023
170 min
Building WebApps That Light Up the Internet with QwikCity
Featured WorkshopFree
Building instant-on web applications at scale have been elusive. Real-world sites need tracking, analytics, and complex user interfaces and interactions. We always start with the best intentions but end up with a less-than-ideal site.
QwikCity is a new meta-framework that allows you to build large-scale applications with constant startup-up performance. We will look at how to build a QwikCity application and what makes it unique. The workshop will show you how to set up a QwikCitp project. How routing works with layout. The demo application will fetch data and present it to the user in an editable form. And finally, how one can use authentication. All of the basic parts for any large-scale applications.
Along the way, we will also look at what makes Qwik unique, and how resumability enables constant startup performance no matter the application complexity.
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
React Advanced Conference 2023React Advanced Conference 2023
148 min
React Performance Debugging
Workshop
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)