Maybe I'm in the minority but after drinking the React 1-way data flow kool-aid I love it. I can think more logically about what a components state is and I can test for that state very easily. IMHO 2-way data bindings are not a feature anymore they are firmly on the cons list for me.
What I dislike about articles like this is the author doesn't really talk about what we should be calling databases.
While calling one CP or AP may not correctly capture all the nuance of what those terms really mean it does give the user a quick idea of the capabilities of the database without having to go into a mutli-paragraph technical breakdown.
It's like describing a house as "orange", there are a million shades of "orange" and it might actually be closer to red or yellow but it gives a quick idea of what the house looks like. I feel the description CP and AP does the same, it gives a quick overview of the capabilities and if that interests you, one should be able to dig in deeper to the more technical details.
There are some pointers to better terminology at the end of the post — e.g. I like Terry's session guarantees (read-your-writes, monotonic reads, etc) — but they too only cover a small subset of the design space.
In the end, this stuff is still evolving, and we simply don't yet know the best way of describing things. I wouldn't want to propose some alternative classification scheme that would be no better than the one it replaces. But I do want to encourage people to be precise and thoughtful with the terminology they use.
I agree with most everything you've said, but until we have good concise descriptions I think it is unfair to really say: "Never use these".
Quick less-precise overviews serve a real purpose and are very helpful to users and decision makers.
I guess my opinion is projects should never ONLY say it is CP or AP, but I think it is perfectly acceptable in your project overview to say: This database is CP*. Then have a longer technical discussion somewhere else where they use more precise and thoughtful language.
I understand and agree with the sentiment, but we humans need fuzzy short overviews. Then again a blog post titled: "All databases need an in-depth technical discussion page" doesn't quite capture the imagination.
Nearly no distributed databases are either CP or AP in their default configuration, and CP and AP have very specific meanings, so it's more like saying a house is Pantone 300[1], when it's really some shade of cyan.
Definitions are flexible and communities collectively decide what words actually mean. Sure if you are talking to PhD Data Scientists CAP have incredibly specific meanings.
I think it is clear that the much broader user/marketing/coder community has a much less rigid definition of these terms. In my opinion, fighting against terms or ideas getting watered down is a lost cause. It inevitably happens and there is very little that can be done to stop it.
As I said in another reply really the battle cry should be something along the lines of "Every database needs a real thoughtful precise technical breakdown" not "Stop using terminology that gives a brief, if imprecise, overview of the product". Because the later is almost certainly not going to happen.
Right now I have no clue what a database means by claiming to be AP or CP, if it doesn't refer to the CAP theorem. Right now it seems to mean "We read a blog article about the CAP theorem and don't understand it"
