Documentation doesn't mention non-watch incremental build

[rosenfeld]

I'm currently evaluating replacing the Rails Asset Pipeline with a better resources build system and took some quick experiments with webpack to have an idea on how the new tool would work for us.

Since moving from Sprockets to another tool will require a lot of time, I'm taking some time to investigate alternative build systems and Brunch is one of them. I've read the comparison with Grunt and Gulp but it doesn't mention webpack which seems to have the same abilities as Brunch from what is stated in that document.

Something I don't like in Webpack, and the reason I'm still researching for other alternatives, is that I'm interested in faster deploy times, which means I'm interested in incremental builds, not just for watch mode. Webpack doesn't support persistent caching so it only builds incrementally in watch mode.

I was curious to understand how caching works in Brunch for non watch mode. Is it the same as webpack?

Sprockets has several disadvantages when compared to webpack, but at least it does support incremental builds by allowing the compile steps caching to be stored in disk or in a Redis store.

There are other features supported by webpack which are essential to my application and I don't know whether they are supported in Brunch:

• able to extract common modules in a separate bundle for libraries that don't often change so that user's caching wouldn't be completely invalidated on each deploy by using a single minified JS;
• able to extract the required CSS rules for the initial load in CSS files I can load from the main page;
• able to load the bundled scripts async so that do not block the initial "loading..." state for the initial page;
• able to transparently download any missing bundles as they are needed. This is very important to reduce the load time for the application so that it could load the minimal amount of code to render the initial page and once the user starts interacting (or we could start loading the remaining of the application after the initial rendered is finished) the remaining of the code would be downloaded and loaded as well as any associated stylesheet rule;
• able to load additional CSS from downloaded JS bundles dynamically by adding it to style tags (or link tags with encoded rules) and at the same time support IE8 by bundling all rules in a single style element to not risk creating too many style elements;
• support for sync and async requires;
• support for source maps and minifying resources;

I was able to get all of this working on webpack through some custom plugins and loaders but the deploy time will still take several seconds because it doesn't support incremental build in non-watch mode.

Also, it would be awesome if I was able to specify some dynamic rules in the watch mode so that my test runner would be able to detect new test files and build their bundled with dependencies and possibly run each test file in an isolated iframe. I couldn't set this with webpack yet.

[es128]

Brunch also only supports incremental building while watching. Every invocation of brunch build is a full rebuild.

[rosenfeld]

Okay, thanks for letting me know!

[rosenfeld]

What about dynamic files watching in watch mode as entry points?

[es128]

Honestly I'm not totally sure what that even means, but probably not. Brunch is a build system, which is why it's more apt to compare to grunt and gulp. Webpack is first a module loading strategy (compare with browserify) and has grown into a full-blown build system as well, albeit much more opinionated than Brunch at least in terms of module structure with its overloaded require processing and such. The closest thing Brunch provides to the concept of entry points is the autoRequire option, but it does not go from there and resolve via your require statements everything else that needs to be built. You need to specify in the config how you want your source files built and concatenated.

[rosenfeld]

Ah, got, so it isn't really an option I would consider. The Rails Assets Pipeline (sprockets) declares the dependencies on each file much like in most programming languages supporting import/require without returning values, which was great when I started working with web apps because it was an easy way to organize the modules dependencies. Grails takes a different approach, which is more similar to Brunch's approach if I understood it correctly, by specifying the dependencies as configurations, which I find a bit fragile when compared to specifying directly in the files.

Sprockets use some magical comments in the files header to specify the dependencies but the dependencies will have to export directly to window so that they could be used, while it's possible to keep things more isolated with the require mechanism in Webpack.

But the main advantage of Webpack over Sprockets (besides source maps support) is that it's easy to set up which code should be loaded on demand, which is almost impossible to set up with Sprockets in a sane way. From the performance data I have been collecting in the last months the size of the resources is the main reason for the slow initial loading time some users experience (about 10% will take over 5s to load a 1MB minified JS file (~200KB gzipped)).

But thanks for clarifying what is the category of Brunch! This is very helpful!

Cheers!