Just want to note Couchbase is not just for mobile. Couchbase Server is an enterprise-class document-oriented (like Mongo) db with a dynamic query language that's a superset of SQL. (FD: I work for Couchbase).
I started a company and chose couchbase. We haven't launched yet, so I've been using the community version and cobbling stuff together.
In this context: please, for the love of God, improve your documentation and dev tools. I love the underlying technology but my experience getting a basic service up and running has been pretty mixed. One of the reasons mongodb has been so successful is that there's 50 bajillion articles showing you how to hack up some crappy code that roughly does what you need it to do. Some of those articles are less bad than others, but in a pinch you can find something to at least get you on the right track. Couchbase doesn't have that deep well of experience to draw on. If you run into a problem, or experience strange behavior, it's up to you to figure out what's going on. That would be ok, but even the official documentation and standard dev tools are not good enough. To get people to adopt couchbase you need to do more to get them started.
Javascript-specific whining: it's particularly frustrating to find an official ODM like ottoman and discover that half the features don't work and that there are tons of bugs that haven't been fixed for about a year. These aren't minor bugs either; some of them stop you using headline features. Forget full text search, N1QL is mostly unusable! Check out ottoman bug #153 for details there.
One of the reasons I love PostgreSQLs jsonb type is you get the power of relational database and power of (nosql?) Document database at the same time. i haven’t run into any query I couldn’t write against a jsonb doc. Granted dot notation on json would be nicer than ‘prop’ > ‘prop’ > ‘prop’, but I don’t feel limited.
In our case, we wanted something more compact, so a query looks more like GraphQL (it's technically a superset of JSON, but it usually doesn't look like JSON). Joins, for example, are just nested declarations that list which attributes on the joined collections to fetch. Here's a query that shows many of the features:
This was a bit of humor delivered for entertainment at the closing of an Android conference (360AnDev, which I highly recommend). The speakers are two of the most well known in the Android community (Chet Haase and Romain Guy, both from Google).
On the "easy" front, your suggestions are cool. Why do you think this hasn't happened?
This is a good question and deserves its own article. Much fun (sometimes justified) has been made of the archetipical "Smug lisp hacker" or "Smug lisp weenie" who thinks that Common Lisp is the best of the best.
On the other opposite side of the spectrum are people who claim that as long as a language is turing-complete, all languages are "equally good" or even "equally powerful". Which isn't really a practical advice, otherwise Assembler would be used for prototyping web apps...
Now, what Common Lisp is, is the evolution of a language invented in 1958, a language which has the peculiar characteristic of being able to be extended almost without limit. This marks the difference with other late-50s languages like COBOL and FORTRAN; to extend Cobol and Fortran (and Java, for that matter), you need to convince the governing body of the language to add feature X, and then they need to release a new revised standard that supports feature X. (Example: C++14 after C++11)
While with Lisp it often can be implemented into the language using the facilities that the language brings in, just like that. This allowed Lisp to evolve with the state of the art in computer science, compilers and languages, all through the 60s, 70s, 80s, and 90s. Common Lisp (ANSI standard, 1994) wasn't really "designed"; basically, it was the standarization of things that were already proven to be "good" and to be "the right way of doing things" all through the past, so it has surprisingly few negatives.
One of the power features of Lisp is that it is truly a "programmable programming language"; some would say "the programmable programming language". What this means that meta-programming is really easy in Lisp, so easy that this is the bread&butter of a Lisp coder. In other words, you not only write "source code", you also write "source code that generates source code" quite often, and to a really good effect in productivity and code readability as well (i.e. by reducing boilerplate and narrowing down the source code to the most higher-level description of the problem.)
Another of the interesting power features are the object orientation facilities. CL was the first object oriented language to receive the ANSI standard. The object oriented system (CLOS) is probably still the most rich in features and most extensible, compared to other programming languages.
Finally, the language allows many programming paradigms (OO, functional, imperative, procedural, even logic programming, aspect oriented). Fortunately, being able to use a multi-paradigm language is finally being recognized to be a Good Thing.
However, to answer your question:
Why do you think this hasn't happened?
There is a problem with Common Lisp; the problem is that, to be able to leverage its intrinsic power, then you would probably be well versed in all the programming paradigms mentioned above. Additionally, the language, being so flexible and expressive, has many, many features and keywords and standard functions, so it represents a large "surface area" that the beginner must walk through in order to truly appreciate and make best use of the language.
So, Perl is "There is more than one way to do it",
Python is "There should be one-- and preferably only one --obvious way to do it.",
...Common Lisp is "There is more than one way to do it, however there exists a best way of doing it, and you should do it that way, but that way won't be obvious if you are a beginner."
However, the language features are mostly very coherent and orthogonal, so learning it will not be particularly hard; it will simply take time. To put it in other words, it can be complex, but it is never complicated.
So, higher learning curve, less developers available, thus less amount of "very nice" tooling available. However, this might change in the next years.
-----
TL;DR: Learning curve is high to be able to take advantage of its full power. So there aren't so many developers.
That analysis is from 4 years ago and is wrong in many, many ways at this point. As for "the general consensus", I'd like to see evidence that's true among real enterprise users. (FD: I work for Couchbase.)
Investigated the grand parent's question myself, though not extensively. The stackoverflow comment contains a lot of items which aren't true (couchbase does have document id's). The replication is multi-master but is cluster wide, which means couchbase has really nice tools to manage adding/removing nodes but doesn't offer ad-hoc replication (AFAIK). The SO comment also lists a bunch of things which won't matter to many devs like pure http-rest api as they'll end up using client libraries anyway from a middle tier layer.
Not to say Couchdb doesn't have many great advantages like the rest api and self-hosted apps, couchbase does to my mind seem like a good but not 100% alternative to couchdb (and vice-versa). Mainly I like that incremental map reduce is still available along with the atomic type of documents and revisions but clustering is still much more developed in CB.
The native/hybrid/web discussion has been going on a long time. The general consensus I've found is that web/hybrid is fine for some things, like magazine style apps, and untenable for more complex needs.
The app described seems to fit into the magazine style category (and was developed on a pretty high-end device). So to me this comes off as a "works for me" inappropriate generalization.
Couchbase (not CouchDB) gives you a whole bunch of things. You get the embedded document database, sync/replication, conflict management, auth, scale, data routing, querying, and more. Not every project needs all these things, of course. It's just damn hard to get this stuff right when you do need it.
I also personally find it way easier to use than the standard stores on Android and iOS for on-device persistence. 2.0 is coming up and should simplify the use a bit, too. So as it stands now I'd say the main sweet spots are, ironically, around the two ends of the spectrum. Easy to use for persistent local storage with no sync, and the industrial strength solution when used with sync.
I haven't used Mongo before. I have always been a Ruby/SQL shop, but now using Elixir/CouchDB. It was an awkward transition away from SQL, but I'm betting on this as a future stack.
Most notable: You write your logic in JS (See _view and _list functions). There are no transactions. Geolocation is not easy.
My product is essentially a SaaS for location based data collection with mobile app front ends. It's for businesses that service lots of clients at client locations and want to track work done. It's super easy to setup and is super customizable, has a flexible custom form builder, etc.
With Couchbase Mobile, we shy away from the "realtime" claim, because it's vague. (Ask a high-frequency trader how they define realtime...) Having said that, we have customers that are very happy with the response times. Always been open-source. Check our blogs for steps to get everything set up front to back to develop on one machine.
Couchbase Mobile is open source. Couchbase only provides the data platform, but is significantly more sophisticated at it than Firebase. Firebase offers many other services, so you can't really make a direct comparison. In simple terms, the way I think of it, Firebase goes wide, offering a package with many elements, while Couchbase goes deep on one area, the data platform. (FYI I work at Couchbase.)
