incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kowsik <kow...@gmail.com>
Subject Re: jQuery dependency (Re: Futon Improvements)
Date Fri, 11 Sep 2009 05:13:44 GMT
Been watching this thread and as a user of couchdb
(http://www.pcapr.net) and not a maintainer or a contributor I have
the following comments.

jQuery *is* the way (my personal opinion) to interact with the browser
and html and ajax and all the jazz. document.getElementById is so
passe' (Yes, I've played with Prototype and all the other
"frameworks").

In my mind the Futon UI is an application that interacts with CouchDB.
The core of couchdb has nothing to do with jQuery. As long as the REST
API is well defined (which it is) and there's an HTTP way of accessing
and managing the database, it's possible for anyone to build a
management layer with auto-completion of view results (prefix
searches), using code mirror (http://marijn.haverbeke.nl/codemirror/)
to syntax highlight the map/reduce functions for instant validation of
javascript, even going as far as eval'ing the function to make sure it
doesn't have typos (similar to
http://labs.mudynamics.com/wp-content/uploads/2009/04/icouch.html) and
so on and so forth with nothing to do with jQuery.

Furthermore, the _utils namespace access allows anyone to drop in an
alternative for managing the DB in any case. One of my first "apps"
was precisely this. Just a _utils html/javascript "app" that used the
map/reduce views to do all sorts of data-mining without requiring
another middle-tier. This was early this year, long before, CouchApp
existed.

I really don't see why jQuery is getting in the way of couch dev. It
happens to be used in the management of the database and is just one
choice of many in building a nifty UI. jQuery itself is already an
awesome abstraction for DOM manipulation. Building yet another
abstraction so we could swap jQuery with Prototype, etc doesn't make
sense to me.

My 2 cents,

K.

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 (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
> 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?
>

Mime
View raw message