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

Rate this content

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.

11 min
18 Jun, 2021

AI Generated Video Summary

Today's Talk covers the evolution and future of Javascript tooling, including dependency management, transpiling, bundling, minifying, and module management. Webpack has grown in popularity and offers features like hot module replacement and code splitting. Other build tools like Rollup, Parcel, Snowpack, and ESBuild are also discussed. The Talk explores browser import and bundling-free approaches, and emphasizes the dynamic nature of the JavaScript ecosystem with evolving tools and project-specific trade-offs.

1. Introduction to Javascript Tooling

Short description:

Hi everybody. Today I'm going to be talking about Javascript tooling, the evolution and future of Javascript and frontend built tools. The essential reasons why we build our frontend code today include dependency management, transpiling, bundling, minifrying, and module management using the browser. The story of building the web started with the first bundlers like Dojo and Google Closure Tools. However, these tools had their own issues. Then, Gulp, Grunt, Babel, and Browserify came up with their own solutions to improve the development process.

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.

2. Webpack and its Features

Short description:

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.

3. JavaScript Build Tools

Short description:

So let's see what the feature looks like. Rollup is a module bundler for JavaScript. It's easier to learn, very fast, and offers code splitting. Parcel, released two years ago, requires zero configuration, has a faster bundle time, and an awesome developer experience. Snowpack skips bundling during development, provides instant rebuilds, and has out-of-the-box support for TypeScript, JavaScript, JSX, and CSS modules. ESBuild is an experimental project that aims to show how fast JavaScript build tools can be, written in Go for native code compilation.

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.

4. Browser Import and Bundling-Free Approaches

Short description:

Browser Import allows splitting code into smaller modules for delivery to the browser. Browser support for ES modules is increasing, offering advantages like caching and async/defer options. Bundling-free approaches, like the Runtime Import System and Snowpack, aim to improve build and deploy times. The JavaScript ecosystem is dynamic, with tools evolving to offer better customizability, extensibility, and faster build speeds. Developers choose build tools based on project requirements, often making trade-offs. References and resources are available for further knowledge.

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.

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

JSNation Live 2021JSNation Live 2021
31 min
Vite: Rethinking Frontend Tooling
Vite is a new build tool that intends to provide a leaner, faster, and more friction-less workflow for building modern web apps. This talk will dive into the project's background, rationale, technical details and design decisions: what problem does it solve, what makes it fast, and how does it fit into the JS tooling landscape.
JSNation 2022JSNation 2022
21 min
The Future of Performance Tooling
Our understanding of performance & user-experience has heavily evolved over the years. Web Developer Tooling needs to similarly evolve to make sure it is user-centric, actionable and contextual where modern experiences are concerned. In this talk, Addy will walk you through Chrome and others have been thinking about this problem and what updates they've been making to performance tools to lower the friction for building great experiences on the web.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
86 min
Using CodeMirror to Build a JavaScript Editor with Linting and AutoComplete
Using a library might seem easy at first glance, but how do you choose the right library? How do you upgrade an existing one? And how do you wade through the documentation to find what you want?
In this workshop, we’ll discuss all these finer points while going through a general example of building a code editor using CodeMirror in React. All while sharing some of the nuances our team learned about using this library and some problems we encountered.
JSNation 2023JSNation 2023
44 min
Solve 100% Of Your Errors: How to Root Cause Issues Faster With Session Replay
You know that annoying bug? The one that doesn’t show up locally? And no matter how many times you try to recreate the environment you can’t reproduce it? You’ve gone through the breadcrumbs, read through the stack trace, and are now playing detective to piece together support tickets to make sure it’s real.
Join Sentry developer Ryan Albrecht in this talk to learn how developers can use Session Replay - a tool that provides video-like reproductions of user interactions - to identify, reproduce, and resolve errors and performance issues faster (without rolling your head on your keyboard).