Brian:
PodRocket is sponsored by LogRocket, a fronted monitoring and product analytics solution. Just to say, it's not really sponsored by anyone. It's sponsored by us, LogRocket. And we're giving it away for free. The podcast is free. The product is not free. There's a free trial. We could split hairs about whether or not that's free to you, but anyway, that's it. There are no more ads. If you're interested and you want us to know that you came from the podcast, please go to logrocket.com/podrocket. If you don't care, logrocket.com works just fine. Thanks.

Brian:
In this episode, Ben interviews Cristian Bote creator of goober, a less than one kilobyte CSS-in-JS solution. Christian is also a member of the Preact core team. Unsurprisingly, they talked about Preact, goober, and WMR. A tiny all-in-one development tool for modern web apps. Let's get started.

Ben:
Hey Christian, how are you doing today?

Cristian:
Hey Ben. I'm doing good. You?

Ben:
Pretty well. And I'm excited to have you here. And I figured we could start by talking about goober. Always fun to say that name and I'm going to add, or I guess we could start before we even talk about what goober is. How did you come up with the name?

Cristian:
Oh man. Yeah. So I don't know. I honestly don't know. It was just a free spot on npm, I guess. I think I started with this idea that you can have styled components, but at the cost of nothing. And nothing translated to me like peanuts. And I saw the peanuts emoji and I was like trying to come up with a synonym that it's free on npm. And goober was it. Yeah. That's how I chose the name.

Ben:
Perfect. Well, I like it and it's memorable. So that's always important with names.

Cristian:
Yeah.

Ben:
So now that we know nothing, it's very lightweight. But what is goober?

Cristian:
Goober is actually a styled components library, but I'm trying really hard to keep it under 1K when it ends up in a bundle. On disc or install size right now might be somewhere around one point something, but that's negligible because with tree shake you get less of that. So I try to keep it also as close as possible to the established industry. Libraries and authors, like, styled components and Emotion. I think those were my main inspiration. So yeah, that's pretty much it. Just if you use Emotion and styled components, you're going to feel at home with goober.

Ben:
And for folks who are maybe not as familiar with the paradigm, maybe just give a quick intro to styled components and what that pattern looks like.

Cristian:
So the classical styling of elements on web is you have CSS, either in line or external style sheet or via a style deck. Well, to be able to develop modern interface or in a modern code base, you're going to have some CSS in your JavaScript. And also, we touch on the CSS in JS term as well. So to streamline the development of components being styled, I think the first library they come up with the CPI was style components. And they came up with an API that you can give it a tech name and then call it with some properties of CSS. And then you get yourself a JSX element or react basically, element that you can render. And it's already styled with the class name attached. And in the background, you get everything pretty much done for you in terms of applying the styles, defining the styles, and appending them to a style sheet in the head.

Ben:
Got it. And style components, correct me if I'm wrong, it helps with the encapsulation of styles. And one of the difficulties with CSS is often that you maybe just want to style one individual component. You don't want to affect other components. And with the component-based architecture, CSS was traditionally a leaky abstraction.

Cristian:
Exactly.

Ben:
So style components helps with that, right?

Cristian:
Yeah, definitely. And also the core location and your styles with your code, right? So you have a button and you have a style for that button. That style won't be applied to anything else on your page, only on your button. So definitely, encapsulation is a strong point.

Ben:
And so how similar is the goober API to that of styled components?

Cristian:
Goober started as me trying to build a website, but got really and heavily sidetracked, basically. Because I started prematurely shave off bytes of my bundles. And the only thing that I didn't touch at that point was the style components. And I was like, "Well, there's got to be a smaller alternative," but there wasn't. Only if you go into the compiled section. But I didn't want to compile anything. I just wanted to have it on the run time. So I started composing my own style function and so on.

Cristian:
Basically, that's how I ended up with goober having the same API, but with a bit of trade-offs. So when you start components, you got your style dot and then the tech name. Well in goober, we cannot offer the tech names attached as a static properties to the style function because that takes space. And only because of that, you have to type in yourself the tag name that you want. So for example, let's say you want to style the div, in goober you can do that with style and then call it style as a function, with the argument of a string with a value of div and that'll give you a div ready to be styled. But that's pretty much like the most huge difference in terms of API.

Ben:
So to dig in there a bit, when you say goober doesn't include the tag names, maybe explain that a bit more, just so folks are listening can understand. What is that trade off mean for when you're actually developing?

Cristian:
Sure. So having those properties there means styled components for example, they have to manually attach those properties onto the styled function. So... And those properties are all the available DOM elements, divs, A's, B's, P's everything that's in there needs to be attached on the styled function and there's less statically type in the code base. I mean, if goober wants to be small, it cannot have that in there. So yeah.

Ben:
So you mentioned goober, is it only 1KB or how big is goober? And then how big is, I think styled components is around 10 KB?

Cristian:
Yeah. I mean more precisely right now. I think style components is 12 and Emotion is around 10, 11. But again, with tree shake you can shave some of that off. But not that much. Right? Cause they do offer some functionality that goober obviously can't compete with that.

Ben:
Yeah. I guess that's a good question besides from what we discussed with tags, are there any other big trade-offs that you've made in the interest of size, functionality that you couldn't include?

Cristian:
Yeah. So practically speaking about the trade-offs one thing that you won't be trading off is the performance. In almost all of the tests, the users of goober and, I personally, goober comes first, obviously because it's small in size. It doesn't have to execute that much code and so on. And so on. One other interesting thing about goober is that while Emotion and styled components, they use a parser to parse the CSS that you pass along to the styled API. Goober uses a regex rule. Which took me really, really long to build. And I'm always trying to tinker with it, see if I can squeeze something more in there or less, or make it shorter and so on. But yeah, so the big trade-off is, if styled components and Emotion uses a third party library to parse the CSS, goober uses the own parser, which is a regex rule, basically.

Cristian:
But my parser from goober passes, I think it's just one case that stylis. Stylis is the parcel desktop component and emotion uses. So it passes almost all the test cases for stylis but just one. There's a bug in the goober repo. So if you feel adventurous and you want to help out. Yeah. And also the developer experience, this is one of the thing that it's fairly important to mention. Obviously, goober cannot offer developer tools, warnings, highlights, and so on. Goober does have TypeScript and types and also has the theming system in there. But other than that, there aren't big trade-offs that one would steer away from goober just because doesn't have that thing. I mean, obviously this is subjectively on each use case, but the people who use goober, they're pretty much happy with it. And they didn't run into big issues that they couldn't solve with goober.

Ben:
Maybe this is a naive question, but couldn't some of those developer tools and warnings and things like that, be built as a development only dependency and then get compiled out for the production build?

Cristian:
That's a good question. To do that you're going to have to make goober aware that's running in production or development mode. And that takes up space. So even that we'll add space into the production bundle and it wasn't something that I wanted to include just because I was so used to the style API that for me personally, wasn't useful. But yeah, that's a good question. And maybe I should explore it more.

Ben:
Yeah. Or maybe if anyone's listening, wants to open a PR with an experiment there, we'll definitley put a link to the goober repo and for any folks who are interested in checking it out or potentially contributing.

Cristian:
Yeah. Definitely.

Ben:
So I guess basically by using goober instead of styled components, you save 11 kilobytes. Different teams have different ways of thinking about the added weight of dependencies and obviously in different industries. I know a lot of e-commerce companies tend to be on the more sensitive side to bundle size versus maybe an internal banking app. Maybe there's less sensitivity in a use case like that. But what does that 11 kilobytes mean? How should developers be thinking about how big a savings that is, on average? And it's a very blanket question, but I just... I often talk to folks who aren't really sure how to think about each kilobyte and what that means for the low time on average of their application.

Cristian:
That's really depending on the project that you're working on, obviously as you say, Ben. But when we measure this things, it totally depends on the code that you're executing. So recently I've been working on a project and we're doing a server-side rendering app and we're trying to see how much dehydration takes up. The first thing that we try to take away was... I mean, we were using Emotion and tried with goober. And obviously, practically when you take out 11Ks or 10 Ks, your metrics should go up in performance, but the size should go down. Well, the size did go down, but the metrics were really scrambled that you couldn't put your finger on "yes, replacing Emotion with goober will save you one second of load time" or start with that. And that's just because there was so much code that replacing one library with another didn't make sense at the end of the day.

Cristian:
So to answer in, what does 1K mean in terms of load? Load time, yes, will be reduced. I mean, how much that only depends on the connection and so on. But if you think in terms of space royalty, right? So you get rid of 10Ks of dependency that 10K can turn into a feature or some more code base of your product and delivering the same performance or even better one. So it's honestly, it's a difficult question. I can't imagine how I would have to answer in a more practical way because it depends.

Ben:
It seems like this idea of taking popular development, paradigms or tools and shrinking them is a theme in your work. You're on the Preact core team. So we can maybe pivot there. And for anyone who's not familiar, can you give us a brief introduction to Preact. Yeah, from what I understand, it's similar to goober and that it's the React API, but a much smaller dependency. But maybe you could give us a bit more detailed explanation of what Preact is.

Cristian:
I believe it was love at first sight for me with Preact. I think I've discovered Preact, I think six or seven years ago while trying to come up with a server-side rendor app, but also serve a small bundle to the client. And the Preact story versus React, it's a bit different, versus goober and styled components. I mean the implementation in goober it's totally different than the other libraries, but in Preact it's different, but it's the same. That's the achievement that I think the Preact team should be proud of. I mean, React, it's a great code base to learn and see the paradigms, the patterns of programming, computer science and so on, you name it. But in Preact everything is so compressed that you have to be there to be able to realize what it does. And also you have to know React and so on. But I think that's the biggest achievement that Preact has, is that, you won't lose on functionalities, on APIs, on anything only on your kilobytes. So you would lose that, but not on anything else.

Ben:
Got it. And how closely does the Preact team track the new changes to React? For example, I mean, Hooks is not that new anymore, but just Preact support React Hooks.

Cristian:
Oh yeah, definitely. Yeah. I mean, that was, I don't want to say an effort, but that was a hurdle that we had to jump over. By the time I joined the Preact team was in the middle of a full rewrite with Preact 10, that included Hooks. So by the time I joined it already had the Hooks in there and they were pretty much settled on the APIs and so on. But yeah, since then Hooks are part of Preact. But in terms of features, there's a bit of a chasing React from time to time. But in all honesty, this chasing will end at some point. With React coming out with several components, there's definitely going to be a fracture between today's development of React apps and the future ones.

Cristian:
So if the future ones would require you to have a node.js server to be able to serve several components, we believe that Preact won't be that kind of framework. Preact will stay true to its original commitment, to be a library that will render your DOM elements with React to similar API. Honestly, we think this is going to be a good thing for us, right? Because we won't have to keep looking at React in a way of, where to go next or what do we need to implement that React did recently? So it'll allow us to explore more things moving forward.

Ben:
So I'm curious to learn more about WMR, which I understand is a tool recently released by the Preact team. Can you give us a bit of overview on what that is?

Cristian:
Sure. WMR, we consider it to be a next gen bundler and it does a lot more, but stays true to the Preact core methodologies, like zero dependencies and comes with very small in size. So the compile down CLI is just two megabytes, which is really a lot less. If you look through the other bundlers and compilers and website builders, this is peanuts. To pun on goober. The thing with WMR that's really great is that you get a development server that's starting instantly. So you get instant reloads. You can develop from the start point. You don't have to install TypeScript, React, Preact anything like that. You got JSX in there it's going to be transformed for you. And it's all based on roll-up. And it has a really great plugin system, which is really to build on top of.

Ben:
Is the right way to think about it as an alternative to Create React App. Create React App basically simplifies the whole process of Webpack, but it has Webpack under the hood, as I understand. So is it, this is an alternative to that?

Cristian:
Yeah, pretty much. It's more in the same context of Vite from Evan You and also Snowpack. They're in the same court and the same context. So I think when we started working on WMR, we exchange ideas Fred, Jason, and Evan we've been talking a lot about what this means and how to build stuff and so on. But I'm using WMR to build all my side projects and websites now. So it's battle tested in terms of that we are using it and goober.rocks it's actually built with WMR.

Ben:
I was going to ask at the end, for anyone who wants to learn about goober where do they go? And I know gooper.rocks is the new website for goober. So for anyone that wants to learn about goober checkout goober.rocks, I guess to circle back on you, the first point you made about WMR and that it's only two megabytes in size. Why does that matter for a development tool? Correct me if I'm wrong, but this is just a tool, a CLI tool that's on your development machine. So whether it's two megabytes or four megabytes, what effect. Nowadays computers have a lot of storage space. So obviously goober, Preact, those are tools that are code that ship to the client. So size is very important. But why does it matter for a development tool?

Cristian:
It totally matters in terms... I mean, I bet you've seen those memes or images where the black hole, with node modules going beyond. So yeah, keeping that in mind, WMR will never be that thing. Right? It's just going to be a tiny portion. So having a bundler which is small in size, I mean, it executes faster, needs less space, and it's going to be installed faster as well. So you get all the performance benefits as you would have like a small website, but this for a CLI. So you don't have to wait 10 minutes for your bundler to be installed.

Ben:
Got it. And if someone's interested in using WMR, can they start using WMR on an existing project or it's something you would generally want to... When you're starting a new project, do your first build with WMR and then you use it from there on in?

Cristian:
Usually folks have been using it. I mean, I'm using only from scratch. I don't remember if out of the bag it's possible to include in a current project. Just because it outputs to this folder to a build folder, so that means you'll overwrite everything you have there. But to get it going, you just need an index dot HTML linking to adjust your file. And that's it. So if you have that already, then yes, you can start using WMR.

Ben:
So for anyone that wants to try out WMR, I guess they can just Google WMR GitHub and is there a landing page for that as well, that you'd recommend checking out?

Cristian:
There isn't one yet. But they can go to Preactjs/WMR on GitHub and yeah, it's going to be there. Or try it with npx init.

Ben:
I think you can use yarn for WMR as well. Right? Or npm even. If you're old fashioned and still use npm.

Cristian:
Oh man. Yes. I am.

Ben:
Anyway Christian, really enjoyed having you on today. For folks out there who want to check out some of these projects we discussed goober.rocks is the landing page of goober. Preactjs.com is the landing page for Preact. And then WMR is in the Preactjs GitHub organization. So go check out those tools, perhaps consider becoming a contributor. Yeah. Especially it sounds like gober is a very approachable tool to contribute to. And as Cristian mentioned, always with contributors. So yeah. Thanks so much for joining us, Cristian. It was great speaking with you.

Cristian:
Thank you so much For having me. It's been lovely.

Brian:
Hey, it's Brian again. So it turns out that running a podcast is maybe harder than we thought. And so I want to hear from you, I'm genuinely interested in your feedback. We have to think about new topics, new guests. We have to find them. And don't get me wrong, we can do it, but it's a lot easier if everyone else who's listening helps. So if you'd like to suggest the topic or volunteer to be on PodRocket, we'd like to hear from you. So you can do that by going to podrocket.logrocket.com/contact-us. The hyphen is next to the delete key, if you're curious. If all of that is too long, you can just email me directly, brian@logrocket.com that'd be great. Also if you're feeling magnanimous, be sure to like and subscribe to PodRocket. Thank you.