Comment by michaelchisari
4 years ago
Setting limits for future features to keep the code base clean and manageable is something developers could be more vocal about.
Acquiescing to every demand product designers and management throw into the mix is what turns beautiful, easily-maintained codebases into nightmares.
What people are talking about here is writing web apps as a series of small, tightly-coupled spas who manage state within very specific parameters. And that's a great way to build software. Until someone comes in and asks you to draw in the state from one section into two other sections. You have the choice to say a) no and explain why, to b) create a clever "glue" that will be hard to maintain and difficult to explain, or to c) take the time to refactor the code into something more general and complex to allow for the feature on a more abstract level.
Guess which one almost always gets chosen.
The upshot is this: The solution to front-end complexity may not be a technical one, it may not require a new framework or library. It may be a shift in what we expect out of the web. We could always temper our expectations in order to keep our code clean.
The end goal of writing code isn't always a "clean and manageable" codebase.
Likewise the solution to SPAs isn't "say no to features".
I'm aware, but the discussion about the failures of spas always center around their failures in maintainable code. So if one's issues with SPAs are codebases becoming unmanageable, the solution won't be technical, it's going to be managerial.
A start would be devs communicating to product & design what the technical limits are to the current approach so that it informs their decisions.