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

31–40 of 59 posts

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

#31

Post by tracker1 »

_puk wrote: post #13
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 no…

I think the irksome point of grunt is simply that you tend to have many temporary directories for various states of files... especially if you use CoffeeScript or other intermediate languages, not to mention merge/minify actions and their temporary spaces.

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

#33

Post by camus2 »

tracker1 wrote: post #29
imjared wrote: post #5

Earlier quoted context omitted.

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.

I think the trouble comes in that 3/4 or more of Grunt plugins are things that really have very little reason to be plugins in the first place. Given how flexible node really is, and how npm tasks work, I'm more an more inclined to simply having a ./scripts/ directory with a file per task registered in package.json, so I can simply `npm run taskname` and have it correlate to `./scripts/taskname.js|coffee` ... With no…

> Shell scripts come close, but ignore the elephant in the room (Windows).

I use mingw and make, never had a problem on windows and it's not like mingw is heavy to download. Most people use git and git comes with a bash on windows too, so 0 excuses to learn shell scripts.

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

#34

Post by M4N14C »

JangoSteve wrote: post #18

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,…

The Rails asset pipeline requires a JS runtime, so Broccoli doesn't have any more dependencies than asset pipeline in my mind.

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

#36

Post by stefan_kendall »

Yet ANOTHER build tool. I've started placing bets on when repositories will flip to NEW-HOTNESS-BUILD-TOOL at the cost of actual product development time.

Engineers will constantly run toward shiny baubles at the expense of everything else.

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

#37

Post by sjs »

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.

It's a crummy pattern. broccoli.js FTW!

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

#38

Post by matteodepalo »

I'm happy to see this reach beta version, it's a great step in the right direction. Grunt is too generic as a tool and we've all seen Gruntfiles reach enormous lengths, to a point when it's really hard to figure out what is processing what.

One thing that has room for improvement though is the syntax, which in my opinion doesn't reveal the intention behind some methods and is a bit too coupled with the implementation. What does `makeTree('lib')` mean? If it's taking a folder and its files then why not rename it to something like `broccoli.requireFolder('lib')`? Also another thing that might improve usability would be chaining compilers instead of calling them directly with the tree as parameter.

These are just minor things anyway, I'm sure the library will improve over time. Congrats joliss, great fan of your work!

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

#40

Post by JangoSteve »

JangoSteve wrote: post #18

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,…

Someone commented below (but their comment is dead, so I can't respond directly):

The Rails asset pipeline requires a JS runtime, so Broccoli doesn't have any more dependencies than asset pipeline in my mind.

Technically they're right that the Rails asset pipeline does require a JS runtime by default. But it's important to note that the Rails asset pipeline doesn't strictly require the JS runtime; it's only required for the coffee-script gem, which happens to be included by default for new Rails apps. If you're not using coffee-script for any of your assets, then no, it doesn't require a JS runtime.

Post reply on HN