Table of Contents
Babel and webpack are two popular tools in the JavaScript ecosystem, but they serve different purposes and complement each other in modern web development workflows like apple🍎 and banana🍌.
Babel vs webpack
Babel
Babel is a crucial tool in modern JavaScript development, acting as a translator that converts the latest and greatest JavaScript (ES6+) code into versions that are compatible with browsers and Node.js (ES5). This fancy code, full of modern syntax and features, may not be directly understood by the browser or older versions of Node.js.
Below is a fancy code that most developers of love to write today. Despite of how fancy it is, our browser / Node.js has no idea what it’s talking about. (Note: Some Node.js higher versions have ES6 support now.)
// ES6 syntax
import moment from 'moment';
export default () => moment().format("YYYY Do MM");
And this is why we need Babel to translate above into the equivalent not-so-fancy code below, that our browser / Node.js actually understands.
// ES5 syntax
const moment = require('moment')
function getDateString() {
const date = moment();
return date.format("YYYY Do MM");
}
exports.default = getDateString;
That’s why Babel is sometimes called a transpiler.
It’s worth noting that Babel is commonly used for both front- and back-end. Why do I mention this? Because Webpack is front-end only (in most cases).
Webpack
If Babel is a translator for JS, you can think of Webpack as a mega-multi-translator that works with all kinds of languages (or assets). For example, Webpack often runs Babel as one of its jobs. Another example, Webpack can collect all your inline CSS styles in your Javascript files and bundle them into one.
What is webpack and why use it?
Webpack is a static module bundler for JavaScript applications — it takes all the code from your application and makes it usable in a web browser. Modules are reusable chunks of code built from your app’s JavaScript, node_modules, images, and the CSS styles which are packaged to be easily used in your website.
Why do we need such a monster for front-end, but not back-end?
Because front-end has many kinds of assets such as CSS, SASS, images, fonts and is way more complex and dynamic than back-end which only has JS. And in the end of day we need to somehow package all variety of assets into a small file that our users’ browser can download at page load time. This is also known as minify and uglify. You see, back-end has none of the above requirement.
Another important reason is that front-end doesn’t work with modules (again, in most cases). Modules are built-in features of Node.js, not browsers. Nowadays developers are so used to npm install, import and export JS modules in front-end, as it allows us to better organize code and share packages. But in reality they are only syntactic sugars, and it’s Webpack’s job to figure out all the dependencies among all the modules that we use in the code, and compile them into one big chunk of JS code that the browser actually understands.
When do we use Webpack in back-end?
A good use case is to support SSR (Server-Side Rendering).
Crips and one lines
Babel is a JavaScript compiler that allows you to use new features of ECMAScript before they are implemented in browsers.
webpack is a module bundler for modern JavaScript applications. It is a module bundler that can be used in a variety of ways, from a build-time tool to a development-time tool.
Consider Babel if you want to use new JavaScript features that are not yet implemented in browsers.
Consider webpack if you want to bundle your JavaScript application for production.
To sum up,
- Backend: we use Babel so that we can use the fanciest JS syntax (ES6/7) with Node.js.
- Frontend: we use Webpack (which uses Babel and other things) to compile JS code and many other assets into a few small bundle files that our users can download when they first load our webpage. For example,
create-react-appuses Webpack and Babel when creating your app.
