incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cinnebar <>
Subject Re: jQuery dependency (Re: Futon Improvements)
Date Fri, 11 Sep 2009 04:22:46 GMT
> 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.
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
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
>     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
> 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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message