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


In this talk, I'd go through the Evolution of JavaScript Tooling and frontend build tools, Javascript itself and the future of them all.

Also, Babel and other build tools, what they might most likely be in the future. Also, I'd talk about javascript itself as a language, it's present and it's future.


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.
11 min
18 Jun, 2021

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Workshops on related topic