Our product, Elevate Web Builder, creates fat-client web applications, and they are much, much simpler to implement than a hybrid approach because you're only c

Our product, Elevate Web Builder, creates fat-client web applications, and they are much, much simpler to implement than a hybrid approach because you're only coding to one environment at a time (browser, server). They are also much lighter on bandwidth requirements because most data transfers are simple JSON and not content. You can see this here with a demo that loads the IP address ranges for various countries into a grid: http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html http://www.elevatesoft.com:8081/maxgridtest/maxgridtest.html (our server is in Chicago - SingleHop is fantastic) Yes, you do make a valid point that things like optimistic database updates can be problematic, if not planned for. However, I would counter that the end result is much more durable and scalable than the alternative. If you build your application to handle distributed, optimistic transactions to a back-end JSON-based API (our dataset API does about 98% of the work for you), you're well on your way to having a distributed application that can be run anywhere and maintains a nice separation of concerns where the front-end or back-end can be swapped out as different needs arise. That, to me, seems to be a much better position to be in than one that requires a mix of both client-side and server-side content generation, which intimately ties the front-end to the back-end (brittle).