Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No more `grunt watch` – faster builds with the Broccoli asset pipeline

solitr.com

Post reply on HN
Print view View original

11–20 of 59 posts

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#11

Post by munificent »

This is slightly related and I don't want to sound like I'm trying steal its thunder, because this looks really cool. I work on the asset pipeline that comes with the Dart SDK. It has many of the same principles as these.

Any transformation step can read in many input files and produce many output files. The built-in dev server tracks the entire asset dependency graph and only rebuilds the assets that are dirtied by a source file changing.

We have a plug-in system, and it's built on top of the same package management system that the SDK uses, so you can get transformer plug-ins as easily as you can get any other dependency.

We still have a lot of work to do to fully flesh things out, but it already does a lot, including supporting complex scenarios like transformers whose own code is the output of a previous transformer.

More here: https://www.dartlang.org/tools/pub/assets-and-transformers.h...

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#13

Post by _puk »

Nemcue wrote: post #3

Not 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.

I've also been playing around with gulp, and whilst still in the 'trying to use it like grunt' kind of mindset, I have seen some merit in using these stream based build tools.

Have to wonder why this all requires new build tools to achieve though.

It's obviously technically possible (npm shows grunt-gulp which does exactly what you'd think), so is the grunt architecture so firmly rooted in files that streams could not be leveraged, or is it something that will come in time?

Personally managed to get a nigh on perfect build process using grunt-watch, so no rush to move away.

Nice to see build tools still moving forward though.

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#14

Post by _puk »

jonaldomo wrote: post #12

I would like to request renaming brocollifile.js to brocolli.js. I believe brocollifile.js is too long for a standard build file name. Gruntfile.js always bothered me. Compare it to pom.xml, build.xml, package.json and it feels out of place.

Broccoli is just one of those words that never looks spelt correctly, even when it is.

Might I suggest lumber.js, considering it's all about trees.

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#15

Post by machty »

_puk wrote: post #14
jonaldomo wrote: post #12

I would like to request renaming brocollifile.js to brocolli.js. I believe brocollifile.js is too long for a standard build file name. Gruntfile.js always bothered me. Compare it to pom.xml, build.xml, package.json and it feels out of place.

Broccoli is just one of those words that never looks spelt correctly, even when it is. Might I suggest lumber.js, considering it's all about trees.

Broccoli looks like little trees. I wanted them to be called `Brocfile`s. Who's with me?

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#16

Post by iamstef »

PascalW wrote: post #7
pedalpete wrote: post #6

Earlier quoted context omitted.

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.

fast builds isn't the entire broccoli offering, I would trade slow builds for accurate consistent and durable builds, amazingly with broccoli I get both.

I actually do not believe grunt/gulp vs broccoli makes terribly much sense to compare as broccoli aims to be a accurate/stable/fast build pipeline, it does not aim to replace your task runner. It's primary goal is to be the best possible build pipeline, and should be programmatically accessible to your existing task runner.

Anyways, since I didn't really compare grunt/gulp with broccoli, let me explain what you get:

* primitives make sense, was able to get a fairly non-trivial or ordinary pipeline setup really quickly

* builds so fast, you don't notice them.

* accurately handles changes (deletions and git branch changes tend to often cause similar tools issues)

* doesn't lose changes that occur while building

* true pipeline. eg. describe the transforms, and the system handles the rest. No needing to construct make-shift pipelines yourself

* immediately usable as server (error reporting, locking)

* development builds.

* minified source mapped production builds.

* the Broccolifile API is well suited for constructing custom piplines

And finally:

the above you essentially get for free, if you need customizations the Broccoli file provides are an API well suited for the task.

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#17

Post by joliss »

jonaldomo wrote: post #12

I would like to request renaming brocollifile.js to brocolli.js. I believe brocollifile.js is too long for a standard build file name. Gruntfile.js always bothered me. Compare it to pom.xml, build.xml, package.json and it feels out of place.

I named it after the `Makefile` pattern, since it contains a build definition. We have `Rakefile`, `Cakefile`, `Gruntfile.js`, etc.

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#18

Post by JangoSteve »

Broccoli is a new build tool. It’s comparable to the Rails asset pipeline in scope, though it runs on Node and is backend-agnostic.

This first line is a little disingenuous. Technically, it's not backend-agnostic, since it depends on Node being installed on the backend (in the same way that Sprockets [1] depends on Ruby). The Rails asset pipeline is a framework-specific integration of Sprockets. In much the same way, you could more closely integrate Broccoli with Rails if you wanted and call it a new Rails asset pipeline.

The project itself looks great, just the first line was confusing since they started the docs off by comparing apples to oranges.

A better comparison would probably be, "It's comparable to Sprockets (which powers the Rails asset pipeline), but runs on Node instead of Ruby."

[1] https://github.com/sstephenson/sprockets

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#19

Post by iamstef »

filearts wrote: post #10
iamstef wrote: post #2

Having 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.

I would be an advocate of this.

But.. competition is healthy, I am glad we are getting some great solutions in the space.

Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline

#20

Post by applecore »

joliss wrote: post #17
jonaldomo wrote: post #12

I would like to request renaming brocollifile.js to brocolli.js. I believe brocollifile.js is too long for a standard build file name. Gruntfile.js always bothered me. Compare it to pom.xml, build.xml, package.json and it feels out of place.

I named it after the `Makefile` pattern, since it contains a build definition. We have `Rakefile`, `Cakefile`, `Gruntfile.js`, etc.

How about "Brocfile.js"?
Post reply on HN