couchdb-marketing mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject How do CouchApps fit into the CouchDB story? (Was: CouchDB Articles, Pills and Tutorials Ideas)
Date Tue, 05 May 2015 08:54:20 GMT
It seems we have a separate discussion going on here, so I forked the

I’ve seen these two sides ever since we invented CouchApps:

 - CouchApps are amazingly simple
 - CouchDB as an app server is a great idea, I don’t need to run any other infrastructure
 - this is the future of web development
 - couchapp* is a great tool to manage design docs

(*or erica… etc.)

 - the concept of compiling design docs is confusing
   - even when they get it, they are confused that they need a third party tool called `couchapp`
to do so, because the documentation talks about building full apps in CouchDB, they have an
external app and just want to use CouchDB as a database, but couchapp is still the tool they
 - the tooling is poor
 - the tooling is all third-party
 - they can only cover a very limited use-case
 - CouchApps are the only way to use CouchDB

I see a number of people being passionate about CouchApps and I believe their enthusiasm is
warranted, CouchApps are a neat idea.

But I also see a greater number of people being confused by CouchApps and in turn by CouchDB.

That is not a good situation.

Let’s think about how (and if) we can fit the CouchApp story into a coherent CouchDB story.

A prerequisite for that is having a coherent CouchDB story, which we don’t have fully finalised
yet, but we have talked about extensively, and the consensus is around the “Data where you
need it” narrative that emphasises replication between CouchDB instances and other projects
that speak the replication protocol (especially PouchDB and TouchDB).

How do CouchApps fit into that narrative?

* * *

(Personal view alert: this is just to give some more background on my own position, this isn’t
meant as a basis for discussion)

I’m personally conflicted. When we set out to develop CouchApps, we thought we are inventing
a new paradigm for how to build the web, and everybody would follow us, because that would
enable a true p2p web. That didn’t happen and probably was a little foolish of us :D

Technically, that would have meant CouchApps had to grow a lot more and I realised quickly
that CouchDB is not the right place to grow such a thing. In addition, there are various fully
fledged web frameworks already and CouchApps could never really compete in terms of person-power
and attention.

That all led me to re-evaluate the whole value proposition, when things like PouchDB came
up and the browser became a decent application development platform. That whole thinking led
to the creation of Hoodie (, which started out with the code name CANG (Couch
Apps Next Generation), where we liked some of the core ideas of CouchApps, but wanted to address
the limitations that would stifle their adoption. Hoodie embraces browser-to-server sync to
allow fully offline apps, it allows all-javascript-all-json development on the front- and
back-end. It uses the database-per-user and the _changes-feed-as-async-worker paradigms and
it is all wrapped into a package that is *really* easy to understand and get started with.
Hoodie, unlike CouchApps, does have a fighting chance of making CouchDB’s unique features
(replication, _changes) available for a larger population and I’m infinitely excited about

* * *

All that doesn’t mean, however, that CouchApps don’t have their place, but again, I’m
not sure where that place is and the place it currently has seems to negatively affect CouchDB,
so I’d like for this list to think and talk about all that for a bit.

How can we make it that CouchApps strengthen CouchDB and not weaken it by adding confusion?

How do CouchApps fit into the CouchDB story?


> On 05 May 2015, at 08:45, ermouth <> wrote:
>> CouchDB-killing answers
> Well... When someone says couchapps is silver bullet – I say ‘No’ and I can
> prove it. Couchapps have a lot, A LOT of problems, and some of them can not
> be solved inside CouchDB. For example, try to implement ACL for attachments
> or try to scale couchapp. You just can‘t do it in reasonable way.
> I know several engineers who tried out couchapps – and left CouchDB
> forever. Not because CouchDB itself, but because couchapps. O‘Reilly said
> it‘s a silver bullet, others said – and what we have? Sloppy and
> hard-to-debug architecture, that does not scale, has no tooling and a lot
> of security issues.
> You gonna solve architecture problems with positive posts?
> What I want to say – there is no need to lie and say couchapps are great.
> Because they are not.
>> would you like to write down some of your positive:-)) experiences?
> – sorry, Russian language.
> ermouth

Professional Support for Apache CouchDB:

View raw message