Really, that's the only thing that comes dangerously close to a concise explanation of what this project actually is - and it makes it sound like a couple of programs that generate a fairly typical MVC website folder structure and auto-compile a few types of files whenever they're changed.
If Brunch is more than that, it might be worthwhile to at least have a gloss of what else it does around, even if the rest of the documentation is in progress. Otherwise, the understanding of any awesomeness is going to be limited to people who're going to plumb the code or went to that Vienna user group presentation. :)
thank you for your feedback! we definitely need not only to improve documentation but also figure out how to concisely communicate what it is all about.
very valuable advice, that is exactly what we aimed for :)
we currently focus on recommending a certain set of components and aim to make their integration seamless.
once we got that and the documentation and code examples are improved we will look into making it easier to switch certain components for people who want something different. comparable to rails (ruby) where you can switch activerecord with something different.
so we certainly don't intend to make replacing components a hassle :)
you have a point. I still see that it is very valuable to provide tooling, documentation and conventions for this toolchain since more and more people use it but every project you see on HN/github/… looks a bit different.
I believe these kinds of opinionated conventions you know from other frameworks really add benefit. So I think there are quite some backbone users who intentionally chose backbone because it does not dictate as much as other client side frameworks do, but there are also many people who want to use backbone and coffeescript and would love to have an easer getting started experience :)
we just presented brunch at the vienna javascript user group (viennajs.org).
we still need some input on good client side testing tools that would make sense to be integrated with a js framework. further we need to get rid of some rough edges and will focus on providing documentation and examples.
currently we would like to get feedback on the chosen toolchain and love to hear suggestions on how to improve their integration (we currently ship a file watcher, still need to add uglify support and different build targets - build.phonegap.com, chrome webstore, …)
thank you for your feedback. npm support was a big win for us since we tried to get the dependencies (especially on languages and package managers) simple.
we definitely will keep sass/scss in mind since it is very popular in the rails community. once the core components work well together we will look into customization (also for the templating component).
that said, I believe there is value in a recommended set of components to have consistent documentation, code examples and a straightforward getting-started experience. but for people who know what to do it should be easy to switch components (comparable to replacing activerecord in rails). easy things should be easy, hard things should be possible :)
We are definitely aiming to provide ways to integrate other templating frameworks. Keep us updated on your progress! Haml combined with CoffeeScript would be awesome.
This looks seriously useful for my next weekend project. That said, I'm looking for a caching, RESTful persistence layer for Backbone that will sync to the network if available, and otherwise caches data locally... anybody know of one?
Looks like a really good fit to what's currently going on in the community. Get working hard on the documentation and keep HN posted on how you progress!
Really, that's the only thing that comes dangerously close to a concise explanation of what this project actually is - and it makes it sound like a couple of programs that generate a fairly typical MVC website folder structure and auto-compile a few types of files whenever they're changed.
If Brunch is more than that, it might be worthwhile to at least have a gloss of what else it does around, even if the rest of the documentation is in progress. Otherwise, the understanding of any awesomeness is going to be limited to people who're going to plumb the code or went to that Vienna user group presentation. :)