The 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."
No more `grunt watch` – faster builds with the Broccoli asset pipeline
51–59 of 59 posts
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#52This 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…
Why 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?
There'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.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#53Is this a beta build system like tup? Sounds like it. I ask because I've recently begun work on the same.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#54Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#55Having 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 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
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#56Broccoli 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,…
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.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#57Broccoli 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,…
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.
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.
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#58Earlier quoted context omitted.
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…
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 soo…
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].
Re: No more `grunt watch` – faster builds with the Broccoli asset pipeline
#59This 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…
Why 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?
This 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.