Brendan:
Hello, and welcome to PodRocket. I'm Brendan, I'm your host. I'm on the engineering team here at PodRocket. And joining us today is Michele Riva. Michele is a software architect at NearForm. Previously worked at some big companies, but most relevant to us, gave a conference talk at the BeJS conference titled Compiling and Bundling JavaScript The Painless Way. Michele, thanks for joining us. How are you doing?

Michele Riva:
All right. Thank you for inviting me. It's a real pleasure to be here.

Brendan:
So compiling and bundling, and that being painless, I'm into that. I think the frontend toolchain in general, and bundling in particular, can be one of the most confusing and intimidating parts of the modern web development stack. So I'm excited to have an expert joining us and breaking down some of those barriers, and maybe we can also talk about what the future of the JavaScript ecosystem and tool chain looks like a little bit as well. But before we get into all of that, maybe you could introduce yourself and tell us a little bit about your background and maybe how did you become the kind of person who gives conference talks about JavaScript bundling?

Michele Riva:
Okay. Yeah, so I'm working as a senior software architect at NearForm. We are a professional services company, mostly specialize in React JS, Next JS, Node JS, of course. We're maintaining a lot of open-source projects. And I'm also a Google developer expert and Microsoft MVP, so in a developer technologies and Google Cloud Platform. So I would say right now, I'm really focused on software architectures, but I do also love coding JavaScript, so I will never leave that field. And that's why I keep on working with new model bundlers, compilers, and whatever can help us achieving better results, writing more modern JavaScript, and target also older platforms, runtimes, and browsers.

Brendan:
Yeah. And I would imagine that in your day job, you're probably working between a lot of different projects and maybe seeing a lot of different environments and setups and tool chains. Is that how you got familiar with this whole area? Where does this interest or expertise in bundling come from?

Michele Riva:
Okay, so the first time I looked into React, it was around, I don't know, 2014, 2015. Can't really remember, but I remember there was create React app, where you could spin up a new application from scratch in like two minutes. And it has been a game changer for us because the biggest pain point for everyone learning React at that time was webpack configuration. So I struggled a lot getting used to the webpack configuration. And I got to say, it's not really changed over the time, the feeling that I have with webpack, even though I totally love it. And maybe we can discuss about why I love it so much later on, but since then, I've always struggled trying to find a better alternative, and it's not easy. So I wanted to give talks about that topic to make people aware that we have other alternatives that can be a direct solution for their problems.

Brendan:
Yeah. And maybe that's a good opportunity to step all the way back to the beginning and ask how we got here as an ecosystem. Why do we even need tools like webpack? What do they do? How did we get into a place... if I have a Python script, I just run my Python script. So what's made JavaScript so different as an ecosystem, as a language that we need all of this tech?

Michele Riva:
That's a really cool question. There are multiple answers, I would say. So, for example, if we are talking about Node JS or Deno or a service at runtime, in general, you might not need a bundler. And that's because you have a module system. So in Node, we used to have Common JS, for example, where you could require other modules. Nowadays, we have ECMAScript modules, so you can directly import instead of requiring modules, but that was not the case for the browsers. So, back in the day, I was talking about React with a webpack default configuration. In 2015, we didn't have direct imports in browsers, so we needed to bundle up the code into a single executable file and serve it over the net. So that was the use case. I would say the primary use case for model bundles, where you couldn't dynamically import code directly from the browser, but you had to bundle it. And webpack, it's really good at doing that, even though it has some complexities. And for that reason, many competitors started to grow, such as Rollup, Parcel, and then Vite and Snowpack and whatever. But yeah, they really helped us achieve the web we have today.

Brendan:
Right. And I think there's also an aspect of optimization to that as well, where as the web has become more performance focused, bundlers and compilers as well have become very focused on improving those core web metrics. Has that been a big part of the development of the bundling and tool chain ecosystem as well?

Michele Riva:
Yeah, I would say if we talk specifically about bundling, we started to think of our code as tree shakeable, for example. So some model bundlers, not every single one, but the most popular ones started to integrate tree-shaking technology, for example. So some duplicated code can be, for example, instantiated only once via singleton pattern. Other code that can be identified as a death code can be thrown away, or we can also fragment the code and make it lazy so that we only load it when it's really needed. So model bundles has become more complex over time, but also very powerful to match up the expectation of a faster web as the time goes on.

Brendan:
And I also like the distinction you drew there between the bundling and compiling aspect that I think usually we merge into one in our head and code comes into webpack and it comes out the other side bundled and compiled. But could you talk a little bit about what the difference between those processes is and how they each contribute to what we need from a product like webpack?

Michele Riva:
Yeah. Absolutely. So we just discussed about bundling, so I won't go over it again, but I can talk to you about compiling. And when we refer to compiling, we refer to that process to transform a code written in a high-level programing language into machine code or byte code, generally speaking. So when we talk about JavaScript specifically, we should talk about transpiling or transcompiling, meaning that we are not targeting the machine. So we are not targeting byte code or binary code, but we are basically translating a source code into another source code. For instance, I don't know, we can transcompile from one language to another. We might have Scala for example or Kotlin, or basically, every single language that nowadays gets compiled via the LLVM framework could potentially transcompile to JavaScript. So that is the transcompilation process. You have a Scala script and you feed the compiler and get the JavaScript in return.

Brendan:
So, on the one hand, there's this more esoteric transpilation process, where you're right, you can take any language and get JavaScript out. And I think the other major use case has been getting features that are coming to the language or have mixed support across browsers to be available to you as a developer consistently. Is that, in your mind, all the same type of tooling or same type of process, or do you see that JavaScript dialect to browser-runnable JavaScript as a different type of thing?

Michele Riva:
So the concept, it's almost the same. If you want to transpile from one language to JavaScript, it's almost the same process you need to do for a super set of JavaScript to JavaScript. So for instance, TypeScript, it's definitely a super set of JavaScript. If you want to target JavaScript as a compiler output for TypeScript, you can do that, but you need to go through all the steps you need for compiling a language. So you have to tokenize it. You have to parse it. You have to create an abstract syntax tree. You have to traverse that tree to understand if the syntax, if the semantics are correct, if the scope for the variables is correct. You have to do many things. And at a certain point, you have to decide, "Will I target a byte code or machine code or will I target JavaScript?" So this is where we make a distinction. If you want to compile, you go with byte code, machine code, wherever. If you want to transpile, you transpile to a subset, so from TypeScript to JavaScript or directly you transpile to another language. So this case, for example, for ReasonML, targeting JavaScript, OCaml, Kotlin, Gleam, and all the languages that targets JavaScript. But the concept is still the whole compilation process, except for the code generation, that it's the different one between compiling one language to machine code than transpiling to JavaScript.

Brendan:
Yeah. Another thing that we've mentioned is that all of this, from our perspective as developers, most of the time, until it breaks happens behind the scenes and is not something that I think a lot of people are thinking about day to day. Why do you think this is such an important topic for developers to be aware of and be thinking of?

Michele Riva:
Because I would say, as developers, we take many things for granted, I would say. So we say, "Okay, I want to use the latest JavaScript features. I want to use them on all the browsers and run times. I will just use Babel, but I need to understand how Babel works for many different reasons." For example, reason, number one, I might want to create my own plugin for Babel because Babel is powered by a plugin system, and it's the de facto compiler for JavaScript. So whenever I want to interact with the JavaScript source code at the compilation level, I need to understand how I want to do that. And now you might be wondering "Why would I ever start a conversation like that? I mean, why should I want to compile JavaScript myself?" That's a cool question. And I can answer you with, for example, code bots. So if you want to refactor a large-scale application and you don't want to do that manually, you can read the source code. You can read the abstract syntax tree, understand how the code is formatted, understand the logic behind the code, and make some changes automatically by writing, for example, a JS code Shift, which is based on Babel, ArcGIS, and other compilers and tokenizers out there.

Brendan:
Right. So it's not just rewriting code by manipulating it as a string input, but actually decomposing it structurally. And that's where you gain the ability to do really sophisticated transformations.

Michele Riva:
Yeah, that's correct. You can also run some interesting optimization. So, for example, if I have an upside syntax three for a JavaScript code base that says, "Okay, this is a binary operation. It's addition. So, on the left side, you have 10. On the right side, you have 10." We know that's a binary operation. If I read the upside syntax three while transpiling my code, I could say, "Why should I ever do that at one time? Let me run the addition at compile time so that you save some space, some memory, some speed at runtime." So I mean, okay, that's a silly example, but I mean, if you think of that at the scale, then can be really interesting to be able to interact with the compiler itself.

Brendan:
Right. And I think there, you're getting some of the optimizations that you would expect if you were writing a very traditional compiled language like C or Rust that you would expect a compiler to do for you. You're getting in JavaScript by virtue of being able to sort of process your code.

Michele Riva:
That's absolutely correct. So, for example, let's say use the dot method in JavaScript. So you basically have an array and you create a new array back. If you're not used to that functional pattern, but you want to loop over an array and push elements to another one after transforming them, you could do that by creating an empty array and pushing elements. That's a good pattern, but it's not perfect. Knowing the size of the original array, you could create a new array with that same length and then push to the individual memory allocation for every individual index. So that's an optimization you can do at compile time, while transpiling from JavaScript to JavaScript just for the sake of optimizing the runtime process.

Emily:
Hey, this is Emily, one of the producers for PodRocket. I'm so glad you're enjoying this episode. You probably hear this from lots of other podcasts, but we really do appreciate our listeners. Without you, there would be no podcast. And because of that, it would really help if you could follow us on Apple Podcasts, so we can continue to bring you conversations with great devs like Evan You and Rich Harris. In return, we'll send you some awesome PodRocket stickers. So check out the show notes on this episode and follow the link to claim your stickers as a small thanks for following us on Apple Podcasts. All right, back to the show.

Brendan:
I think it might be a good time to now switch gears from this general overview of what we're doing and why to talking about some of the specific technologies, because that's another big part of the ecosystem. You mentioned webpack and Babel, some of probably the things that everyone's heard of, but there's a whole new generation of build and bundling tools, Esbuild, Vite, Snowpack that are coming online now or in the past couple years. I'm curious if you could talk a little bit about what's behind both that proliferation of tools and what are they doing that's new or different from each other that might make us want to choose one versus another.

Michele Riva:
There are tools such as Webpack that only does one thing and does it very well. So it's not really true that it does just one thing, because it's capable of doing many things, but at its core, it's a bundler. So you give it many files, it outputs just one single file. So that's the main purpose. We have, as you were saying, a new generation of tools, such as Vite built by Evan You, the creator of Vue JS that it's now capable of doing more. It's not just a model bundler. It's a development server. It uses esbuild, which maybe we would be talking more later, but uses esbuild as a local development tool for speeding up your build times and refresh times. And most important, it's a bundling tool that doesn't bundle code. So that's pretty strange, but it basically runs a series of optimizations, et cetera, and compilations and whatever you need, and it outputs ESM models. So you basically get modern models in return, and you can basically use them on the browsers without the need of bundling one single executable, which is pretty good.

Brendan:
And so is that something that can exist now, but couldn't exist in the past because of changes in the browser ecosystem and what browsers are able to support, or why does this tool get built in 2022 as opposed to 2015?

Michele Riva:
You are absolutely correct. So the fact that the browsers are getting more modern and we finally dropped support, for example, for Internet Explorer, that was blocking most of the new age compilers and bundlers, so we now have a situation, where we can really experiment with very different stuff for bundling and shipping our code. So I guess that's one of the reasons why we had to wait for such a long time to get this kind of great tooling. And I feel like we haven't exploited yet the full potential of many of those tools. For example, we might talk about SWC, which is a project nowadays maintained by Vercel, which it's a building tool. So it's a compiler. It's still in beta but could also be a bundler, which is still completely written in Rust. That means that it could potentially run on the browser. And that's super interesting. I don't know if anyone have tried doing that, but it's exciting to know that we have a possibility there.

Brendan:
And so what would be some of the implications of that? Are there potential projects you can can think of that would be particularly able to benefit from being able to run this tool in the browser, or is that what you're thinking of as the area we haven't explored yet?

Michele Riva:
I will be brutal here, but for example, you run on a very old browser. Okay, you won't be supporting WebAssembly, so that's not the case, but if you are on a, let's say, quite new, but still old browser that supports WebAssembly, but it's not up to date, so okay, only for you I can transpile the code, for example, or I can publish my code to a CDN and then get it transcompiled, as it was a just in time compilation directly on the browser. I don't know, maybe that's a good idea. Maybe it's a bad one. I have no idea about that. I don't have benchmarks, but I guess it opens to a world of possibilities, and it's a great time to be an innovator in that field thanks to those tools.

Brendan:
Yeah. So we've talked a little bit about SWC. We've talked a little bit about Vite. What are some of the other new or exciting tools in this space, and what's their claim to fame or the thing they're doing that's interesting?

Michele Riva:
So I would say, yes, Build is one of those. It's definitely an exciting technology building Golang. I remember I wrote some time that it has been built with speed in mind. So speed was a top priority for... Evan Wallace, I think wrote it. So the former CTO of Figma, so he wrote esbuild, which is basically a bundler, a compiler, and it's capable of outputting code in a very fast manner. So it's also used, as we were saying, by Vite. It was used by Snowpack. I'd like to talk more about Snowpack, but it's a dead project super sadly. But it's also cool to know how Snowpack worked, because I feel like it was really similar to something we have today with Webpack, which is Module Federation. And Module Federation is the reason why today I still use Webpack. So we have many things to discuss, I would say.

Brendan:
Yeah, well, you said that you love Webpack and you wanted to have a chance to talk about why. So maybe this is a good point to pose you that question. Why do you love Webpack, despite, perhaps, the challenge we've all faced of trying to figure out what the heck all those options do?

Michele Riva:
Exactly. So Webpack, it's not easy. I've been stuck for five months trying to upgrade Webpack 4 to Webpack 5 on a very large code base in the past. So I know it can be painful, but the fact is that it's really mature. And if you want to interact with your compilation process or bundling process, it allows you to do that. And also, it opens to a world of optimizations, for example, the ones that gets done by Module Federation plugin. So for those who don't know what Module Federation is, it's a new way of shipping code, basically, in real time, possibly, where you have, for example, a React application made with Create React app that will work just fine.

Michele Riva:
You select individual components, scripts, types, whatever you want, and you can serve them as individual components. But the good thing is that thanks to the way that Webpack works, the Module Federation plugin, it's able to say, "Okay, you're using a nav bar. That nav bar uses three-button components. You're now using also a header, which uses one-button component. I will read the abstract syntax tree, and I will give you just one reference for that button." So the cool thing is that you will be shipping code with very few repetitions, highly optimized, and that's because Webpack is super cool at doing this stuff. And it's really easy to interact with the compilation and bundling process, so we are capable of building something really special, such as Module Federation.

Brendan:
Mm-hmm. And you mentioned both the maturity and the architecture of Webpack. Is that level of optimization an artifact of this project just having been around for so long and then having been battle tested against the needs of people working in large code bases, or is it specifically the architecture and design of Webpack that lets you solve those problems?

Michele Riva:
I would say both. So Webpack has been a community-driven project for a very long time. Nowadays, the creator of Webpack works at Vercel, if I remember correctly. So, first of all, we know that it will have some good support for a very long time. So having a big company supporting your project, it's something good. In the past, we had other companies contributing also financially to Webpack, which is not something we can take for granted when we talk about open-source projects. So thanks to the financial support, thanks to the rich community, thanks to the fact that it was the de facto bundling tool in the React Rising era, Webpack has become very popular, well supported, and there are many developers nowadays that really know how to make it work properly. So even if it's really complex for enterprise projects, it's still a good idea. If you're starting your own website, personal website, or side project, maybe Vite or parcel are good options, but if you want to go on an enterprise scale application, then Webpack, it's well suited for the task.

Brendan:
I feel like a latent theme here that we've touched on a couple times is the developer experience of these tools, both the challenges of the developer experience with Webpack and also the way that SWC and Vite have focused on providing more all-in-one functionality and more pieces of the tool chain together. Is that something you see as a trend that's going to continue, that there's going to be more developer focus in where these tools go in the future? Will there be more specialization? What do you see as the big trends?

Michele Riva:
That's a nice question also. I would say the trend will be to be as developer-friendly as possible. So if I have to bet, I would bet on the fact that the next generation of bundlers will move into a developer-friendly way, so convention over configuration, for example, more fast tools, such as esbuild underneath. Also, Vercel is nowadays sponsoring a project, where they're basically rewriting... Or sorry, no, they are porting TSCs so the type script compiler in Golang to make it faster. So that's basically and purely a developer experience-based porting. On the other hand, I would say there will be a niche of tools that will stay on the productivity side, whereby productivity, I mean, being able to do whatever you want out of a configuration. So Webpack, it's here to stay. I'm sorry for those who find it really complicated. I'm one of those, but sometimes you really need it.

Brendan:
And I guess, I'm curious if you wanted to think about what are some of the pain points or unsolved problems in bundling or transpiling or the just the JavaScript tool chain, in general, that you would like to see solved in the next few years?

Michele Riva:
Okay. I would say bundling time, it's definitely a pain point. And for example, Vite, it's capable of solving that with a constant time. So if we talk about, O notation, for example, we can say that the compilation time for Vite it's O1. So if you have like 10 dependencies, Webpack, which is linear, so ON, the compilation time required grows linearly as your number of dependencies grows. So if you have, for example, 10 packages with Webpack, you change one dependency, you have to rebuild them all. With Vite, we don't have that. We only rebuild the one that we change, so it's faster. So I guess that's the pain points that the model bundlers are addressing right now, and I'm really happy about that, even though I would say that in the future, my goal would be to have... Oh, sorry, my prediction would be that we'll have no bundle at all. So we won't need bundlers at all because of ECMAScript modules, because of browsers getting more modern, and so that's my hope. That's not only a prediction. So I really hope being there as fast as possible.

Brendan:
And I guess the big obstacle there, as always, is probably browsers and browsers converging on being able to support the exact same set of functionality and operations.

Michele Riva:
I'd also say that the TC-39 committee, it's doing an awesome work getting some cool specifications for browsers. And I would say that also the browsers are moving really fast and well, so we have basically Chromium-based browsers and Mozilla Firefox and Safari. These are the main... We have just three browsers today that needs to support new features, while 10 years ago, we had a variety of browsers that needed to catch up with the latest features. So today, I would say it's easier for us to get into a direction that is dictated by TC-39 or all the committees behind individual browsers.

Brendan:
All right. Well, Mitch, thank you for joining us. Before we go, is there anything you'd like to point our listeners to, anything they should check out, or where to find you online?

Michele Riva:
Yeah, I would recommend anyone going to the esbuild website, there is an awesome benchmark, where it's basically comparing the compilation speed and bundling speed of esbuild against Parcel, Webpack 5, and Rollup. And I won't spoil anything. You will see how fast it is compared to traditional bundlers, and it's really a game changer. So I will leave you there.

Brendan:
All right, well, we'll leave it on the cliffhanger. Mitch, thank you. It's great to have you on the podcast and we'll see you online.

Michele Riva:
Thank you again.

Speaker 4:
Thanks for listening to PodRocket. You can find us at Podrocket pod on Twitter, and don't forget to subscribe, rate, and review on Apple Podcasts. Thanks.