There are two constants involved in JS that come to mind when preparing code for release: Webpack and Babel. These two technologies are responsible for modern JS projects properly being served. Despite how influential, familiarity and understanding aren’t widespread. Most just getting into the space see these two names thrown around a lot, but it takes a minute to get a full grasp of what they are. It’s completely understandable.
When most get introduced into web development, the typical path they are put on only involves the language level. Very seldom will you find most engineers be steered toward a level or two down to inspect how the files are prepared for them. They are a big deal and require fundamental and expert knowledge around to get the most out of what we build at high levels.
Each is different though, and today we’re going to do a bit of comparison to help your fundamental knowledge.
What Is Babel
Getting things rolling, we’ll begin looking into Babel. In the shortest of words, Babel is used for converting modern JS into a backward compatible file(s). Using a more current example, let’s take a look at React. Assuming you’re like most using React’s JSX syntax instead of React.reateElement, then you are already using this concept. The browser doesn’t understand what a JSX file is, and as far as I know, there aren’t any plans for that to be implemented in the near future.
So with Babel, those JSX files are compiled down from JSX file(s) into a browser digestible JS file. That’s the power of Babel, and a look under the hood of a technology you’re already familiar with. While this was a great example, it’s not 100% accurate. While the correlation to Create React App was a great way to explain compiling in JS, Babel isn’t actually the tool that does it. That would be Webpack.
What Is Webpack
In comparison, Webpack is a bit more complex. I say that because Webpack does cover the same ground that Babel does, while also doing much more. In more correct terms, it takes it further. It’s best described as a module bundler, that begins from a single entry point. From that entry, a dependency graph is formed based on how files or modules are included in the application.
Think of your main file, probably named App.js. At some point, everything you build in your application must be linked somehow to this file to be included. Dependencies(npm package) and your own JS files alike, all have to point here in some way. That is because Webpack works by starting at the entry point specified, and then looks deeper and deeper into every import found there and what is imported into those files as well.
How To Choose
Both are great technologies and serve a valuable purpose. They solve similar things in a similar fashion, but one is more complex. So deciding can be daunting. Mostly, I view it like this. For simple projects where I’m not using any supersets and just want to use the latest JS features available then I’ll lean over to Babel. In other cases, which is most of the projects I work on, where I’m using a superset like Typescript and have a more complex structure overall, then Webpack is the clear answer.
In Closing
This was a great introduction to both technologies for seeing what they both offer, and how powerful they both are. Knowing what happens under the hood is important because that allows you to build the best applications possible. So take this as an introduction if you’re unfamiliar, or a refresher if you’re venturing deeper for the first time. I’ll be writing more about them, and other things similar in the near future, but this primer will get you in a position where you’ll be able to grasp the deeper information coming from me or you’re exploring on your own!