9 ms·
No more `grunt watch` – faster builds with the Broccoli asset pipeline
- iamstef 13y agoHaving 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.
- pedalpete 13y agoI was about to move over to Gulp. Can you let me know why you prefer Broccoli over Gulp?
- PascalW 13y agoI 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.
- iamstef 13y agofast 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.
- deleted 13y ago[deleted]
- filearts 13y agoAs 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.
- iamstef 13y agoI would be an advocate of this. But.. competition is healthy, I am glad we are getting some great solutions in the space.
- pmllr 13y agoI have been working on replacing the whole production build pipeline as well. And since Grunt isn't a thing you can ignore these days I created a simple grunt wrapper that collapses the entire 200+ lines of config down to two config options: https://github.com/Munter/grunt-reduce https://github.com/Munter/grunt-reduce
- Nemcue 13y agoNot 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.
- imjared 13y agoYep- 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.
- tracker1 13y agoI 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 node.js as a host environment, it's easy enough to do pretty much whatever you want as a script/task, and is pretty much cross platform, and works well. Shell scripts come close, but ignore the elephant in the room (Windows). For the record, I'm biased as all hell, like node.js and JavaScript in general.
- camus2 13y ago> 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.
- virtualwhys 13y agoAgreed, 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...
- mikewhy 13y agoNot 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`
- clhodapp 13y agoI want to note that this headline is a wonderfully hilarious if read without js-programmer context.
- krsunny 13y agoBroccoli, the laxative your JS needs.
- munificent 13y agoThis 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.html https://www.dartlang.org/tools/pub/assets-and-transformers.h...
- pekk 13y agoWhy can't Dart reuse (or provide) a tool that also works for things other than Dart? Why does every language need to have its own everything unique to itself?
- bilalq 13y agoThere's always value in being able to stick to one language. I've worked on a project where we had a Gemfile, Gruntfile, composer.json, bower.json, .bowerrc, and package.json all within the same repository.
- munificent 13y agoThis is a great question. There are two main reasons: 1. The asset build system is built on top of a bunch of policies and conventions specific to our language's package manager. The build system needs to be able to locate plug-ins somehow, and it's hard to define that "somehow" without some kind of assumptions for how dependencies are located and organized. 2. Like other platforms, we want to minimize external dependencies. If we reuse grunt, then every user has to have node and npm installed. There's nothing wrong with that, of course, and many users do already, but we'd like to avoid forcing that dependency. 3. Since the build system is plug-in based, we need a way for the build tool and plug-ins to communicate with each other. We want that API to be simple so that it's easy to create plug-ins. Since they're sending entire assets through that communication channel, we need it to be efficient too. It's hard to do that in a language-agnostic way. 4. We want to make it as easy as possible for people to contribute to the build system and various build plug-ins. Since we already assume users know Dart, then when those components are also written in Dart, it increases the chances that they are able to pitch in and help. I don't like walled gardens or feeling like we're reinventing the wheel (though I'll note that before this announcement, I wasn't aware of many other build systems that were as many-to-many based as ours), but there is value in having things be internally consistent.
- jonaldomo 13y agoI 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.
- _puk 13y agoBroccoli 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.
- machty 13y agoBroccoli looks like little trees. I wanted them to be called `Brocfile`s. Who's with me?
- dgeb 13y agoI like the Broccoli name quite a bit (and the whole concept and implementation - great job Jo!), but I also prefer `Brocfile` to `Broccolifile`. Does that make me a broccoliphile against broccolifiles?
- joliss 13y agoI named it after the `Makefile` pattern, since it contains a build definition. We have `Rakefile`, `Cakefile`, `Gruntfile.js`, etc.
- JangoSteve 13y agoBroccoli 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 https://github.com/sstephenson/sprockets
- M4N14C 13y agoThe Rails asset pipeline requires a JS runtime, so Broccoli doesn't have any more dependencies than asset pipeline in my mind.
- JangoSteve 13y agoSomeone 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 13y agoBut 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.
- sonnym 13y agoThis looks like a solid project. I want to mention mincer[1], which I have used in the past for compiling assets, and it has been an entirely painless process. Definitely take a look at it as an alternative, which has been around longer and has seen assistance from the folks behind sprockets[2] (according to the README) for creating a similar API. 1. https://github.com/nodeca/mincer https://github.com/nodeca/mincer 2. https://github.com/sstephenson/sprockets https://github.com/sstephenson/sprockets
- Kiro 13y agoWhat's the difference between a build tool and a task runner?
- machty 13y agoTasks are a more general concept; one of the many possible tasks you could program would be to build your project.
- roryokane 13y agoOther possible tasks including initializing the database (for a new developer), regenerating some artificat that isn’t normally regenerated during the build, and launching a local web server running the project.
- jakswa 13y agoAnyone know of any resources for writing plugins?
- grayrest 13y agoRead the source for the ones there. The ES6 module plugin is the most involved.
- stefan_kendall 13y agoYet 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.
- matteodepalo 13y agoI'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!
- ChikkaChiChi 13y agoThere are at least 5 separate build tools referenced in these comments. Obligatory XKCD: https://xkcd.com/927/ https://xkcd.com/927/
- SippinLean 13y agoCan someone please build a Grunt GUI that I can drag-and-drop project folder to, to watch multiple folders? Prepros is the closest software out there now, but it's not extensible like Grunt.
- Natsu 13y agoThe fun part is when your non-technical coworkers ask what you're reading so intently and you read something like this to them with no context: "Run broccoli serve to watch the source files and continuously serve the build output on localhost. Broccoli is optimized to make broccoli serve as fast as possible, so you should never experience rebuild pauses."
- malandrew 13y agoIs this a beta build system like tup? Sounds like it. I ask because I've recently begun work on the same.