mmm that a lot of things for webapp used to admin a tool:) I am not convinced it's really needed.
Anyway I will trust you about that. Time to play with the current code. On Thu, Nov 1, 2012 at 8:21 PM, Russell Branca <[email protected]> wrote: > 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 >
