Sizzy with Kitze

Episode Description

Kitze discusses building Sizzy, frustration-driven development, choosing Blitz.js over Redwood, and why web developers overcomplicate their tools and stacks.

Episode Summary

Kitze, creator of Sizzy, joins the podcast to walk through the evolution of his developer browser from a responsive design testing tool to a full-featured development environment with project management, built-in plugins, and simulated device conditions. The conversation explores his philosophy of "frustration-driven development," where personal pain points with existing workflows drive every product he builds, including Sizzy and his changelog/roadmap tool Blink (built with Blitz.js). A substantial portion of the episode becomes a candid comparison between Blitz.js and Redwood.js, with Kitze explaining why he chose Blitz for its simplicity and seamless integration of front-end and back-end code, while acknowledging moments where he misses GraphQL's strengths. He recounts his rocky experience with the Prisma/Nexus toolchain and how he rebuilt a months-long GraphQL project in seven hours using Blitz. The discussion broadens into a critique of the JavaScript ecosystem's tendency toward unnecessary complexity, with Kitze arguing that most developers overcomplicate their stacks by mimicking Facebook-scale architecture for small projects, and that frameworks like Blitz and Redwood struggle with adoption precisely because they make things too simple for developers who equate complexity with sophistication.

Chapters

00:00:00 - Introducing Kitze and the Sizzy Browser

The episode opens with introductions and Kitze describing his daily routine of juggling too many web development projects while cycling through burnout. He gives the elevator pitch for Sizzy, explaining how it evolved from a responsive design testing tool into a full browser for developers, arguing that anyone opening localhost in a standard browser is wasting time.

Christopher offers his own pitch of Sizzy's responsive testing capabilities, and Kitze clarifies how the tool works under the hood. While everything runs on Chromium rather than simulating different browser engines, Sizzy recreates device-specific conditions like pixel density, OS interface elements, and available screen space, giving developers a far more accurate preview than Chrome's built-in responsive mode.

00:04:58 - Sizzy's Hidden Features and Project Management

Kitze reveals that many users, including Anthony, barely scratch the surface of what Sizzy offers, from dark mode and light mode previews to network condition simulation, multi-user testing, and a gamified checklist that rewards exploration. He highlights the project management system that lets developers visually organize all their local projects and switch contexts instantly, with bookmarks, notes, to-dos, and browser tabs all following the active project.

The conversation shifts to Kitze's motivation, which he describes as pure frustration with inefficient workflows. Every feature in Sizzy traces back to a personal annoyance, from managing terminal windows to debugging CSS with red borders. He coins the term "frustration-driven development" and argues that the best features often come not from user roadmap votes but from building solutions to problems users haven't yet articulated.

00:09:08 - Developer Tools, WebStorm vs VS Code, and Browser Editors

Anthony observes that Kitze's drive to optimize tools reflects a common developer trait, and the conversation turns to why web developers still use primitive tooling compared to professionals in game development or 3D modeling. Kitze draws a sharp comparison between WebStorm's batteries-included approach and VS Code's plugin-dependent ecosystem, likening it to the difference between Sizzy's integrated features and cobbling together Chrome extensions.

The discussion moves to browser-based code editors, including Codespaces, Gitpod, and Edge's developer tools integration. Kitze expresses reluctance toward browser editors because they rely on Monaco rather than his preferred WebStorm shortcuts, though he acknowledges that JetBrains' Fleet editor and Gitpod's planned JetBrains integration could change his mind. He also teases that Sizzy's roadmap includes an embedded code editor for quick project editing.

00:18:52 - Blink: A Changelog and Roadmap Tool Born from Frustration

Kitze introduces Blink, which he describes as a GitHub for private paid apps, combining roadmaps, user issue tracking, voting, changelogs, and a help center into one product. The tool was born after a competing changelog app crashed twice mid-writing, destroying lengthy draft entries. Blink's approach uses Kanban-style cards for individual features that can be grouped into versioned releases, automatically notifying affected users when their reported issues are resolved.

Christopher highlights Blink's features tab, which documents each product feature alongside its update history, eliminating the need to maintain duplicate documentation across help centers and changelogs. They discuss the universal startup frustration of building help centers that users ignore, and Kitze notes that no matter how thoroughly you document a product, users will still email asking questions answered in bold text on the help page.

00:23:25 - Building with Blitz.js and the GraphQL Debate

The conversation pivots to Blitz.js, which Kitze adopted early because of its radical simplicity in collapsing the front-end and back-end into a single codebase without a separate GraphQL layer. He contrasts Blitz's approach, where changing a Prisma query immediately updates TypeScript types without server restarts, against the friction of maintaining separate front-end and back-end processes. Christopher shares that he made the opposite choice with Redwood.js, and both acknowledge they evaluated both frameworks before committing.

Kitze reflects honestly on his relationship with GraphQL, admitting he was likely more in love with automatic type generation than with GraphQL as a querying technology. He notes that as Blink has grown in complexity, he sometimes misses GraphQL's fragment reuse capabilities, and concedes he hasn't fully made up his mind about which approach is superior for every use case. Anthony explains how Redwood's decoupled architecture addresses some of Kitze's concerns, leading to a nuanced comparison of both frameworks' strengths.

00:35:07 - The Prisma/Nexus Toolchain Struggle

Kitze recounts his difficult history with the Prisma ecosystem's GraphQL tooling, describing a revolving door of product names, deprecations, and breaking changes that left him unable to run a year-old project without encountering multiple failures. He tells the story of rebuilding his entire GraphQL teaching app in Blitz during a single seven-hour stream after months of struggling with the Nexus and Prisma tools integration.

Christopher validates this experience, sharing that he also found the standalone Prisma/Nexus stack confusing before adopting Redwood. Anthony explains that Redwood uses Prisma only as an ORM while providing its own simplified GraphQL conventions, directly addressing the instability Kitze described. The exchange illustrates how both Blitz and Redwood emerged partly as responses to the same pain points in the JavaScript ecosystem, arriving at different but parallel solutions.

00:41:04 - Overcomplication and the Future of Web Development

The final segment becomes a broad critique of the JavaScript community's addiction to complexity. Kitze argues that developers need to stop imitating Facebook's architecture for small projects, referencing his conference talk "You're Not Facebook." He points out that tools like Blitz and Redwood struggle with adoption precisely because they simplify development, and many developers equate complexity with professionalism.

The hosts discuss the fragmentation of the framework ecosystem, with Kitze wishing that leaders from Next.js, Redwood, Blitz, Vercel, and Netlify would agree on shared standards rather than endlessly reinventing buttons and data fetching. He shares his internal company strategy of freezing their tech stack for several years to maximize productivity, and the episode wraps with Christopher noting that the industry's move from Bootstrap to Tailwind exemplifies the same self-imposed complexity problem. The conversation ends at 00:50:10 with Kitze joking that his alternative career plan is becoming a fisherman.

Transcript

00:00:00 - Christopher Burns

Yeah, swearing, that's up to you. Allowed? Not allowed?

00:00:03 - Anthony Campolo

The swearing is fine. Usually what I do is edit it in post, but feel free to speak freely. Don't worry about censoring yourself or anything like that.

00:00:11 - Kitze

If you edit it in post, it also might sound like a long beat.

00:00:26 - Christopher Burns

Welcome to the show. Kitze, you are the creator of Sizzy and a few other interesting things on the internet.

00:00:33 - Kitze

Oh, hi.

00:00:34 - Christopher Burns

What do you do on the internet every day?

00:00:37 - Kitze

That's a loaded question. We don't have four hours for the podcast. I try to do way too much, and I'm in constant cycles of getting burned out, saying I'll do a little bit less, never doing a little bit less, getting burned out again, and repeating.

Mostly I'm messing around with web dev, building products, managing products. We're going to talk about Sizzy and other stuff that I've built, mostly web development, trying to build this Sizzy startup and a bunch of other things. Whatever you want to get into, we're going to get into it.

00:01:03 - Christopher Burns

Yeah, I think it's worth starting with Sizzy. Really, what is Sizzy?

00:01:07 - Anthony Campolo

And how do you spell it so people can Google it?

00:01:10 - Kitze

Yeah, it's S-I-Z-Z-Y. There are probably links in the description and stuff. Once I paid for an ad for it and it cost a lot of money, and the host pronounced it as sizzle or something, and we couldn't undo it.

Sizzy started as a tool for testing responsive design, and for the longest time we marketed it as the browser for responsive design. But after a couple of months working on it, now we have a small team who works on it. We rebranded to the browser for developers, meaning if you're a developer and you open localhost in your daily work, you're wasting time if you're using any other browser. Regardless of whether it's responsive design or not, if it's not done in Sizzy, you're wasting time. So that would be the pitch.

00:01:51 - Christopher Burns

I've used it from its early days as the responsive browser tester. So much has been added to it over my period of usage.

Let's get into the crux of it. We'll start, obviously, with the feature I know most, the responsive testing. Do you want to pitch it, or should I?

00:02:07 - Kitze

I would love to hear your pitch on responsive testing in Sizzy.

00:02:11 - Christopher Burns

Well, as I, what would I call myself, a full-stack JavaScript engineer who sometimes does websites for other people? I used to do more of them. You obviously build a front-end experience. For me, it was a lot of time in Gatsby or Next, connecting things like Shopify. I've been doing it myself this week.

You need to test your mobile menus, your grids on different screen sizes. It's so easy as a developer to be like, I've taken my window and I've just made it smaller and it looks fine, then made it bigger again and it looks fine. You go, I've got an iPhone 12, so I'm going to test on that. Yep, looks fine, and call it a day. But what we tend to forget is that there are so many different kinds of phones, so many different kinds of tablets, so many different kinds of web browsers that all emulate and interpret websites differently.

So the job of Sizzy is to show you, on one nice, pretty screen, your website on multiple devices at the same time, giving you that full experience where you can scroll, you can view, you can open a menu, and it's all linked all the way between them.

[00:03:21] Everything I've said there is correct, right?

00:03:23 - Kitze

I like the pitch, but not everything is correct there. I'm not sure if you're aware, and I don't want to spread any fake information about Sizzy. It doesn't simulate different browser engines, so everything is Chromium.

The difference is, even when you use Google Chrome and when you go to responsive mode, you're still in Chromium. What we try to build is this: all the devices run Chromium. We try to run simulations on them, like the pixel density and many other things that any other browser won't give you if you open an iPhone 11 in Google Chrome. If you open an iPhone 11 in Sizzy, we simulate the actual size because we also simulate the browser UI and the OS UI. So you get the iPhone clock and everything else, and basically you will see how much actual space you have left for your website. Instead, if you open it in Google Chrome, you'll get a very tall device and you might think, oh cool, I have enough space for this page.

[00:04:12] I don't need to make it smaller or whatever. So we try to simulate as many things as possible, but we're not simulating different browser engines. That might potentially happen in the future. So for quick testing and for day-to-day work, definitely, I use Sizzy all the time, maybe not in the responsive tab all the time. But when you do final testing, you would still need to see if it's going to break on an actual Safari browser or an actual Android tablet.

We have a future plan to actually run real simulations. But for now, we're mostly focused on which things we can simulate. So when you work on your website, you make sure that not a lot of things are broken besides responsive design. These things include dark mode, light mode, simulating a software keyboard, simulating network conditions, simulating different users. I can list a bunch of things that even you, as an early-stage Sizzy user, will be like, wait, what?

[00:04:58] I can simulate multiple users. I've never tried that because a lot of our users don't know what Sizzy can do. And even I sometimes go and do something and Sizzy will give me a badge, like points that I unlocked something, and I'm like, oh crap, I forgot that we ever built this. That's nice to have. Yeah, long story short, it simulates responsive design, but it also simulates a thousand other scenarios that you're forgetting.

Like you might be developing in light mode and you're going to forget to check how your website looks in dark mode. Sizzy gives you an option to see side by side light mode, dark mode, Chinese language, English language, slow network conditions, an admin user and a guest user, and basically just see across all of these scenarios if your page is going to break.

00:05:37 - Christopher Burns

I didn't mean to say that it was emulating the actual browser, because that's a very hard task. Then you've got to stop supporting certain CSS rules in different browsers, and that is obviously a lot harder to do.

One of the other things that I really like about it is it's really good for taking screenshots because you can get a full-page screenshot. You can get a screenshot with the UI. That's really good. But that's only half the features, and you've been working on it for a really long time. Those are, I'll be honest, most of the features I have used. I've dabbled in the rest of the features, but I've never gone fully into them yet.

Why don't we start talking about them? When you remarketed it from the responsive browser tool to a full browser, how does that go to the next level? What else can the browser do to help everyday developers?

00:06:30 - Kitze

We remarketed to that when I realized that a lot of other users and I actually use it in full mode. Full mode looks like any other browser. When you develop something in Google Chrome and you have the DevTools open, you're basically in full mode in Sizzy.

What does a browser for developers mean? We have enough plugins and built-in things that usually in Google Chrome you would need to install like 50 extensions to get those. But still, at the end of the day, those extensions won't talk to each other, and they won't complement each other in a way that makes you feel like, oh my God, it's the tool that was missing in the space for whatever task you're working on.

Let's say you're working on your meta tags and you want to make sure that your social previews are going to be fine. There's a tab for that in Sizzy. As you're working on your meta tags, you can actually see real previews of how this website will look when I share it on Twitter, Facebook, or LinkedIn. For basically any other scenario that you're working on, there is a feature in Sizzy.

Maybe you want to convert a color. You'll find something for converting colors in Sizzy. Or let's say you want to kill a port. There's a process running on port 3000 and you want to kill it. There's a feature for that in Sizzy. There are billions of these small and big things that as you discover them day by day, you're going to be more and more amazed at how you were working in a browser that doesn't have all of these features.

I would suggest you use the little icon in the corner, like a tutorial cap thing. When you click on it, there's a huge checklist of things that you can try, and we give you points as you explore them. If you get to level like Sizzy Wizard, you've explored basically most of the stuff that we have in Sizzy. So if you want to play around and see what's there, you can just go through the list.

One of the things that changed my life, basically, is I realized how much I hate talking about the features that we have. It feels like patting myself on the back constantly. But one of the major things that helped me is I work on many projects and I change between them daily. I work on open source libraries or different front-end projects or full-stack projects, Blitz apps, whatever apps I have.

I had to previously organize them on disk using my Finder to open a terminal, navigate to the folder, blah blah blah. We built something called CC Projects where you visually organize all of the projects that you have on disk. So when I need to switch between projects, I can just run a command and easily open that project in my code editor, open it in Finder with just one command. I switch my entire context and suddenly I'm working on that project. Sizzy contextually switches my notes, my to-dos, my bookmarks, my links, my devices. So everything switches for working on that project.

Usually in a regular browser, this will look like you open a bunch of tabs, let's say your deployment URL, your GitHub URL, and a bunch of other things. And then once you're done working with that project, you need to close all of your tabs and open a new set of tabs. In Sizzy, all of these tabs are remembered, and you just switch projects and suddenly you have your GitHub repo, your deployment URL, docs, whatever you need for that project.

00:09:08 - Anthony Campolo

That's interesting because before we started recording, you were fussing about with Zencaster trying to figure out how to get a keyboard shortcut for muting. I think this is a thing with some devs. They are just never satisfied with the tools they have, and they always have this need to create their own and get it highly optimized for their own setup.

So where do you think that came from for you? This desire to have full control over your tools and the workflows?

00:09:35 - Kitze

You nailed this point because everything that I've ever built, my only drive, my only motivation, and I hate myself for it, is that I hate that certain processes are a certain way. I was never driven by money or a financial goal or some number that I have. I start doing things like back when I was freelancing. They told me, hey, this website needs to work on four different devices.

As soon as I started using Google Chrome and switching between iPad and iPhone, then iPad, then iPhone, then desktop, I'm like, how do people work this way 30,000 times per day? So there's just, like, a fork in my life, and I pause everything I'm working on. I'm like, the world needs a browser for developers right now.

So as I was working on it, when you open the gates and you're like, wait, now that we're building this and now that it's an Electron app, the possibilities are endless. So basically, everything that I hated in my web development process, like managing my projects or using the terminal or using a red border around my elements in order to debug CSS, all of the features that you see in Sizzy are 99% based on my frustration.

So of course we listen to user feedback, we listen to what the users want. But sometimes you have to invent and give users something that they don't know that they need. I think that's where invention comes from. When nobody thinks, like, it would be nice if I organized my projects in a visual way, I hate using the terminal, so nobody will upvote that feature on a roadmap where you have, like, hey kids, we all need a way to organize our projects.

So sometimes I have to listen to my own frustrations and be like, okay, the users want one thing, but we're going to give them something completely different that's based on my frustration. And then you listen to their feedback and they're like, oh my God, this saves me so much time. We can call this frustration-driven development.

00:11:09 - Christopher Burns

Maybe I have to admit that I've literally just loaded up Sizzy, and I've looked in the top right, and I've seen the hat icon. I've got, what do they call them now? I've actually done a few of them without noticing. That shows you how much I've noticed it, but I'm still such a novice. I'm still on the first level, and there's loads of cool features in there.

One of the big things that I wanted to ask about it was, as you could say, a browser developer. Do you find that we are changing the way we build websites necessarily, and the tools that we're using to build them are becoming complex enough that they now need their own suite of debug tools that are not good enough for the default debug tools?

00:11:57 - Kitze

Nothing is good enough. I'm talking about this in all of my talks. Basically, I show this slide. How do other people work, like movie editors or people who create games, or people who create 3D models or worlds or VR apps? Whatever it is, all of them are creating more complex things than us web developers. We're just moving rectangles around, right?

All of them have these amazing tools that they're working with. We're the only ones who still fire up a terminal and a regular browser, like the browser that you use for shopping and for recipes. You're using the same thing for building apps, and you have this right-click inspect element thing. That's fine. I don't want to offend the Chrome developer tools or whatever, but there's a gazillion things missing. My frustration is there's still more things missing, more tools missing in this space, so we can finally feel like one of these game developers who have all of these nice visual tools for building stuff.

[00:12:47] I still think that we're very, very far, even with things like Sizzy or whatever else is out there. We're very far from having this set of tools because most developers want to feel like hackers day to day. They want to fire up the terminal, they want to do things the old-school way, and they want to feel good about how complex their life is. That's why we're not getting there.

00:13:06 - Christopher Burns

I think one of the biggest things that is the blocker is teaching and learning. Even if Chrome could do everything Sizzy could do, how do you start teaching people about these things? How do you start guiding people? And that's what your education tool inside Sizzy is actually really good at.

And talking about future tools, how are we still doing this so badly? My perfect example is debugging. Debugging JavaScript. As a beginner, you have no clue where to start apart from a console.log.

00:13:39 - Kitze

I still don't know where to start. I still use console.log.

00:13:42 - Christopher Burns

I've learned the upgraded debugger, and then you run debugger and you're like, okay, time to run my console.log.

00:13:49 - Kitze

That's fancy. If you're using a debugger, you can call yourself Senior Rockstar Ninja Developer.

00:13:55 - Christopher Burns

Talking about these tools, you've said that Sizzy already has tools built into it, so you've already got half of the Chrome plugins an average developer would install built into it. Do you find that it is easier and better to integrate somebody else's tool, as in from the Chrome Web Store, or to build the tool yourself?

00:14:19 - Kitze

This is an analogy I can use here because we don't actually install the Chrome extensions, we don't actually use the UI of the Chrome extensions or whatever. We just see which things are missing and we build them as our own plugins.

The difference I can tell you is I'm using WebStorm as my code editor, and if I'm good at guessing, you're probably using VS Code like 99% of the planet, right? The difference between WebStorm and VS Code is you install WebStorm, it's ugly, you change the theme, you install Material UI, and then you have everything working out of the box, so you're using it day to day. You're just surprised by all the magic things that they put into it. You don't install plugins, you rarely do, and you have all of these magical surprises like, I'm going to be refactoring React and it suddenly knows how to extract a piece of React, combine it into a variable, move it somewhere without me thinking about installing a plugin.

Or you have VS Code where you have to install 50 plugins that don't understand each other. And at the end of the day, you're still far from the magical experience that's WebStorm. I understand a lot of people don't want to pay for it, even though there's an open-source version, there's a free version and everything else. And a lot of people love hype. If your favorite thought leaders are using VS Code, no matter which magical things there are in WebStorm, you're still going to be stubborn and you're still going to try to make VS Code WebStorm with 50 plugins.

00:15:31 - Anthony Campolo

This is funny because I have a buddy who actually is a WebStorm evangelist, much like you are, so he's made this exact pitch to me many times. Didn't JetBrains just announce their new kind of VS Code competitor editor just a couple days ago? Do you know anything about that?

00:15:46 - Kitze

I saw it. Just to finish my previous thought, it's basically the comparison. Sizzy is like you have all the plugins built in and it works magically out of the box. In Google Chrome, you would have to install 50 plugins that don't talk to each other, and you get a half-assed experience at the end of the day.

Regarding WebStorm, I'm not saying that it's perfect, but every time I try to switch to VS Code, it's like, why do I need to build this myself? It's like somebody handing me a box of Legos. Half of them are built and half of them have very unclear instructions about what I need to build.

I saw a new editor by WebStorm. I don't know what their goal with that is, but I guess they want to modularize all of their editors and kind of make this thing that will be similar to VS Code. I'm not sure what they're going to do, honestly. I don't know what their strategy is because they're selling WebStorm as a package. So now they have this bare-bones editor that you would need to install plugins to, so I'm not sure where that's headed.

[00:16:36] I still have faith in the team who's working on this, because they understand all the languages, they understand all of the needs, and they've done pretty magical things inside of WebStorm. So I have faith. We'll see.

00:16:47 - Christopher Burns

One of the interesting things that we can talk about is the rise of browser editors. This is a really interesting one. Obviously we have Codespaces and Gitpod, but what I'm actually really interested in, and wondering if you've seen it or have any opinions on where it's going, is actually editing your code through your browser. Edge, I think, is doing it now. Every time I open the developer tools in Edge, it says, oh, tell us where your VS Code is, tell us where this is. And every time I've done it, it's crashed. But I think they're trying to get it to a point where you can edit from inside the browser.

00:17:25 - Kitze

My stance on browser editors is I don't want to use them because all of them are based on Monaco, which is the VS Code editor. I'm way too used to all of my shortcuts and all of the things that WebStorm has.

I tried using the trick where you do dot in a GitHub repo and it opens a VS Code thing, and I just can't stand it because this is not the thing that I use day to day. I guess for people who use VS Code, it's pretty magical for them and they love it. For now, unless you can put WebStorm in a browser, and I think that new editor, Fleet, or whatever the name of the new editor was, runs in the browser too, so maybe I'll start liking them as soon as I start using this tool.

00:18:02 - Christopher Burns

Gitpod is currently working on integrating JetBrains into the browser. I don't know how it's on their, what do they call it...

00:18:12 - Kitze

I saw it, like the roadmap.

00:18:13 - Christopher Burns

There you go. Roadmap.

00:18:15 - Kitze

It could get pretty interesting. And one of the things on the roadmap is, as I mentioned, the Sizzy projects. So when you work on a project, you switch. Let's say I work on the Sizzy landing page. I write a command, switch to Sizzy landing page, and everything switches.

It would be nice if, on the side, I could also edit the code of this project without opening a code editor. So this is definitely one of the bazillion things we want to do, and it's on our roadmap. But I guess I'm not prioritizing it because every editor we could integrate in Sizzy will be based on Monaco and won't be based on WebStorm or any of the IntelliJ tools. But it's definitely on the roadmap to be able to quickly switch your project and edit your project from the browser.

00:18:52 - Christopher Burns

That would be really, really cool. Why are we talking about roadmaps? I think we should segue into some really interesting things.

00:18:59 - Kitze

That's a good segue. That's a great segue.

00:19:02 - Christopher Burns

You've built many tools over your career. One of them, obviously, is the biggest one, Sizzy. You've been building, I believe you've been building on your Twitch stream as well, a roadmap slash changelog tool. Can you tell us a bit about it?

00:19:18 - Kitze

Yeah, there are way too many slashes there. We added way more slashes. It's like roadmap, user requests, issues. We're trying to build a help center, a home page. So basically we can describe Blink as a GitHub for private apps. And when I say private, I mean you're building a thing that's paid. You don't want to have a GitHub repo for it, but you want users to report issues. You want to update users on how those issues are going. You want to have a public-facing roadmap. You want people to vote on this roadmap.

And once you release something like a changelog, what you can do in Blink is select which issues you fixed in this changelog. And basically all the users that complained get email updates saying, hey, your issue is now closed and it's released in version 37, for example.

Blink also was born out of my frustration with these other tools. I forgot the name. I was using some changelog app and it crashed twice on me in the middle of writing a big changelog.

[00:20:10] So let's say we're releasing Sizzy 58 and I want to describe all the changes that happened there. I was using their in-browser editor thing, and after typing for like 30 or 40 minutes, I either closed my tab or the browser crashed and I lost my draft. After this happened twice, I'm like, I need to develop a tool where, instead of writing the entire changelog, you describe the features one by one. You keep them in a Kanban-style card layout, and once you're done with the individual things, you just group them and you release a changelog and you say, releasing version 57, we fixed X, Y, and Z.

Basically I wanted a more magical process to communicate to our users, let our users vote on features that they want us to build, and then once we've built them, we update them and we tell them, hey, this is now released. I hate that I started working on this. I tried really hard not to develop another tool, but just looking at the products that were out there, we had to combine a few different tools in order to get this functionality, so we had to build it.

00:21:04 - Christopher Burns

This is actually a really interesting area. I believe you're very lucky to be building a tool where developers love to complain and love to tell you what's broken and what needs fixing. I've actually used some of these roadmap tools before, a changelog tool in my own startup. Our target audience, literally, they don't care. They literally don't care, and they just want to see an email once a quarter.

I hate that because every time I see a product update, I'm always like, oh, what's changed? What's updated? But this is actually really interesting because, as we said, it has loads of slashes. It's a help center. It's a roadmap. It's a request. It's a changelog.

One of the things that I think is actually really cool, I'm actually looking at the Sizzy one, and you have the features tab. Under the features tab, you have basically every single feature of Sizzy. And then you say when they were last updated, what was changed, what was updated on a feature-by-feature basis, not just this massive changelog list.

00:22:03 - Kitze

So the idea is I want especially small creators and small teams to easily have a page on Blink where they can showcase their roadmap, their features, their changelogs, and everything else without writing everything twice.

If we have a feature called, let's say Responsive Mode, you want to document this feature. You either have a duplicate help center where in the help center you re-describe everything that you already wrote in your changelog, or you can repurpose your changelog to tell the users what happened with this feature. I want a lazy way for us to keep building products, and for them to be automatically documented with as little effort as possible. That's basically Blink.

00:22:38 - Christopher Burns

That's the thing. Help centers are this really interesting beast in any startup. I've built a tool, great, now you gotta explain it to everybody. And sometimes you feel this is such a founder's problem. You can feel it.

Sometimes you wrote a help article that says how to do this. Click this button. Screenshot of me clicking that button. Type in this word. Do that. Click save. Click post. That's how you do that. And you still get questions on your help bot saying, how do I do that?

00:23:11 - Kitze

For sure. It's frustrating. You cannot describe your product enough that you won't get people emailing you about things that are written with big, bold letters in your help center. People will still be like, yeah, but please email me and tell me how to do it.

00:23:25 - Christopher Burns

Yeah. And half the time it's then, look at this article. And obviously there's tons of chat tools to help there and all those things. Blink is actually built in Blitz.js. Did it start in Blitz, or did it evolve into Blitz?

00:23:39 - Kitze

I think Blink was the first thing that I tried building with Blitz, so it started with Blitz.

00:23:44 - Anthony Campolo

I had watched a stream you did with Brandon like a year and a half ago. This is the first time I'd ever seen any of your stuff. So it's like you've been on the Blitz train since it very, very first started.

00:23:55 - Kitze

Yes. Super early.

00:23:56 - Anthony Campolo

What got you fired up about it in the beginning?

00:23:59 - Kitze

Overall frustration with how we do things. As I said, everything that I do is frustration-driven. And when I saw Blitz, I was like, oh, cool. We don't need four folders on our desk and a back end and a front end and millions of APIs and a complex thing like GraphQL.

So when I saw it, I love GraphQL. I'm teaching GraphQL to companies, and after I learned about Blitz, I felt like a hypocrite doing my GraphQL workshops to companies because I'm like, yeah, but in like 90% of companies, you won't need anything as complex as GraphQL. And if you use Blitz and you write all of your queries and mutations separately, you will save yourself a lot of headaches.

The initial pitch from Brandon seemed very interesting to me. I'm obsessed with working faster with a small team. I don't want to grow my team above ten people. I think right now we're around five or six people, counting the people that are part time, but they're still involved in all the processes I'm obsessed with.

[00:24:45] How do we keep this team under ten people and just keep printing products? The tools that we build, like Sizzy and Blink, are part of this story. But also Blitz is a huge part of this story because I think that if it's used properly and if we open-source a lot of stuff that we use in our Blitz projects, we can build new products using Blitz at a speed that would take other teams...

I'm joking about this in my stream, like three months, 300 meetings. So you need 30 people, 30 months, 300 meetings to do what we're going to do with Blitz in a couple of hours. I absolutely love it. It's something that makes me work faster, ship faster. So of course I'm obsessed with it.

00:25:21 - Christopher Burns

This is actually a really interesting area. You're an early evangelist of Blitz, and I'm an early evangelist of Redwood. I'm building a startup myself. When I say to people, you know exactly what we've built, how much we've built, they say, you know how many teams? And you're like, I did it all myself. And they're like, what?

So how did you actually hear about Blitz in the first place?

00:25:42 - Kitze

I have no idea. Probably Twitter or somebody brought it up in my Discord or in my Twitch. I don't know.

00:25:47 - Christopher Burns

Wow, that's an interesting one. The first time I ever heard about Blitz, first I heard about Redwood, and then secondly, I heard, well, this is the other thing compared to it. And I've actually never built a project directly in Blitz, but I've read about it. I've done a lot of projects. I've just never needed to go extra, as in where Blitz is better than my Next projects.

So what enticed you to use Blitz over something like Redwood?

00:26:16 - Kitze

I was of course evaluating both of them. I decided I want to start and try one, and then keep an eye on how the other one develops. I don't want to say it was completely chance that I picked Blitz first. Honestly, if you compare the two sets of documentation, Blitz seems way simpler.

I really like the simplicity of Next.js where you go and create a page like we're back in the PHP days. You go to your pages folder, you right-click, you make a new file and you call it about, and suddenly you have an about page. Blitz just took this idea: if you want to query on this page, you also create a query and you just query it here. There's no back end. You don't switch to another project, you don't do anything. You just write the query here, you query it here.

I'm pretty sure Redwood also works the same. You don't get a front end and a back end, right? But you still have the GraphQL layer and other things there.

00:27:01 - Anthony Campolo

Well, you do have a front end and a back end in the sense that there's a website and API side. But the way it's set up, because you basically run a command that scaffolds out your back end, you get the CRUD created for you, and then you can just write your query. So the CLI is able to make it so you don't really have to think about the back end, but it's there and you can edit it and it still exists.

00:27:22 - Kitze

But does it run? Does the back end run on a separate port? And then you have a CLI that just generates types?

00:27:28 - Anthony Campolo

Yes, it does.

00:27:29 - Kitze

I hate it. I absolutely hate that, because one of the things that I hated in the process of GraphQL is I have a server that's running. I have to save it, it kills the entire server, restarts it, then I have to go in my front end, make sure the types are updated, and just doing this 50,000 times per day made me way slower.

00:27:45 - Anthony Campolo

Well, don't use TypeScript then.

00:27:46 - Kitze

Yeah, I was using TypeScript. Oh, you mean don't use TypeScript?

00:27:52 - Anthony Campolo

Yeah, just don't use TypeScript.

00:27:54 - Kitze

Yeah, well, the idea is I want to sleep at night, and TypeScript really helps me sleep at night because I know that my code is fully typed sometimes.

But when I saw Blitz, I can go in my queries file and let's say I have a query where I get all of my users with their blog posts. Let's say I want to fetch the comments on the blog post. I go to the file, I change the Prisma query, then I go back to my React component and I can already type blogPost.comments, whatever. Because there's no type generation, there's no killing the server, restarting the server. Everything is one thing.

I think this is the thing that really sells me on Blitz and it makes me faster. I don't interrupt my thinking process, I just code and I don't care if this is on the back end side. The API side, Blitz kind of fakes and tricks you into not thinking there's a back end at all. So basically everything is the same thing.

[00:28:38] And that's why I like it.

00:28:39 - Christopher Burns

I think it's really interesting that you said earlier, I looked at both of them. I keep evaluating both of them, and I happened to pick one of them. I feel exactly the same, but on the opposite side of the coin. I picked Redwood, but I evaluated both of them, looked at both of them, and went with a choice. And this is where it's going to be really interesting. The main reason I picked Redwood over Blitz in the early days, obviously they're both going to that 1.0 at this point, was on the core principle of GraphQL.

So you spoke about GraphQL being the best thing ever, and you were teaching it to all your clients, and then you picked a framework that doesn't use GraphQL. Is that contradictory, or has it taught you that maybe GraphQL is not necessarily required all the time?

00:29:29 - Kitze

Yes, GraphQL is absolutely not necessary all the time. What front-end developers do is they see what people are doing at Facebook and at Pinterest and at Quora and at all of these websites that have billions of users, and they're like, oh, well, also my blog with three pages and five users, I also have to use GraphQL. So that's how I think we spread all of these libraries like diseases throughout the community. One person uses Redux for an actually complex project. Five years later, everyone is using Redux to push a string into an array.

So we had the same issue with GraphQL that everyone is doing it. It doesn't matter if the app is big or small or whatever, I need to do it too. And honestly, I don't blame anyone because it's definitely better than just using a REST API and generating types from it and so on and so forth.

But I realized that maybe the biggest value I was seeing in GraphQL was I get the types automatically, so I cannot make a mistake. On the back end side, I cannot make a mistake on the front end side and everything is fully typed. I think I was more in love with that than actually GraphQL as a querying technology, because the queries are great until you dive deeper and you need to scale and you need to protect everything, and you need to write guards and authorization and roles and everything else.

And sometimes you might ask yourself, why does this even need to be a graph? When I'm on the blog post page, I can just write the permission there. I can write the Prisma query there, and this is what I get on the blog post page, without thinking about how does a blog post relate to a comment, how does it relate to a user, and blah blah blah.

00:30:50 - Anthony Campolo

So when do you recommend to use GraphQL? What do you think are good uses?

00:30:54 - Kitze

I honestly don't know because in Blink right now, when I'm doing my streams, probably once per stream I'm saying, damn it, I miss GraphQL for this because we're at a scale right now. We have that many things that are easily solvable with GraphQL fragments and stuff that with Blitz and with Prisma, you have to invent your own reuse mechanism.

Basically, you're either going to reuse the parts of the Prisma query, but it's still not GraphQL at the end of the day. So I'm still not sure how to answer this. When would I recommend for people to choose GraphQL or Redwood over Blitz? Because I'm still struggling with points of developing this app where I'm like, it would have been really nice if we had something like GraphQL somewhere for some part of this data, but not for everything.

So there are cases where there are complex reusable queries where we don't need the data directly from the database, but we need the data from the database combined with some other data, with a bunch of other computed data, which GraphQL completely nails. And in Blitz and Prisma, you're left on your own to write all of these reusable queries, fragments, and things.

So I still haven't 100% made up my mind on this thing. I still need to finish building this app for me to say in the future I'd prefer to use Blitz, or I'd prefer to go back and use GraphQL for everything.

00:32:04 - Christopher Burns

I think this is a really interesting point because whenever we get the roundtable together, Redwood, Blitz, we all talk so similarly on Prisma. We instantly talk exactly the same because we use it exactly the same way. React is pretty much identical. But the area that is so different between both of them is that querying layer. Your Redwood camp goes, GraphQL is the only way to do it these days. Like, why would you do it any other way? And then Brandon and Blitz would go, you don't need that. We will show you how to do it without that. And then you go, huh? Can you even do that?

The most interesting concept that actually made me pick one over the other was the multiple client use case. When you need a second client to connect to your API, I believe it then gets a lot harder to integrate that into your Blitz app. Have you had any use cases of that yet, or has it always been direct one-to-one with the front end to the back end?

00:33:03 - Kitze

I wouldn't say this would be easier with GraphQL if you have a consumer-facing API, but you also use the same API for yourself. Actually, you can make more mistakes. You have to think about all sorts of permissions, like what can I expose to the users, what's kept only for our internal usage.

We have this thing with Blink where we expose the Sizzy features through an API in order to consume them on the Sizzy landing page. So if you go to the landing page, there's a section that's built by querying Blink for the key features that we want to display. And that's done by just exposing one API endpoint called slash API slash project slash features. So anyone who has a Blink project, they can easily expose their features to this API endpoint.

So I wouldn't say that this is harder and I wouldn't say that for this I'm missing GraphQL. But if this starts getting bigger, it's going to be very hard to build with just a REST API. And I guess if we expose a public API for doing more things, we're going to do it with GraphQL.

[00:33:57] So we're still going to internally use the Blitz queries for the internal front end. But externally, as soon as it gets more complex than three to four functions and API endpoints, I would definitely just call it a day and expose one GraphQL endpoint there.

00:34:09 - Christopher Burns

This is actually also really interesting. GraphQL, how did you build with it and what tools did you use? Because Redwood likes to say that it is, you could call it the pinnacle of GraphQL development. And when I say that, that's me saying that.

00:34:28 - Anthony Campolo

Yeah. None of us has ever said that.

00:34:32 - [unclear speaker]

Well, I was gonna say that.

00:34:33 - Christopher Burns

I say that because I used GraphQL before Redwood and after Redwood, and after Redwood GraphQL became a lot easier. Things like permission management, things like building your queries, SDL management, function management, all of them came a lot, lot easier when I used it with Redwood instead of building the graph myself.

Is that something that you think is the missing part in your mind when you think of GraphQL? When you say everything's a lot harder, is it because no tool is managing all of that for you?

00:35:07 - Kitze

Yes, 100%. I've been using the Prisma set of tools since the beginning. I trusted Prisma that they're the right way to do GraphQL. Since the GraphQL days, I remember going to their tiny office in Berlin and having lunch with them. And when they told me, oh, soon GraphQL is gonna be gone and we're gonna open source everything, I just dropped my fork and I'm like, this is not gonna end well.

So throughout the years, they just open source more and more and more, and they basically, by thinking they're simplifying the way to build GraphQL endpoints, I think they lost their way in what Prisma is and what's their set of tools. So they had GraphQL Nexus. Then no, it's not GraphQL Nexus, it's just the Nexus framework. Then we drop the framework. We just call it Nexus. Now it's Nexus with Prisma Tools plugin. No, it's not Prisma Tools now, it's just the Nexus Prisma schema plugin.

When you throw all of these 30,000 words at a beginner and tell them how to build a GraphQL server with Node.js, a lot of people will be like, no thank you, I'll just use Blitz or a REST API or whatever, because you cannot rely on any of these tools. They get deprecated, and there hasn't been one tool in that space that has been supported for a long time and kept the same API for a long time.

[00:36:12] Recently I had to do a workshop about React, and I've built myself an app with Nexus, GraphQL, Prisma tools things, and the last time I touched this app was a year ago. So now I need to fix things in my teaching app before the workshop, and I try to fire up this Nexus Prisma thing. Fifty percent of the things were deprecated or weren't working anymore. I try to run my project. It's like, oh no, this is deprecated. Oh no, Prisma doesn't work that way anymore.

So we just did a stream with one contractor that works with me, and I was like, can we rebuild this in Blitz? My entire app that I've been building with GraphQL for months, can we rebuild it with Blitz in three hours? And it actually took us seven hours, but we rebuilt the entire app. So I've been struggling with GraphQL, Nexus, Prisma tools things for months, and now we rebuilt it in seven hours. I'm pretty sure that people will be able to build it with Redwood also in seven hours, but the Prisma and Nexus set of tools is way too unreliable to throw it to a beginner, or even to someone who's not a beginner.

It's going to get intimidating with the amount of options that are there. I don't know how you build with Redwood, so I don't want to compare, but this is way too complex.

00:37:16 - Christopher Burns

When I initially built our first MVP, I built it with Prisma, Prisma, Nexus, and all those tools that were the gold standard for a GraphQL API. It was confusing as hell, and I completely agree with you.

I would say if you want to reignite maybe your passion for GraphQL, you should try it with Redwood.

00:37:38 - Anthony Campolo

Yeah, because all the things you're talking about are exactly what Redwood is trying to address. Redwood doesn't use Nexus, it's only using Prisma as the ORM, and it's trying to create a much more stable, reliable way to build GraphQL. So we hear you on that. And that is exactly what we're trying to do with Redwood. GraphQL is awesome, but it's complicated, and there are ways we can simplify it, and there are ways we can create conventions to make it a lot easier. And that's the whole point.

00:38:03 - Kitze

What if I would like to build a GraphQL endpoint only without actually using Next.js, because Prisma tools and Nexus allow you to do that? I'm not sure if Redwood, if that's the purpose of it, or it's just tightly coupled with Next.js and it doesn't make sense without it.

00:38:16 - Anthony Campolo

Well, it doesn't use Next.js at all. So it has its own React router built in.

00:38:22 - Kitze

Oh yeah.

00:38:23 - Anthony Campolo

You can just ignore the front end entirely.

00:38:26 - Kitze

Aha.

00:38:26 - Anthony Campolo

Because you're saying you hate that you have two ports, right? But because you have two ports and they're separate, you can just delete one entirely from your project. You can just have a static React front end if you want. Or you can just have a GraphQL API if you want, and then you can combine them, or you can separate them and you can run one in a Docker container and one not. It's totally decoupled. And so that's the thing that I really like about it, I think is really nice, is they're decoupled and you can do whatever you want with the front or the back end and take or leave either.

00:38:53 - Christopher Burns

To give you my example in Elephant, where it's basically a payment platform, we have a dashboard and an API. The dashboard is built in Redwood's website. The API is built in GraphQL. And then we also have a Next.js client. That's the payment app that allows you to do all the payments between everyone. That is built in Next.js and communicates directly to the GraphQL API without touching the Redwood side of the Redwood web.

It's definitely worth giving a look at. But the biggest caveat is Next.js is its own complete beast that has its own ways of doing everything, and you will probably miss the Next.js nuances with Redwood. But where Redwood excels is with its API layer, for sure.

I like to say I like to use the best tool for the best use case, as in Next.js with the GraphQL client for the speed in that area, and Redwood for its connectability, doing those front-to-back API calls. It's really worth looking at. This is not one of us trying to convert you over to the Redwood side from the Blitz side.

[00:39:57] It's just that thing, like you said at the beginning, I've looked at both tools and picked one of them. We set these notions in our head that we hear Prisma, Prisma. Well, I would say Prisma 2, but now it's just Prisma. You know, I want to use the best ORM. I want to use the latest version of React. I hear Jest is pretty good and should use that, and Storybook and all these things.

And then you go, I'm going to start gluing it all together myself, and then the amount of hours you've spent gluing it all together, you go, that was pretty much useless because someone else has done it for me. And that's what all of us are coming toward, this point of there's all these tools out there. Some of them are really helpful. And as you said, some of them are viruses that we've spread across everywhere with no need. So it's where to go and where to find their use cases.

I still believe today that Redwood.js and Blitz.js have different use cases for different apps, and it's actually really good to have somebody on the podcast that has actually built an app in Blitz.js in production, because we have actually been very Redwood-heavy, even though we've had Brandon on multiple times.

[00:41:04] What do you think the ecosystem needs to see more Blitz.js websites, more companies integrating things like Blitz.js into their tech stack from the beginning?

00:41:18 - Kitze

Oh, that's an interesting one. We need less hype. We need people to stop listening to, I'm putting big quotes around this word, thought leaders. And we need people to start using their own heads to look at their own analytics and to see, oh, we're actually catering to 100 users. All of them are in the USA. All of them are on a speedy network. I don't need to do whatever Facebook does.

So my latest talk was called You're Not Facebook, where I'm basically repeating for 30 minutes, I mean I wish this was the talk: You're not Facebook. You're not Facebook. I'm trying to tell developers, don't do everything as Facebook does. You don't need to use Recoil to have pure non-mutated state management. You don't need to use GraphQL. You don't need to complicate things.

Because I think when people look at Blitz, they're like, oh, this is simple and straightforward. And what we're used to in front-end development is, I want to make my life complex because secretly I want to believe that I'm building the next Facebook, but you're actually building your blog that three people are going to read.

[00:42:10] So I think that in order for people to adopt this, they need to be more realistic with themselves. Who are they building for? And people need to definitely stop talking about scale in every scenario. Everyone is like scale, scale. But does it scale? Does it scale? Well, in a lot of cases, it doesn't matter.

The discussion about serverless versus servers. I tried Blitz with the serverless Prisma version a couple of times. Too many bugs, too many connection strings, whatever. Prisma is complaining. And I'm like, why am I trying to use serverless at all? And I had no answer. I'm totally fine paying for a server that's stable and supports all of the users that we have now. In the future, if we need to support billions of users and we don't scale, then we can easily switch.

But with everything I've been saying throughout my career since I started attending conferences until now, I see easy solutions in front of my eyes, and I see the majority of developers don't want to accept these solutions. This is a recurring pattern.

I started with Redux. I saw MobX. I was like, holy shit, this is a billion times easier, a billion times more scalable. In my workshops, I open the Sizzy folder. I tell people, I show them our state management in Sizzy. We have, and I'm not exaggerating, probably more than 300 files only for state management with Redux. I would have quit a long time by now. So we're using MobX State Tree.

So we see this as a simple solution, and I hear the majority of people saying, no, but somebody from Facebook said that Redux is scalable and it's nice, blah, blah, blah. Then we have something as easy as Blitz. People don't believe in easy. We have something as easy as WebStorm pitching themselves as, hey, you install this, your life's gonna be easy because we've thought of everything. And then the majority of developers are like, nah, but I would still like to build my own editor and install 50,000 plugins.

Then you have stuff, even Redwood. I would put it in the same corner with Blitz. When people look at Redwood and Blitz, they might say, oh wait, but this is too magical. I want to build my own micro front-end Dockerized Kubernetes solution because I don't think that Redwood or Blitz are good enough for me.

So it's not about what should happen to adopt Blitz or what should happen to adopt Redwood. All of them are in the same corner. Web developers like complicating their life. They like complex things. Redwood and Blitz are pitching themselves as simplifying someone's life, and that's why I think they're not popular enough. Might not be the answer you're looking for, but I really believe this. And I'm not joking.

00:44:25 - Christopher Burns

I do completely agree. And you see all the time with so many tools. My favorite one is fetch. We have this default API in every browser to fetch some data, and then you start believing, you know, if you believe everything you hear on the internet, well, you're going to need SWR or React Query to fetch some data now and then start managing that data. And you've just built a blog or something that just fetches the data once in a blue moon. It can get overkill really, really fast.

And I think that's where we are seeing this overhype really not take off, but polarize a lot of users. I have been polarized, for example, by Gatsby. I built a store, a Shopify store in Gatsby for somebody. It worked for a year, and I want to say after a year it started getting worse and worse. It just started breaking and breaking, like it just won't build. And they're like, look, we really need you to fix it.

[00:45:24] I was like, how hard can it be to not even change the UI, but just change the underlying layer? You know, it's just communicating with Shopify. It took me more than 40 hours to swap it from Gatsby to Next.js. And this was a pretty complex e-commerce store. And it's just like, and now it's on Next.js.

I go to them and I'm like, oh, so you used to have to click build and they would wait five minutes and then you'd get your answer. Now, if you just refresh the page, it'll just refetch it in the background. And they're like, what do you mean? I'm like, it just does that now.

And it's like that thing of technology moves so fast. We're all so fast to jump on something before we've seen how it's going to turn out. And this is my big thing right now with Jamstack frameworks. We watch conference talks about how Astro and all these other tools are coming along and how we should jump on them today.

[00:46:15] But if you're going to build something today, what should you really build it on? I think that's actually a really hard question, and even coming to know where and what framework you should pick to do that, it's still an answer that I don't think we have in the industry, and that's why we're seeing this mass of frameworks coming out of the blue. Here's my way of building it, here's my way. But there's no unified way. That's just the way forward.

00:46:41 - Kitze

Yes. And it's super frustrating. I'm joking in my streams that in this web community, we don't have enough people sitting in pubs drinking beer together all the time.

When I get frustrated with GraphQL and Blitz, I'm like, can the people from Redwood and Brandon from Blitz and the people from Next.js and Guillermo and whoever's in charge of Vercel and Netlify or whatever just grab a beer together and be like, guys, we're all fetching JSON and we're all moving rectangles. Let's just come up with a standard.

So there's not a developer every Monday rebuilding a button, every Tuesday rebuilding a form, every Thursday changing the way we fetch JSON. And at the end of the day, just look back ten years and look back now. Websites look the same, everything looks the same. It's still a bunch of rectangles, but nobody likes to agree on a standard. Everyone thinks, oh, I'm going to build it better than the other person, and it just doesn't end. That's it.

00:47:31 - Anthony Campolo

Part of the dream for this podcast is to get those people together and have those conversations.

00:47:37 - Kitze

Not enough people. We need way more people sitting at a round table making decisions, saying we're not going to rebuild the way we do buttons until 2035. On December 17th, 2035, we're going to change the way buttons look.

I'm trying something internally in my company. It's a bit hard. We said we're going to freeze our stack to Blitz, Chakra UI, Prisma, and a couple of other things that we do internally, and we're not going to change it in the next few years. Because all the time there are new shiny things, like you told me about Redwood right now, and I might go back tomorrow and tell everyone, guys, we're changing everything to Redwood. But I think if we just stick to Blitz, Prisma, and Chakra, and a couple of other things, we can build more, we can reuse more, but it's hard. It's definitely hard.

00:48:19 - Christopher Burns

My final comment is, Bootstrap has been around for years. Why did we move away from it to Tailwind? Why do we now have 20 class names for one button? We seem to hate ourselves and be building ourselves these monsters in our closets.

Thank you for coming on the podcast. We'd love to get you on again to talk about this stuff again in the future. Maybe when Blitz has hit 1.0, we can get you on to talk about how you've found upgrading and growing with the framework inside your company and outside. So where can people find you and get a hold of you?

00:48:53 - Kitze

All right, well, first of all, thank you for inviting me on the podcast. It was a pleasure being here and talking to you. Thank you for not starting to talk about CSS, because we would have needed another hour to do it.

People can find me at kitze.io. That's my website and I have all of my projects there. Usually I'm on Twitter. That's T-H-E-K-I-T-Z-E. You'll probably have links to this and I won't need to spell it.

So either we're going to do another podcast at some point, or I'm going to get so frustrated with all of these frameworks and the way we do things, and I'm going to become a fisherman and we're never going to talk again.

00:49:33 - Christopher Burns

Thank you.

00:49:33 - Kitze

All right. Thank you very much.

00:50:05 - Anthony Campolo

Sweet. You almost made it the whole episode without swearing. Dropped one swear right towards the end.

00:50:09 - Kitze

Okay.

00:50:10 - Christopher Burns

Hey, that's classed as PG-12 these days.