Broccoli or Webpack


#1

I was happy, that Angular project chosen Broccoli, based on Ember CLI for the Angular CLI project. However, as I see, they are migrating to Webpack (https://github.com/angular/angular-cli#webpack-preview-release-update), instead of keeping Broccoli, which is definitely one of the fastest solution.

I’m just wondering, anyone knows what’s the reason behind that decision to migrating to Webpack?

Is there any plan to make Ember CLI more standard, popular, open builder tool, a kind of general Frontend CLI tool?


#2

I think that’s Broccoli. You can easily use Broccoli to build out a pipeline that fits any need. If you need a CLI tool to pair with that, just use make.

It’s interesting to see that they are making this kind of move. I don’t believe web pack brings more to the table overall. It does looks like it does more out of the box and require few plugins for the most common tasks.


#3

From what a friend told me, the benefit to webpack is that it allows for code to be rebuilt and swapped out in place so you dont loose your UI state. Lets say you need to work on a feature that is several UI steps deep, and every reload resets the UI. Supposedly webpack will swap out the relevant code changes on the fly without resetting state.


#4

With webpack you can import everything straight from npm. I see that as a big benefit. Last time I checked, with ember-cli you need to add app.import line to ember-cli-build.js which exposes globals.


#5

Not quite the same, but you can use ember-browserify to import NPM modules.


#6

The confusion here is because webpack and broccoli are completely different things.

Broccoli is a tree builder, and that might not even be the right phrase to use. It’s basically virtual-dom for the file system. It’s not an asset bundler, nor a build pipeline. Ember-cli is a build pipeline that uses broccoli to assemble the things it needs to operate on. As one step of this build, it might use rollup or webpack or something else to operate on assets.

Webpack is an asset bundler that confuses itself for a build pipeline. It happens to do a couple of things well, but it’s been a huge failure in larger projects. Angular-cli chose to move to it for poor reasons that they aren’t even sure of. I’m also not surprised, ember-cli has an amazing plan for bundling in the works, but angular-cli probably jumped the gun here for a nearsighted win because despite forking ember-cli they showed little interest in being part of the community and angular2 launch was approaching.

Last time I checked, with ember-cli you need to add app.import line to ember-cli-build.js which exposes globals.

This does not expose a global, it merely adds it into your pipeline. If the module it’s importing is a global, then yes, it will add a global, but your use of it should still be to use import.