search

linemanjs / lineman

Lineman helps you build fat-client JavaScript apps. It produces happiness by building assets, mocking servers, running specs on every file change
MIT License
1.18k stars 83 forks source link

lineman vs gulp for ember projects - why lineman? #312

Closed eibrahim closed 9 years ago

eibrahim commented 9 years ago

I know it will be tough getting an objective opinion here :) but you did good comparing it to ember-cli at https://github.com/linemanjs/lineman/issues/250 so I thought I would ask anyway.

Why should I use linemanjs over ember? I did my last project in lineman and switching to gulp for this one. It took a little bit to setup but it was pretty easy and seems a lot faster. I was also able to do sass compilation without compass which is great because I didn't want to install ruby on all my machines just for that. With that said, lineman feels more solid but it also feels slower with compilation and seems harder to configure... what are your thoughts?

davemo commented 9 years ago

have you tried lineman since we fixed the performance regression with the watch task? it's a lot faster; @searls also just added support for being able to use grunt-contrib-watch in 0.34.0: https://github.com/linemanjs/lineman/releases/tag/0.34.0

Also, lineman vs ember isn't really the right comparison IMHO, as lineman is a meta productivity wrapper around grunt that is MV* framework agnostic, and ember is a client-side MV* framework (or am I misunderstanding your question?).

Lastly, you can use node-sass (which uses libsass) and drop the ruby requirement when using lineman.

eibrahim commented 9 years ago

That was a typo. I meant to say lineman over gulp.

searls commented 9 years ago

Two major points:

1

Using Grunt for a multi-task workflow is slow, at least relative to Gulp, because Gulp doesn't necessitate writing files out in an intermediate state. This isn't life-and-death awful, given that full builds are infrequent and a single asset type usually only goes through 2 or 3 transforms in development (e.g. Coffee -> JS, JS -> concatenated). It's a valid point, especially on very large projects, but there's been a lot of FUD spread, too.

2

A downside of Gulp (and vanilla Grunt), and even (to a lesser extent) Broccoli, is that each requires your project to encode what an application is by specifying where sources are, what tasks must run, where those artifacts go, etc. This doesn't feel like more than a minor nuisance at the beginning of your first project, but on your second, fourth, eighth, it becomes unwieldy—and it adds a lot of unnecessary complexity The reason we built Lineman was to get that common stuff out of each individual projects and into one central place to store the defaults & establish conventions. Lineman isn't the only project that tries to do this (Brunch, Mimosa, ember-cli, etc. do as well)