example config of asset bundler that process LESS files, concats, and mi...

[withjam]

...nifies js and css

[paxtonhare]

Matt,

I think we would rather see this done with gulp than with middleware.

[grtjn]

The scripts gulp task does that partially for JavaScript already. It is more generic than this code, as it doesn't hard code the js file names. Not sure why it is excluding bower_components and vendor folders, but that could be changed easily.

Gulp also watches for file changes, so you don't need to restart the node server if you added a new js file. I vote for a more dynamic solution.

[grtjn]

Matt, Paxton, maybe we should discuss this a bit further. The gulp task is generating an all.js, but it is not as intelligent as it maybe should be. I started thinking about concatenating bower_components for instance, and I am not sure that can be automated that easily. The all.js is good for all custom js work, but might not work so well for bower_components and vendor stuff..

[withjam]

The benefit of middleware is not having to watch or restart anything. It
generates the bundle on-demand at request time. Configuration options per
environment allow you to determine if it will cache, minify, run other
tools, etc. So, for instance, in dev it will regenerate the bundle asset
each request whenever a file has changed since the last request, but in
prod it will generate the bundle only on the first request and serve the
cached file from then on.

I had chosen to specify files in order to support the ability to configure
them also per environment in assets.json, but I didn't get that far. This
could also glob by file pattern as an alternative.

The choice of middleware or watch task really just comes down to
preference. I prefer middleware because node handles it and I never have to
worry about serving an old file during dev (I almost always have to refresh
twice per change when using a watcher, but again that's just my style)
Watching files allows gulp to generate the files as part of a build step
which seems to fit into the CI process better. So I'm fine with the
decision to keep it in gulp, just wanted to point out the differences.

As far as bower components goes I think the best approach is to keep them
in a separate bundle. This is for two reasons: 1: putting everything in
one bundle makes a very large file which the browser must download all at
once, splitting the files up a bit allow the browser to download in
parallel which is faster. 2: we will most likely change our source bundle
many times without any updates to dependencies, so we only need to
invalidate the browsers cache for our bundle - it doesn't have to
re-download the entire bower components bundle. #2 is less of a concern for
internal demos but an old habit of mine to worry about optimization. It
makes a bigger difference on mobile devices also which have more limited
space and bandwidth.
On Nov 14, 2014 1:45 AM, "Geert" [email protected] wrote:

The scripts gulp task does that partially for JavaScript already. It is
more generic than this code, as it doesn't hard code the js file names. Not
sure why it is excluding bower_components and vendor folders, but that
could be changed easily.

Gulp also watches for file changes, so you don't need to restart the node
server if you added a new js file. I vote for a more dynamic solution.

—
Reply to this email directly or view it on GitHub
#50 (comment)
.

[grtjn]

Excellent feedback. Discuss this offline with the three of us to make up our minds and decide?