On Thu, Sep 10, 2009 at 9:22 PM, cinnebar <[email protected]> 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. 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.couch.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 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 http://jchrisa.net http://couch.io
