couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Ramage <>
Subject Re: Futon.Next Proof of Concept
Date Thu, 01 Nov 2012 19:26:35 GMT
I am +0 on grunt. It does do a lot for the building the app.

But before going too far, I would like to see some work done on
integrating into the couchdb actual build. As we can all agree,
keeping std couch build dependances down will be important. If you can
show it working with a couch build, I will move my vote up.

On Thu, Nov 1, 2012 at 1:21 PM, Russell Branca <> wrote:
> On Thu, Nov 1, 2012 at 11:40 AM, Benoit Chesneau <> wrote:
>> On Thu, Nov 1, 2012 at 7:34 PM, Simon Metson <> 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, 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

View raw message