To Fork or Not to Fork with Brandon Bayer

Episode Description

Brandon Bayer returns to discuss why Blitz.js is forking Next.js, explaining the technical limitations that led to the decision and how they'll maintain it.

Episode Summary

Brandon Bayer of Blitz.js joins the FSJam podcast for a third time to explain why the project has decided to fork Next.js rather than continue with its custom compiler approach. The conversation begins with a general explanation of what forking means in open source, touching on historical examples like the Node.js/io.js split. Brandon then walks through the specific technical pain points that drove the decision: Blitz's custom compiler, which transforms user code into a valid Next.js project in a hidden .blitz folder, had reached its limits, causing issues with browser stack traces, file path resolution, and compatibility with tools expecting a standard project structure. He outlines the two paths considered—becoming a lightweight add-on or forking—and explains why the fork preserves Blitz's identity as a batteries-included framework akin to Rails or Laravel. The discussion covers how the fork will be maintained using a tool called git subrepo, the relationship with Vercel and Guillermo Rauch, deployment compatibility, and the broader cultural dynamics of forking in open source. Brandon also touches on the new Blitz website (itself forked from the Tailwind docs site), Tailwind JIT, the path to 1.0, and how the refactoring follows a "make it work, make it right, make it fast" philosophy.

Chapters

00:00:00 - What Is a Fork and Why Do They Happen?

The episode opens with Brandon Bayer being welcomed back for his third appearance on FSJam. The hosts set the stage by asking Brandon to explain what a fork is in open source: essentially copying a repository to make independent modifications while optionally contributing changes back upstream.

The conversation broadens into historical context, with Christopher recounting the Node.js/io.js fork that was driven by frustrations over corporate governance and slow adoption of V8 improvements. Anthony raises the ambiguity of how forks appear in the GitHub UI—whether they signal abandonment or healthy evolution—and Brandon notes that forks sometimes serve as a way to continue maintaining a project the original author has left behind.

00:04:18 - Why Blitz.js Needs to Fork Next.js

Brandon lays out the core technical problem: Blitz needs special folders for queries and mutations that get automatically converted into API endpoints, but this can't be added to Next.js core. The workaround was a custom compiler that transforms Blitz code into a valid Next.js codebase inside a .blitz folder, but this approach has hit its limits with broken browser stack traces, file path issues, and incompatibilities with other tools.

The hosts connect this back to earlier episodes that debated the tradeoffs of building on Next.js. Brandon clarifies that the fork doesn't mean moving away from Next—Blitz will stay in lockstep with upstream releases. The goal is simply to replace the fragile custom compiler by surgically injecting the needed functionality directly into Next.js internals, resulting in better stability and faster performance by eliminating a redundant compilation step.

00:09:49 - Performance, esbuild, and Maintaining the Fork

Anthony asks whether Brandon plans to integrate esbuild into the fork, which Brandon laughs off as too ambitious given the need to minimize merge conflicts with upstream Next.js. He explains that any major internal change like swapping the bundler should be done collaboratively in Next.js core. The team's strategy is to keep the fork as close to upstream as possible and only make targeted, surgical modifications.

Brandon then describes the tooling behind maintaining the fork, specifically git subrepo, which pulls the forked Next.js code directly into the Blitz monorepo without the complications of git submodules or subtrees. Development happens in the monorepo, changes are pushed back to the forked repo, and upstream updates are merged on a tag-by-tag basis. This setup integrates with Blitz's CI, running both Next.js integration tests and Blitz's own end-to-end tests.

00:14:29 - Framework Philosophy and the Relationship with Vercel

The discussion turns to the broader implications of the fork. Brandon sees it as healthy competition, giving users who want features Next.js won't adopt a place to go. He explains that Blitz and Next.js have a fundamental tension: Next focuses on content sites, fast ecommerce, and static generation, while Blitz aims to be a full-stack framework like Rails or Laravel.

Brandon shares that he discussed the fork with Guillermo Rauch before writing the RFC. Vercel was willing to work together on an add-on approach, but ultimately the Blitz team decided forking better served their vision. He reassures listeners that deployment compatibility will remain intact—Blitz's compile output will continue to match Next.js, meaning anywhere you can deploy Next, you can deploy Blitz, including serverless environments.

00:19:09 - The New Website, Tailwind, and Branding

Anthony shifts to the new Blitz website, which Brandon reveals was built by forking the Tailwind documentation site and converting it to Blitz—taking advantage of its existing MDX and navigation infrastructure. This leads to a lighthearted exchange about Blitz's comfort with forking and the ethos of building on top of existing open source work rather than reinventing the wheel.

The conversation touches on Tailwind JIT, which Brandon praises for eliminating the old workflow of starting with a massive CSS file and purging unused styles. The hosts also discuss framework branding, with Brandon crediting designer Christina for the Blitz logo and website design. They compare swag stores—Blitz uses Teespring while Redwood has a custom Shopify site—and Brandon announces free Blitz stickers available worldwide.

00:27:12 - Beta, the Road to 1.0, and Next Steps

Brandon confirms that Blitz hit beta on February 17th, exactly one year after the initial launch announcement, meaning minimal breaking changes going forward. Christopher notes that reaching 1.0 matters partly for organizational buy-in, even though the actual jump in stability from the last pre-release will be small. Brandon adds that users are already so productive with Blitz that occasional breaking changes haven't deterred them from using it in production.

Looking ahead, Brandon explains that he merged the PR switching Blitz to the forked Next.js build that same day, with a canary release imminent. The next phase involves migrating functionality from the custom compiler into the forked Next.js core over the coming one to two months, following the principle of "make it work, make it right, make it fast." The episode closes with Brandon promoting free Blitz stickers and the hosts wishing him well on the fork journey.

Transcript

00:00:00 - Anthony Campolo

What could go wrong? Certainly nothing.

00:00:13 - Christopher Burns

Welcome back to the FSJam podcast. With us today is someone who's been on before with some exciting news and a pretty major development. It's Brandon from Blitz.

00:00:27 - Brandon Bayer

Hello, hello.

00:00:28 - Anthony Campolo

Hey, you're actually our third-time guest at this point because you joined us for episode six, and then you're also on the roundtable episode eight. It's really great to have you.

You have continued to really work on Blitz as your main thing since you first talked to us, and it seems you're actually going to continue to expand out into even more of your own thing. We want to talk about the thought process behind the fork and what you're hoping to get out of it.

First, can we set the context and describe what a fork is in the first place? This might be something that people may not know if they're not as technical. I actually learned about forks from blockchain and crypto. The first fork I ever heard about was the Ethereum fork, and at the time I didn't really know what that meant.

00:01:23 - Brandon Bayer

Blitz is built on top of Next.js, and so we have forked Next.js. What a fork means in the context of an open source project is: there's a main project that has a main repository on GitHub, and on GitHub you can click a fork button. It will basically copy that repo over to your own, to a separate repo, that allows you to make pull requests back to the original repo. Or you can just make changes in your fork and use your fork.

So if the main repo does things that you don't like for some reason, then you can just fork it, modify it, and use your modified version in place of that. That's pretty much what a fork is.

00:02:04 - Anthony Campolo

What are some common reasons people would want to fork?

00:02:07 - Brandon Bayer

Well, a big one that happened a number of years ago is people forked Node.js. That was the fork. I'm not sure why they forked, but I think it was sort of like...

00:02:19 - Anthony Campolo

We actually talked about this with Peter Cooper a little bit. It's kind of complicated. I'd be curious to hear your take on it, actually.

00:02:25 - Brandon Bayer

No, actually, I don't know that much. So maybe you should fill us in here.

00:02:28 - Anthony Campolo

Yeah, it was catalyzed by a specific event, which was a Russian hacker who was basically mad that Joyent wasn't merging his pull requests fast enough because there were all these kind of corporate structures being built around companies like Joyent and npm. The people who just want to hack on open source were kind of frustrated.

There were also people who were frustrated that they weren't adopting V8 improvements and stuff like that. So people kind of rallied behind this one guy. Forking, they call it a table-flipping moment. Then a bunch of people played a lot of politics around it, and it ended up splitting into two groups and then eventually merging back into one group.

00:03:13 - Brandon Bayer

Well, thanks.

00:03:15 - Anthony Campolo

That's interesting.

00:03:16 - Brandon Bayer

Thanks for answering my question.

00:03:19 - Anthony Campolo

It's a lot of podcasts.

00:03:21 - Christopher Burns

The one thing that I have with forks, and I wouldn't say it's a vendetta or anything, but I could never quite tell in the GitHub UI when it says something is forked if it's like a stamp of glory or a stamp of shame. It's just one thing I don't know. Sometimes I see it's like, oh, this one's been forked. But is that a good thing? Sometimes yes, sometimes maybe not.

00:03:47 - Brandon Bayer

Yeah. Sometimes projects get abandoned and then somebody will fork it and continue to maintain the fork in place of the original one.

00:03:54 - Christopher Burns

Exactly. But at the same time, why don't they just copy the code into a not-forked repository? Maybe these are some Git things I don't understand.

00:04:03 - Brandon Bayer

Well, you can copy the thing and set up a new GitHub repo where it doesn't show that it's forked, but essentially it's exactly the same. But sometimes it's helpful to see, like, oh, this has been forked from this other thing. So you can kind of get the context and the history of it.

00:04:18 - Anthony Campolo

There's also going to be the question of whether we want to bring these changes back into the base library at some point. That's something we're definitely going to get into.

When we get into the specific decision-making around Next.js and why you guys have decided to maintain your own fork, we'll link to this in the show notes, but you have an RFC that just says, "Time to maintain a fork of Next.js?" So what are the considerations here?

00:04:48 - Brandon Bayer

There's one key thing that we needed for Blitz.js that Next.js doesn't provide, and we needed a way to make our Blitz queries and mutations work. We have special folders in Blitz.js called queries and mutations. Those are automatically converted to API endpoints without you having to do that.

So it's a very similar process to how pages folders and API folders work in Blitz and Next, where if a component is in a pages folder, it's automatically turned into a page and wrapped with the routing logic and everything that it needs internally. We needed to take that same process, but for queries and mutations.

But we can't add that into Next.js core. So what we ended up doing is very clever, but we've reached the limit of it. We built a custom compiler thing that literally takes your Blitz codebase and has this complex Node stream processing engine that takes your Blitz code and processes it, changes internals of files, moves some files around, and then spits it out into the .blitz folder as a totally valid Next.js codebase.

[00:05:59] So if you go into the .blitz folder, you'll see that inside the pages folder and the API folder is all your queries and mutation handlers and so forth. That's worked decently and it's gotten us to this point, but we've really kind of reached the limit of that. It's sort of busting at the seams at this point.

Number one, it moves your files around. We have to, in the log processing, read all the logs and recreate the file paths, but that only works on the server right now, not in the browser. So your browser stack trace is goofy.

Also, we're actually running Next.js from this other folder, not from your project root, and that causes problems like using Nexus and other things that expect something more normal. So we decided we were having too many problems. We need to just fork Next.js and modify the internals so we can get rid of this custom compiler thing.

[00:06:55] So honestly, it's a little bit gross. It's going to be a much nicer, more first-class thing, and it's going to solve most of the problems that we have right now blocking us from 1.0.

00:07:06 - Anthony Campolo

This is so interesting because if our listeners want to go back, they can listen to episode one, which is our second episode. Episode zero is our first episode, but in episode one, called The Next Requirement of FSJam, the whole discussion was between me and Chris and talking about, do we want to build on top of Next? Do we gain something or do we lose something?

You've been a proponent this whole time that by using Next you gain a lot, but you hit a point where you started to see more of a drawback of continuing to go down that road.

00:07:38 - Brandon Bayer

Well, so we still 100% are on board with building on top of Next. That's one of the big reasons people choose Blitz, like over Redwood, for example, is because they want to use Next. We're not moving away from Next.js. We're only changing the internal implementation of how we do this.

We're going to continue to keep the Next.js fork up to date, so we'll continue to stay in lockstep with Next.js proper. Any features they add will automatically get those too. It just changes how we implement the current Blitz functionalities. It's going to be much more stable and nicer.

00:08:12 - Christopher Burns

One of the big questions that I have: some people looked at it as a cone of shame when Redwood decided not to take the Next route, and others backed up Blitz because other projects were appearing with the same kind of mantra, with Next as the base.

Do you think other projects that choose to use Next as a base, such as Bedrock and also Bison, will also see the same limitations that Blitz is seeing? Or do you think they will totally circumvent them?

00:08:43 - Brandon Bayer

No, they don't have the same problem at all because those are basically boilerplates. It's just using regular Next.js and adding stuff on top. They're not frameworks.

So the issue we have is that we're building a framework, and we want to customize stuff that's inside Next.js, like how API routes work and stuff, where those are just fully okay to keep Next.js like it is and then build stuff on top.

00:09:11 - Anthony Campolo

And that's because they don't have any sort of compile step, right?

00:09:14 - Brandon Bayer

Right.

00:09:15 - Christopher Burns

Does the fork affect performance? Because you said a lot of it is about internals. So will the fork make the Blitz stuff faster in the long run?

00:09:25 - Brandon Bayer

Yes, definitely. We take your code, compile it into a different folder, and then Next.js takes your code and compiles it. Then we run that. Anytime you change a file, it gets copied to your .blitz folder. So that's one step. Then Webpack has to detect it and actually compile your code, and then it gets to your browser. So yes, this is going to make it a lot faster. I can't wait to get it fully shipped here.

00:09:49 - Christopher Burns

But yeah, my next question is, are you going to implement esbuild into your fork just to smash Next into the floor and be like, this is what you should have?

00:09:59 - Brandon Bayer

Yep, here we go. We're going to do it. No, I'm just kidding. It would be hard. That'd be really hard.

We're hoping that they do that or something similar. I saw a tweet this week or last week that they've made hot reloading three times faster. They're definitely making improvements on that. Hopefully they'll keep working on that.

00:10:17 - Christopher Burns

I saw that tweet as well. It was by one of the core team, and they were basically rebuilding the Vercel homepage banner in real time, almost like it was one of those effects in some websites where it types out and then deletes, then types it out. It was literally like that.

00:10:37 - Brandon Bayer

Yeah, it looked like it was just typing. So I'm not sure if it was powered by a VS Code plugin or not, but I don't know.

But building and changing it would be too big of a thing for us to change the internals. If we wanted to put esbuild in it, we would go and do that in the Next.js core, collaborate with them, and do it there. Since we have a fork and we want to keep up to date, we have to be careful about how we change things. Otherwise we're going to have gobs of merge conflicts.

We want to keep things as close to Next as possible and then just surgically inject certain changes and things where we need them.

00:11:12 - Christopher Burns

As you just said about surgically injecting things, this is just a more complex version of it. There's a package that literally, when you install it, will edit the node modules.

00:11:26 - Brandon Bayer

patch-package.

00:11:27 - Christopher Burns

patch-package. Yeah, it's a more complex version of that.

00:11:29 - Brandon Bayer

Yeah, that's a cool tool. But this just modifies your code in node_modules. A fork is going a step further and actually publishing a changed package to npm.

00:11:40 - Anthony Campolo

And you had mentioned that you had considered changing Blitz to be an add-on to Next.js. What would that have entailed?

00:11:48 - Brandon Bayer

The base assumption was we have to get rid of this custom compiler setup, and there's two paths. We could fork Next.js and move the functionality that we need into Next.js, or we can go a different route and make Blitz less of a framework and more like just an add-on to Next.js.

The problem is you would lose a lot of things, like the coherent nature of Blitz being the framework. So it's just going to be more like a library. People like that it's a framework. It's a batteries-included framework. It's a one-stop shop for everything they need versus having to go look at a library for Blitz and then go look at a library for whatever else they're doing. That's more like the old school way. It's just piecing stuff together, right?

In fact, we had a bunch of people really excited about forking Next.

00:12:32 - Anthony Campolo

Yeah, that was one of them.

00:12:34 - Brandon Bayer

So there's various things that Next does that's just not great, and we want to change some of those. Hopefully some of those we can roll back upstream, but obviously Vercel is in charge of Next, and they're making decisions. They do a pretty good job of making decisions that are good for the community, but they also have their business interests in mind.

Another constraint is they don't make breaking changes. So they're pretty much backwards compatible since day one, almost. We're a new framework, and so we can change things now that they can't. That's another reason.

So fundamentally, Blitz and Next have a fundamental tension between what they want to be. Next.js and the existing community there is focused more on content sites, really fast ecommerce pages, static incremental generation, all of those sort of things. Blitz wants to be a more full-fledged framework like Ruby on Rails or Laravel. So they're not a lot different, but they're different enough that if you try to keep them together on the same path, using the same package, it frustrates us.

[00:13:41] It frustrates them. And so if you fork, then we can have this space between us, kind of like running on parallel tracks. It's not that far away, but it's enough away that it's going to be a better experience in the long term.

00:13:53 - Christopher Burns

And it's that thing where, say if you want something added to Next.js and only your community desires it, that means you could implement it and Next.js doesn't need to care.

The other thing to open source projects is you could comment one day saying, hi, I've got this feature released, totally built it out. Then the team goes, yeah, we're not integrating that. That's totally against what we're standing for. And that's the end. But if you forked it and obviously keep the fork up to date yourself, then that software lives on and can be used.

00:14:29 - Brandon Bayer

Right. I think it's also kind of healthy to provide a bit of competition. There's now an outlet for people who want things in Next.js that aren't there or aren't willing to change. Now we can add them in Blitz and they can just use Blitz. Even if they're not using the queries and mutations, but they're just basically using a vanilla Next.js project, they can use Blitz and get the nice features with zero overhead or anything really.

00:14:57 - Christopher Burns

Have you renamed the fork to something different or is it just blitz/next?

00:15:02 - Brandon Bayer

So most of our packages are published under the Blitz.js namespace, @blitzjs. This is published as @blitzjs/next.

00:15:10 - Christopher Burns

I might put in a petition to rename the fork to Next++.

00:15:16 - Anthony Campolo

Yeah. You opened this RFC in February, February 23rd. How did the community first react to the RFC?

00:15:26 - Brandon Bayer

It was quite positive. The vast majority of people were in favor of this, and so that's why we did it. We talked about, in the RFC, the add-on route or the fork route, and there's more discussion around that. It's been good there. They're excited for it.

00:15:41 - Anthony Campolo

Was there any consistent thing that they were concerned about or that they were really saying like, this is what we need to consider if we're going to go down this route?

00:15:49 - Brandon Bayer

The only thing really is just the overhead of maintaining the fork, which right now is mostly on my plate. I'm dealing with it, so it doesn't really affect anyone else too much. I'm doing everything I can to minimize that. We could talk about some of those things.

00:16:01 - Anthony Campolo

Yeah. So we were talking about how if you are going to fork it, then you have to worry about how you're actually watching for the changes. You can't just watch the repo and every time an email comes in, be like, all right, what changed? I gotta change that in mine now.

How do you do it? Do you have automated ways of checking what changes are made? How do you approach that?

00:16:22 - Brandon Bayer

Git is a super powerful tool, and Git has a couple things built into it that allow you to pull nested repos inside of another repo. Git submodules is one of those things, and then there is, I forget the name of another one.

It allows you to take another repo and nest it inside your own. But there's a bunch of problems around that, and it doesn't work quite like you want because what we want is just one monorepo, right? We want to have the Next.js build inside our monorepo and it all works together, just like it does now. We don't want to have a separate repo where we're working on Next.js core and then another repo that's other stuff.

So what we're doing is using a tool called git subrepo. It does not use git submodules, or the other thing that I can't think of the name of. It's a new way that allows you to take code from another repo and bring it directly into a repo, but without...

[00:17:16] There's no Git shenanigans for end users. For anyone cloning the repo, it just looks like normal code. It's just normal pull requests and normal everything. But there's a special file in there called .gitrepo that has a little bit of metadata about where the code came from and the commit data, and that allows you to easily push and pull from another repo.

So we have a forked repo under the Blitz org that is just a straight fork of Next.js. Then we use git subrepo to pull that forked repo into the main Blitz monorepo. That's where we run all the tests and everything. Just today I merged that PR into canary that integrates that fork. It's all integrated with our CI. It runs all of the Next.js integration tests, and it integrates with our own Blitz.js end-to-end tests and so forth. It's pretty sweet.

So what happens is we do the development in the Blitz monorepo. When we're ready to sync the fork with Next.js, we run the git subrepo push command.

[00:18:17] It pushes it back to our forked repo. Then we go in our forked repo and merge in the changes from upstream Next.js into there. We'll do that on a tag basis. So I will be doing git merge Next.js at 10.1.2 or whatever is the latest version. That will merge upstream changes using Git straight into our repo. If there are any merge conflicts, then I'll resolve those and then we push those back to our monorepo. And there you go.

00:18:46 - Anthony Campolo

Git subtree is the other one you were thinking of?

00:18:49 - Brandon Bayer

Yes. Subrepo is an improvement on both of those. It's pretty cool.

00:18:53 - Christopher Burns

I also wanted to talk to you about something else that has happened since you were last on, and that is you have a new website. It's not quite new at this point because it's been out about a month or so, but I was wondering what the internals are on that website. Is it built with Blitz? Is it built just with Next?

00:19:09 - Brandon Bayer

It's built with Blitz.

00:19:10 - Christopher Burns

Oh, interesting. And do you use any of the Blitz features?

00:19:13 - Brandon Bayer

No. It's pretty much just a plain Next.js site. The base of it, we forked the Tailwind docs site and then just converted it to Blitz, which is super easy. Now it's a Blitz site.

00:19:25 - Christopher Burns

You forked the base of Tailwind?

00:19:29 - Brandon Bayer

Not the Tailwind library, but the Tailwind documentation site.

00:19:32 - Christopher Burns

Any reason why you did that?

00:19:34 - Brandon Bayer

Because they already had a ton of MDX navigation menu stuff all set up. It's a lot of code to make it work.

00:19:42 - Christopher Burns

Right? No, I think that's really interesting that you basically forked someone else's website. It's not technically cheating. It's more like you're just copying the boilerplate.

00:19:52 - Brandon Bayer

But open source, man. Do what you want.

00:19:57 - Christopher Burns

Yeah. It's open. Of course.

00:19:59 - Brandon Bayer

We're kind of good at this forking thing, huh?

00:20:03 - Christopher Burns

Yeah. You are?

00:20:04 - Brandon Bayer

Yeah. It's great to build on top of other things that are already there. It's like, why reinvent the wheel?

00:20:09 - Anthony Campolo

So do you think someone's going to fork Blitz?

00:20:11 - Brandon Bayer

Well, it's possible, but hopefully they'll talk to me first. I see no reason to fork Blitz because we're very open to whatever people want. Let's put it in there.

00:20:19 - Anthony Campolo

Yeah. It's a really interesting cultural difference because it gets back to what we were talking about. Do you accept contributions at all? This is where the question of forking really comes into play, because it's kind of like declaring independence. This is now my domain and I declare this is my zone. I can do whatever I want with this.

It's one of the things I really like about open source, because it allows people to kind of self-select into where they want to go. So I think it helps alleviate some conflict and tension there by always kind of having that escape hatch. I just wonder if it kind of leads to a more fractured ecosystem if everyone's jumping off and doing their own thing.

00:21:05 - Brandon Bayer

Yeah, I think some people, I've seen some libraries, are super quick to just fork something and change it, or they don't even really try that hard to make the changes in the original repo. I think your first step should be to try to make it work together, try to make the changes in the main thing.

But there comes a point when you just need to. When your vision and your goals are totally not aligned or something, there comes a time where you need to do the fork.

00:21:34 - Anthony Campolo

Yeah, and I know you've been involved with speaking with Guillermo, who is the leader of Vercel and Next. You guys were trying to work this out for a while before the split ended up happening. So I'd be curious, to whatever extent you're comfortable sharing, how that conversation went. What sort of stuff you guys were discussing.

00:21:53 - Brandon Bayer

I brought it up with him before I even wrote the RFC. There was some discussion about, could we make it an add-on? Because right now, as it stands today, we couldn't even really be an add-on. They would have to modify things or add features in core in order for us to even do that.

They were definitely willing to do that, and they were wanting to work with us, but ultimately we decided that that wasn't the best approach for Blitz.js.

00:22:18 - Anthony Campolo

Interesting. Do you know how other people higher up in the Next group felt about it? If they were trying to push more towards, let's make this work, versus people who were kind of like, let them do their own thing. Do you have a read on how the rest of the team felt about it?

00:22:33 - Brandon Bayer

No, not really.

00:22:34 - Christopher Burns

Even though we forget that Next is only part of the pie because Vercel is the thing that makes Next money, and they are pretty good at supporting everything at this point, not just Next.js websites.

So one of my last questions regarding Vercel would be, is it still fully supported? Do you think you'll see a point in the future where it's no longer supported, or will there be better options?

00:23:01 - Brandon Bayer

We have zero plans to change the compile output of Blitz.js. The long-term goal, as far as I can see, is to keep the same compile output format as Next.js itself. Next.js and Blitz.js apps should always be deployment compatible pretty much anywhere.

It should be even better because this custom compiler thing sometimes doesn't work quite right. Once we get rid of that, then it should be even more aligned. Anywhere you can deploy Next, serverless included, Blitz will work. So I don't see that going away. I don't see any changes on that front.

00:23:39 - Christopher Burns

Do you like Tailwind?

00:23:43 - Brandon Bayer

Yes, I do. I especially like Tailwind JIT.

00:23:48 - Christopher Burns

Oh, no. It'd be interesting if you forked that documentation website and were like, I hate Tailwind, and took it out.

00:23:57 - Anthony Campolo

So what is Tailwind JIT? Why is it cool?

00:24:00 - Brandon Bayer

Oh, it's a just-in-time compiler for Tailwind. You no longer start with a two-megabyte file and then have to use PurgeCSS to purge it out. Now you start with nothing, and it detects what classes you use and then adds them. It's way faster. You don't have to set up variants ahead of time, and you no longer run into out-of-memory issues with Next.js and Blitz because of too-large CSS files.

00:24:28 - Anthony Campolo

Indeed. I don't know if you've ever seen it, but Tom Dale has a famous blog post that says, "Compilers are the new framework."

00:24:35 - Brandon Bayer

I haven't seen that.

00:24:36 - Christopher Burns

What's really interesting is I like something called twin.macro, and one of the big things about it was you didn't have to import anything. Everything was just built in time with JS and CSS.

But the thing is, the JIT compiler has pretty much put a spanner in that one. Now the only thing you would go to something like twin.macro for is having your Tailwind in JS. What's really interesting is they both use the exact same syntax, so there must have been some communication beforehand with the short-hand in JIT. If you like z-index, then a square bracket five, you could do that in twin.macro for a little while. So I wonder if there was communication there and maybe a fork of someone's code.

00:25:29 - Brandon Bayer

I don't know that there was, but it was probably some inspiration for sure.

00:25:33 - Christopher Burns

Yeah, I can't get over how good your website is. You had someone offer their time to design it for you, didn't you?

00:25:42 - Brandon Bayer

Yep. Christina. She is the one who designed the Blitz logo all the way back, very early, and then started working on the Blitz website design too. She's amazing to work with, did an amazing job, and all for free, so I definitely sent her swag.

00:25:58 - Christopher Burns

Is she a developer?

00:26:00 - Brandon Bayer

No, just a designer. She's a web designer. She does great web design.

00:26:04 - Christopher Burns

It's such an interesting conversation about how frameworks and packages get their brand. Redwood went to 99designs. I'm pretty sure that's public info. He said it in the one-year meetup.

You obviously got help from a graphic designer. Gatsby, I think, open sourced their logo as well. It was a conversation of which one do you like best back in the day before 2.0, I believe.

00:26:29 - Anthony Campolo

Oh, you're the Gatsby guy.

00:26:32 - Christopher Burns

I am. Now we're talking about something else, such as swag. You also now have swag. Redwood now has swag. But who has the better swag, would you say?

00:26:42 - Brandon Bayer

Well, Redwood definitely has the best storefront because it's a custom-built Shopify site, or at least it's a custom Shopify site. I don't know how much of the UI is custom.

But we're using Teespring, which is an on-demand print service. You upload your designs, pick your products and colors and everything, and then they have the site for you and the fulfillment and all of that sort of stuff. Eventually, at some point, we might get a custom Shopify site too.

00:27:12 - Anthony Campolo

But Blitz.js is in an interesting spot right now because you guys hit, I think, beta and you're getting close to 1.0. Is that the right kind of timeline?

00:27:20 - Brandon Bayer

Correct.

00:27:21 - Anthony Campolo

So what does that mean going into beta? What changed?

00:27:24 - Brandon Bayer

That means that most of the outstanding issues were fixed. That was, I think, February 17th, which was the exact one-year anniversary of the first launch announcement. So that was cool.

It's minimal breaking changes from here on out. Most of it's there. It's a good time to start building production websites with it, even though there's a bunch of people that already have been doing production sites for a long time.

00:27:49 - Anthony Campolo

It'll be really interesting to see as these projects start to hit 1.0, how much of an effect that'll have. It's partly just people feeling okay telling their boss that they're using this thing because it's like, oh, it's 1.0, it's a real thing. Being able to justify picking it as a technology is potentially a big thing.

But like you say, the jump from 1.0 or whatever the minor version right behind that is actually going to be very, very minor because these frameworks have put in so much work to get to a stable point by 1.0, right?

00:28:23 - Brandon Bayer

It's one of those things where people try Blitz, and they're so productive with it that they're like, it doesn't matter if we have some breaking changes. We have to change it. The productivity is still way better than what we had before.

00:28:36 - Christopher Burns

So is there anything else you want to cover? Anything interesting in the next few months that's going to happen? Anything that you know is going to be such a quick win with the fork of Next?

00:28:46 - Brandon Bayer

Just today I merged the PR that switches Blitz to use our forked build, so it doesn't change anything about the custom compiler. Everything's still exactly the same. All it does is switch to use our own build of Next.js. That is merged. I'll be shipping a canary version probably today.

So the next steps are to start moving functionality from our custom compiler into Next.js core with the intent to get rid of our custom compiler. Hopefully that'll take a month or two to complete, but that should resolve most of the issues that we have right now.

00:29:22 - Christopher Burns

And so when that's all done, it's almost like you're not rewriting the whole framework. You're just refactoring and re-putting it into a new spot.

00:29:34 - Brandon Bayer

Yep.

00:29:35 - Christopher Burns

It's going to be like a whole new, fresher pain.

00:29:37 - Brandon Bayer

It's like that make it work, make it right, make it fast type of thing. So we made it work. Now we're making it right.

00:29:44 - Anthony Campolo

It's actually in Redwood's readme.

00:29:46 - Brandon Bayer

Yeah.

00:29:47 - Christopher Burns

Well, thank you for your time today, Brandon. We'll have to get you on again. But there's a lot of people waiting for a second episode. By then, we shall know if the fork was doomed to fail or doomed to succeed. Doomed to fail.

00:30:07 - Brandon Bayer

It was meant to succeed or something. To succeed. Yeah.

00:30:11 - Christopher Burns

There we go.

00:30:12 - Brandon Bayer

It was meant to succeed. Thanks for having me on. We now have Blitz stickers. So if you go to Blitzjs.com/stickers, you can enter your name and address, and we will send you three different Blitz stickers free anywhere in the world. So we're finally catching up to Redwood on that point. It's cool.

00:30:33 - Anthony Campolo

We have to grab some of those.

00:30:34 - Christopher Burns

I smashed my laptop screen and I'm going to have to get it replaced by Apple. So maybe once I get a new screen, I'll put the Blitz stickers on it first.

00:30:43 - Anthony Campolo

Cool, cool. Thanks a lot, Brandon. I wish you the best of luck on this endeavor that you're going down. It seems like you're at least making all the right considerations, and you can never know going into these things what's actually going to happen. But I imagine you're going to learn a lot in this process either way.

00:31:00 - Brandon Bayer

I've already learned a lot about the Next.js internals, which is good.

00:31:04 - Anthony Campolo

Cool. Thanks so much, Brandon. Have a good one.

00:31:06 - Brandon Bayer

Thanks. Bye.

00:31:37 - Anthony Campolo

I've been trolling Ryan Florence so hard on Twitter.