Unless I'm missing some of the problems you're trying to solve, this seems like an extremely over engineered solution to the problem of code duplication (like validation) and boiler-plate communication code. For the former, if you're using a node backend, you can pretty trivially reuse the same code between client and server side. The later doesn't really seem like a big enough issue on its own to really warrant an architecture that requires a back-end with per-tab mirroring - you can usually encapsulate the 'cumbersome AJAX calls' with a straight forward API (or GraphQL query if that floats your boat).
This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.
I've been working on a project where we generate and synchronize view models (instead of full views like this proposal) between the server and web/app clients. We maintain (view)state in an Actor based backend, pushing updates to the clients through websockets. The client only needs to databind and render the model. This gives a really nice realtime user experience and is quite efficient.
Like SyncNinja, our architecture moves a layer of clientside code into the server. This enables more code sharing, at the cost of tight coupling between client and server (which does not matter for web but is problematic for our app clients). For use cases that need to work offline it falls apart; for that you need api's that work at the business layer and duplicate the view logic in each client.
I think SyncNinja will share difficulties we found around offline/localStorage, besides high resource usage, support for non-web clients, and all the problems you'd expect from browser differences (i.e. input prefill).
No, we're just starting out, pivoting from a previous similar idea. We wanted to include community from day zero, so anyone can contribute to the design as well.
[+] [-] zerovox|10 years ago|reply
This approach also forgoes many of the nice side-effects of having a clear slide-server boundary like avoiding leaking implementation details into your front-end code. Also, a simple REST API can be reused across platforms, so when you want a native experience on Android, iOS, etc you wont have to replicate this architecture or the underlying logic on each of those platforms.
[+] [-] Maarten88|10 years ago|reply
Like SyncNinja, our architecture moves a layer of clientside code into the server. This enables more code sharing, at the cost of tight coupling between client and server (which does not matter for web but is problematic for our app clients). For use cases that need to work offline it falls apart; for that you need api's that work at the business layer and duplicate the view logic in each client.
I think SyncNinja will share difficulties we found around offline/localStorage, besides high resource usage, support for non-web clients, and all the problems you'd expect from browser differences (i.e. input prefill).
[+] [-] vladaionescu|10 years ago|reply
[+] [-] rywalker|10 years ago|reply
[+] [-] vladaionescu|10 years ago|reply