Let's Learn esbuild!

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: Okay. So, you can just open the site and you'll see esbuild.github.io. It's basically a compiler for JavaScript and web projects. This is very much in the vein of tools that you already use like Webpack or, you know, if there's a browser stack out there, very common tool. So, esbuild comes and says, hey, the one problem that I think can be solved, this is effectively the author, Evan, hey, I think these are built inefficiently and I can increase how fast these things are built by orders of magnitude. And that's the first thing that strikes you about the page. But we talk about projects that could take 30 seconds to build that are otherwise being built with esbuild in under a third of a second. That doesn't make sense when you hear it. That sounds like -- that sounds like a fake -- you know what I mean? There's no way that can be true. But the reason it's true, it's for two reasons. One, it's built in a language that isn't JavaScript. It's built in Golang. But the other is that Evan is a very good programmer. And instead of trying to do everything, there are particular constraints that you can put on the application. Like the kind of code that can be written. Which, by the way isn't that part of a constraint for like regular programming? Like, hey, I'm going to script type, I'm not interested in the static type checking. You use ES6 import/export syntax for writing today. Not to say that it doesn't work with JS code, particularly with dependency. But it's very good programming in a very good language with well-chosen constraints. Which are great things to hear about when you're building software. That's what leads you to produce high-quality software. And that's where the speed comes in. So, that's about the software itself. And we can talk about that. But the thing I want to talk about -- that I wanted to -- so, Rob from Bloomberg, he taught me a phrase that I really like. He's like, hey. Most programmers are what are called stark programmers -- most of the universe is filled with dark matter, not regular matter. And these are folks not on Twitter. They are not building libraries. They are building applications and shipping it to production. They are not interested so much in what the cutting edge is. They want to find stuff that works, that works well. And they can like just get -- and these are the folks that you should actually be catering to. Not to the thought leaders on Twitter and stuff. And I think about a class of programmers at JPMorgan. So, this is a thing in JPMorgan. But a number of industry regulated places. The Citrix work spaces, virtual Windows machines where you need to log in and literally portal into a virtual Windows machine in the cloud somewhere. And these aren't very powerful machines. So, sure, I'm on an M1 Apple super-fast laptop right now. I'm just like, yeah. Everything just looks fine on mine. But tools that aren't built to be fast really struggle on machines like this, and there are thousands and thousands of those programmers at JPMorgan, and potentially millions of them across the world. And these folks are not represented in the conversations we're having with this syntax needs this tool. And esbuild and the ecosystem building around it is very much catering to that. And I think that's a very noble and a right pursuit to have. Because if you make software faster for them, if you make the tools faster, a couple of things happen, right? One is that the engines of the world effectively move a little better because these folks are building financial systems and hospitals, just regular stuff. But also, it means better software for the rest of us as well. In general. These things will work better for me too. Instead of software that has been built and catered to run great on an M1. So, I think -- I think that's why it's so exciting to me. And while we are talking right now, I wouldn't even mind sharing some numbers of before and after before and after esbuild. That's why esbuild is good. It says, hey, stop faffing about programming language theory and things that don't particularly matter to shipping "Business value." I hate the phrase, but I understand why they say it. I understand it. Ship stuff that actually matters. It says, with these constraints, what are the huge things that you can build? What are the economies of scale that you can achieve in your system? If you were able to ship twice a day because of how slow your build was, what happens when that becomes a hundred times faster.

Jason: Right.

Sunil: Can you imagine shipping to production 200 times a day? And these are questions that we can now answer.

Jason: Right.

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.

Jason: Right.

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.

Jason: Yeah, I think you're right. I think what we see is that the feeling is, you know, it's this constant process of understanding, like, we want to break through limitations. But when we break through limitations, we get this spread. And so, there's a kind of -- we all move in different directions. We all solve different problems at different levels and then start to see the connection. So, we start bringing those connections together and we kind of, you know, whittle that down to like the next, you know, the next kind of evolution. So, it is a cycle in that sense. And I think that that's healthy. That shows that the language is improving, right? If we didn't have these sections of people who were saying, no, it can be better. I'm gonna try something new. Then we would be stagnating. We would be sitting on a language that hadn't evolved. Nobody wants to be there, right? Like there's -- technology is always moving and the world in general is a process and we have to solve different problems on technological levels, on human levels, on organizational levels and, you know, all of that is moving, whether we want it to or not. So, I do love this kind of -- I love that the JavaScript community is engaged. I love that we're starting to see tooling coming in from like Rust and from Go to actually make this stuff as fast as it can be. You know? Kind of recognizing that JavaScript is a very, very powerful tool for building web apps. But there's some inherent limitations when you try to throw it on a build process. It can not go as fast as Rust. Period.

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.

Jason: Before we do that, let me switch over to -- to the view. Because there's a graph I want to show that I think is gonna really sit nicely with why that question is a good question. So, I'm gonna switch over here. And the first thing I want to do is I want to do a quick shoutout to Amanda from White Coat Captioning who is live captioning with us today. She is out here giving us all of the tech space representation of our ramblings as we go. Thank you so much, Amanda, for being here and putting up with me. That is made possible through White Coat Captioning and the support of sponsors, Netlify, Fauna, Hasura and Auth0 kicking in to make this show more accessible to more people. You can load the captions up at Learn with Jason.dev. And she can out Sunil, @threepointone on Twitter. And a very good account to follow. Lots of good insights and always, you know, if -- you can get a good finger on the pulse of the JavaScript community by keeping an eye on Sunil. So, definitely do that. With that being said, I want to look at this graph. So, this -- I'm gonna reload this page because it's such a good -- look at this. This is the esbuild home page. It's such a brilliant visualization. I'm going to read this out loud, it's small. What this graph is showing is the time to do a production build of 10 copies of the three JS library from scratch using default settings, including minification and source maps. So, esbuild is doing this in .37 seconds. And the next is fastest, Rollup, 36 seconds. It's a factor of a thousand? A hundred? I can't do math. It's a hundred times faster.

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.

Jason: Wow.

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: Absolutely, great question. And the answer is, kind of. And the question is whether those tradeoffs are good enough for you. So, for example, well, right now, for example, it's not feature-complete. And this is kind of why everyone -- why no one is using esbuild in production right now. For me, the big feature that's personally missing for me is CSS code splitting. It kind of does code splitting with JavaScript, but not so much with CSS exactly right. And I don't want to go into like the technical reasons for it. But there's actually a couple of issues open on the issue tracker if you want to go check it out. Then the way that esbuild's minification works is naive. And I use the word "Naive," but naive implies that it's worse than it is. It shortens variable names. It removes whitespace and it does -- it does like old-school style minification before as it did with terser and stuff. Which means your minified builds would be bigger than if you ran it through a terser. The answer is take the esbuild bundle and run it through Terser. You should probably do that if bundle size is a big priority for you. And even then, it will still be a lot faster. But in a place like mine which is heavily client-side rendered and long-running applications on browsers. Folks literally put it up on four monitors and stare at charts. That's how money is handled, I'm told. I still don't understand. But for that, you're like, fine. I'm happy with 10% bigger bundles. That's okay. That's absolutely fine for me. So, that's -- so, that's a couple of it. Then there's the whole like ecosystem thing. So, esbuild is literally just a bundler. It does not do everything that a Webpack does. So, first thing that you notice, for example, is there is no React refresh experience. And React is build on Babel, by the way. There's no hooks for hot module reloading. And it's effectively a one-man job at the moment. Like Evan is very focused on -- like he has a vision and he's taking it forward. Which means, for example, it's not a community that's contributing towards this. Some people might consider that like a, oh, that's kinds of weird. But it means that right now I think it's in a phase where it has to be like a singular vision and that is being executed. I don't really see that as a problem. But it does mean that either -- the reason that people aren't using it right now is because the whole story is not there. There's not the whole story. How do you use esbuild with jest? There's a package called esbuild and jest that is trying to solve this, I contributed to it. It's still bumping into a couple of bumps. But that should also stabilize in a while. So, if we were to re-create the last 5 years, 6 years of Webpack work, but with esbuild before it's like production-ready, right? So, that -- and I think that's where tools like Vite and Snowpack come in.

Jason: Yeah.

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.

Jason: Yeah.

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.

Jason: Interesting.

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.

Jason: Okay.

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.

Jason: Okay.

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.

Jason: Cool.

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?

Jason: Whoa...

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.

Sunil: Bam!

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.

Jason: Go?

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?

Jason: Yes.

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.

Jason: Okay.

Sunil: Replace Vite with Vite build.

Jason: Okay.

Sunil: And we are not doing tests and stuff. Leave that as-is.

Jason: Okay.

Sunil: If you look in -- there will be an index.HTML file under public, move it to the root folder.

Jason: Okay.

Sunil: Let's open the index.HTML file. See the public_URL thing? Just delete all instances that have. Just remove it.

Jason: Buh-bye.

Sunil: At the bottom, I feel this be should be out of the box. Just before the body tag closes, add a script tag.

Jason: Okay.

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.

Jason: 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.

Jason: Yeah.

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?

Jason: Absolutely.

Sunil: GitHub.com/JPMorganChase/modular.

Jason: Modular.

Sunil: L-a-r, yes. This is what I have been working on for stuff internally where we want to use build spaces and very much like a monorepo style too. This is built on create-react-app and Rollup. And there are a bunch of niceties. And I like on my laptop right now I have a version of the entire innards replaced with like Vite and other niceties. I will probably move straight to esbuild. And there's -- for me, I happen to see opportunity where there are a couple of other interesting things that are happening this year. I don't know how many folks on the chat are watching this or are familiar, but React is coming out with a very cool feature called server components. Server components are exciting because I think it's kind of the first -- well, they already had rendered the string. But the idea is you can run some of your components of the application on the server itself. Yeah, they have a blog post and everything. You should see this. It's great. Lauren and Dan take you through a whole demo of how it works. But the idea is there are components where you never have to ship the JavaScript to the frontend at all. They just run on the server. Great for MDX or blog posts. Because you must be familiar with this. Which is when you build a site with React, even if you're serverside rendering it, you have to send all the components to the frontend once you hydrate. But server components takes that and says, no. There can be a whole bunch of components that you never send to the frontend. It's great. Not just the components, but the dependencies that the components depend on.

Jason: Right.

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.

Jason: I think about that a lot. One of the reasons I love working with React is the ease of building sites. But something that always pushes me back toward, maybe I should just build this site with Eleventy or something, I'm building largely static content. The vast majority of what I'm sending down, even in a really interactive web app, is not dynamic content. It's a header, it's a sidebar, it's navigation. These things don't change. So, the fact that I have to send all of the JavaScript down and re-hydrate this into a React app when all I really needed React for dynamically was, you know, I need to do some async calls and show some data for the dashboard or whatever. It would be wonderful if that 10% was the only 10% that became a React app. But I got to use React to build the whole thing so it feels like one cohesive experience. When I saw this, that was the lightbulb. What does it mean for static site generators? There's Toast, I know Chris is in the chat right now. Could it just use server components for most of what happens? And I get this beautiful React written, but statically-rendered no JavaScript website out the end of it for my marketing site. Can Gatsby or NEXT introduce the patterns so when I'm building so that the JavaScript bundle is only JavaScript when I need JavaScript and not JavaScript because I wrote the thing in React.

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.

Jason: Yes.

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.

Jason: And I think another thing, like and this is my only nitpick with server components is I wish they hadn't called them server components. Because it implies the requirement for a server. But that's not actually the case. It can be like your build process can be that server. So, you can, you know, you don't necessarily need like a server running to -- to have server components in production. Which I think that might be part of what the kickback is. Well, I don't want to have to, you know, my JavaScript shouldn't need a backend. And that's -- that's potentially fair. Like, I'm a big believer in let's ship our websites without backends. And I think that distinction is an important one. I'm actually really excited. I'm try trying to figure out how to get somebody from the React team to talk about server components. Stay tuned for that. But this is about how it can work in different patterns. Serverside rendering on a server, to the build process and the serverless and all the ways that you can approach this pattern.

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.

Sunil: Yep.

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: And not just Babel. I think his temperament and the way he interacts with people. Such an amazing human being. But back to the topic. Maybe it's a good thing that Babel won't be the critical part of 5 million JavaScript developers. And 5 million is a number I pulled out of my ass. I think that's close to the actual number. It might be 6 or 7 million JavaScript developers. I don't know how many there are out there. For a team that doesn't actually make that much money and everybody does it on the weekends and this thing and still maintains such a high quality, maybe it's good if the focus of Babel isn't everybody's application. Now, this -- the tradeoff, of course, is we are saying Evan Wallace is in the critical part of this. And as JS features become mature, I assume they will have to land in esbuild as well. But I assume by that point as well the community will pitch in and there will be more of a support system. But I think it's kind of good that Babel isn't the only player in town.

Jason: Right.

Sunil: It's healthy for the ecosystem that we have a Babel, we have an esbuild, we have an SWC. This is all good news. Especially when it's standards-driven. Right? It's not like one team is saying our version of JavaScript is better than your version of JavaScript. It's still driven by standards. Maybe there's a future where Babel will go. I don't know. I'm just making shit up. But, yeah, I think it's actually good for -- you want -- it was kind of weird that this thing which was a tool for both academics and pushing the language forward was also in like production tool chains for everybody. Served a great purpose. It literally pulled the entire ecosystem along with it so quickly and so well. But, I think it's -- I think it's healthy that there are other players in the ecosystem. Like it just -- it just makes sense to me.

Jason: Yeah.

Sunil: Yep.

Jason: I'm with you on that. And I think, you know, the other thing that you bring up that I think is really interesting is this idea of, like, innovation versus production work. And not necessarily as opposed ideologies. But just as different spaces. Because one thing that I have noticed is that Babel created a kind of footgun for large organizations where if somebody comes in and they're really excited about something and they'll introduce like a stage zero language feature into their codebase. And then they leave the company. And now there's a whole bunch of stuff in the core codebase that's built against this proposal that actually got abandoned and is no long part of the language. So, when I go to work for this company, now I am -- I am now like stuck learning a non-feature of the JavaScript language that is part of how we, like, maintain and run our codebase. So, one of the things that I do kind of like about Babel as an approach -- or about esbuild kind of removing Babel from the critical path is it does -- it does create a little more consistency with the way that production apps get built. In that it's harder for us to go out there and say, hey! I have this idea that's not really standard, but I like it. And so, I'm gonna introduce, I don't know, Decorators into my codebase. And now you all get to live with that forever because that was my preference even though JavaScript doesn't like support it or intend to implement it natively or whatever. And so, I do -- I like the idea of Babel for experimenting, for trying things. And, you know, maybe upstream as a way of making libraries, you know, you have a Babel in that build change. But for production apps, for things people are going to use day-to-day I like the idea of not moving into an unknown quantity when I open a new JavaScript codebase, you know what I mean?

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.

Jason: Yes.

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: Yeah. What I like about it too is that it feels like, you know, when -- maybe 5 years ago or so when things like Webpack were just kind of starting to -- it was probably longer than that now. When Webpack was really on the rise, Babel was really on the rise. And there was kind of a sense in the community that there were too many tools and there was JavaScript sprawl and we were all kind of tired and, you know, JavaScript fatigue was a thing. What I've noticed is that we're seeing a little bit less of that. We're seeing fewer, like, brand new paradigms. We're starting to see things that are a slight iteration on the way of doing things. And I think that's been really interesting to see because we're watching the community really zero in on these patterns. Like, I think hooks in React and the composition API in Vue. And they're very similar in conceptual application. Just fit into the framework that they're part of. And so, we're starting to see teams kind of get like the community is starting to centralize around some practices that make us good at things. And when we get around practices that make us good at things, we don't need as multi-purpose of like foundational tooling. So, now we don't need like the magic of Babel to make any framework work with the browser because we're all starting to circle around the same core components. Components have won. We're moving towards components. How to make the tooling focus on components and modules and not worry about hitting all of these other edge cases. And that feels like we've hit a level of stability. And I think you touched on this earlier. We hit a level of stability in the ecosystem that we can focus on. What's the tool that tells us how to do the one thing that we have landed on as a community quickly? And that feels like that lays the foundation for kind of what will eventually be the next iteration where we go, okay. We solved this workflow. What's the next workflow that we have to solve?

Sunil: So, this is a little meta. But this is something that kind of bothers me about JavaScript Twitter. You know that. JavaScript is on Twitter. That's kind of the social network that everyone is on. But there's a bit of confirmation bias about what is important and the things to focus on. Because Twitter as a format, or social media as a format, rewards library developers and cool demos that fit in the 3 or 5 seconds demo. It does not reward your 6 months of work where you shipped your startup to the credit of like the company and everybody loves you. There's very little -- it's very hard to share that story in a Tweet. Which is why, for example, that folks, they look for open source with like libraries and like little experiments and they think that's the way to become a great software developer. That's one part of it. But developing a cadence of shipping, of understanding your users' requirements, your stakeholders' needs is the real software development story. And it's so cool that now we -- oh, man, we have these tools for free, man. I mean free as in -- it's a version that people get mad if a project doesn't have documentation. We're such an entitled bunch that we have all of this stuff magically available to us. God damn it, we should do something with it instead of wasting it for social media cloud. That's what I'm saying, I guess.

Jason: You're not wrong. I love that we're starting to see more discussions around -- like the code is important. We have to ship things that work. But what matters is what the code does. Is I really -- like I love that sentiment, I love what you're talking about. Yes. Sunil absolutely does have a Twitter. Let me drop that in the chat again. See, this is what I'm talking about. Follow Sunil. He just does this all day. And it's very -- [laughing] -- but, you know, I love this kind of discussion about, like, if we're talking about how to really drive value in your career. And like, how do you level up from just being a good developer to being somebody whose actually making an impact at work or making an impact in the community? Like libraries are one way to do that. And they're, you know, as you said, we're in a pretty exciting space right now where like esbuild and Vite and this kind of new thing that's emerging is opening up the space for new patterns. And there is room for like new ideas to come in show us how to use the patterns in a really effective and productive way. But the other side of that coin is, like, how am I as a developer working at a product company going to use these patterns to not rearrange the deck chairs on our app or burn the whole thing down and start it over so that as you said, I can leave my job in 6 months and find another place to burn down. How do I ship real, tangible value. How do I make the product better? Make the people on my team more productive? The advancement of a JavaScript career, a coding career in general, you hit senior and then everything after that point is not on how good you are. It's on how good you make the people around you, right?

Sunil: 100%.

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.

Jason: Right.

Sunil: You could figure it out. Maybe like esbuilder just works. Try it out.

Jason: Yeah.

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?

Sunil: Right.

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.

Jason: Yeah.

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.

Jason: Yeah, I'm definitely looking forward to that. And I'm, you know, similarly, I'm looking forward to -- this feels like it has the potential -- to put a bow on this before we wrap up -- this feels like it has the potential to be a little bit of a water shed moment. The way there was a before Babel and an after Babel. There feels like there might be a before esbuild, SWC, whichever one becomes the defacto standard. It feels like there might be a before and after in terms of JavaScript epochs. So, yeah, I'm so excited to see how this goes. And I guess maybe something that's worth asking is like, where are you going to keep up with this? What do you recommend for somebody who wants to follow this and see where the opportunities are and maybe start trying out? What do you think they should go and look at?

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.

Sunil: That's the one. I don't know. JavaScript happens on Twitter. I assume if you're on Twitter and following like you, like should be able to find out about these things. But you should 100% try this out today. Like you should try it out locally today. Try out esbuild, and the plain and the JavaScript transform API and think to yourself, hey, where can I use this? That would be interesting. It's very well-documented. Like Evan has done a very good job of documenting it. What's weird is that he has like core sensibilities reflected in the API choices which is -- it doesn't take any getting used to. It's nice. It's all statically typed.

Jason: Nice, nice.

Sunil: Yes, and you should -- you know what? It's a good time to be cautiously excited for the future of JavaScript. Like, it's clear that things are changing. It's good.

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.

Jason: Absolutely.

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: Have some esbuild as a treat. Yeah. Okay. So, I mean, this has been amazing. I'm super-excited. I'm really, really looking forward to just kind of what comes next. And as you said, cautiously optimistic about kind of the next year or two for JavaScript. It seems like we're gonna see a lot of new developments that are probably not going to feel that jarring, but will make a huge difference in the day to day work. Life gets better and you don't have to relearn everything. Those are the best changes.

Sunil: 100%.

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.

Sunil: Bye!