Hello everybody, my name is Cedric Aguilentario and today I'm going to be talking about
javascript tooling, the evolution and future of
javascript and
frontend build tools. I'm a social developer, I'm a developer advocate, 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. So 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 these latest syntaxes without having any browser compatibility issues. Bundling, we need to be able to package all our codes into a central file. Minifying, 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 our
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. So Dojo was released in 2005 with its own build tool called Dojo Builder, which offers minification, dead code will involve 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 its own build tool which helps remove code, dead code, minimize code, link 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 very poor
documentation. So 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. So they also gave developers freedom to write their own build scripts and plugins were also available for, readily available for basic tasks for developers. In 2012, it 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 common JS and allowed developers to build custom plugins for their needs. So about 2012 to 2014 saw the come up of Browserify. This was the game changer 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
node.js and it also has 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 version one to currently version five. And it's 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 and it had features like hot module replacements, code splitting, live reloading, et cetera. And it also had the power of
npm scripts so developers can write their own
npm scripts without worrying about anything. Their own build script basically with
npm scripts. 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, really good for developers. So let's see what the future looks like. So the future. So we have Rollup. So Rollup is a module
bundler for
javascript. It was released about say five years ago and it's easier to learn obviously and it has 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 very fast, it had a faster bundle time. It uses multi-core processing. Plugins are not necessarily needed. This is because certain basic tech tasks that require developers to use plugins were already built into Parcel so the need for plugins were not really, really that much. It had an awesome
developer experience. It has a very nice
documentation for developers and it also has a very nice
community. So Snowpack. So Snowpack was recently released. Its 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 ESM inputs, ES module inputs. So it is, I give it the ability to skip modeling and 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 tool currently. It provides instant rebuilds on sale so because there's nothing to rebund you so your change reflects almost immediately. It's obviously a faster build tool and 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 ES Build. So ES Build is basically an experiment. It's still experimental. It's the main aim of the project is 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 and 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 tiles in your browser so splitting your code into smaller, smaller pieces and delivering them as
modules to your
javascript, to the web, to the browser basically. So browser support has not really been great but the web is advancing. Browser support for browser imports for ES
modules would increase 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 specify 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, 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 Snow, other
build tools for this. You just basically will be bundling directly in the web. So it's basically bundling free. So 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 so 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, Telecosystem is dynamic. It changes and only the best tools can survive technically. It's basically a composition. So in the future we'll be seeing tools with no configuration, no configuration at all, better customizability, so it gives developer more flexibility to do whatever they want to do, more extensibility features and also faster speeds, blazing fast build speeds. So the kind of
build tools developers will use for an application's front end is basically a personal core 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 this or what I've spoken on today, you can check out these links. Thank you so much for coming to my talk, I appreciate it and I hope you enjoy the rest of the conference. Thank you.
