Mailing-List: contact marketing-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: marketing@couchdb.apache.org
Date: Wed, 6 May 2015 17:48:34 -0400 (EDT)
From: Joan Touzet <wohali@apache.org>
Reply-To: Joan Touzet <wohali@apache.org>
To: marketing@couchdb.apache.org
Message-ID: <4051975.373.1430948915773.JavaMail.Joan@RITA>
In-Reply-To: <F9F3BA14-B69A-4064-9457-0FDD634CFC52@apache.org>
Subject: Re: How do CouchApps fit into the CouchDB story?
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

I'm going to step in and describe my story of learning about
CouchDB for the first time, how CouchApps played into that, and how
after thinking they were the bees' knees, I've come to hate them.

I first learned of CouchDB while in grad school doing textual
analysis of synchronously medicated student computer supported
cooperative work - aka, analyzing student IM and IRC text chats.
I learned to convert my data into JSON rapidly, I was able to
apply MapReduce to my data set quite easily, and then I heard that
I could include a simple web app, *in my database*, so that when
I replicated the database away to someone else with CouchDB, they
would see the data exactly as I would.

After getting lost on couchapp.org for about a week (and trying to
understand if I HAD to use mustache.js for it or not) I eventually
produced a tabular format with some dropdowns that let people sort
data in different ways and view a few of the complex result sets.
The other geek in the department loved it. No one else could install
CouchDB.

Later on I started asking: why don't CouchApps have better security?
Why can't I incorporate this other web serving app as part of the
solution - because it has my blog or wiki or something? And how do I
extend the functionality of the CouchApp environment?

I realized that the answer to these questions was why CouchApps were
never going to be as rich as other environments when I talked to Robert
Newson. He reminded me that, in the end, Apache CouchDB is a small
community of developers who need to focus on the core of what is possible.
They know they'll never be able to duplicate the functionality in Django,
or Rails, or modern JS frameworks like Angular or React. They are
instead focused on making the core stable, adding functionality to
views, and improving clusterable performance. As I joined the 
community and started looking for tasks to tackle, it became obvious
that digging into CouchApps to improve them was hardly the most important
task to be accomplished. (At the time, it was getting stable Windows
builds done. I worked hard with dch to squash a few release-breaking
bugs that were preventing my employer from moving to v1.2.0.) Sadly,
very few people, if any, have taken any CouchApp related functionality
requests or improvements as top priority...and we haven't received very
many either. 

I think that's telling.  CouchApps are simply a victim of having not 
moved forward in 5-7 years. Perhaps we could evolve CouchApps to be
something amazing for today. But perhaps we could just instead focus on
Fauxton being awesome (which already takes a team of 7 or more, easily
doubling the developers involved in CouchDB) and call it a day. And turn
to a modern web dev and they will already have their favourite
stack...we're fighting an uphill battle where I don't think we have the
requisite innovation.

Technically speaking, as a dev I'm in favour of modularising CouchApp
functionality so you can load it or not, if you need it, and that we
would continue to maintain CouchApps as a core function (i.e., not
deprecated functionality). It might or might not be enabled by default,
I haven't really thought about it.

Hope this helps,
Joan