8 comments

[ 4.5 ms ] story [ 34.1 ms ] thread
(comment deleted)
Author here. This is my first attempt at open sourcing code!

Some background: I work at Pollen Digital in Sydney, Australia. We regularly get web-based projects to develop and release. My manager encouraged me to package up my workflow and send it out into the world. So here it is.

The workflow created by this generator utilises the following tools:

Grunt as the task runner

Bower as the package manager for web libraries/frameworks

Jade

CoffeeScript

LESS

I also wrote a little utility that amends css/js/image references in Jade and LESS files with their corresponding md5 checksums (first 8 characters to be specific) as a means for cache busting. This is included in gruntutils/index.coffee under the generated project's root.

I've not used Yeoman before, but we use mimosa http://mimosajs.com to do our front end building pipeline.

What are your opinions on something like mimosa?

Bower and Grunt seem interesting, I'll go look into them.

Hi Torn,

I have not used Mimosa before but it looks quite nice! I have not spent much time with it beyond going through the steps of setting up a new project.

Grunt won't be very interesting if Mimosa is meeting your immediate needs well. The only thing I can say like about it (at this stage) over Mimosa is that you start with nothing under Grunt and build your workflow from scratch. It doesn't pre-install coffeescript/livescript/typescript compilers and so on as its own dependencies - you install their corresponding grunt tasks (e.g. grunt-contrib-coffee) when you decide you need them.

Bower is great to have in a project to manage your front-end package dependencies if you don't already have something similar in your dev environment.

Starting with nothing and building everything from scratch is the opposite of what Mimosa is trying to do for you. The idea with Mimosa is you are coding straight away rather than hunting down plugins/modules, or finding generators ;), and then figuring out how to configure them. All those compilers are available, but if you don't need, for instance, TypeScript compiling, then the TypeScript stuff stays out of the way. No harm having those extra things.

Mimosa lacks Bower integration, though. Bower integration is nice for managing those sorts of things.

I agree with what you say.

If I failed to do so already, please allow me to state that yeoman and its generators (including my generator) as well as Mimosa may very well be an "expression of opinion" of various developers. The opinion is regarding what makes a productive workflow. This will certainly change over time or, at least, on a project-by-project basis.

In a different comment I made on this submission, I mention that if you are a developer that has worked with Jade, CoffeeScript and LESS - and enjoyed doing so - then my generator may make the process of getting up and running with them a bit faster for your next project.

What makes this different from the default yeoman webapp generator?
If you like the combination of Jade + CoffeeScript + LESS, then I submit my generator for your consideration (and I would appreciate any insights you may have on its shortcomings or possible improvements). My generator is slightly more barebones than webapp:app. I don't include LiveReload, connect or require.js initially:

- I did not need LiveReload or connect because I use a combination of `grunt watch` and `http-server -c-1`[1] during development with no issues.

- require.js has not been an immediate requirement for me across a lot of projects, so I decided to defer the decision to the developer and go with a minimal setup.

The inbuilt webapp generator makes no decisions on which template language to use (some may prefer this over starting with Jade). It also decides to go with SASS/Compass instead of LESS. This is also fine except that it means I now need to have ruby and compass installed which I wanted to avoid[2].

The way I approach asset revving is a bit different in that I pass the developer a function to use in their Jade templates to refer to assets (images/css/etc...). It will resolve the path to an asset and form the url with a revision appended as a request parameter during template compilation (not after). It is kind of similar to the way django_compressor does its job if you are familiar with it (that was my primary inspiration).

Finally, I intend to improve the Gruntfile further by defining concurrent tasks, adding a clean task and so on.

[1] https://github.com/nodeapps/http-server

[2] I've written both SCSS and LESS and enjoyed both. Going with LESS really came down to reducing time till first page preview.