couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Russell Branca <>
Subject Re: Futon.Next Proof of Concept
Date Thu, 01 Nov 2012 19:21:05 GMT
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

* 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


View raw message