eventreduce

With real private fields you can make a minifier that minifies the fieldname/functionname which is not possible before.

It has like 100 times more moving parts that can break.

Because you can make good money by migrating the customers java project once each year.

Most people do not "deserve" bed space because most sickness is selfmade. People smoke, drink and eat too much, so they all deserve to die?

It sounds like you did not read the READme. What you are describing is something that does scale up with more data but not with more requests. When you have an application where 1000s of users subscribe to different queries, your view-maintainance would kill the write performance while EventReduce does not.

The difference is that with simple caching you have to run full queries again when the cache becomes invalidated. This is often expensive especially on write intensive data usages.

All your assumptions are wrong. Please read the other comments here or at least the readme of the repository. I will happily answer all ongoing questions you have afterwards.

No and I also do not want to "claim" something. Feel free to do your own tests.

EventReduce is a simple algorithm. It does not care or affect how you handle propagation of writes or how you handle your events, transactions or conflicts.

See it as a simple function that can do oldResults+event=newResults like shown in the big image on top of the readme.

EventReduce is an algorithm and not a database-wrapper. It will not care about your writes or if your database layer is a cluster and so also not affect them.