3 ms·

>I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely >At a certain size you should look into frameworks I he

>I also worked on projects with a great MVC pattern with jquery handling the view and it worked nicely >At a certain size you should look into frameworks I hear this a lot--the idea that jQuery or vanilla JS can work for smaller projects if well-organized, but larger projects require frameworks--however, I honestly have no idea how it makes sense. Seems to me that if you have a good pattern and foundation, then it should scale up to larger projects; else, what we're really saying is that it's still a mess, but a small mess that's manageable because the project is small and there isn't that much code. But, the framework dogma these days is such that we dare not even suggest undertaking a large project without committing to an "acceptable" framework du juor. I say this as someone who sees some value in frameworks, but also doesn't believe that the ROI is always there, or that it is absolutely necessary to use a framework on even larger projects. After all, frameworks aren't magical. They are just code. More specifically, they are reusable libraries attached to pattern enforcement. Why can't I choose a couple of libs, come up with reusable code, and implement my own patterns without all of the added cruft, opinion, politics, and risk of jumping on someone else's framework? Plus, many frameworks have just gotten way too big and complex, and we too infrequently emphasize the cost of using a framework vs. simply championinig the benefits. I want one-way data binding, but I have to change languages, introduce copious build steps, and generally follow all of your opinionated patterns, introducing layers of cruft and structure? Then, after all of this, you may change course with no upgrade path or the framework may simply become unpopular? No thanks.

watwut 9y ago
Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.
- unclebucknasty 9y ago
  >It is easier when framework itself encourages common patterns It's like developers don't want to design anything these days. Frameworks are generally overkill and, increasingly, insert too much opinionated cruft into a project. How can it possibly always be more efficient to wedge in this singularly opinionated way to implement every app just because the team exceeds n members? There are ways to enforce discipline on larger teams without relying on someone else's ideas.
Chris_Newton 9y ago
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.

watwut 9y ago

Scalling up means more people,new people, and people with different opinions about what is good. It is easier when framework itself encourages common patterns. Own solution tend to be tailored to first use case and work nor as well in general.

unclebucknasty 9y ago
>It is easier when framework itself encourages common patterns It's like developers don't want to design anything these days. Frameworks are generally overkill and, increasingly, insert too much opinionated cruft into a project. How can it possibly always be more efficient to wedge in this singularly opinionated way to implement every app just because the team exceeds n members? There are ways to enforce discipline on larger teams without relying on someone else's ideas.

Chris_Newton 9y ago

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.