4 ms·
It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new w
by bweitzman 11y ago
It seems to me that MV* architectures have been popular because we are forced to separate code into client side, server side, and DB. As we are developing new ways to integrate these, I 'm curios to see how this paradigm will change.
I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical?
- noelwelsh 11y agoGiven network latency it seems dangerous to abstract out the client and server distinction. As for MVC, I think there has been an ongoing shift away from it, or at least a refinement, for a long time. Functional programs looks quite different. React is a good example, emphasising unidirectional data flow rather than the cycles in MVC.
- wlievens 11y ago> I wonder, if we could write one single file that would handle client side, server side, and DB code using the same types, objects, functions, and language with no visible boundaries to the programmer, would MV* become less practical? GWT, basically?
- deleted 11y ago[deleted]
- davegurnell 11y agoThere are a handful of Javascript frameworks taking this approach. The community has adopted the term "isomorphic javascript" to collectively describe them (i.e. "same code on the client and server"). See http://isomorphic.net http://isomorphic.net for examples. However, note that they appear to be quite inclusive in their definition. For example, I'd definitely consider Meteor to be one of these frameworks, but React? Not so much.