4 ms·

This is spot on. But, I disagree with your last statement: > Day After sites will be rendered on the server again; because we are now working with extremely "

This is spot on. But, I disagree with your last statement: > Day After sites will be rendered on the server again; because we are now working with extremely "complex" 3D hologramed Apps. Data is data is data. When the problem of distributing, syncing and querying data distributed between client and server is solved, it is solved forever for all classes of application which are built on that paradigm. This is true whether you're rendering a 2D web page or a 3D holographic image from that data on the client. There would never be a need to go back to server management of data or state - that's why leaps forward in this space, which React is and now Relay looks like it will be, are incredibly exciting and pull the whole industry forward. I would suggest a more likely 'Day After' problem would be managing more granular distribution of data and state through networks of clients, i.e. apps built on the peer-to-peer IoT paradigm rather than today's dominant client-server paradigm.

deleted 11y ago
[deleted]
yazaddaruvala 11y ago
Fair points! I think we agree on everything. I was honestly just being coy with "Day After". I don't believe I can adequately predict tomorrow's complexity issues. I just picked something arbitrarily "complex", not really giving it much thought.
- rwh86 11y ago
  s/coy/cute? http://dictionary.reference.com/browse/coy http://dictionary.reference.com/browse/coy
  - yazaddaruvala 11y ago
    /embarrassed Probably: s/coy/silly
Joeri 11y ago
The distinction between client and server is already evaporating, with things like server-side dom bringing client functionality to the server and service workers bringing server functionality to the client. I expect the next generation of distributed databases will include the client into its storage layout. However, that will only make it more apparent that the fundamental problem of synchronizing state between multiple machines is an unsolvable one, thanks to the CAP theorem. By unsolvable I mean that the intuitive expectation of the user is an always available system that is completely consistent, and we know we can't give them that. I feel like we're heading into the data processing equivalent of the AI winter, where the wet towel of reality will dampen much of the hyperbole around p2p and IoT.

deleted 11y ago

[deleted]

yazaddaruvala 11y ago

Fair points! I think we agree on everything. I was honestly just being coy with "Day After". I don't believe I can adequately predict tomorrow's complexity issues. I just picked something arbitrarily "complex", not really giving it much thought.

rwh86 11y ago
s/coy/cute? http://dictionary.reference.com/browse/coy http://dictionary.reference.com/browse/coy
- yazaddaruvala 11y ago
  /embarrassed Probably: s/coy/silly

Joeri 11y ago

The distinction between client and server is already evaporating, with things like server-side dom bringing client functionality to the server and service workers bringing server functionality to the client. I expect the next generation of distributed databases will include the client into its storage layout. However, that will only make it more apparent that the fundamental problem of synchronizing state between multiple machines is an unsolvable one, thanks to the CAP theorem. By unsolvable I mean that the intuitive expectation of the user is an always available system that is completely consistent, and we know we can't give them that. I feel like we're heading into the data processing equivalent of the AI winter, where the wet towel of reality will dampen much of the hyperbole around p2p and IoT.