41–50 of 59 posts
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.
Anyone know of any resources for writing plugins?
Prepros is the closest software out there now, but it's not extensible like Grunt.
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…
What's the difference between a build tool and a task runner?
Tasks are a more general concept; one of the many possible tasks you could program would be to build your project.
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…
You can either do this explicitly (by setting up aliased), or implicitly (by all the temporary file watch jiggery and pokery).
It's unlikely that I will start any new projects with grunt, even though I know it a lot better than gulp right now.
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.
Honestly half the battle is having a great easy to use plugin style that gets lots of people making plugins, and given the incredibly brief mention of plugins which makes them seem quite complex, I'd be quite wary of broccoli at this point.
Earlier quoted context omitted.
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…
grunt takes an almost entirely declarative approach, which becomes really hard to reconcile with situations that the order of execution really matters. because you are basically trying to map a flat(ish) array of commands onto a tree-like structure to trick the grunt internals to work the way you need them to. You can either do this explicitly (by setting up aliased), or implicitly (by all the temporary file watch ji…
Earlier quoted context omitted.
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…
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 it…
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.
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…