The project proposes a model that will have significant (negative) implications on client performance, server performance, developer cognitive overload, and latency (despite transactions).

It'll also introduce a very big attack surface for malicious agents to DDoS your server and possibly exploit the server-side V8 once an appropriate vulnerability shows up.

And it'll also produce application tightly coupled to browser API emulation, which would become an obstacle to the server being able to properly support native mobile and desktop applications.

I can put these issues aside for a moment, and attribute them to me being too cynical to believe in a new way of doing things.

But let's look at the benefits. This is the example being given for the kind of client code that SyncNinja would enable:

    someDatabase.lookup('users', 'john', function (err, userData) {
        console.log("User's real name is " + userData.userName);
    });

This is already possible to do on the client-side, in plain JS, and any kind of server, as a very, very thin wrapper around the available AJAX calls provided by the server web API.

So my point is, I see no convincing examples of SyncNinja making something possible that wasn't already trivial before, and without the big overhead. Maybe you guys should work on what the value of this system is in practice.

Your "before" example doesn't show limitations of the browser, but simply a missing thin client library to abstract the AJAX calls.

Additionally, you have no prototype of this concept at all. Even a toy prototype with just one kind of event, or something. It sends the message that everything written in the paper doesn't come from experience, but it's merely hypothetical. And there's a giant leap from an idea to a working prototype.