So, why the web is built? So, the essential reasons why we build our frontend code today. These reasons include dependency management, we need to be able to manage all the dependencies our code needs without having to worry about any of them breaking. We also need transpiling, so we need to be able to use this data syntaxes without, or in our browser, compatibility issues. Bundling, we need to be able to package all our codes into a central file. Minifrying, we need to be able to make the size of our code smaller and have a faster delivery to the client side. Also, one very important part is no module management using the browser. So, there are certain browsers that do not have module management, so we need to be able to manage a lot of modules without having to worry about anything.
So, the story of building the web. So, 2005 to 2010 saw the era of the first bundlers. Dojo was released in 2005 with it's own build tool called Dojo Builder which offers minification, dead code removal, multiple build profiles, module management, and you can even make use of Node.js for faster build. Google Closure Tools was also released in November 2009 by Google and it had a compiler, so this is basically it's own build tool which helps remove code, dead code, minimize code, lint code, and also optimize code. So, problems of the first builder and bundlers, why they weren't perfect. So, Dojo Builder was heavy. It relied heavily on Java and had a very poor documentation. Google Closure Compiler issues were, it was proprietary, obviously it was made by Google and it was some kind of an internal project before it was released to the public. It required Java 2, compile time was really slow, and it had poor developer experience. So, 2010 to 2012 saw the come up of Gulp and Grunt, they were the first to try and standardize building usable pipelines on top of plugins. They also gave developers freedom to write their own build scripts, and plugins were readily available for basic tasks for developers. 2012 saw the come up of Babel. So, Babel allowed developers to use latest ASX syntax without worrying about browser compatibility issues. It converts ASX syntax to CommonJS and it allowed developers to build custom plugins for their needs. 2012-2014 saw the come up of Browserify. This was the gamechanger mainly because of it had the power of npm as a package registry. It allowed developers to use certain plugins. It had the same syntax as NodeJS, and it also had ASX module syntax so developers were pretty much happy but it had its own drawbacks.
2. Webpack and its Features
From 2015 till now, Webpack has grown from v1 to v5 and is being used by many corporate giants in production. It is faster than Browserify and offers features like hot module replacements, code splitting, and live reloading. Webpack also has the power of npm scripts, allowing developers to write their own scripts without any concerns. With plugins and presets, it provides a better developer experience.
So from 2015 till now, we've seen the come up of Webpack, of how it has grown from v1 to currently v5. A lot of corporate giants are currently using Webpack in production. It is faster than Browserify. It has a very cool Webpack development server called Webpack Server. It has features like hot module replacements, code splitting, live reloading, etc. And it also has the power of npm scripts so developers can write their own npm scripts without worrying about anything. And it had plugins for various uses and it also had presets for extending the features of Webpack. It also had a better developer experience than other build tools. It was really good for developers.
So Parcel. So Parcel's selling point when it was released about two years ago was that you needed zero configuration, so the pain of developers configuring Webpack rollups did not happen in Parcel. It had a faster bundle time. It uses multiple processing. Plugins are not necessarily needed. This is because setting basic tags that require developers to use plugins were already built into Parcel, so the need for plugins were not really, really that much. It has an awesome developer experience. It has a very nice documentation for developers, and it also has a very nice community.
4. Browser Import and Bundling-Free Approaches
So, browser support has not really been great, but as the web is advancing, browser support for browser imports for ES modules gets increased also. So it has a very good advantage like caching, so the browser does not...once the modules have been loaded once, the browser does not really need to reload everything unless there's a change in one of the modules. You can also async or defer in the script tag for specifying your script, your modules to async or defer, which is a very, very cool feature for the ESM for the ES module, basically. And also, finally, we have bundling-free approaches, the Runtime Import System. So basically, bundling-free approaches basically would use ES modules, so you would not need your webpack, you would not need Parcel, you would not need other build tools for this. You just basically will be bundling directly in the web, so it's basically bundling-free. All of the production... So if you need a production... You would definitely not need a production build, and also, an example is Snowpack. So Snowpack is trying to make use of the bundling-free approach with ES modules. It is not too much in use yet, it's still kind of experimental, and if we are able to achieve bundling-free approach, we will have lightning-fast builds and also deploy time.
So references and useful resources. So this is kind of... If you need more knowledge on what I've spoken on today, you can check out these links. Thank you so much for coming to my talk, I appreciate it. I hope you enjoy the rest of the conference.