Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.216.181 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=Xstql71f2uLyRoGLilIBjL9AtRDQhcGsFyyLeA4NKzwXUsRaHqj4l7uoFhQrrPKAJw
         T326FcDEcWevFdYPFPBsbV1Py0EIIvR4Gl4rvDqMA0ip92BnkeSbl3C41ScA0sPffTIs
         XaOhsBnr5JpjWGyPgmSfkPeU8Zpwmhib7sqNU=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <cf8122d20909102122u4fc15c66h354a4177ae7768d5@mail.gmail.com>
References: <e2111bbb0909091320v33fb31beucad40ffd5aafb170@mail.gmail.com>
	 <921000909091416m2e184420xebdc664f71d30541@mail.gmail.com>
	 <cf8122d20909091833y41ddacedg974b5b30b0f9a59c@mail.gmail.com>
	 <DD6F6B54-3F8E-4E0B-AC66-C9125C7A0ADE@apache.org>
	 <8a02878f0909100816q504832adg6cf8d30af922f195@mail.gmail.com>
	 <8a02878f0909100820v19bc9d96r3988bf82ee0dd8c8@mail.gmail.com>
	 <8a02878f0909100822k4403b580i1d50042c04908e6e@mail.gmail.com>
	 <cf8122d20909102122u4fc15c66h354a4177ae7768d5@mail.gmail.com>
Date: Sat, 12 Sep 2009 22:11:07 -0700
Message-ID: <e282921e0909122211g165f8960ya0d1f1b6a9403aab@mail.gmail.com>
Subject: Re: jQuery dependency (Re: Futon Improvements)
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 10, 2009 at 9:22 PM, cinnebar <merz.online@gmail.com> 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 (perhap=
s
> 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 jque=
ry
> on top.
>
> The project I am involved with is being built with its own js component l=
ib
> to avoid longterm development cycles of third party libraries such as
> jquery. =A0We are employing techniques and functions/methods from a numbe=
r of
> popular and not so commonly used libraries with license requires and cred=
its
> where credits are due...
>


> I am sure that a growing percentage of couchdb users consider jquery styl=
e
> 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.

Chris

[1] http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/couch.js
[2] http://svn.apache.org/repos/asf/couchdb/trunk/share/www/script/jquery.c=
ouch.js
[3] http://hg.toolness.com/browser-couch/raw-file/blog-post/index.html


> Additionally as Futon serves as both initial access to the couch and as a=
n
> 'out of box' demo of input methods and application design. Development of=
 a
> couchapp first requires knowing or learning jquery which more or less fir=
st
> requires knowing or learning js and ajax. =A0jQuery is an extra level of
> complexity.
> The argument I have noticed is that the primary target user group is runn=
ing
> 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 sai=
d
> target user group it does not seem wise to develop CouchDB toward
> unnecessary exclusion of users that may not have years of experience usin=
g
> 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. =A0 The more new featu=
res
> that are added to Futon using jquery methods the harder it is to factor o=
ut
> jquery (perhaps this is stating the obvious again). =A0It is wise to
> anticipate progression from current standards. =A0Perhaps loose coupling
> jquery/js libs somehow is worthwhile.
>
> One method of mitigating these issues is to provide more documentation of
> the current code base. =A0I mentioned this as a point of discussion not a=
s a
> feature request.
>
> Beyond this I think that clever alternatives based on Futon can only enri=
ch
> CouchDB I dont really get why anyone would find it threatening? =A0Often =
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 importan=
t.
> 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,
>> =A0 =A0 I've seen raw JS, Dojo, Prototype & Sproutcore apps, maybe more
> without
>> =A0 =A0 a line of jQuery.
>
> =A0the discussion that this thread stems from is concerned with Futon
> development so
>
>> Given the very excellent http request api that is a fundamental aspect o=
f
>> 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. =A0In many cases Cou=
chDB
> is at least initially dependent on Futon. =A0Futon serves as both initial
> access to the couch and as an 'out of box' demo of input methods and
> application design. =A0I understand your point but given the context I am
> unsure why you felt it was a neccessary point to make?
>


--=20
Chris Anderson
http://jchrisa.net
http://couch.io