It's the coupling of user interface and network. The best way to achieve sub-20ms response times (instantaneous to the human eye) is to decouple the user interface from the network, to transport views and controllers separately across the network, fuse them on the client, and buffer data against the network.
This cannot be done with server-side MVC frameworks (no matter how popular) as they simply were not designed to do this, to deal with network latency, one of the "8 Fallacies" (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...). The problem is there's too much CPU activity on the server and not enough on the client, when the reverse could be true.
What is needed is a network-aware, network-straddling framework. The "thin client/fat server" metaphor must give way to the "thin server/capable client". This would probably also encourage Javascript on both client and server, and make offline access a reality as a matter of course. For example, see https://szpil.com.
Comments
It's not front-end widgets that are responsible.
It's the coupling of user interface and network. The best way to achieve sub-20ms response times (instantaneous to the human eye) is to decouple the user interface from the network, to transport views and controllers separately across the network, fuse them on the client, and buffer data against the network.
This cannot be done with server-side MVC frameworks (no matter how popular) as they simply were not designed to do this, to deal with network latency, one of the "8 Fallacies" (http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Comput...). The problem is there's too much CPU activity on the server and not enough on the client, when the reverse could be true.
What is needed is a network-aware, network-straddling framework. The "thin client/fat server" metaphor must give way to the "thin server/capable client". This would probably also encourage Javascript on both client and server, and make offline access a reality as a matter of course. For example, see https://szpil.com.