Joined May 2013



Posted to Managing assets in ASPAX vs Grunt over 1 year ago

@icflorescu in my project I have divided tasks between grunt and "asset tool" for example like this:


  - lib/swiper/idangerous.swiper-2.3.js
  - lib/moment/moment.js
  - lib/moment/lang/ro.js
  - lib/jquery.unveil.js
  - scripts/public/index.js

  - lib/underscore.string.js
  - lib/jquery.ui.core.js
  - lib/jquery.ui.widget.js
  - lib/jquery.ui.mouse.js
  - lib/jquery.ui.sortable.js
  - lib/jquery.iframe-transport.js
  - lib/jquery.fileupload.js
  - lib/jquery.autosize.js
  - scripts/admin/admin.js
  - lib/jade-runtime.js
  - templates/templates.js

  - lib/icomoon/style.css
  - lib/swiper/idangerous.swiper.css
  - styles/index.css

  - styles/admin.css

  - styles/product-print.css

images/logo.png                     | fp : images/logo.png
images/logo@2x.png                  | fp : images/logo@2x.png
images/carbon-texture.png           | fp : images/carbon-texture.png
images/carbon-texture@2x.png        | fp : images/carbon-texture@2x.png
images/carbon-texture-light.png     | fp : images/carbon-texture-light.png
images/carbon-texture-light@2x.png  | fp : images/carbon-texture-light@2x.png
images/barcode.png                  | fp : images/barcode.png
images/barcode@2x.png               | fp : images/barcode@2x.png
images/breadcrumbs-separator.png    | fp : images/breadcrumbs-separator.png
images/breadcrumbs-separator@2x.png | fp : images/breadcrumbs-separator@2x.png
images/spinner-140x105.gif          | fp : images/spinner-140x105.gif

favicon.png                              : icons/favicon.png
apple-touch-icon-57x57-precomposed.png   : icons/apple-touch-icon-57x57-precomposed.png
apple-touch-icon-72x72-precomposed.png   : icons/apple-touch-icon-72x72-precomposed.png
apple-touch-icon-114x114-precomposed.png : icons/apple-touch-icon-114x114-precomposed.png
apple-touch-icon-144x144-precomposed.png : icons/apple-touch-icon-144x144-precomposed.png

fonts/im.eot  | fp : lib/icomoon/fonts/icomoon.eot
fonts/im.svg  | fp : lib/icomoon/fonts/icomoon.svg
fonts/im.ttf  | fp : lib/icomoon/fonts/icomoon.ttf
fonts/im.woff | fp : lib/icomoon/fontsfonts/icomoon.woff

module.exports = (grunt)->
  'use strict'

  _ = grunt.util._
  path = require 'path'


    pkg: grunt.file.readJSON('package.json')

        src: ''
        src: ['scripts/**/*.coffee']
      options: grunt.file.readJSON('../coffeelint.json')

        sourceMap: true
        join: true
        src: [
        dest: 'scripts/public/index.js'
        src: [
        dest: 'scripts/admin/admin.js'

        compile: true
        src: ['styles/index.less']
        dest: 'styles/index.css'
        src: ['styles/admin.less']
        dest: 'styles/admin.css'
        src: ['styles/product-print.less']
        dest: 'styles/product-print.css'

        client: true
        src: ["templates/*.jade"]
        dest: "templates/templates.js"

        atBegin: true
        files: 'scripts/**/*.coffee'
        tasks: ['coffeelint:application', 'coffee']
        files: 'templates/*.jade'
        tasks: ['jade:templates']
        files: 'styles/*.less'
        tasks: ['recess']

  grunt.loadNpmTasks 'grunt-coffeelint'
  grunt.loadNpmTasks 'grunt-contrib-coffee'
  grunt.loadNpmTasks 'grunt-contrib-clean'
  grunt.loadNpmTasks 'grunt-contrib-watch'
  grunt.loadNpmTasks 'grunt-contrib-jade'
  grunt.loadNpmTasks 'grunt-recess'

  # tasks.
  grunt.registerTask 'compile', [

  grunt.registerTask 'default', [

It gave me the full power of Grunt for compiling stage (coffee, less, jade etc). And simple and predictable syntax to prepare assets for "client usage".

Posted to Managing assets in ASPAX vs Grunt over 1 year ago

My opinion is:

  1. Grunt configuration syntax is suitable when you need to perform one action for all files. For example: compile all coffee files (src/*.coffee) or lint all js files
  2. Aspax configuration syntax is suitable when you need to perform multiple different actions for single file or group of concatenated files. For example: concatinate js files, minify result, copy result for aplication and just minify and copy for libraries

The ecosystem is much more dynamic than Ruby/RoR, things are changing really fast,
Personally, I'd rather keep ASPAX codebase as simple as possible and choose to focus on plugin development. So, if you have an idea...

Yes, NodeJS community likes simple and small modules for solving only one problem (like unix=). In this case comparison with Sprockets was inappropriate.

@icflorescu @jonahoffline I hope that we can make a great tool like Asset Pipeline!

Hi @icflorescu,

I have created issue for each question/remark
I think it will be more convenient than discuss all together.

Thanks for the ASPAX, it's great!

I have exactly the same basic ideas: five or six other libraries surely knows what I'm talking about. And not all of them are suitable for CommonJS/Component usage style.

Even if they support the package system, it is not useful if for example you need a custom build of bootstrap (CSS and JS).

excellent Asset Pipeline


A complex asset management Gruntfile.js is a bit cumbersome and runs the risk of becoming difficult to maintain for medium-to-large projects.

Yes, build phase should be separated from asset management phase.

I think ASPAX should do:

For small projects:

  1. watch and compile only by plugins (build phase)
  2. concatenate, minify and fingerprint
  3. copy file to assets directory

For medium-to-large projects:

  1. only watch changes
  2. concatenate, minify and fingerprint
  3. copy file to assets directory

For large projects, it makes sense to divide build to compile phase and asset management phase. Complex assets can be compiled by well known tools like Grunt or Make (not 300 lines of code but 100). And complex asset management phase can be done by ASPAX.

But I also have a few questions and remarks:

  1. I find it more appropriate to use hash like fingerprint. To avoid unnecessary "cache busting" for identical files. example
  2. Executing not JavaScript files are not best practice (Iced Coffee in this case). And it is deprecated
  3. File compression is a task for static server. In case of express it is compress middleware. It compresses according to http headers, not for all requets.

I think that I can close my similar project and join to ASPAX development.

171 Karma
6,679 Total ProTip Views