incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: jQuery dependency (Re: Futon Improvements)
Date Sun, 13 Sep 2009 05:11:07 GMT
On Thu, Sep 10, 2009 at 9:22 PM, cinnebar <> wrote:
>> a) jQuery is a very popular js lib, I don't see how that is a deterrent.
> I am going to try to address this and it may take a few posts/emails.
> Firstly jquery is a useful, popular and all round great framework (perhaps
> this is stating the obvious).
> The discussion that this thread stems from began with this:
>> So I'm at a bit of an impasse. I've got a couple ideas for how to give
>> Futon an extra bit of polish but I have no AJAX-fu. I thought I'd just
>> throw out some ideas and see if anyone wanted to try implementing
>> them.
> Implementation of any new features in Futon immediately requires at least
> being down with jquery or otherwise being down with js and ajax with jquery
> on top.
> The project I am involved with is being built with its own js component lib
> to avoid longterm development cycles of third party libraries such as
> jquery.  We are employing techniques and functions/methods from a number of
> popular and not so commonly used libraries with license requires and credits
> where credits are due...

> I am sure that a growing percentage of couchdb users consider jquery style
> js an unnecessary layer of complexity.

Being tied to closely to a single library isn't always a great idea.

CouchDB ships with 2 javascript client libraries:

The couch.js reference client [1] is used for the test suite. It is
synchronous, instead of using callbacks, and is designed to document
the HTTP API. CouchRest and a few of the other non-JS client libraries
started out as ports of couch.js

 jquery.couch.js [2] is the client Chris Lenz wrote for Futon, and
which is the basis for a lot of the CouchApp JS I've been writing. It
is a full featured asynchronous client, and since I already prefer
jQuery (I had a long slog getting there...) I don't have a big reason
to experiment with others.

There's an advantage in using the built-in clients because the code
will probably be in browser cache, and it makes application component
reuse a little easier to have a shared basic library as well.

There's another client called BrowserCouch [3] that is pretty cool.
It's JS that replicates with CouchDB and then makes local calls
against the HTML5 localStorage API.

That said, I encourage people to please do crazy stuff with the Couch
Ajax APIs. If you've written a JS CouchDB library, please release your
code. I don't think CouchApp or any of these are the end-all-be-all of
JS CouchDB development. What really matters is what people are doing
with it.



> Additionally as Futon serves as both initial access to the couch and as an
> 'out of box' demo of input methods and application design. Development of a
> couchapp first requires knowing or learning jquery which more or less first
> requires knowing or learning js and ajax.  jQuery is an extra level of
> complexity.
> The argument I have noticed is that the primary target user group is running
> CouchDB to augment other complex components in a larger system but given the
> current and proposed feature set it does not seem to limit use to the said
> target user group it does not seem wise to develop CouchDB toward
> unnecessary exclusion of users that may not have years of experience using
> complex systems but may have stunning new ideas and unjaded enthusiasm.
> The profound succinctness of the design of CouchDB core is something that
> sets it apart and is worth vigorously maintaining.   The more new features
> that are added to Futon using jquery methods the harder it is to factor out
> jquery (perhaps this is stating the obvious again).  It is wise to
> anticipate progression from current standards.  Perhaps loose coupling
> jquery/js libs somehow is worthwhile.
> One method of mitigating these issues is to provide more documentation of
> the current code base.  I mentioned this as a point of discussion not as a
> feature request.
> Beyond this I think that clever alternatives based on Futon can only enrich
> CouchDB I dont really get why anyone would find it threatening?  Often cover
> versions and remixes rock.
> Are there any other suggestions regarding development of Futon?
> I have working with a group on some alternative open source methods for
> using CouchDB that are quite different from any I have seen so far based on
> the idea that separating structure presentation and behavior of the front
> end is important but where the separation actually occurs is not important.
> More dev time is required tho and I seem to have wasted far too much time i
> wont get back being insulted for no reason.
>> b) CouchDB has no dependency on jQuery :) Feel free to use any you like,
>>     I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more
> without
>>     a line of jQuery.
>  the discussion that this thread stems from is concerned with Futon
> development so
>> Given the very excellent http request api that is a fundamental aspect of
>> CouchDB we consider that the current jquery dependancy is a major
> deterrent
>> regarding general uptake of CouchDB.
> was in the context of discussing the jquery dependency of Futon I thought
> that was clear there is no other CouchDB dependency.  In many cases CouchDB
> is at least initially dependent on Futon.  Futon serves as both initial
> access to the couch and as an 'out of box' demo of input methods and
> application design.  I understand your point but given the context I am
> unsure why you felt it was a neccessary point to make?

Chris Anderson

View raw message