3 ms·

If you had to build e.g. Google Maps from the ground up, how would you architecture the frontend?

ReptileMan 7y ago
With the ability to measure straight line distance between two points not hidden and afterthought.
cfv 7y ago
CQRS comes to mind. spam events from user interaction, respond to them with any number of disjoint event handlers, with a tiny core runtime that ultimately acts on a specific subset of those events destined to modify the DOM in some way or another
jerf 7y ago
Assuming you are implicitly claiming it only makes sense to use MVC, it couldn't be MVC, because as I said in my other reply, network communication is too big a concern to just slip in to the design. It's a fundamental change. MVC doesn't have any provisions for network in it. One of my major objections to the concept is the way people think good design == MVC and MVC == good design. I could describe to you my architecture, but then someone stuck in the MVC mindset would see my discussion of how the UI controls will drive the map object, and say "AH HA! Aren't you saying that the map is a View and the UI controls are the Controller?" To which my reply is, if MVC describes everything, and you can squeeze anything into it if you squint hard enough, it describes nothing, because that makes everything "MVC" and therefore you can't distinguish the quality of a design by whether it is or is not MVC if everything is MVC. On the other hand, if MVC isn't everything, but is in fact a very precisely specified combination of OO patterns, then no, my Google maps design would not be MVC, because I would not use the MVC patterns as my guideline in the slightest and the odds the resulting design would happen to conform to the strict definition by the end of the project approach 0, even if you could pick out bits and pieces that sort of seem to resemble it sometimes kinda sorta. I don't "avoid" models, views, or controllers, but I never chase them.

With the ability to measure straight line distance between two points not hidden and afterthought.

cfv 7y ago

CQRS comes to mind. spam events from user interaction, respond to them with any number of disjoint event handlers, with a tiny core runtime that ultimately acts on a specific subset of those events destined to modify the DOM in some way or another

jerf 7y ago

Assuming you are implicitly claiming it only makes sense to use MVC, it couldn't be MVC, because as I said in my other reply, network communication is too big a concern to just slip in to the design. It's a fundamental change. MVC doesn't have any provisions for network in it. One of my major objections to the concept is the way people think good design == MVC and MVC == good design. I could describe to you my architecture, but then someone stuck in the MVC mindset would see my discussion of how the UI controls will drive the map object, and say "AH HA! Aren't you saying that the map is a View and the UI controls are the Controller?" To which my reply is, if MVC describes everything, and you can squeeze anything into it if you squint hard enough, it describes nothing, because that makes everything "MVC" and therefore you can't distinguish the quality of a design by whether it is or is not MVC if everything is MVC. On the other hand, if MVC isn't everything, but is in fact a very precisely specified combination of OO patterns, then no, my Google maps design would not be MVC, because I would not use the MVC patterns as my guideline in the slightest and the odds the resulting design would happen to conform to the strict definition by the end of the project approach 0, even if you could pick out bits and pieces that sort of seem to resemble it sometimes kinda sorta. I don't "avoid" models, views, or controllers, but I never chase them.