00:00:00 Kent: Hello everybody, this is my friend Mark Del... Oh, I do this every time. I practice your last name and then I'm like saying it and you're not the only 1, so don't feel... I guess don't feel special. No, but you are special. Don't feel singled out. Okay, DelGlish.

00:00:17 Mark You nailed it, perfect.

00:00:18 Kent: Yes, all right. So this is Mark. Mark and I, you know, I don't think we've ever met. Have we met in person?

00:00:26 Mark We have in Amsterdam.

00:00:28 Kent: Oh, 0, that's right. That's right. Yeah, good. So, but we knew each other long before that. I think, I mean, I knew who you were from CSS modules. I don't think you knew who I was at that time. But yeah, pretty early on, I was an early user of CSS, not very early, but pretty early user of

00:00:48 CSS modules. I was using it with AngularJS. So I was probably 1 of like 12 people doing that. But anyway, so that would have been like 2014. And I'm not sure exactly when we developed a relationship, but I have really enjoyed our friendship over the years and

00:01:08 would love for people to get to know you a little bit. So Mark, why don't you introduce yourself to us?

00:01:15 Mark So, hi, my name is Mike Douglas. I am, as you said, most known for my work with CSS modules, which goes back to the, it came out of the early work we were doing with React. So it's been a big part of the React community since then. But that for me really grew into a real love of front-end tooling in service of

00:01:35 being able to componentize everything. So that's how do we, not just the CSS, obviously CSS modules is a big part of that. We extended our work there into vanilla extract as well, ultimately. And I've worked on tools like Playroom, which is a JSX in-browser design tool, effectively, for your design system.

00:01:56 And I worked on design systems at Seek, the company I worked at when we built these tools, you know, all of these together as a package, how we built the CSS, how we prototyped with it in the browser, how we built and deployed it to all of the teams. And that work has led me to work on Remix now.

00:02:17 So, yeah, I'm working on Remix at Shopify now. So I'm helping all the build tooling around that and getting more CSS features into Remix itself as well.

00:02:28 Kent: Thank you for doing that. I think that, well, thank you for all of the stuff that you've done. CSS modules was my first taste of tooling-enforced componentization of CSS. Before that, I'd use BEM. I actually had my own Tailwind-esque-like

00:02:50 thing where I, Stylus was great at this, at doing like loops and stuff. I could never get LESS or SAS to do what I could do with Stylus. But so I created my own like Tailwind classes And I actually really liked that, but it just never really took off for me. So then yeah, I discovered CSS modules

00:03:10 and that got me started on componentized CSS. And then eventually we go through the CSS and JS phase and all of that, which was kind of, probably be a good thing to talk about as well. Because when CSS and JS was a lot more popular than it is now, there was a lot of pushback from the greater

00:03:30 web ecosystem saying this is just so terrible for all these reasons. And I never really felt like I disagreed with them, but the challenge that I had with that was that CSS and JS was solving some major problems that I had. And they were saying, well, CSS and JS isn't the answer. And they just didn't have an answer for it.

00:03:50 So anyway, you wrote a blog post. I think it was Unified something.

00:03:57 Mark Unified Styling Language, I think it was.

00:03:59 Kent: Yes, yes. And I remember sharing that blog post with people saying, listen, I get your concerns. Here's this blog post that explains why I still want to use CSS and JS. And now I feel like we've kind of moved on from that, but without getting rid of those benefits that you talk about. But yeah, I'd

00:04:19 love to hear from you about your experience through CSS modules into CSS and JS and what you're working on now and a little bit about that blog post too.

00:04:29 Mark Yeah, I mean, maybe it's jumping to the end a little bit, but I think we can work back from this. To me, even though I spent a lot of my professional career working on tooling for how to compile and package up CSS, What's been more exciting to me has been more at the React

00:04:49 component-oriented layer, where to me the benefit of a tool like React was that for once I had a component system where I felt like I could really build my own design-oriented DSL, so that I could compose up a UI out of components that I designed the API for them. You know, and it wasn't, and to me that was

00:05:09 a big difference to what I'd used before where it was more, you know, templates and you would just have reams and reams of HTML. The componentization of React was so strong that to me it naturally gravitated towards the world of design systems, where it's like if I'm working at a sizable company that's trying to have consistent UI, especially across multiple teams, is where it really

00:05:30 starts to pay off, right? That was the environment in which I was like, CSS and low-level HTML is kind of getting in the way of us being consistent because we want to be speaking the way our designers speak, you know, And this has become very mainstream now. Like I think early on in React, it

00:05:50 was novel, but now it's become very normal that people, basically any sizeable company realizes we need a component library so that we can all be on the same page and we're not reinventing the wheel and we're consistent. And if we want to make changes to our design language, we can roll that out. So to me, that is the world in which componentized CSS fits, right?

00:06:10 I always thought, even from the beginning with CSS modules, I was thinking that CSS was like private implementation detail of a component. If I'm consuming a component, I shouldn't actually have to care whether it uses CSS modules or something else. The idea is just as long as it's portable and it just works, then I actually don't mind at

00:06:30 all. And so that's why, even though I've been working with a lot of very opinionated CSS tooling, I'm totally open to other approaches as long as including things like Tailwind, for example, which is very popular now. But to me, I'd still would like to treat that as private implementation detail of a component so that as a consumer, my app

00:06:50 just looks like my design language, custom design language for my company and my product.

00:06:58 Kent: I 100% agree. I think that is just, it cannot be overstated how awesome it is to work in an application that has a well thought out design system with an implementation in React components with that API designed around it. So I think this would actually be a pretty interesting topic

00:07:18 around that, and that is, do you allow, or as part of your API, do you allow people to sidestep things and to like say, well, for this button, I need the padding to be like X, or do you turn that into like, oh, well, if you want that, we've got to make an API for it. Or do you allow

00:07:38 people to just pass arbitrary styles or CSS?

00:07:42 Mark Yeah, this is like 1 of the biggest questions when it comes to design systems and something we, like, so when I worked on design systems at Seek, where CSS modules came from, our first design system definitely went to the extreme of trying to accommodate people doing custom things. Basically, I mean,

00:08:03 in practice, what this amounted to was we would spread props a lot of the time. And we would say, if you pass a class name to this component, we'll just add your class name on there as well. If you pass an online style, we'll put that in there as well. And I think to me, like, to me, that was a really good experience to see the downsides of

00:08:23 that approach in practice at scale, particularly because, you know, the vision of a design system is about moving quickly. It's about being consistent and it's importantly, it's about being able to make changes to the system in the future as well as if you want to redesign, if the company wants to go through some sizable redesign, having a good component system really helps that.

00:08:43 What we found was there was sort of 2 major problems with opening up that level of flexibility. The first 1 was that, to the point about change, it was really hard to make changes after the fact because there wasn't a strong contract between the outside world. So seemingly any CSS

00:09:04 change to the component could break some consumer and there was just no way to have any confidence about those changes. So that made things a lot harder. That meant the components tended towards just not changing much at all. Yeah, yeah. But then I guess a secondary problem to this as well is that the design system is meant to be

00:09:24 kind of at any given time, ideally it's a snapshot of the way designers want the site to look in general, right, as standards across the whole company. And what we found is that if we open up these escape patches, people very much use them and would use them instead of talking to us

00:09:45 about what should be a really important conversation in the sense that if there's a team trying to use our standard design language, but then there's a disagreement, we should be talking about that. But those conversations were just not happening. Developers were just punching holes everywhere. And so those 2 problems together meant that the

00:10:05 system wasn't evolving as quickly as it should. The important design conversations weren't happening. And then we were afraid to make changes to the system later. So we actually built a second system later on because we needed to do cross-brand theming. And it was such a big new requirement that it was easier to build a new 1 than try and retrofit that requirement.

00:10:25 And that was the time when we took the opportunity to start more conservatively in terms of our API. And we said, we're not opening up class name and style. We're going to be really restricted with props. And we found that for us anyway, at least at the scale where we were operating, that was much better for us. It meant that the system

00:10:46 encouraged people to be more standardized, it empowered developers to push back on designers so that they would have these conversations. And if they couldn't resolve it by using an actual standard pattern, the designers would then end up talking to us as a team to try and figure out, well, how do we, you know, how do we standardize these patterns that maybe are

00:11:06 emerging that don't quite align with what we have so far?

00:11:09 Kent: Yes. Yeah. I think, and I'm guessing that worked out pretty well.

00:11:16 Mark Largely. I mean, there's always going to be, it's 1 of those problems that there's always going to be natural tension between these 2 extremes. So it's not that, you know, 1 approach is really bad and the other approach is obviously really good. It's a trade-off, but I think overall, I prefer the trade-off of saying, yeah, consumers should be as consistent as possible. And if you

00:11:36 can't work around it via composition, I think maybe that's the worth calling out as 1 reason we were able to get away with this is that we focus really strongly on composition. So that you... We really tried to break down into primitives that could be composed in different ways and recombined.

00:11:56 So that there wasn't that same need to have to, you know, pass extra props into components. You would just arrange them in different ways. I think that meant that it was very rare that someone literally just could not do something standard with the tools that we gave them.

00:12:15 Kent: Yeah, that makes a lot of sense. What kind of things did you find people wanted to diverge? Like, was it completely new designs that the designer came up with, or was it just like margin here, padding here, that sort of thing?

00:12:31 Mark I guess, yeah, I mean, it varied and it often depended on the designer too. Some designers are better at being closer to the standards and some, just because of their workflow, will end up with more differences that are just sort of random differences.

00:12:45 Kent: Incidental.

00:12:46 Mark Yeah, I mean, this is sort of to my point, right, is that because the conversations weren't happening, often the dynamic was, and also depending on the developer as well and their design skills as well, some developers would have the relationship with their designer that they saw their job as just a pixel perfect match the mock-up.

00:13:08 And so what would happen is sometimes, you know, in the old environment where there were no guardrails at all around this stuff, developers would just say, oh, the padding is off by 2 pixels. I guess I'll have to override the styles.

00:13:22 Kent: Oh, yeah.

00:13:23 Mark And that might just be a change that's... If you were to actually go and talk to the designer and say, hey, this is 2 pixels different to the component, The designer will say, oh, well, yeah, well then go with the standard 1. And so there was definitely extremes of like things that were just a side effect

00:13:43 of people naturally working in an unconstrained design tool. But then the other extreme is you would have things like they'd add icons to something that didn't have support for icons before. And so that would actually, again, that would like a button, for example, it's like maybe there was no built-in support for icons on the button, or it didn't look right if you just

00:14:03 used it in the text, something like that. And that would, again, like that would force that conversation where we would say, oh, you're right, this is something that needs to be solved at the primitive level and we're missing it. So we would prioritize working on those features. But yeah, a lot of the time we could solve designs just by composition. So, and,

00:14:25 you know, rounding to the nearest design standard, that goes really far.

00:14:30 Kent: Yeah, yeah. I'd like to dive into the composition a bit. There could be folks listening who are not familiar with what you mean by that. Can you describe that a little bit?

00:14:40 Mark Yeah, I mean, the idea with composition, I guess, ultimately is that you rely on, if we're talking about React specifically, it's like you leverage nesting of children rather than having a component that takes a lot of different props to customize it. So a good example, a basic example of this is you might have a card component,

00:15:00 right? And all it does is give you some padding and background color, that sort of thing. You know, you could keep adding props to card, you can have a title prop and a subtitle prop and a whatever, you just keep adding props. But then you know, the other approach is you say a card is just a container, Like it should have the minimum

00:15:21 props possible. And if you want a title, like you put a title component in the card, and you put a subheading component in the card and so on. And even then you can go even further in terms of, you know, a card might have props for padding, but you can equally have layout

00:15:41 components that their job is literally just to provide white space. Right? And so now it's like, so then you can start to rethink, well, how much do we even maybe even need a card component or is it a card or is it just a surface component? And inside of that, I put an inset like layout component. And then inside of that, I put a stack component to like vertically lay out the items. And

00:16:01 so once you start going down this road of trying to keep props to an absolute minimum and leverage components instead, it often leads you to components that are just generally trying to do less and work together as a set more.

00:16:15 Kent: Yeah, composition is really the solution to so many problems. And it's, Epic React is currently getting an update. And 1 of the things that I wish that I'd done from the very beginning was talk about composition. So there is an exercise in the updated Epic React about composition,

00:16:35 because I just think it is really, really powerful. Epic React does have a compound components exercise, which is very, very good and very similar kind of idea, but even composition from a layout perspective, I think is underutilized. And I would say that in the React ecosystem,

00:16:56 the lack of composition as a regularly used pattern is a big reason why people reach for context to avoid the prop drilling problem and stuff like that too. So let's work our way backward a little bit from the

00:17:17 design systems and components and talk a little bit about what motivated things like styled components and well, actually, you know what, I wanna ask you as the co-creator of CSS modules, when styled components came out and CSS and JS became a real

00:17:37 thing was, did you ever end up using that? I know that you kind of came to its defense for what it was trying to do, but I don't know if you ever really ended up using CSS and JS.

00:17:46 Mark Yeah, not in production. So yeah, that's why I think some people who were familiar with my work at the time were surprised that that blog post came from me, where I was defending this thing that you might think I would have been against. So my position at the time was that I very much, because I was doing server rendering with React, like that's actually what got me

00:18:06 into React was the fact that you could render it on the server. Because of that, I was very much trying to go with the grain of the web and ship, like I just wanted to ship plain style sheets from the beginning. That was kind of what I wanted to do. And I guess what worried me about a lot of the CSS

00:18:26 and JS approaches was that it felt like it was trading off on runtime performance to make my life as a developer better. And obviously there's a bit of a spectrum there, like it's not black and white, but I was, my concern was that operating at the scale of a large company with like lots of teams that are going to be consuming our component library, in that context,

00:18:46 my concern was that the runtime performance could become a problem at scale and then would be really hard to reverse that.

00:18:54 Kent: Yes.

00:18:56 Mark And so I wasn't against it in like in theory, it was more just, I really was wary of walking into a bit of a trap there. So I felt like we had good alternatives, that we didn't have to go down that road of runtime CSS and JS. So we just made do, and like I said, because we focus on our components as the

00:19:16 mechanism for sharing style rather than the CSS itself. It meant that you sort of, in some sense, it felt like CSS and JS anyway, because I'm designing via my React components. So like, who cares if it's static CSS files behind the scenes? I think history's proven me correct on this based on my own conversations with a lot of people over the

00:19:36 years who've said, yeah, we've got ourselves into a performance problem with runtime CSS and JS where it's just slow, but it's death by a thousand, It's the worst kind of slow where it's death by a thousand cuts. And how do you fix that? You've just got to redo everything, basically is the problem I saw people running into. But you know, again, I'm

00:19:56 not using this as an excuse to say CSS and JS is bad. Like some, you know, some people are happy to take that, take that win and bash CSS and JS, that's not my position. Like I think for a lot of people, the runtime performance is a complete non-issue. And the upside is much better than the downside.

00:20:16 So yeah, I guess I have a pretty nuanced take, but I've always been, I've always been in, in favor of, that approach in theory. And I mean, I was definitely interested in trying to have the best of both worlds and be, and seeing if I like the authoring experience, can we keep the authoring experience as close as possible, but still

00:20:36 ship plain CSS files? And obviously that's what led into vanilla extract as well.

00:20:41 Kent: Yeah, yeah, absolutely. I think 1 thing that I always appreciated, because I could tell that you never actually shipped CSS and JS because you had reservations around that. But what I appreciated about your stance on it was that you could relate to the problems that were trying to be solved. And they really were

00:21:02 big problems. Like the biggest problem is can I delete the CSS? That's probably the biggest problem in general. Even if you're using Vim or any other 1 of these conventions, can I delete the CSS? I think CSS modules solved that a lot, but 1 of the reasons that I struggled with CSS modules was

00:21:22 even inside of that, I could have CSS that wasn't being used. And it just can be challenging and like dynamic things. And now we've got CSS custom properties. And so dynamic stuff is a little, well, a lot easier now. But yeah, to

00:21:42 continue on with that train of thought, I think vanilla extract is kind of the best of all worlds as you described. So let's talk a little bit about vanilla extract and how is that an evolution of CSS modules and like kind of, well, I'll say it this way and you can correct me. It seems to me that vanilla extract

00:22:03 is like CSS and JS and CSS modules had a baby. Is that kind of what you would say?

00:22:09 Mark Yeah, like literally in the readme, 1 of the first things I wrote as its tagline was like, I said, it's basically CSS modules in TypeScript. Ah, yeah.

00:22:16 Kent: That's kind of

00:22:17 Mark the way I sold it and the way I thought about it. I think it maybe makes sense if you think about how do you arrive at that point if you're, like I said, if you go back in time to when CSS modules was really big And you've got sort of 2 parallel sets of work going. You've got people work in terms

00:22:37 of the tooling people are using. You've got your plain CSS files, and then you've got your runtime CSS and JS stuff going on. Because we were trying to stay in that lane of keeping things static. If you're working in plain CSS, as you said, like now we have custom properties, but even that, people find they want to go even further than that. We were using

00:22:57 pre-processes. So at Seek, we were using less, but it could equally have been SaaS or you said stylus as well, anything else like that. What I found is that because we wanted to be able to reuse, you know, variables, mixins and so on, like we had a, because it's a design system, right? Like once you get into the CSS file, there's still

00:23:17 a level of standardization you want to have available within the CSS file. And what I found was that we were just hitting a level of complexity in CSS pre-processing that I was missing JavaScript. I was Like, it's frustrating to me that when I switch context from my React code, where I've got my HTML,

00:23:38 I've got my standard JavaScript, I've got my HTML, like rendering logic in JavaScript, but as soon as I go to styling and I wanna have logic for how to generate my styles. I'm now in a completely different language that works completely differently. You know, can I test it? Are there unit testing tools for this thing? Yeah.

00:23:59 And I think this especially came to a head when TypeScript came along because then the gap really widened. Because it's like, I've got JavaScript, which I much prefer working into LESS, and I've got static types in my JavaScript now, which I don't have in my LESS file. So Vanilla Extract

00:24:19 was kind of like saying, okay, basically how do I use TypeScript as a preprocessor effectively? I want to generate in the same way that LESS or SAS is a language that generates CSS. It's like, I want TypeScript to be that language. And then I get the best of both worlds. It's like, I get the same performance characteristics of using plain old

00:24:39 CSS files, but I get all the benefits I'm reaping else literally everywhere else in my code base, basically TypeScript.

00:24:48 Kent: Yeah, I mean, it sounds like a no brainer, honestly, having typeset because with CSS modules, you have that style thing and you can apply these class names but like you don't know if that class name exists anymore or ever did. And so being able to get that type autocomplete and all of that,

00:25:08 that just, yeah, that's pretty, pretty brilliant. So you mentioned earlier, or we talked a little bit about Tailwind. How would you say, like, what is your take on use cases where Tailwind versus CSS or vanilla extracts are? I don't

00:25:28 know if, you also have this sprinkles thing as well. That might be a little more analogous, I guess.

00:25:35 Mark Yeah, I think so to me, it's a really interesting problem because I think the short answer for a lot of people is just use Tailwind. I think that has become the short answer for most people. And I think the reason for that is out of the box, Tailwind solves so many problems and gets you focused on just like shipping

00:25:55 in a consistent way. So like, because you can configure it with, so from a design system perspective, it forces you to think of things in terms of like palettes, right? Like you've got your space scale, you've got your color palettes and so on. Like so much of design consistency boils down to that. It's like anytime I set padding on

00:26:15 an element or I set a color, you know, if you're just working in raw CSS from the ground up, people tend to just use random arbitrary values everywhere. Yeah, they eyeball it. Yeah, exactly. Tailwind encourages you to think more in terms of like, Which item from the palette am I going to pick? And it just gives you fewer choices in a good way.

00:26:35 So much of the design is about that constraint. And then it also solves the other problem in terms of like, how do I keep CSS as close to where it's used as possible? And don't have this like Rube Goldberg machine of like, how do I actually generate the CSS that eventually gets used somewhere? It keeps it local. It's like, so I think it, it, it,

00:26:56 it's the best way to get, especially people who are, I want to be careful how I wear this, especially if you've got people who are less experienced with CSS, it'll like, it will get them on working in a good architecture right off the bat. But I think, I don't think it's only for people like I've been working with CSS for decades at this point, basically, and I still

00:27:16 think Tailwind's a really great solution. So that's like the background to say I'm a big fan of Tailwind at a high level. I think there's some trade-offs, like the API is obviously a little weird, like running these giant strings, But I think it's 1 of those things like React has had its quirks, like JSX itself was like weird. Once you

00:27:36 get used to it, you're like, okay, you go with the grain of this is actually brilliant. Where I think Tailwind for some people, and this is true for me as well, like where it becomes a bit trickier is when you start working at the scale of a design system with multiple teams. Like I think if you're in 1 repo,

00:27:56 right, and you're just building a little startup or something, you've got 1 project, Tailwind's a complete no-brainer. When you've got a centralized team that's trying to ship a component library, in that environment, if you're using Tailwind, to me, that's where it starts to get trickier. And I think that's why a lot of people who are building design systems, they're the ones that get the most value

00:28:16 from vanilla extract because they want to think of CSS as private implementation detail of a component. They don't want their consumers sort of inadvertently consuming every CSS decision you ever made as public API. But that's kind of the way Tailwind naturally, at least out of the box, naturally works. Like if you configure Tailwind to be your

00:28:37 company's design guidelines and then you ship that as a component library, your Tailwind config basically now is public API across the whole company. And so if you were then, if designers, you know, 6 months, whatever, 2 years later say, we're going to have a big design refresh and we want to effectively change our Tailwind config,

00:28:58 how does that play out across, you know, maybe dozens of repos consuming or projects consuming your Tailwind config. To me, that's where like the lack of type safety becomes a problem. That's where like basically every class name being a public API, a piece of public API becomes a challenge. So these are conversations I've had with people who are like, yeah, we've

00:29:18 thought about Tailwind, but because of this problem, we don't want to adopt it. We want to ship components to people. Or maybe even if they want to use vanilla extract, they want to be able to ship like type safe utilities and things like that, where there is a clear boundary between the design system,

00:29:38 like the component library and the consumers. I think it's doable. I do think it's doable with Tailwind. It's just, we would require a lot of maybe extra tooling and discipline to enforce that boundary between the provider of it and the consumer.

00:29:54 Kent: Yeah, I think that's a very well stated nuanced take. So Thank you for that. Okay, so I also wanted to ask you, before we get to the end of our time, I want to ask you about what you're working on at Shopify on Remix. So you joined up about the time that I left, so about a year ago, is that right?

00:30:15 Or was it later?

00:30:16 Mark Close to a year ago, yeah.

00:30:18 Kent: Yeah, yeah, I promise that my leaving had nothing to do with your arrival. I was actually really bummed that we didn't get to work together. So yeah, very soon after you joined is when vanilla extracts got added and also like the, we learned about this in the workshop, the CSS,

00:30:38 whoa, what is it called? The bundle, yeah, CSS bundle stuff got added and all of that. So I'm sure that you had quite a lot to do with that. So what else have you been working on and what are you looking forward to in the future for Remix?

00:30:55 Mark Yeah, so I mean, just to drill into that a little bit, like what attracted me to Remix was I felt like I had a lot to add in the space of fleshing out the compiler a bit more around the area of CSS because I like as an enthusiast looking at Remix from the outside, I was super excited about basically everything it was doing,

00:31:15 But then when it got down to the styling portion, I felt like it basically only gave me a couple of realistic options to do styling. It was like you could manually manage each individual CSS file and wire them. That felt like I wasn't a huge fan of that. And the other approach was tailwind. And

00:31:36 again, like I said, I'm not against tailwind, but that felt like super restrictive to me. Like, like I basically, those are my only options. And so I was, and because Remix kept the compiler basically as private API, there's no plugin API. And when you look at other similar tooling, particularly in the React space, you'll see tools that

00:31:56 have built-in post-CSS support, built-in auto-prefixer, built-in, on and on it goes, Sass, less CSS modules. And so it felt like there was a big gap between what people might expect Remix to do in this area and what it was doing. So I was definitely keen to jump in and try and figure out, you know, how do we start to bring some of these features

00:32:16 into Remix. But it's funny, in terms of looking forwards, what we're seeing is that, I guess the challenge is, you can imagine adding all of these things and maintaining them, making sure they're bug-free in Remix, like, it takes a lot of work. And the Remix team is not very big. So I think the work up to this point has been really good for

00:32:37 fixing these issues for people who want to come to Remix, but maybe find the tooling in this area was lacking. But we want to unlock this going forward so you don't have to rely on us to implement all these things. So, you know, there's 2 things on the horizon we're looking at. There's, I mean, first of all, the big elephant in the room is server components because

00:32:57 that changes the way you think about bundling in relation to React going forwards. And Remix potentially can do a lot less work than it's doing today when it comes to bundling. And so in that world, maybe we can reorient things away from us owning so much of the compiler and you can bring your

00:33:17 own compiler. But that's maybe more of a long-term play as well. In the short term, there's definitely room for us to revisit our tooling choice. Remix historically was, I think, roll-up based and then moved to ES build. And we're still open to changing that as well, maybe in service of allowing people more access to the compiler. So

00:33:37 we're sort of trying to play the short to medium and long-term games at the same time and figure out how do we let you do even more in Remix? So for example, we don't have built-in SaaS support right now. Some people still want that. And ideally, you don't have to wait for us to ship that. You can just, if you have access to the compiler,

00:33:58 you can just add your own plugin in there and you're done. So I'm definitely excited about letting consumers do more with Remix, but hopefully in a way that means we don't have to do so much as owners of Remix as well.

00:34:11 Kent: Yeah, yeah. So invert control a little bit there. The challenge with inverting control then is in the same way as we were talking about at the beginning, that people will use those class names and they'll just throw stuff in there. And now all of a sudden, like changing 1 little thing that you thought was just an internal thing could break somebody, which

00:34:31 I, so I think that the Remix team was, was right to keep the compiler locked down, especially early on when things were still being worked out. But yeah, there's, there's that trade off of people being kind of limited on what they can do.

00:34:48 Mark Yeah, I think to me, that's why I personally, I mean, I'm not the only 1, like that's why personally most of my interest is at the moment is in solving this problem is around VEET, because I think VEET does have a good answer to this where, yeah, I think that's why so many frameworks are moving or like are built on VEET is because it's sitting at the right level of

00:35:08 abstraction where me as a consumer of a framework that's built on VEET, it's really quite trivial to integrate something like Vanilla Extract, for example. Like we have a Vite plugin, and so it just naturally works with all these Vite-based frameworks, like no problem at all. Yeah. So I feel like that's the right level of abstraction. I mean, I'm

00:35:28 not as deep on how server components fit into the Vite story. I know there's people experimenting in that space, but I guess that's where the VEET being opinionated, somewhat more opinionated about the architecture, the fact that there's an SSR server, you know, obviously those opinions then need to be

00:35:48 shaped a bit more when the architecture moves towards server components. So I've still got a lot of learning to do to figure out what does that mean long-term. How do we balance these 2 things is interesting to me.

00:36:01 Kent: Yeah, yeah. It's very cool. Well, Mark, we're getting to the end of our time. Did you have anything that you wanted to talk about before we wrap up?

00:36:11 Mark What do I want to talk about?

00:36:15 Kent: Did we miss anything?

00:36:19 Mark If I would encourage you, I mean, maybe it's going back to the original topic a bit, but if you're working with React and you're trying to build design systems, I would, if you're someone who's working on a component library, I would really encourage you to try and force yourself to build complete pages with no custom CSS. And if you're working with Tailwind, that includes like try to

00:36:39 avoid custom, you know, strings of class names, right? Because to me, that is the real test of like, is my component library workable in and of itself? Can I recombine these Lego blocks into a UI? Because I think that was basically the secret to us coming to a lot of these conclusions, is tying 1 hand behind your back

00:36:59 saying, and Playroom, our in-browser JSX editor was a tool for testing this out, was saying, if I really force myself to not write CSS, how far can I get? And yeah, I think that's the best way to learn, because you'll probably come up with different opinions than mine

00:37:19 in terms of how do you reach that goal, but just that constraint forces you to make some really good decisions around component design.

00:37:26 Kent: Yeah, yeah. Tie your hands to free your mind. It's a good practice in general. Well, Mark, Thank you so much for giving me some of your time and having this chat together This is fun. It's always good to chat with you. And yeah, we'll see everybody on the epic web Bye-bye