[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

[JangoSteve]

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.

[Wintamute]

But isn't Broccoli more of a frontend build tool? The primary motivation seems to be to speed up frontend development in terms of the save-file-build-wait-view-in-browser loop? I don't know much (anything) about the Rails asset pipeline, but isn't it used by the actual backend framework? As far as I can tell Broccoli is used to compile assets before the frontend files get anywhere near a backend ... so in this way its backend agnostic.

[byroot]

Sprockets is a frontend build tool. It works basically the same way.

The main difference between sprockets and grunt / lineman / broccoli, is that sprockets do not watch files. It's a web application that compile your assets on the fly[0][1] when you need them.

So it's lazy, and blocking. Meaning that you do not have to guess if your assets have been recompiled yet. Your browser just ask for them, and get them as soon as they are ready.

[0] In development mode of course [1] In fact it cache the output, but whatever.

[JangoSteve]

Bingo. But keep in mind that Sprockets doesn't have to be used just as a Rack server to compile on the fly, it can also be used to precompile to static files. In fact, you could then combine it with something like the watcher gem, and you now have automatic precompiling whenever you save your source files. In fact, there's the guard-sprockets gem which does all this for you [1].

[1] https://github.com/pferdefleisch/guard-sprockets

[spellboots]

No, it is correct. Backend agnostic means that it doesn't require your frontend project to be served by a rails app, a node app, a python app or whatever. It is written in node, but it is backend agnostic. This is not disingenuous at all if you use the same definition of backend agnostic as the author is implying.

[JangoSteve]

What I'm saying is that the author's definition is incorrect. Backend agnostic would mean that it doesn't matter what software or language your backend is running. Backend agnostic would be a term you'd use e.g. for a front-end library. Broccoli is not that. Broccoli requires that your backend has Node.js installed and running. Even if Broccoli were written in Bash, it still wouldn't be backend agnostic.

Think about it this way. Heroku, for example, can either have Ruby or Node installed on a single server, not both. If you have a Ruby app deployed on Heroku, you could not use Broccoli in production, because it requires Node to be installed on the server (not that you'd want to anyway; it's a precompiler, so you'd run it locally before you deployed to Heroku). The fact that you can have a backend setup on which this could not run means it's not backend agnostic.

Anyway, that's not the disingenuous part. The disingenuous part is implying it's better and more flexible than the Rails asset pipeline, which is an apples-to-oranges comparison. This is comparable to Sprockets. Sprockets does this sort of thing (with a slightly different implementation), but is written in Ruby. Then someone created a sprocket-rails gem, which set up and configured Sprockets to run more tightly-coupled with Rails (making it easier to use within a Rails app). That is what then became the Rails asset pipeline.

You can still use Sprockets with a Rails app, Node app, Python or Django, whatever, as long as you have Ruby installed on the server. Just the same as you can use Broccoli as long as you have Node installed on the server. This tool is comparable to Sprockets, not the Rails asset pipeline.

Now, sprockets, in addition to precompiling, also happens to have a live Rack server that can run in development mode, which you'd have to configure with your app in order to use. In that case, yes, Sprockets has more interdependency with the specific implementation of your web app. But if you just used Sprockets for it's precompiling, and added the Watcher gem, you'd essentially have what I understand Broccoli to be (but I could be wrong as I haven't actually delved much into the Broccoli source code).

I'm not being down on Broccoli. Quite the contrary, I think it looks really cool. I'm just saying that comparing it to the Rails asset pipeline implies that the existing alternatives aren't as flexible or configurable as they really are.