Let's Learn esbuild!
with Sunil Pai
How will we build web apps in the future? Sunil Pai believes we'll be using esbuild. Let's learn how esbuild and bundlers like Vite built on top of it work to see how it can speed up our dev workflows!
Resources & Links
Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.
Jason: Hello, everyone, and welcome to another episode of Learn with Jason! Today on the show, we are bringing in the one and only Sunil Pai. Sunil, how are you doing?
Sunil: Great, how are you?
Jason: Great. Great to have you on the show. Sunil and I met at React India. What a magical experience that was. That might have been the last conference I went to remotely before the lockdown.
Sunil: That was a year and a half ago, Jason.
Jason: I can't believe it. It's been so long. But, yeah. So, Sunil, for those who are not familiar with your work, do you want to give us a little bit of a background on yourself?
Sunil: Sure, hi. My name's Sunil. I currently work helping build frontend infrastructure in the big evil JPMorgan, great place, by the way. Come work with me. It's so nice. Before that, I worked at Facebook for a while, I was or not React team, before that, eCommerce in India. I've done a bunch of things. And I think a lot of people know me from Twitter where is where I spend a lot of my time. An unhealthy amount of time. But, yeah. Folks know me from -- oh, I was a big part of the CS and JS things for a while. Sorry about that. But yeah. A whole bunch of claims to fame, I guess. And now I'm on the Jason show. That's nice too. I'll tell people that too next.
Jason: I look forward to seeing it at the top of your resume. I hung out with some bearded clown on the Internet once. I'm super-excited to talk to you for a multitude of reasons. You have been at the center of a lot of big movements. Your involvement with CSS-in-JS, your involvement with React, your work on constantly moving the ecosystem forward. When you're paying attention to something, it's a good thing to give serious consideration to. Just having that access is always really exciting. I think you're cool. It's fun to be able to hang out and spend some time with you. But the other thing that I'm really interested in is you pitched teaching something that I think a lot of people are really starting to hear about, but not a lot of us have really had a chance to learn. Which is esbuild. So, at a high level, what is esbuild?
Sunil: Can you imagine shipping to production 200 times a day? And these are questions that we can now answer.
Sunil: It's weird.
Jason: Well, what I think is exciting about this is it's something that opens up the door to more generally to something that's currently possible with like very specific architectures, right? So, when you talk about shipping to production multiple times a day, one of the things that -- that like, you know, I work at Netlify and the whole pattern that we talk about is this kind of like pre-compile, you know, immediate CI kind of workflow. And as a result, because of these architectural decisions that we've made, at Netlify, we typically ship to production a dozen or more times a day. And it's because of these architectural constraints. What esbuild is promising is that it's gonna broaden the types of architectures that can start to adopt these patterns. Now, it's not gonna solve any of the issues that tend to slow down shipping that are more red-tapey like caching policies and complexity of shipping that makes apps kind of fragile and hard to reason about. But like the strict law of, we have some code, that code needs to get to production. If esbuild is delivering that, you know, that 10x, that 50x speed improvement, that's like -- it's kind of a game changer. Because now you don't have to churn the whole app. You don't have to rewrite the whole thing to get that benefit. You can just swap out the way you're bundling.
Sunil: I was highly skeptical about this even like a month ago. Like, hey, this doesn't make sense. Webpack 5 has persistent caching and that should be good enough for me. I don't really need to ship 200 times a day, come on. That doesn't make sense. That's -- except that when you actually dive into it and you try it out in production, it -- you see that it actually benefit -- like, it's very knock-on effect benefits. Oh. Now I figured out how to make my build faster. But I'm still spending 45 minutes running just tests. And then you go into the indulgence and see they have flags called only change. Which runs tests only -- it runs only the tests that were affected by the files that were changed in the PR. And suddenly your tests are going down from like 45 minutes to 2 minutes. And there's this whole knock-on effect of affecting the way -- you start demanding more from your software. Why the hell isn't the TypeScript team running faster so I with go faster? And the incremental mode. Why would I care about persistent caching when my build can run faster than the time it takes to run the cache and populate it on my machine. Those are the kinds of questions you can start asking. It's pretty crazy.
Jason: What I find fascinating about this discussion, right, is the conversation kind of moves between complexity and practicality as we start kind of moving any technology forward, right? So, the -- the amount of complexity that we need to ship is limited by the practicality of shipping that thing. And so, then we get overwhelmed by complexity. And, you know, like we saw this -- a good example of this was when Redux kind of took hold of the React ecosystem, it was such a good solution that it became the defacto solution and then people started to, like, find edge cases. And instead of building, you know, something that would work for their use case, they built on top of that solution. And suddenly we had these really, like, enormously complex Redux setups that was not through a fault of the Redux software. But the fault of building on top of it instead of solving at the root level. We saw this retraction. Let's go back to simplicity. How to make this as un-complicated as possible. And then the movement towards, what if we shipped fewer moving parts and fewer layers of complexity. We run into those limitations and start adding complexity again. There's a seesaw that we're on. What I like about this particular approach, it doesn't feel like we're adding complexity for the sake of development velocity. It feels like we're going in the opposite direction, where, instead of saying, let's figure out how to manage complicated caching policies, or figure out how we can keep a fingerprint of what changed and what data came in, what file was used, what if we built that thing really, really fast? That's simple. I have some template and data and smash them together and get something at the other end. That makes sense to me. I don't need a white board for that. It's infeasible, I have a million files. I can't rewrite a million files every time it changes. What if you can?
Sunil: The analogy you used, seesaw, it's interesting. The other version of the seesaw is you're reinventing the wheel. The other analogy I have started using a lot is the heroes journey in movies. Most movies in the last 40 or 50 years has the same pattern. A hero starts out from a place of whatever, goes out into the world, learns something, comes back a changed person and faces the boss or whatever. It's a hero's journey. There's an article about it. What that means for me is like esbuild would not exist if Webpack walked so that esbuild build could run, so to speak. If we didn't have what we learned with Webpack and like the language went through this explosion over the last 5 to 10 years where it finally matured. But that -- the result of that maturity has to be stability. And that's what we're actually seeing right now. No one is really throwing now syntax. Like the syntax is fairly stable. There are some modifications happening. But it's a completely different piece than what it was say 5 to 10 years ago.
Sunil: Because we have that stability, now we can say, now we can shed the layers of complexity that we have that got us here. And using those constraints. Yeah. So, esbuild really is one of the first -- and there are a couple of tools like this, by the way. The other is SWC, it's written in Rust. It's a new movement of tools that focus on speed and efficiency. That's just it. Maybe we'll do this for another 5 to 10 years and then we'll go back to, okay, fine. We need to do this hero's journey shit again.
Sunil: So, I mean, we should actually just dive into the esbuild thing itself a little. Which is why is everyone not using esbuild today? Like, okay, fine.
Sunil: It's a hundred times faster.
Jason: Which is kind of incredible.
Sunil: It doesn't make sense the first time you see this. That's why internally, okay, fine. We need to validate this on real source code. Me and a couple of folks. Shoutout to Luke and -- well, I'm kind of taking credit for the work they did, I suppose. They took esbuild on an existing codebase, about 14,000 TypeScript files, I think. And a whole shit-ton of Node modules and ran it through esbuild. And with Webpack, it's the sort of thing that takes 15 or 20 minutes on build machines. So, we ran it on my laptop. It compiles, it just chews through the entire thing in under 20 seconds. The first time you do it, you think, oh, it's broken. Something is wrong. There's a parameter. But, no, it spits out the source code and source maps and loads in the browser.
Sunil: At which point we were like, oh! I guess this works. Like, we should be rethinking so many things right now. At that -- which is where the conversation starts going. What else can we achieve if we can do this? What else happens when you can recompile your entire codebase when you refresh your page? Right? So, yeah. This -- it's cool. It's very cool.
Jason: And so, just kind of asking, like, maybe the obvious question here. It feels like we are probably making some tradeoffs in what's being done here, right? Like are we losing functionality when we use esbuild versus something like Webpack?
Sunil: That's leading into the next tab that I suppose you have, which is, hey, Evan who has been working on the bundle, I think when he started building this, Vite one was Vue-specific. Like the Vue framework specific. And then he was like, oh, there's nothing about this that really needs to be Vue-specific. Like, it can be just a general tool. And what Evan You, god bless him. The thing I tell people -- because I speak to a lot of people, you see? Is that Evan is very, very pragmatic about his design decisions and how he builds software and that is reflected so deeply in the choices that Vite makes and why it's so good. Vite is French for "Fast," by the way.
Jason: And to clarify the question, Evan is the creator of Vue, yes.
Sunil: The creator of VueJS. Which has the logo. I like this one more, it's more wavy.
Jason: It definitely is that, I dig it.
Sunil: It makes sense. Logos make softwares go faster. Vite, the logo is great. That's why the software is good. If you have a shitty logo, I'm not going to touch it. It's probably no good.
Jason: It's true. You can tell. I feel how fast esbuild is. It's got lightning, that must be fast.
Sunil: That must be fast. If it was a turtle, oh, that's terrible software. I want to talk about Vite. So, Vite does a couple of things. So, it doesn't use esbuild completely. It uses it in very clever places. I have no idea what these GIFs are.
Jason: The sound effects are -- yeah, the chat will have fun all the way through the episode.
Sunil: Right. So, I want to talk about some of the design decisions that I noticed that Evan took while building Vite. And I was noticing these when I was like out of spite looking at Vite. I was like, there's no way there is as good as everyone claims it is. I walk away two days, and, okay, fine. It's good. I get it. And there's just to fix a couple of things. So, for example, I think when tools like Snowpack and Vite started, hey, let's just do ES modules for Dev and then do a production build later. Just load it. Like, it will just load. The problem with that is that you end up with this waterfall-style of models. And it actually takes a long time to load up. So, no matter how fast your compiler is, doesn't matter. It will take 8 seconds to load up a bunch of things. So, Evan does a bunch of smart things. Runs esbuild on Node modules. All third party, scans through the codebase, whatever the third party dependency is, React, React builder, and runs ES on that. That's one thing that's loaded. And then your source code is loaded as ES modules. And if I understand right, and I need to really check the implementation, because Vite knows the dependency graph, it doesn't have to be a waterfall thing. It pushes all the modules that you are going to use. It will come fairly quickly. So, this is dope because it means that your server startup is like that. It's so fast. It's sub-second. It's under one second. You can hit it. That's like -- I love that. That's one decision. Second, and this is the React refresh thing, which is, hey, React refresh requires Babel. Esbuild is not Babel. What do we do? And he is like, well, it's only in developer mode, so, let's use Babel in developer mode and apply it to source files and it works.
Sunil: It's dope. So, React refresh, the hot, you can click a button and change text and just maintain state. All of that just works. One thing that Vite does right now which is pragmatic but could get better. So, Vite doesn't actually use esbuild for its production into it. What it does is it uses Rollup and you can optionally use esbuild as a minifier.
Sunil: That's still faster. And I think it also reuses caches. I'm not sure. It still means that, for example, it's about twice as fast as a Webpack build. Which is great. And again, this is a pragmatic choice because esbuild is not feature complete yet. It doesn't do the chunking exactly right. And CSS code splitting like I mentioned. But there's a note in the documentation about how once esbuild does become more mature, then Vite will provide a path to do that. So, this is again the pragmatism that comes into play. We need something that can work right now. And if we can figure out the shape, then we can switch it out for something better later. It's a little complicated with the way we do plugins. I don't know. This is why, for example, if you're building a newish application today, you should -- you should at least try Vite. Like give it luck a good go.
Jason: I mean, can we give it go right now? Let's see what happens.
Sunil: So, there are two ways that we can do this. I was thinking that we would do this in a little fun way. So, if you click on get started, just click the get started button.
Sunil: And I think there's -- if you scroll down -- where's the command -- there's a command for starting a new project. But I don't want you to use this.
Sunil: Don't run this. You know what? Okay. Run it just to show how fast it is to create an application.
Jason: Okay. Let's do it.
Sunil: Yeah, let's just do it. Cool. By the way, that's like 2 seconds to get to a project name, which is kind of dope.
Jason: Call it Vite-project.
Sunil: Choose React-ts. That's the stack I like.
Sunil: Run into it.
Jason: Just want to pop this open and see what it gave us. A Vite config, a TS config, a package.JSON with not that many dependencies. I always like to see that. And as a source file, we got a standard create React app set up. Then I'm going to run NPM install. Did I use Yarn lock?
Sunil: No, use NPM. It's fine.
Jason: That took 9 seconds for installing everything. Which was nice.
Sunil: Stay start, I think the command is on Dev -- oh, it's npm run Dev. Okay. You can count, okay?
Jason: Holy crap. 751 milliseconds.
Sunil: You know what you should do? Close this. Close it can be shut down the server and start it up again. Okay?
Sunil: Much faster. There's stuff that's cached and now it works. This is cool in itself. You want to do a build just to see how fast it can build. With that.
Jason: Yeah, let me do this side-by-side here so earthquake see it happen.
Jason: That feels like instant refresh. That's beautiful.
Sunil: That's so good.
Jason: Yeah. Let's try a build. Let's do that. I'll do npm run build.
Sunil: That should do it. One, two, three -- as you can see already, that it's not as fast as esbuild is. But it's still faster -- like it's pretty damn fast.
Jason: 10 seconds for a full React build. That's nothing -- nothing to shake a stick at, right?
Sunil: So, what I want to do is now say cd dot, dot. So I want show you how easy it is to move from another tool I love. How to migrate from create-react-app. How to make the effort to move from create-React-app to Vite. Let's make a create-React-app application.
Jason: Okay. Creating a new project, cra-with-Vite.
Sunil: Stop it, stop it.
Jason: I broke it. Okay.
Sunil: Start with dash, dash template TypeScript, I think.
Jason: Like that? I've never run this template before.
Sunil: Yep. That should do it.
Sunil: That should do it, yep.
Jason: Okay. So, we have a -- oh, I guess my other one broke it. So, let me delete that and we'll try it one more time. Okay. So, we got it mostly installed here.
Sunil: Oh, it's not done. It's gonna take a little time.
Jason: And so, I guess what we could also do a comparison straight of like we can start this and see how long it takes and all that. And then we can switch it over.
Sunil: Exactly. By the way, you can already tell that on your I assume fast-ish machine that it takes this long. So, on one of those Windows work space machines -- on one of those Windows work space machines, this can take 2 to 2 and a half minutes.
Jason: Yes, I should have prepped you better for how much chaos happens on this show.
Sunil: That's fine. That's fine. That's okay. That's -- I get it. It's actually like -- kind of slaps, whatever the tune was.
Jason: Okay. So, this -- a minute and 3 seconds to get set up and running with create-React-app. So, I'm going to move into it. And I think it's the same thing. Let me -- let me just -- let's just --
Sunil: I think it's start. Yeah, let's have a look at the code quickly.
Jason: And it did Yarn. So, same general setup, a few extra bonuses, the web vitals and some testing that I don't think is in the Vite project. But generally speaking, it's the same. And we get a start, build, test and eject. So, let's do npm run start. Okay. And that opened a server over here which we can pull over. And it's still going. Still thinking.
Sunil: Uh-huh. Okay.
Jason: That took a little bit more time. Around 20-ish seconds. It looked like it cleared my thing so I can't see it. But around like 18 to 20 seconds was about where we landed. Okay.
Sunil: It would be a little faster if you start it up again, but not that much faster. Feel free to do a build. A start.
Jason: Yeah. Let's run it again. We'll see how it goes. Starting the development server. It's running. Okay. So, about 9 -- about 9 seconds that time around. So, still significantly slower than 300 milliseconds that we saw from Vite. And then let's run a build. Okay.
Sunil: Where's the music?
Jason: I know, somebody get back in here. Oh, wait, we're done. Okay. So, 13 seconds. So, not like slow by any means. But, you know, let's -- let's see what happens. Oh, so, we would need to add code.
Sunil: I like that. Okay. So, that's the build. So, now the experience is how do we convert this to a Vite project, right?
Sunil: So, let's start with the first thing. Which is let's install Vite. Npm install Vite.
Jason: I have a yarn. So, yarn add Vite.
Sunil: Sure. That's it. That's it.
Jason: Just want to make sure I don't screw up my lock files. I feel like I do this once an episode and everything breaks. Oh, we didn't even need it. Now we've got --
Sunil: Now you have Vite installed. Now replace the start command with Vite.
Jason: Just Vite.
Sunil: Not start, just Vite.
Sunil: Replace Vite with Vite build.
Sunil: And we are not doing tests and stuff. Leave that as-is.
Sunil: If you look in -- there will be an index.HTML file under public, move it to the root folder.
Sunil: Let's open the index.HTML file. See the public_URL thing? Just delete all instances that have. Just remove it.
Sunil: At the bottom, I feel this be should be out of the box. Just before the body tag closes, add a script tag.
Sunil: And say the source, src is dot, slash, src/index.tsx. And give this a type module. Because this is the fancy one. Okay. Done.
Sunil: My guess is this is all it took. You could save it and run yarn Dev and it should just work. Let's hope so. Let's see it just work.
Jason: Okay. Here we go. We're running. Let's make a change. So, go into -- here's our app.tsx.
Sunil: It might not do the fast refresh. You might have to actually refresh the page.
Jason: It did the fast refresh. I mean, it reloaded the page, but, dang, right?
Sunil: You can set up the config. By the way, this is a testament to both pieces of software. That create-react-app abstracts this config from you. And Vite comes with batteries included where it takes care of the common idioms. But this is literally if you have a create-react-app instance, this is what it would take to migrate to Vite. That's amazing.
Jason: It really is.
Sunil: Hand waving things, because create-react-app provides a bunch of configuration stuff. And the testing story and linting and stuff. But you know what? It's a matter of time before the community just plugs those gaps as well.
Jason: For real. And look at in, this was the same create-react-app that was 9 or 10 seconds to build, now it's like --
Sunil: Run it again, it might run faster. If it uses caches, maybe, maybe. Let's see.
Jason: About the same. I mean, it's a small app. Also it could be that gets more impressive as time goes on. Because it was like .2 seconds faster. And a that could be variability or a little bit of caching.
Sunil: And again, you could actually mess with the configuration and use esbuild for minification and bring that. But this is the pitch where you're like, oh. This is close to being production-ready. And not -- like, it's kind of production-ready for a number of use cases. If you're building a throwaway -- if you want to learn React, maybe you should use a Vite project to do it.
Sunil: Would be kind of dope. So, that's kind of -- it's not just Vite. You should also use Snowpack. It's snowpack.dev.
Jason: I have that open over here.
Sunil: It's a different set of constraints, but also great. It has some other angles on how it does configuration and stuff. But it's so exciting -- just so we're clear because some people might have come here via the Tweets. Folks shouldn't be, like, Vite has solved all the problems. Right? The takeaway here is that suddenly the ecosystem has opened up again. This whole section. For innovation on a new vector. If you're interested in contributing either to a project like Vite or Snowpack or esbuild. Or creating your own customized tool chain where you're like, I can make things better. This would be a worthwhile endeavor. I'm going to be doing something like a -- can I show you my project I have been working on?
Sunil: While it might mean -- using plain esbuild, that might make your bundles let's say 10% bigger. This is an opportunity to reduce the size of your bundle by 50%, maybe more using server components.
Sunil: It's so exciting. There are people who say, oh, this is kind of what we have been doing with PHP for the last 30 years. But that's a good thing.
Sunil: You should be happy that you can do this without having to rewrite your site. Your existing React application, you can add the server.js files. It's not like the React team wants to ship breaking changes to enable a new module. No, this will start working with your existing application and have a code mod, whatever.
Sunil: So, my pitch -- not really a pitch -- my thing is, it would be a damn shame if when they released server components that it was Webpack-only. Right? If what we are seeing here is, hey, it looks like the industry now wants to move to an esbuild ecosystem. I'm not saying that they will ditch Webpack. Webpack does a shit-ton of stuff that's actually pretty cool. But that being said, it's -- I have so much faith in the JS ecosystem for filling in gaps. I can literally be just, yeah, give it 3 months in production and some genius will show up and magically show up and say, here is the open source project that I am doing that does everything you are asking for. Esbuild and everything. It's just a question of waiting. I'm just so impatient. So impatient. I want it! I want it all! Is what it is.
Jason: Well, I think it actually -- like, we touched on this a little bit and I think it's worth calling out. Is the amount of groundwork that was laid by Webpack and Babel so that, you know, you said -- you put this really well, you said Webpack walked so that esbuild can run. But extending that a little bit further to the role that Babel has played. I feel like Babel has been probably one of the most transformative technologies on the web in the last decade because it introduced this model of you can use the future today. And that, I think, it changed the whole mindset around development. But a really good kind of question around that is esbuild doesn't support Babel. And, you know, I don't know if that's an intended like eventually it will, or if that's a definite decision, that's not something we're gonna do. What do you think the tradeoffs here -- and like are they good tradeoffs? Because you did mention that one of the things that esbuild is built for is not the futurists and the thought leaders. But it's built for what you called dark matter programmers. People in the trenches having to ship things on deadlines. Not the people trying to imagine what could be if there were no rules. So, what tradeoffs do you expect that we're going to see and how do you think that we will reconcile that gap between like I can't maybe ship Babel with esbuild, but Babel did open this door for innovation. What -- I guess do you have any thoughts around that?
Sunil: I kind of do -- this is all speculation.
Jason: Sure, sure.
Sunil: So, there is that. So, if you remember the history of Babel, Babel didn't just win because like I said, you could use new syntax. Because there were actually a couple other projects out there at the time that could also do that. I think -- I'm trying to think of names. I think it was Recast or possibly a couple of other Facebook projects itself. And things that were like very academically interesting. So, folks who worked on standards and stuff were already using. The thing that Babel actually nailed was actually the user -- the developer experience. When I say "Developer experience" you remember it became popular around the time JSX came out. And folks wanted to use JSX. And just use the Babely file. Just add this one thing and it will work. So, it actually nailed the experience. And I think the leaders of the project were like Sebastian McKenzie and James Kyle, but Henry has been the most amazing maintainer. The gold standard of open source. The whole team. Not just these people.
Jason: Let's shout out -- Henry is amazing. He's been on the show. We've worked on some stuff. He is a truly wonderful person. Where is his --
Sunil: I think it's left-pad. Which is, by the way, hilarious.
Jason: Yes, there he is. Like, Henry is wonderful. He's like one of the unsung heroes of the ecosystem. He really did like this heroic effort to keep Babel going. And I know he's working with a team. But that's pretty thankless work.
Jason: And good on him for sticking with it and being such a good -- he called himself a steward. And I think that's a really good name. He's been a good steward for the open source community. So, shoutout to him for all the work that he's done.
Sunil: I was trying to think of this in terms of constraints. As engineers, we are very attracted to attractive problems. And programming language theory is one of the big ones. Where, oh, if I could do write this magical piece of code, it does this magic. Oh, and I can introduce it into a codebase at work. Which is very good, it's the sort of thing that gets you bonuses and promotions and stuff. Which is why esbuild, and esbuild is really just a symbol for what I'm thinking about here. Which is introduction of constraints. Where when these things are not -- when these attractive problems are not an option anymore. Suddenly you have this mind space to actually start focusing on the product. And this actually harkens back -- harkens back to development model the in like 2006 and 2007.
Jason: Oh, my god.
Sunil: Right? So, like this is right when Firebug 0.1 was launching. You had to use Window.alert for debugging. I'm giving -- to a bunch of old hands watching this, by the way. It was kind of amazing. And like transferring PNGs. But what -- and even the like Chrome wouldn't come out for another three or four years. Which meant that browsers were slow. And inside these constraints, you had to ship features and products. And it was great, Jason. It was so much fun. Because you would spend your mind space on solving problems that were real problems. Those are product problems. Not how do I make my bundle 6% smaller? Like, fine. Sure. Like. Instead of trying to figure out a way to do that at the language level, you would be like, hey. Instead, let me write good code and lazily load this widget, this button. Let me go argue with the designer and say we don't need rounded corners for our dives. Which by the way was an argument all the time.
Jason: Oh, I remember that argument.
Sunil: All the designers were like, what are you talking about? Why can't we have rounded corners? And like, I can't get into this conversation again.
Jason: You bring up something -- you articulated something really well that -- if I take a consulting client or something. It come us in discussion a lot. I've seen a pattern with teams, especially big teams, where as the code gets more complex, the product requirements get more demanding, there is a growing unrest in the engineering team that eventually somebody's gonna say, this would be easier if we tore it all down and rebuilt it with X. And then during the rebuild, it feels that way. Because you're re-solving a lot of solves problems. But then when you get to that 80% or 90% mark again, the new stack hits the same constraints that you were hitting in the previous stack. And now you have to solve those problems. And those problems didn't change, they were always there. You were just distracted by the fact that you were rebuilding your app. And then when you hit it, people start saying these problems would go away if we rebuild in this stack. I have seen teams that every few years do this major refactor in hopes that the last 10, 20% of problems will magically disappear with another codebase. And I think what you're saying is really an interesting point. If we scope down and say the constraint is what you can deliver, not how you can build what you deliver. Then we're forced to focus on the actual problem and not rearranging the ways that we're presenting the problems. And I think that's the way -- color by numbers or even just giving an artist a prompt instead of a blank sheet of paper, suddenly you have somewhere to go instead of spiraling around on how or what or why. Okay, I have a problem. I'm going to solve this problem.
Sunil: Jason, it's been an hour and a half and you just hit the nail on it. This was never about speed. This was never everyone about the set of features that esbuilders put. This is a call to arms for frontend developers who are writing the software that humans interface with to really start focusing on the things that matter to you. This isn't even about business value or making your company rich. Which you are welcome to do. Amazing time to do it. But it's about building software that matters and prioritizing. And working on the things that -- so that you can ship, dude. Instead of having to do a rewrite in 6 months and freshening up your resume and going and joining another company.
Sunil: So, like, this is a call to arms to actually give a shit about the products that you're building. And speed of build time is literally one of those vectors. But there's so many things that you can say that this -- this esbuild or SWC or whatever tool -- it's a call for developers to start building good stuff again. That's what I'm super-excited about. That's what it feels like.
Jason: Yeah, yeah.
Sunil: It's been so long. Like, React was getting kind of like, old. And I was thinking, oh, there are not a lot of cool stuff. But suddenly this came up, man, 2021 is going to be cool again. Good stuff.
Jason: How do we use this tooling to create those power ups and the force multipliers for the teams and the rest of the people around the company? Or in the ecosystem if you're in open source?
Sunil: There's so much to do. There's so much work to do. We'll get there. We'll get there. I wanted to do a quick shoutout to a very interesting project that -- so, I follow this dude named Brandon Bloom on Twitter. Do GitHub.com -- that's the one Slash uni. He's started exploring esbuild for building big-ass repositories. Like Facebook-style repositories. I wanted to call this out because I think that this model, if not this exact tool, but possibly this exact tool, is actually going to get -- become like a little more popular -- not this year. Maybe this year? I don't know. I tried it out locally and it was very nice. But this is the Facebook/google monorepo, everything is in one repository, one package.JSON, a bunch around things. And tough tooling as fast as esbuild, then you could potentially move as fast as a company as Facebook or Google does without breaking the democracy. That would be pretty great.
Jason: That would be need. I could get behind that.
Sunil: It's nice. 2021 is looking pretty great. It's a lot of things to do. I think folks watching this should look at this as an opportunity to -- I want to say prioritize. But maybe prioritize -- is to be intentional about the things that you choose to contribute and provide to. It would be easy to do something easy for social media cloud and like a great Tweet. And maybe you should still do that. Because that's what keeps Twitter fun. But also, there are big, nice problems to be solved for the dark matter programmers. Those are the people that matter. They will always matter. They will matter today, they will matter 10 years from now. There will be way more of them than your thought leaders on Twitter. And it sure would be nice if we did stuff to make their life better.
Jason: Like you said, making their life better makes my life better. If any bank website is easier to use and faster. Those are the things we want. If we can build the tools and make that possible, we inadvertently are helping create that world. Yeah. I'm very on board with that. There's a great question in the chat from sana_lama_ding_dong. They have an ecommerce site built build on Next. Can they benefit from esbuild or should that happen upstream?
Sunil: There are two answers to this. First off, start with the jump stream. And the maintainers, when I say for a fact, I mean surely, the maintainers of Gatsby and JS are looking at esbuild. Hey! What are the assumptions that we take. It becomes harder with Gatsby and Next.js, if you were depending on a fancy Babel plugin. That might make it harder. But if you're smart enough, maybe go through the codebase and remove those cases. I don't know. So, there's that. That there's -- it's obviously that meta frameworks like Next.js, Gatsby --
Jason: Nuxt, all of them, yeah.
Sunil: Nuxt. All of them. Looking at tools and see picturing if they can incorporate it. If your codebase is relatively simple configuration-wise, then you can absolutely take a crack introducing esbuild into it. The one I have seen, I think it's called esbuild loader. So, that works with Webpack configurations. So, if you literally look for esbuild-loader. I haven't tried it out myself. It's literally loaded for Webpack. I don't know whether you would get your 100x style wins from it. But I bet it would make it faster anyway. The numbers that I have heard -- again, don't hold me to it -- I have heard numbers from 30% faster to 60% faster. Which would be great. It might be better for you. Or it might not be as good for you. I don't know. There's no clear answer for this specifically because we're in the phase where we're discovering the answers to this.
Sunil: You could figure it out. Maybe like esbuilder just works. Try it out.
Sunil: Someone has used esbuild to create a React app. So, rough answer, we are using the esbuilder for React app. Someone is trying it out and it's working for them.
Jason: Pretty wild.
Sunil: You could make your build faster by 2x today. By the way, I need to wave to make the lights come back on. Maybe not. I don't know. Yeah, I think this is the phase where we're actually finding out the answers to this. But if you Google it, there usually is some industrious soul who has tried it out and put it up on npm.
Jason: Yeah. It is really exciting. We'll see -- I can't imagine a world where something that is a hundred times faster doesn't make its way into the frameworks. I think and the frameworks that are unable to make that switch will be replaced by frameworks that do. And like you said, this is good competition. Because we don't want to settle into, well, this is as good as it can be because we don't want a change. And the fact that something like esbuild is coming along and saying, like hey, this could be literally a hundred times faster than what you were doing right now. And what does that mean? Because, like, the other thing that I think is really interesting about this is this doesn't just affect build times. Like, if you're able to build in, you know, you can bundle an entire like ten copies of three JS in .37 seconds, how fast can it do one template, right? If it's able to do that in a couple milliseconds, what if we just ran that straight off of a serverless function or something? What if we ran that -- you know what I mean? Like on-demand instant bundling.
Sunil: You are reading my mind, right?
Jason: What's the future of programming if that's the case?
Jason: There's so many areas to explore. This is opening a door that was previously not really -- it was feasible, but with a lot of work. And now this is almost like, okay, well, the hard work just got done. So, what can we do with?
Sunil: 100%. It's wide. You could run it on the server. Just do on-demand bundling. Take us back to the days where we did a check of the source code on the server and start searching it.
Jason: How wild would that be?
Sunil: There's a Bazel build of esbuild, and you can run it in the browser. Why that's exciting, you can do Dev tooling that runs in the browser. Like writing code. What if code sandbox was built with esbuild? Which, I don't know, it's already pretty fast. But I don't know how much faster it could be. Maybe their startup time could be faster.
Sunil: There's a whole re-thinking of everything that we thought was either solved or that we worked it on. And you're like, oh, I could just simplify now. I wanted to answer a question, I have no who this Elli belly person is. I'm a pie in the sky. I want to show you the great-ass view of the top floor of my apartment building. There's a bunch of reflection. I don't know if you can see it clearly. But that's kind of like London -- you can't really see it anything.
Jason: It's a great view. We should have done it before the sun Wednesday down.
Sunil: There's London behind me. It's pretty dope.
Jason: That is a really nice setup. But, yeah, I also like -- I like the idea of that as an evil layer. I'm kind of imagining that window is actually your eyeball and it's a big building shaped like your face.
Sunil: It -- I like this place. I love London so much, by the way. I can't wait to go back out there. Done with the stupid pandemic. I hate it! I hate it!
Jason: I am extremely same. I am counting down the days until we can all -- there's news in the US that we might actually have enough vaccine by May that maybe we'll get to go outside in the fall. And it's like, can't wait! I'm gonna --
Sunil: So, what I'm going to do is I'm going to take my life savings and I'm going to take empty tequila bottles, spends all the money on vaccines and literally go on to the streets with bottle shots and lemons. Wait, it's salt, vaccine, lemon. Yes. That's the thing. I'll just give it to everybody. I don't care. I want everybody to be healthy and safe. Let's just do this. I'm so --
Jason: If only it worked that way. I feel like if we could do it like spring break, we would probably all get vaccinated a lot faster.
Sunil: Exactly. That would be pretty dope. That would be dope.
Sunil: So, I think the clear one, of course, is the two tools that are emerged as kinds of the figureheads? Whatever the phrase is for this Vite and Snowpack. You should experiment with that today. You should literally try it out on your laptop today. Okay. This is kind of cool. Maybe I can start a new application with it. I would be very immediately -- wary of redoing your product roadmap based on these tools. Like I said, there are still rough edges. If you go to your manager and say we should stop everything we're doing and rebuild it with Vite. It may not be as smooth as you want. But you should be following Evan Wallace, the Vite JS folks. A wonderful group of people. I especially like Patrick. Because his -- his -- he has an incredibly cute cat which I assume is his cat. And he wanted me to read out a Tweet where he's talking about how Vite JS is like the Babel fish with -- trying to get that -- it's a good Tweet. Maybe -- I'll just Retweet it right now so that folks can see it on my feed, I guess. But they have a Discord, which is very cool. The Vite JS folks have a Discord. You should follow Fred Short, who is lead maintainer on the Snowpack project. Esbuild is one of the only I'm subscribed to all changes because I want to -- I think he is fks.
Jason: His supply name.
Sunil: Follow him. Such smart people working on this problem right now.
Jason: I'm learning about people to follow today too.
Sunil: Great projects. You should, I don't know. You should -- what else is there?
Jason: Well, in the chat, Jani says we should all follow Sunil. Which I agree with. Let's go and do that.
Sunil: Hype man here.
Jason: Wait, Jani's birthday today.
Sunil: Jump a good friend. Can I tell you? Like he -- I just hit 270 days without smoking and him and Ellie are the why. Great friends and great people. You should be falling Jani. Great dude.
Jason: Hey! Look at the balloons.
Sunil: Jani has a great open source, you should be following that project called Foam.
Jason: Here it is.
Jason: Nice, nice.
Jason: I love -- like that's one of my favorite states of existence. Is cautious optimism. I feel like that's where I want to be all the time. I don't want to just run off eyes closed into the arms of the unknown. But I love being excited. I love being excited about what's coming next. And I think that that is the -- it's my favorite state of existence.
Sunil: And after the year we have all had. We deserve it. You know what? We deserve this.
Sunil: Thanks. Thanks to everyone doing this. And like I said, it's free! I can't believe it's free!
Jason: You know, go out there. Have that extra chocolate. Have that esbuild, you deserve it.
Sunil: You deserve it.
Jason: With that being said, I think this might with a good point to call it. I want to do another shoutout. We have had Amanda with us all day doing live captioning. Thank you so much, Amanda, for sticking with us and dealing with all of our nonsense. Amanda is from White Coat Captioning, they do a whole bunch of live event captioning. If you need had captioning, have a human do it, it's much better. That's made possible by Netlify, Fauna, Auth0 and Hasura. All of whom are kicking in to make this more accessible to more penal. Speaking of which, did you hear Auth0 got purchased by Okta?
Sunil: For a zillion dollars.
Jason: Yeah, like 6.5 billion.
Sunil: Renegotiate the sponsorship deal.
Jason: My new rate is $6.5 billion. I know you have the money. I saw. And while you're over at the site, make sure you check out the schedule. We have some really fun stuff coming up. We're going to do video with React, super-fun. Jonathan Burger is teaching us. Gant Laborde, rebuilding TikTok's timewarp filter with a webcam. David Khourshid is going to help us build with state machines. We did a solo episode on state machines. David is going to talk about the tooling and the concepts since the last time he was on the show. Over a year ago. We have Prince coming back, real-time notifications with the Twitch API. State machines on Kubernetes, I don't know what that means. Excited to see what Abhi is working on. And Cassidy will come on, trolling Sarah Drasner. I'm excited. And Jennifer is coming to talk about angular. That's all coming down the pipeline. Check out the schedule, add the calendar on Google and it will show you when we're live and who is coming on. With that being said, yeah, Sunil, anywhere other than Twitter where people should follow you?
Sunil: Nah. No. Let's get those Twitter follower numbers up.
Jason: That's right, everybody. Go smash that like button and ring the bell. All right, y'all. Thank you so, so much for hanging out.
Sunil: I would to thank you too, man. This was so man. I missed this. It was nice to talk to you. Thank you for having me. I hope it helped. Thank you so much. It was a great time.
Jason: I love the shows where we can spin out to galaxy brain. This was a great show for me. Always a blast. I absolutely will be talking to you about what we can do this on in the future. It was so much fun. Chat, as always, thank you so much for hanging out with us today. This was an absolute blast. We're going to find somebody to raid. Stay tuned. Sunil, thank you from the bottom of my heart for hanging out with us today. We will see you next time.