Hello once again to Readers’ Questions, presented by the folks at The Ember Times 
with a little help from the Ember Core Team and Friends 
Today I’ll be answering a question by Ilya:
Why does Ember use Broccoli and how is it different from Webpack, Rollup, Parcel?
Tools which are often used for packaging JavaScript applications like Webpack, Broccoli, Rollup and Parcel differ in many aspects. Let’s take a look at some of the most striking ones:
Bundlers versus Asset Pipelines
Probably the most essential difference between Broccoli on the one hand and Webpack, Rollup and Parcel on the other is their use case. Webpack, Rollup and Parcel can be seen as bundlers - utils that help their users to concatenate assets together and allow for optional transforms like ES6 transpilation or CSS processing via plugins - whereas Broccoli can be described as an asset pipeline.
In contrast to asset bundlers, an asset pipeline like Broccoli is by default agnostic about the type of files and transforms that are managed in a particular build. Since Broccoli provides a functional programming API that allows users to chain different code transforms through plugins, any kind of build steps can be embedded into its pipeline. This also means that Broccoli can even leverage bundler libraries like Webpack or Rollup themselves as transforms.
This means that Broccoli can also be used for file transformations which go beyond the common use case of packaging JavaScript applications. Bundlers like Webpack or Parcel are more specialized and developed for bundling JavaScript projects in particular.
Differences in Developer Experience
Tools that are often used for JavaScript packaging vary in regards to their developer experience: The functionalities of asset bundler libraries like Webpack or Rollup can be extended further to apply additional code transforms via modules, plugins or loaders that need to be installed additionally. Parcel allows zero-config builds, inclduding asset bundling, code splitting and transpilation via Babel. It leverages a default build configuration (which of course can still be extended beyond the default settings) and makes the use of a separate configuration file for your first build obsolete (1).
In contrast to Rollup, Webpack and Parcel, Broccoli is an asset pipeline and can be configured through an imperative API. This allows users to chain build steps and integrate all kinds of transforms, like transpilation or CSS postprocessing (2) thanks to a pretty extensive plugin ecosystem.
Differences in Performance
Tools used for bundling or building JavaScript apps also differ in their performance metrics. e.g. in the amount of time needed to build and re-build a certain project. According to the ParcelJS documentation and other benchmarking tests Rollup might be one of the fastest bundlers as of date (3).
It makes a lot of sense to take these metrics with a grain of salt though: Build times can vary significantly depending on the size and structure of the application built, the transforms used in the pipeline, the system specifications of the machine the test is run on and which kind of caching strategies were leveraged. This means that if you try to take performance into consideration when deciding for one tool over another, it makes sense to run your own benchmarks and see how it works for your project first!
Why does Ember use Broccoli?
To some part historic reasons play into the adoption of Broccoli: As early as with the 1.11 release of Ember, Ember CLI has been adopted as the build and scaffolding tool for creating Ember apps. What was back in early 2015 still a rather novel workflow for developing JavaScript applications, turned out to be one of the biggest strengths of Ember as a framework and similar approaches have been adopted in many other JavaScript communities since then.
Broccoli used to be one of the few asset pipeline solutions around back in the day when the Ember community decided to adopt Ember CLI as an integral part of the ecosystem. It has since then proven to be extremely useful to let developers develop their Ember apps with ease. Since Broccoli as an asset pipeline is extremely flexible, it is possible to swap in the best tools and transforms available anytime without forcing end users to rethink their build system.
Which Bundling Solutions Are Used in Other JavaScript Eco Systems
As of date a variety of bundling solutions is leveraged in different JavaScript ecosystems; whereas command line solutions like Angular CLI, Aurelia CLI or Create React App are making use of Webpack for scaffolding projects, utils in the Ember ecosystem like ember-cli-cjs-transform or Ember CLI are utilizing Rollup.js or Broccoli respectively.
In the past the question on using Webpack instead of Broccoli in the build process for Ember apps has been raised. One of the main arguments has been that it was not possible to provide features like code splitting, tree shaking and improved bundling strategies through today’s build pipeline (4). However, the upcoming 2018 Roadmap for Ember CLI aims to tackle exactly these issues to bring the functionality of Ember CLI fully on par with the feature set of other build tools (5).
Further Reading
Be sure to check out this excellent talk at EmberConf 2014 by Broccoli creator @joliss introducing the concept and motivation of using Broccoli’s pipeline strategies in Ember CLI. You can also read up more about the original architecture of Broccoli in this stellar blog post.
If you want to learn how to create your own build pipeline with Broccoli, then @oligriffiths’ amazing Broccoli tutorial is a must-read for you.
If you want to learn more about how the Broccoli build in Ember CLI works exactly, then be sure to watch @brzpegasus talk “Dissecting an Ember CLI Build” which gives an outstanding introduction into its feature set and setup.
Sources
- 1: Qualitative Comparison between Rollup, Parcel and Webpack
- 2: Broccoli.js Tutorial by Oli Griffiths
- 3: Performance Comparison between Rollup, Parcel and Webpack
- 4: RFC for Improved Learning Story in Regards To Ember CLI
- 5: Ember CLI 2018 Roadmap
This answer was published in Issue #62 of The Ember Times. Don’t forget to subscribe to the newsletter to get new Readers’ Questions and other development news right to your inbox. You can also submit your own questions! You will find a link at the bottom of the newsletter.
See you in the next issue! 
