Yeoman and Brunch

[ButuzGOL]

What the difference between Yeoman and Brunch ?

[paulmillr]

This is my subjective opinion from the position of web application developer.

Updated at November 24

Pros of yeoman:

• Bower package manager support (coming in brunch 1.5)
• Auto-reload out-of-box (can be added with brunch plugin). I do not add this by default because yeoman does not allow using different server with yeoman server command, unlike brunch. Brunch autoreload works with any custom server. Been thinking on the problem for a while, still I hadn’t got any great solution. Same with png / jpg optimizer, there is a plugin for this.

Conceptual differences:

• By default, yeoman does not concatenate files to one / two / whatever you set. While this is better for debugging, it is better only until source maps support is shipped (just later this year, uglifyjs v2, coffeescript v2). As a result, yeoman requires manual adding of the new scripts to index.html every time. Quite annoying to me. Brunch has automatic ordering and usually all you need is just add file to vendor/ directory (ies). Moreover, is there any way in yeoman to make file.coffee be compiled before file.js and after something.js? Didn’t found the functionality. Brunch simply does not care about language you use, you can set concatenation order however you like, if compilation is supported.
• Scaffolding is much more complicated. While generators are more powerful, it’s not something I’d want to create often. You can’t change generated file paths (brunch g --path). As a contrast, in Brunch, you can make generator by simply executing brunch g generator stuff or just by adding simple json file and pointing it at which files to copy. It can even call other generators, like yeoman. And the most important, brunch generators are local to your application, because every app needs slightly different scaffolding that is simple-to-change.
• Generators in yeoman also seem to have functionality of brunch skeletons. I don’t think this is a good idea, because you use skeletons only once, at the start of the project.
• Ugly & extremely verbose configuration files (gruntfiles). Compare: brunch config & yeoman config
• Libraries (not all) that are shipped with default apps are minified. This is a bad decision because it affects debugging very much and in production environments, you’re already minifying stuff.
• Default application is quite small, unlike brunch with chaplin skeleton. The reason brunch with chaplin is default is that it allows to build any sized webapps simply (simple != easy, remember), but you need to know backbone + chaplin. Which does not seem to be hard task, considering there are great example apps (http://ost.io, tweet your brunch) and that my team learnt brunch with chaplin + coffeescript + handlebars + less stack after only Django / Python experience in something like two days.
• Speed seems to be slower too, my usual workflow is: change a file, instantly alt-tab to browser (brunch instantly [<500ms usually] compiles stuff), play with web inspector. I can’t do this with yeoman because for example compass files are compiled quite slowly.
• As for skeletons, yeoman has simple yeoman init ember instead of brunch n -s <url of ember skeleton>. Not bad idea. This of course couples some skeletons with yeoman (you need to maintain angular yeoman skel, ember yeoman skel) which is something I can’t do because I don’t use these frameworks (the best products are made by folks who use them).
• Seems that there are no CommonJS / custom modules support, only AMD.
• No notifications (OS X 10.8 Notification Center, Growl, libnotify).

Developing the “free market” topic, I believe existence of Yeoman is a potentially good thing, because it brings competition to the board. Yeoman will become better, brunch will become better.

[ghost]

Shouldn't you add also the language used in the conceptual difference? (Coffee vs js)

I wonder, if yeoman was in coffee, would they have used brunch instead of grunt?

[paulmillr]

I don’t think user really cares in which language his tool is written unless he contributes to it.

After all, both brunch and yeoman support compiling both coffeescripts and javascripts etc. Nothing stops yeoman from using brunch as a backend instead of yeoman (brunch is compiled to js, after all), but I think they’ve picked Grunt instead because of its ecosystem.

But from the view of contributor to both projects, the big coding difference between projects:

• yeoman (OOP) prefers shared mutable state with Grunt which makes stuff easier for folks not familiar with functional programming
• brunch (FP) prefers (not forces) pure functions and immutable structures which reduces bug count and makes code simpler etc. And it is written in coffee because it makes functional programming easier. Well, and because I love cleaner languages.

[eriwen]

I can't predict what Brunch will look like with Bower, but along those same lines perhaps it is feasible to have some CLI sugar for adding brunch plugins. Something like: "brunch install livereload" = "npm install livereload-brunch --save"?

[paulmillr]

@eriwen good idea!

[KyleAMathews]

The only thing I see in Yeoman I'd like is an automated appcache manifest generator.

[paulmillr]

@KyleAMathews you mean like appcache-brunch?

[KyleAMathews]

No -- it looks like they're using confess.js to do the actual manifest generation - yeoman/yeoman#21

[paulmillr]

cool idea.

[andriijas]

Brunch is far more mature because it existed longer. I predict yeoman will fight some of the issues brunch already solves.

[ghost]

yes true. Brunch is more mature. I tried yeoman, and while it has some fancy things, I don't like how it interferes with the workflow. With brunch, I just create my app under client and point express's public dirs to the brunch dir.

Besides, yeoman is based on grunt and js... I'm a coffeescript user and it made a difference to see js instead of cs in the code.

[ecgan]

tUrG0n, yeoman is an opinionated workflow. It's either we love it, or not.

[ghost]

that's too simple. I don't believe you can generalize this easily. Each has its pros and cons.
Depending on the what tradeof you accept, you pick the workflow.

[vbfischer]

Curious what the status is of bower support. Mentioned as going to be part of 1.5. I see there's a package here: https://github.com/brian-c/bower-brunch but before attempting to use wanted to find out if there was an "officially" supported one

[paulmillr]

no bower support, it still does not support stuff for build tools

[vbfischer]

gotcha. Thanks for very quick reply btw. Trying to use it manually, and attempting to grok the regex in the joinTo part of config.coffee to filter out (or just include) the *.min.js files... But that's a question for a different forum :-)

[davidchambers]

@KyleAMathews:

The only thing I see in Yeoman I'd like is an automated appcache manifest generator.

Take another look at brunch/appcache-brunch. It now generates the cache manifest based on the contents of the public directory, and includes a hash in a comment that will invalidate the manifest if—and only if—something changes.

[KyleAMathews]

Been using it on a project for awhile :) It works great. Thanks for the
pointer!

Kyle Mathews

Blog: kyle.mathews2000.com/blog
Twitter: http://twitter.com/kylemathews

On Sat, Jul 13, 2013 at 1:23 PM, David Chambers notifications@github.comwrote:

@KyleAMathews https://github.com/KyleAMathews:

The only thing I see in Yeoman I'd like is an automated appcache manifest
generator.

Take another look at brunch/appcache-brunchhttps://github.com/brunch/appcache-brunch.
It now generates the cache manifest based on the contents of the public
directory, and includes a hash in a comment that will invalidate the
manifest if—and only if—something changes.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/408#issuecomment-20926105
.