Hello everyone, I'm really excited to be here with you today. The topic that we're going to discuss today is about the next generation of web bundling with RSPack. My name is Konstantinos or Kostas and I'm actually a software engineer at BIT, where BIT is basically the simplest way for you to join the journey to component driven development. We provide a collection of tools to build and reuse components really fast. These are some of my social handles. You can find them on Twitter or X on GitHub and also on Bitcloud, where I will be able to share some of the resources of this talk with you later on. But before we jump on to the RS pack, let's discuss what is a bundle. A JavaScript bundle is a very simple thing. It's a collection of multiple scripts combined into a single file. During Sentinel Bundler, what it had to do was actually a plus equal operation, like a concatenation for a long time. And this was a actually what Everyone was needed then. I don't know how many of you are familiar with Browserify. Browserify is a tool that was released in 2013 and solved the problem of Node. js developers who wanted to reuse their code into the browser. What it was doing, it was actually making the common JS module system work for the browser by crawling the dependency tree, reading files, and building a single bundle file. It also made node built ins and conventions like, for example, process, buffer, crypto, etc. work in the browser by implementing polyfills and symbols for them. This was a ridiculous amount of work that had to go into building all this infrastructure. And basically what it was doing was Webpack was trying to understand which kind of environment this module was actually running into. And depending on this environment, if it was a Node. js environment or a browser environment, would expose this module. After some time, in 2015, Webpack was actually, was introduced. And Webpack's goal was to create a dependency graph for all the assets of the website. It is not just JavaScript Browserify, but it also includes CSS images, SBGs, even HTML. And what this enable enabled us to do was actually break some node conventions and introduce code like this where we were actually able to require CS files or SVG files into the JavaScript. And the reason Webpack did that was for a few different reasons. Now, website assets can be expressed as a dependency graph. And it becomes easy to define components as a collection of HTML, CSS, JavaScript images, etc. As standalone modules that can be easily reused or even published to npm. Hot module replacement, which is very important for the development purposes, is easy and natural because we are based on a JavaScript module system for assets. And even, for example, for stylesheets can automatically be updated by injecting and replacing into the DOM via script. Finally, it is providing a lot of configurability through loaders and plugins, meaning we can get the benefits of an integrated module system without having to ship gigantic JavaScript bundle to your users. And here you can actually see the adoption of Webpack. The adoption has been amazing. most of the web projects are using web app today. And you can see that lately has actually reached 120 million downloads per month, the last. Even when I search just for Webpack on NPM, you can see that it returns 6, 000 packages. So you can understand how big this adoption has been and how many tools and modules have been built related to Webpack. But this actually started getting a bit out of hand. more difficult for us because with web app, we started having different performance issues like bundle sizes, really slow hot module replacement, with some tools like react and production build times. And this. Resulted to a great amount of different articles of how we can actually optimize and make the webpack bundling and development server faster. This is when RxPack basically came in. RxPack was initially created to solve the performance problems encountered by Dice. Bytance is a very big company, you can, you might have heard them before, for TikTok or CapCut, they're actually building quite many different tools and products. And it's basically a tech company that maintains many large monolithic application projects with complex bundling requirements. The production build times have grown a lot in Bidens, 10 times to even half hour in some cases, and cold start times could exceed several minutes. This is how RSPack is actually pronounced. RSPack comes with a great amount of benefits. It provides high performance for bundling, a really fast startup time for your development server, light and fast hot module replacement, for your development purposes. It comes with Webpack compatibility, offering backwards compatibility with the configuration that we provided in Webpack. And it's also framework agnostic, which means you can actually use it with tools like React, Vue, JS, Svelte, etc. And speaking of performance, as you can see here, it is really fast. It's basically compared with a combination of Webpack and Babel. It is way, way much faster and also compared to more up to date bundling tooling like Vite. The community is really excited about RSPack. You can see that even Repack, a tool about bundling React Native code using Webpack, has actually tried migrating to RSPack and found out five times faster build times and HMR. The reason RSPack is so fast it is because it is based on Rust and is written in Rust. Rust language efficiency is designed to prioritize performance topping benchmarks for speed and memory management. it is highly parallelized architecture, where JavaScript is a weak support for multi threading. RSPack's native code takes full advantage of the modern multicore CPUs. And this is how RSPack actually generates binary native code. So the native code that runs in your operating system. And the way that SPAC actually does that is through a tool that is called Nappy Rs, which is a framework for building pre-compiled no JS ADONs in RAs. And what it does, it actually generates the native code that you run in your system, in your operating system, and an OJS library that you can use in your application, like an SDK, that can communicate with the Rust implementation that has been exposed in this native code. It comes with a great amount of features, like built in CSS support, even for CSS modules, This is currently experimental, but you can still use it and it's very good support for built in support for asset management, like for example, PNG files, SVG files, JPEG, even JSON files, also web workers. And it also provides different loaders for TypeScript and JSX for CSS, as I mentioned before, a lot of plugins for HTML or CSS Extract plugin, for example, the hot module replacement is really easy to implement. Now, for example, with react or any other tools, it also provides a lot of optimizations that you don't need to configure, like code splitting and reshaping as it are, they are offered by default. And of course, module federation version two, which is actually a great amount of work, for this ecosystem. But you might be wondering, that's all great, but how can I actually migrate from Webpack to RSPack? We can start with some of the dependencies, so you can actually add RSPack core and RSPack CLI to your development dependencies, and then you can actually remove Webpack CLI, and Webpack dev server. Then, in your packagation, in your npm scripts, You can replace Webpack CLI from using to RSPack and this is like very simple. You just change the command that you run, but you can actually use it with the same API and configuration options. And finally, what you need to do is rename your webpack config. js file to rspack config. js. And I think that's all. We are, this is the presentation for today. That's actually a joke, a really bad joke, sorry for that. But still, you can actually, this is enough. For you to start using, RSVAP and this is the magic of it because it is very simple to, to do it and you can start getting the performance benefits out of it very, simply with this kind of migration, depending on your configuration, you might need to make some more adjustments and we're going to see now what are these kinds of configurations that, we will need to adjust. First of all, loaders, RSpack loader, runner is fully compatible with Webpack's loader functionality. It is supporting the vast majority of Webpack loaders, and, you can use your existing loaders without any changes. But in order to get the benefits of RSpack and the REST implementation it comes with, you will need, for example, to change. The bubble loader to built in SD SWC loader. This is a loader that is, written in rust, by our team and, is providing much, much better performance. And the way that you can do that, for example, is you might have such a web configuration with, A TSX and a JSX loader using bubble and some presets depending. on your files and then what you need to do is basically migrate that to using the built in SWC loader that provides support for both TypeScript and JSX. and using built in SWC loader offers better performance, as I said, compared to the Babel loader and the external SWC loader, as it avoids frequent communication between JavaScript and Rust. You will also need to change some of these loaders like the file loader to the asset resource, the URL loader to asset inline, and the row loader to asset source. Asset resource converts an asset to a separate file and exports the URL address. The AssetInline converts an asset to a data URI using Base64 encoding. At the moment, no other codings are supported, but later on we might have more of them. And AssetSource converts and exports the asset file as a raw string. When we actually say about plugins, we mean built in plugins and also community plugins. RSPack has implemented most of the Webpack's built in plugins with the same name and configuration parameters allowing for easy replacement, and also supports most of the Webpack community plugins and also offer alternative solutions for some currently unsupported ones. So for example, in Webpack configuration, if you're using defined plugin, you can actually Migrate to RSPack 1 by changing the import and also changing the reference to RSPack 1. And this is very simple. Similarly, you might be using, your HTML, the HTML Webpack plugin, which is a way for you to integrate HTML into your Webpack configuration. This plugin is supported in RSPack as well, but if you want to get the benefits of the Rust based implementation of the same plugin, you can actually reference to the RSPack implementation of it. this is implemented in Rust, and its build performance is significantly better than HTML Webpack plugin. There's some differences between those two plugins, just to be aware, but for the majority of the purposes will fit your needs. RxSpack team has done a great job in documenting all these, available plugins that you can use with RxSpack and you can find them in this page over here in the documentation. But like any migration, there are some caveats and these are related mostly to SCSS modules. I don't know if you're familiar with this error, with this warning. this is basically happening when, the default export is not available when you import a module. This is usually happening, in a React project. For example, when you import the styles from your CSS module like this, and then you're able to provide the class names, to your JSX elements. Like this. so by default, this is going to be the error that you're going to be facing. This is the warning. this warning is there because the compilation will still be successful. But when you run the application in your browser, you will actually see the application without any styles applied. And what you would need to do in order to change that is actually change your source code from importing the default export. To, to import everything as an alias of styles. But as I'm not a fan of basically, changing your source code because you're basically migrating to a new tool from Webpack to RSPack, I would prefer to do that with the tool itself. The way that you can do that is by enabling the built in support of CSS, which is still experimental in RSPack, but it's still experimental. And this is actually how you can actually, you can enable and try out some experimental features in RSPack with experiments object. Once enabled, RSPack will enable native support and CSS related parsers and generator options. Then you will be able to define this kind of configuration for generator and parser by disabling the named exports when you parse the CSS related files. And also by disabling the ES modules For this reason, then you will be able to define your loaders for SCSS files by using the SaaS loader, which is not built in, supported, in our respect. so you will still need to define this kind of loader. And you need to define the type CSS auto, which helps RSPAC understand that these, these files can actually be either CSS or CSS modules, and it can, actually decide which of them, should, how it should handle its case. then you can. Change your CSS, loader to just type CSS and, RSpec will take care of loading your CSS files in the, in your code base. And since you're actually now have the built in support, you can actually entirely remove the CSS loader for that purpose. This behavior I would like to see be supported by default. And this is something that I have raised with our respect team before. And I would be very happy for you if you're able to support this kind of approach, because it could be really important for us To be able to use, SSS modules without the need to do all this extra configuration in RSPack. And, with Bit we basically have helped a lot of customers migrate to RSPack already. We have seen at least three times faster build times, if not five, in some cases. And basically the way that we've done that is with, a tool that is called Configimitator. Configimitator. which helps you migrate to RSPAC much, much easier. You can imagine that usually this is a configuration that you would need with RSPAC, for example. But what if, instead of all this configuration, you were able to write something simpler, just like this, which is by importing the RSPAC config imitator. Then you can actually initialize this new data and can start creating your own configuration with a much more descriptive language, like setting the mode to development, adding the CSS, the TypeScript support, and even React support, if needed, by providing this extra parameter, adding the CSS modules without the need to know the internals of how our Spark works. is actually working under the hood and, also providing SCSS support, without the need to configure the generators, the parser or everything like that. And what is the benefit of this tool? It can even use Your own configuration, the configuration that you have, you already, provided, your own custom configuration and updated based on your needs, for example, by adding the TypeScript support, with React or not, or CSS modules and everything like that. And, you can actually find this config mutator, this tool, it is documented on Bitcloud. This is a link where you can actually find out and learn more about how you can actually start using this tool, how you can, start migrating using this tool. And this is basically the way that we have helped a lot of customers migrate to RSPack already. Finally, RSpack is the building block for a great amount of web infrastructure that RSpack team provides. On top of RSpack, we have rsbuild, rspress, rsdoctor, and rslib. Which are few different tools for different purposes. RS Build is a tool that provides an out of the box setup for development purposes. RPR is a static site generation tool. RS Doctor is basically a great tool for analyzing and visualizing the build process and artifacts. And R Lib is a build tool. Mostly targeting to lib authors. And with that, I think that's all for today, folks. Thank you for joining me today. I really appreciate it. And I hope you learned something new today. Thank you very much. Bye.