On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau <[email protected]> wrote: > On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <[email protected]> wrote: > >> HI >> >> >> On Thursday, 1 November 2012 at 18:32, Benoit Chesneau wrote: >> >> > Just to clarify. for what does grunt actually it would be pretty easy to >> > handle the same in any language. >> >> Indeed, but those tools don't exist _today_. We could write them and then >> work on futon or we could just work on futon. I prefer the latter. >> > > Do you need today to minify or concatenate files ? :) What will be the > other use of grunt? Also not saying that gruntjs at the end wouldn't be the > only solution to use. But I think it's really important to make sure it > won't increase too much the toolchain when it will be time to release it. > > > >> > My main concern today is the status of >> > nodejs in distrributions. For example latest ubuntu has the 0.6.19 where >> > the last versio is 0.8.14. Which can be problematic when we include it in >> > our toolchain. >> >> I'm using node 0.8.1 with grunt quite happily. >> > > well I meant what is available with ubuntu. I will check but I had to > install it by hand last time (or some can use a ppa I guess). > > - benoit
Using grunt provides a lot more functionality than minifying javascript (which as I mentioned before, still typically requires node.js or java to accomplish). We need the ability to extend Futon with additional modules at build time, provide custom skins, and also customize the deployment targets. Let me give you some examples of the tasks grunt provides for us: * Compiling js as expected. * Compiling .less files into css. - to answer an earlier question, the combination of less and bootstrap provides a simple and direct way to customize the look and feel of Futon, and drastically lowers the barrier for design and UI contributions. * One other nice compilation grunt does, is that it embeds your html templates into the bundled javascript as strings, allowing you have to local html files as javascript templates in your codebase. This also decreases the complexity of bundling html templates with plugins. * Integration of the test suite into the build process, currently you cannot build the static assets unless the project passes lint checks and the initial test suite in place. * Templated path loading of assets, whether you want to deploy into _utils/fauxton, as a couchapp in /fauxton/_design/fauxton, to the root of a site such as futon.com/index.html, or as the new Puton, you need to change the asset paths appropriately at build time. * CDN loading of assets, in addition to changing the base destination of assets, we also want to be able to deploy the compiled assets to a CDN for efficient distribution. * Dynamic inclusion and exclusion of plugins. For instance, we want to be able to exclude the _config module as we don't use it at Cloudant, and also allow 3rd party plugins to be included as desired, such as alternative text editors, or interesting tools like Dale's idea for remote editing of CouchDB nodes. * And more… These are non trivial tasks requiring a substantial amount of development time to reproduce, and would most likely culminate in the creation of something analagous to grunt. Hopefully that helps explain some of the motivations for using grunt, and also gives a better idea of what we're looking to accomplish with it. -Russell
