The last good framework I used was Metrowerks PowerPlant.
The primary issues that make frameworks flawed
11–20 of 43 posts
Re: The primary issues that make frameworks flawed
#12It sounds like the author doesn’t really have any idea what a “framework” is, but has heard several things they dislike called frameworks, so the presented thesis is “frameworks considered harmful” when what might be more accurate is the ”the following design patterns have this set of problems.”
So what is your definition/understanding of the term "framework"? Can you give examples of something widely considered to be a "framework" that doesn't suffer from problems described by OP?
Re: The primary issues that make frameworks flawed
#13If you aren't using a framework, you are writing your own framework. Moving from project to project will be a pain, for you and others.
Disliking frameworks is not very different from disliking DRY, conventions and abstractions.
Re: The primary issues that make frameworks flawed
#14Frameworks are demonstrably not broken, as millions of individuals and companies use them, successfully, as part of their projects and products.
Why do software developers equate "this technology is imperfect" with "this technology is worthless"? It's the kind of hyperbolic, emotional thinking that I would expect from a child, or Donald Trump, not people who supposed to be rational, analytical engineers.
Re: The primary issues that make frameworks flawed
#15He is right. Give me a specialized collection of functions any time, aka, a library, but I will never again use a framework, which is a half-finished program, of which the users are supposed to figure out how to fill in the blanks. A framework imprisons your own code within confines and limitations of what will often turn out to be some kind of imbecilistan.
"a framework, which is a half-finished program"
I think you might have another point here. If the framework wasn't a half-finished, but reasonably complete, program, then the criticism of the article wouldn't fly. It's perfectly OK for a finished program to be non-composable.
Emacs is a good example. It is a text editor first and framework second (although it's hard to believe, because people joke about it). It's not composable, merely extensible. Emacs has all faults that the article criticizes about frameworks; however, since it is usable on its own, it works out positively in the end.
Re: The primary issues that make frameworks flawed
#16If you aren't using a framework, you are writing your own framework. Moving from project to project will be a pain, for you and others. Disliking frameworks is not very different from disliking DRY, conventions and abstractions.
You can also write a library, which is a different thing than framework. What you're saying is a false dichotomy, based on different understanding of the term "framework".
I think what mainly distinguishes framework and library is that framework dictates you conventions outside its own code, where library does not. This dictate can be as simple as "I must be in charge of running the program, i.e. the top-level thing".
See, the conventions are not bad per se, however, they do not compose. So bundling conventions with potentially reusable code, as frameworks do it, is a wrong idea.
Re: The primary issues that make frameworks flawed
#17If you don't use an existing open source framework, you end up writing your own custom framework from scratch - And the outcome is not usually as good.
Then the next developer has to learn how to work with your custom framework from scratch (which is not as easy as learning the popular open source one).
Re: The primary issues that make frameworks flawed
#18Frameworks are demonstrably not broken, as millions of individuals and companies use them, successfully, as part of their projects and products. Why do software developers equate "this technology is imperfect" with "this technology is worthless"? It's the kind of hyperbolic, emotional thinking that I would expect from a child, or Donald Trump, not people who supposed to be rational, analytical engineers.
I read the "broken" in the OP title as conceptual problem, not a practical one.
"as millions of individuals and companies use them, successfully, as part of their projects and products"
This was true for COBOL in its heyday, too (well, maybe not millions, but there was less computers in the world, too). But would you use COBOL in a new project today, even if it's not actually broken?
Re: The primary issues that make frameworks flawed
#19If you don't use an existing open source framework, you end up writing your own custom framework from scratch - And the outcome is not usually as good. Then the next developer has to learn how to work with your custom framework from scratch (which is not as easy as learning the popular open source one).
All projects will have custom code in it, the business logic, that other unfamiliar developers will have to learn, regardless of whether or not a framework is used.
If instead of a framework you use a platform, like Ring on Clojure, Facebook React, JVM servlets, etc, then all a new developer needs to know is how the platform works and then get familiar with the code that has been written so far. Typically, these platforms have minimal implicit behaviour, so everything that happens is traceable via some kind of "main" entry point.
What part of this is "writing your own framework"? I don't feel that I write my own framework, I feel that I completely avoid the framework and the framework related problems highlighted in the article.
Re: The primary issues that make frameworks flawed
#20It used to be the case, circa the 1990's, that you only saw libraries and example code. Sometimes a "skeleton project". Anything beyond that was exceptional. Having lots of open code available online was a new idea.
The thing that made the framework prolific - and it happened in tandem with the rise of Wordpress and other CMS systems - was having so many small, disposable projects. Rather than copy the same skeleton over and over, you could run a cute "new" or "init" command to do the same thing, glom together some plugins, tutorials, and styling, and instantly have something that looked the part - provided you didn't actually test it on a actual business case. Since many web site projects were and are still primarily fancy landing pages, with simple interactivity, frameworks became hugely appealing as a way to ensure a degree of polish and maintainability.
But frameworks became marketed as the way to make web apps, and here I think our enthusiasm went astray, since apps pretty consistently need to work through all their infrastructure from first principles, even if they're doing something relatively small. The "microframework" approach of bundling together unrelated libraries or interfacing their functions to a common protocol has remained a popular one, and that is most likely because it better satisfies the needs of app makers.