3 ms·

At a more general level: > People have been saying tech X saves us from complexity for decades (OOP, noSQL, Knockout, Angular, etc...), and after a few years o

At a more general level: > People have been saying tech X saves us from complexity for decades (OOP, noSQL, Knockout, Angular, etc...), and after a few years of use we realize it's not actually a magic bullet. Throughout all your years of education, you were challenged the same amount. Doesn't mean you weren't doing/learning more. X did save us from complexity. We just, continually, keep writing increasingly complex things. Yesterday's sites were rendered on the server, with all state stored on the server. Today's are rendered on the client, buisness state on the server and rendering state stored on the client. Tomorrow's will distributedly store all data on the client; Think bit-torrent + encryption + web-rtc. Day After sites will be rendered on the server again; because we are now working with extremely "complex" 3D hologramed Apps.

davnicwil 11y ago
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.

davnicwil 11y ago

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.