Javascript Tooling - The Evolution and Future of JS & Front-end Build Tools

Hi everybody. My name is Cedric Alcantara. I'm a Certified Developer. Today I'm going to be talking about Javascript tooling, the evolution and future of Javascript and frontend built tools. I'm a Social Developer, I'm a Developer Advocate and I'm also a Guest Technical Author at Smashing Magazine.

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.

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 let's see what the feature looks like. So the feature. So we have rollup. Rollup is a module bundler for Java scripts. It was released, about, say, five years ago. And it's easier to learn, obviously, and it is a very fast build. It offers features like code splitting. It is really, really easy to configure compared to Webpack and it's the perfect build tool for building JavaScript library because it takes small pieces of code and converts it into a very complex file.

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.

So Snowpack was recently released. The selling point is that it does not need bundling during development, so it skips that bundling process in development. This is because of the power of ES module imports. So it is giving you the ability to skip bundling during development, although you need to... So it also provided a plugin where you could use either Parcel or Webpack to create your own production builds. It does not have its own custom production build currently. It provides instant rebuilds on sale, so because there's nothing to rebund you, your change reflects almost immediately. It's obviously a faster build, too. It has out-of-the-box support for TypeScript, JavaScript, JSX, and CSS modules, so you don't need to install plugins for these particular languages' extensions.

So, ESBuild is basically an experiment. It's still experimental. It's the main aim of the project just to show how fast JavaScript build tools can be. It is faster than Webpack, Rollup, and also Parcel. It is written in Go, which makes it really fast because Go compiles to native code.

So far, we're looking at it to be a very, very bright project. So, Browser Import. So, Browser Import is basically making use of your modules in your browser and your script in the browser, so splitting your code into smaller and smaller pieces and delivering them as modules to your JavaScript onto the web, to the browser basically.

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 conclusion. So the JavaScript ecosystem is dynamic. It changes and only the best tools can survive technically. It's basically a competition. So in the future, we'll be seeing tools with no configuration, no configuration at all, better customizability, so it gives developers more flexibility to do whatever they want to do. More extensibility features. And also faster speeds. Blazing-fast builds speeds. So the kind of build tools developers will use for an application's front-end is basically a personal code based on the requirements of the project. It's like choosing what works best for you, basically, for that particular project. And most of the time, selecting developer to build tools are kind of trade-offs.

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.