Every few years the tide appears to turn and what was old becomes new again. In the early 2000s web standards were all about separating logic from presentation,

Every few years the tide appears to turn and what was old becomes new again. In the early 2000s web standards were all about separating logic from presentation, eliminating all inline code (can cause messy delayed browser rendering), etc. Recently SPA not only reversed that but made it fashionable. The reality is you forget your own code within a few months and when you have a team they need to be able to contribute to your code over time, so most code is not “fully known” when modified. The way a lot of projects go south is by becoming “hairy” - you don’t know all code that affects a module or a piece of logic, complexity gets added, functionality gets replicated, conflicted, etc. The key to surviving this is organization and documentation of the code under the assumption that nobody knows the code and needs to onboard quickly. If the code has a lot of abstractions - they will be forgotten, so you’d better have tooling to surface or explain them when it matters. If the code is self-explanatory (partly why I like Go), you have a lot less headaches. The locality of behavior can break down easily when functional complexity increases. Because front end and backend and user experience and state and appearance are caked on together, any custom aspect to either of them will force you to segment out code into more files or sections. So, what if we assume that is bound to happen and plan for it instead. What if there is a way to visualize all dependencies, possibly with a tool? Tracing, logs, flame graphs, maybe more? Still not ideal as they don’t fully capture all “ends” and “sides” of that hairdo.