3 ms·

I agree with the general argument here. Frameworks have pros and cons, but they aren’t magic, and they certainly aren’t the only way to get good results. Often

I agree with the general argument here. Frameworks have pros and cons, but they aren’t magic, and they certainly aren’t the only way to get good results. Often the challenge in scaling up UI code isn’t the amount of data, it’s the increasing complexity of the relationships between different parts of the data. The more dependencies, the more you have to take into account when you’re updating one part of the UI in response to a change somewhere else. In another comment, le-mark mentioned Brooks’ distinction between essential and accidental complexity, and that applies here as well. A UI needs enough logic to represent the essential complexity in the underlying data, which might be complicated in itself. However, sometimes the UI also introduces accidental complexity to handle transitioning from one state to another. This is why I find the modern rendering libraries like React to be a genuine improvement in the state of the art. They allow rendering based on the absolute state of your system, instead of changing the DOM selectively relative to whatever was already there, which in general may be an exponentially more complicated situation. Adopting this approach can directly and sometimes dramatically reduce the complexity of the UI code, compared to manually changing the DOM in response to changes in the underlying state. The heavyweight frameworks I’ve seen don’t offer that same sort of qualitative improvement. They do provide a systematic architecture, which can certainly be helpful as software grows. On the other hand, we’ve been building much larger software than any web app using good software design principles for decades, without necessarily needing the help of these pervasive frameworks. The trade-off with frameworks usually seems to be a quicker start time as the big advantage against potentially being less flexible if the project’s needs change later as the big disadvantage, but since neither of these issues is unique to frameworks this feels like a quantitative question more than a qualitative one.

unclebucknasty 9y ago
Well, that's a refreshingly reasonable approach to frameworks! I agree 100% that the biggest challenge solved by many of these frameworks is state management and, more specifically, capturing and reflecting state changes in the UI. Just seems that most frameworks start addressing this single issue, then get greedy; metastasizing their way up and down the stack. Suddenly, you're completely hooked in, using npm or similar to generate tons of boilerplate with framework-specific templating and a mini language, on top of a custom build process. So, simplicity is kind of an amorphous concept here. Maybe you pick up the binding, but you've traded away a lot for it. I haven't had much experience with React, and maybe it does a better job of confining its intrusions to view state management. But, with Angular and others, I have seen and experienced these huge learning curves that make sound developers' heads explode. Like anything, we eventually get it and it becomes second nature, so the perceived complexity is hidden to some extent. So, we tend to say, "hey, look at this neat binding that simplifies my code". Meanwhile, we're completely overlooking the learning curve, boilerplate, build process, and MB-denominated framework file sizes. >potentially being less flexible if the project’s needs change later as the big disadvantage Interesting take, as it's usually the reverse you hear: that is, without a framework everything will devolve into utter chaos as the project grows and takes on new requirements. My take is that, framework or no, at the end of the day nothing can take the place of good design. And, I guess that's really my larger point here. People tend to offer up "framework" as the one word answer to Web development these days, and I don't think that's a healthy state.

unclebucknasty 9y ago

Well, that's a refreshingly reasonable approach to frameworks! I agree 100% that the biggest challenge solved by many of these frameworks is state management and, more specifically, capturing and reflecting state changes in the UI. Just seems that most frameworks start addressing this single issue, then get greedy; metastasizing their way up and down the stack. Suddenly, you're completely hooked in, using npm or similar to generate tons of boilerplate with framework-specific templating and a mini language, on top of a custom build process. So, simplicity is kind of an amorphous concept here. Maybe you pick up the binding, but you've traded away a lot for it. I haven't had much experience with React, and maybe it does a better job of confining its intrusions to view state management. But, with Angular and others, I have seen and experienced these huge learning curves that make sound developers' heads explode. Like anything, we eventually get it and it becomes second nature, so the perceived complexity is hidden to some extent. So, we tend to say, "hey, look at this neat binding that simplifies my code". Meanwhile, we're completely overlooking the learning curve, boilerplate, build process, and MB-denominated framework file sizes. >potentially being less flexible if the project’s needs change later as the big disadvantage Interesting take, as it's usually the reverse you hear: that is, without a framework everything will devolve into utter chaos as the project grows and takes on new requirements. My take is that, framework or no, at the end of the day nothing can take the place of good design. And, I guess that's really my larger point here. People tend to offer up "framework" as the one word answer to Web development these days, and I don't think that's a healthy state.