No more `grunt watch` – faster builds with the Broccoli asset pipeline
1–10 of 59 posts
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#2Having used literally ever alternative, Broccoli has been a joy to use so far, can wait to port all my projects to it.
It manages complexity really well. I have thrown many known failure scenarios at it, and it handled them all without a hitch.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#3Not often I see tools announced with such a thoroughly researched article. Great stuff!
I guess the problem these build tools are facing is the amount that people have invested in Grunt. There are just /so/ many grunt tasks at this point.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#4Not sure what the pros are against Brunch. The author states:
> Brunch also tries to do partial rebuilding rather than caching; see section “Caching, Not Partial Rebuilding”
But the end of that section seems to imply that it's still something that needs to be implemented per-plugin:
> Plugins that map files n:1, like Sass, need to be more careful about invalidating their caches, so they need to provide custom caching logic.
I'm excited to see what comes of it, but still prefer the idea of simply running `npm install (sass|jade|less|stylus|coffee-script)-brunch --save`
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#5Not often I see tools announced with such a thoroughly researched article. Great stuff! I guess the problem these build tools are facing is the amount that people have invested in Grunt. There are just /so/ many grunt tasks at this point.
Yep- a search on npmjs shows not quite a dozen tasks for Broccoli while Grunt has hundreds of results. Not that quantity necessarily == quality but when it comes to a task runner, I need to, you know, run tasks.
Definitely awesome that people are trying to optimize in the devops space but just not sure I could be convinced to switch to something that isn't at least somewhat mature.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#6Having used literally ever alternative, Broccoli has been a joy to use so far, can wait to port all my projects to it. It manages complexity really well. I have thrown many known failure scenarios at it, and it handled them all without a hitch.
I was about to move over to Gulp. Can you let me know why you prefer Broccoli over Gulp?
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#7Having used literally ever alternative, Broccoli has been a joy to use so far, can wait to port all my projects to it. It manages complexity really well. I have thrown many known failure scenarios at it, and it handled them all without a hitch.
I was about to move over to Gulp. Can you let me know why you prefer Broccoli over Gulp?
I also wonder how it compares to Gulp (mainly in terms of performance in practice). I've just started to use Gulp, migrating away from Sprockets and so far it has been a joy.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#8I want to note that this headline is a wonderfully hilarious if read without js-programmer context.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#9Not often I see tools announced with such a thoroughly researched article. Great stuff! I guess the problem these build tools are facing is the amount that people have invested in Grunt. There are just /so/ many grunt tasks at this point.
Agreed, Grunt has served me well, much like Bootstrap up to v2.3.2 has, so am in no rush to go looking for the hat on my head.
Hands full server-side anyway, client-side moves way too quickly to keep pace with the latest and greatest...
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#10Having used literally ever alternative, Broccoli has been a joy to use so far, can wait to port all my projects to it. It manages complexity really well. I have thrown many known failure scenarios at it, and it handled them all without a hitch.
As the author mentions, the real insight seems to be to switch from the file-based unit to the tree-based unit. This means asset building can be made more intelligent.
Now, I wonder if the same approach can be taken in gulp using vinyl-fs? Otherwise, I wonder if it might be worth plugging this tool as a specialized asset pipeline into existing grunt/gulp files.