My experience has been that for systems of nontrivial size, the two alternatives to using a pre-existing framework are spaghetti code and an ad-hoc framework built as you go. The first is obviously bad, but the second is wildly variable. Sometimes you end up with a nice lean framework that's a delight to use and solves the problems you need to solve and not much more. Sometimes it turns out that you actually did need a heavyweight framework, and your nice lean framework gradually turns into a worse version of things that already exist. Sometimes the core design of the ad-hoc framework turns out to just be a terrible idea from the beginning.
Also, and this is the part that's always bugged me: you will never know if your homebrew framework is a great one or an awful one until it is way too late to replace it.
It must be a corollary to the Dunning-Kruger Effect or Peter Principle: you can't know your own competence.
It's also possible to have a large and clean non-spaghetti codebase that does not rely on some framework, be it pre-existing or ad-hoc. For example, Linux.
"Framework" for some has the connotation of being dogmatically prescriptive: a monolithic culture of libraries where you must buy into the whole system to use any of it. For example, a classical C++ framework might come with its own string class, its own container classes, its own smart pointers, its own way of binding to other languages, etc. Escaping the cultural ecosystem to integrate something external can be quite a burden.
A middle ground is where you try to factor out useful parts but do so in a way that keeps in mind that users might not want to also use associated packages X, Y, and Z. This means backing off a bit from the maximally elegant integration you might do when you have a giant framework ecosystem and imagine people wanting to use all of it in its glory.
Doing this requires resisting the inclination to build a code empire -- a megalomania that anyone ambitious among us has felt as your excitement at being able to build more complex things grows. You only learn the opposite instinct after being burned suitably by frameworks, or looking upon your own empire and despairing.
In my opinion, the biggest problem with an "ad-hoc" framework, or custom-built framework, is that there is definitely going to be less documentation for the next person on how to use that framework.
No, thank you. And this is coming from someone that read the OP years ago. The fact that short-term reposts gain so much volume on here indicates that front paging is incredibly stochastic. It's been this way for a while; submit a link once and it gets 0 comments, and the second time 130 comments, and the third 14 comments, all within a month and using the same title. As sad it is, the only way to fight through a stochastic system is to increase the frequency of posting everything so that on the average things break through for the "right" amount of time. Though, this doesn't bode well for the future of this medium.
At our shop we don't use frame works, well at least none that came from anyone else.
The problem with frame works is that if you need to modify them, then you no longer can just update them when everyone else does. You are stuck always making changes to the framework ever after as they new ones come out.
But also you don't often fully know what the code does. If you have code that does something you don't understand then you end up not understanding how it changed later.
With Front End Development things like TwitterBootStrap get you a great looking site very quickly, that is nice. But if you want to tweak things suddenly your version isn't going to be the same as the stock version and you can't have it be cached from some fast CDN, and so your site is slower than it should be.
With BackEnd small changes to the official version of a framework can introduce bugs. Sure this is also true of things like Minor Revs to the language. (A lot of people got burned by moving to PHP 5.4 before WordPress was ready for it, and had only decided to enable auto updates to PHP because WordPress 3.2 required PHP 5.1) (And I'm not fond of PHP or WordPress so don't flame me because this is my example, it was one of many, but one that a great many people experienced so I figured the enormity of the event made it a good example)
The moral of the story is OWN YOUR CODE. The more you rely on other people's code the less you are the master of your own fate.
"The more you rely on other people's code the less you are the master of your own fate"
To head it off at the pass, comparison with shared libraries and the like are unfair.
A typical library has one, usually simple, well documented demarcation point between your code and it. A framework is a global construct where you interact with the filesystem, the combined sum of all code in the entire framework (most of which you won't understand unless you're a dev on the same framework...) AND everything else in your app.
Using a framework is often like writing one big app all global variables all one giant function. Everything interacts with everything else and when it works thats nice, but when it doesn't...
Finally a framework is the ultimate SPOF single point of failure. Don't like the play! framework router? tough cookies do write your own entire framework or forklift upgrade to Lift. On the other hand if library implementation #7 of a base64 decoder doesn't work or you hate it, try ten other implementations or write your own, its just one small-ish function not a giant overbearing framework.
Finally don't throw out the baby with the bathwater. If the syntactic sugar of MVC design works for your app, run with it. You don't need a framework to tell you how to design to split your views and controllers and models. Or if you're just in love with the template engine component of a framework, go for just a template engine.
Someone should write the framework to rule them all which supports multiple plugins. An infrastructure.
Need to include a qualifier that they're identical size/complexity. I find it hard to believe an app exists for a serious "bulky" framework that uses 99.999% of the code in the framework. Once you get down to 0.1% or so it starts getting easier to maintain your own ten lines than to cooperate/tolerate someone elses 10K lines.
So what happens when you write a seriously hard to solve bug or you accidentally misarchitected your internal framework in some fundamental way that wasn't clearly obvious until you're too far down that path to fix it? What do you do when the 1 to 10 of you that "own it" aren't smart enough to figure it out? What happens if that mistake is time sensitive or extremely costly?
Looks more like a rant about factories than framework.
I define a framework by opposition to a library.
Your code calls the library, but the framework calls your code (the "hollywood principle": we'll call you).
I actually dislike frameworks because it's really hard to see what's going on behind the scene (relevant stuff).
Frameworks happen when you've written your nontrivially big program, you've successfully abstracted out all of the mechanisms in effect in that program, and actually rebuilt your original spaghetti mess on top of those abstractions, everything is working nicely, you've carved out most of the cruft you at this point know you won't need, and then you get the killer idea that the next time you—or someone else!—need to write a similar program it will be much less work if you turn your existing program into a framework for writing similar programs.
Nobody ever does and you never do.
And if you did, you'd be several steps ahead of yourself at that point and you would do it all very differently because you know more now.
Frameworks are just reflections of a single program: a framework is essentially extrapolating from one data point.
Simple modules or interfaces can be turned into genuinely reusable libraries. They'll become orthogonal tools that can be used with other libraries, and often without any of the libraries it was developed with. A big software project always contains several libraries originally written for the project. But what you think is a framework of code that contains several modules or libraries for doing XYZ-ely things and that is used to implement program XYZ is actually the program XYZ itself.
When I first started programming I used to quote this post. A bit later on I realized I was making excuses for my Not Invented Here Syndrome. Now I favor getting things done, though my NIH Syndrome still peaks out every now and then.
The clojure community has great meme: libraries over frameworks.
In my mind java is notorious for having frameworks that box you in. You have to think like the framework or you will have major problems. Think spring/hibernate.
The library over framework idea is that external tools that you use should solve a problem and be composable. You should be able to mix and match easily if you want to throw something away or introduce something new.
Composable libraries can reduce NIH and keep you flexible.
Choosing to use a library should still be a carefully weighed decision. You often must commit to the library's data structures, or write a bunch of boilerplate wrapper code to insulate them from the rest of the system. I imagine this is less of a problem in languages with dynamic typing or golang-style interfaces.
If you're using only one or two functions from a big library, it might not be worth the overhead. A lot of Boost libraries are super complicated and really turn me off when I want something simple like a directory scan or a synchronous socket. Sadly there is often no alternative because the C++ community has thrown so much weight behind Boost.
I wish C++ had a module/package system and a simple version of Boost that only covers the most common 90% of functionality. But that leads to another problem with libraries: when you suddenly hit the limits and need to completely ditch them for something more powerful.
I like libraries but it's not always an easy choice to use one.
To be fair though, it is more than just a mindset. Creating composable software in Java is non-trivial if not impossible as compared to functional languages. Even if you set out with the goal of creating a composable library in Java, it is very hard to achieve that.
The article shows problems with each approach, without hinting to a solution. I do not see what is wrong with the shop selling a bunch of different types of hammers, while providing guidance on when to use which.
I am also not sure if the complaint is against the specific frameworks OP has seen, or he could really show that this would apply to all frameworks including those not built yet. My guess is the former.
We should always remember to not think in black and white.
My first complaint to the article is that it paints a framework as a universal hammer that tries to do many things. This simply isn't a fair comparison. I am not a builder, so I'm sorry if this analogy falls flat, but it's less like a universal hammer and more like the framing of a house. While there might be different approaches of framing a house for the most part the goal of framing is to ensure the house is structurally stable and can then be built into what the owner wanted. This is exactly what a framework attempts to do. My second complaint is similar.
If I'm building a simple "spice rack" such as a contact form then a framework is certainly overkill. However if one uses a framework to solve such a simple solution then the complaint should be targeted towards the developer. Quite frankly given the hardware available, and the fact that I could develop something like this quickly with or without a framework, it almost makes this point moot.
Finally it's the job of engineers/developers to understand that each problem has multiple solutions. As such it is up to the engineer to choose the solution that best fits the problem and execute. Frameworks will not always be a good solution, but at times they will be absolutely the best decision one can make. Good engineers don't think such black and white terms.
I think what he is really targeting is enterprisey enterprise frameworks that are checklist compliant. Those have every feature you want, even if they support it only half-heartedly.
And because they try to be everything to everyone, they suck.
Truth is, for a medium to large system, you either use a framework or you write something that approaches a framework or you have a complete mess on your hands.
Targeted frameworks that solve real problems (like Angular.js) are simply great. Bloated messes like JEE are not so great.
I don't think an analogy about hammers is a particularly strong way to make a case for or against software frameworks. There are many situations where a framework makes a lot of sense and lots of situations where they don't. Some simple heuristics like ' you don't want to use a framework when your project has the following properties... ' would explain the case better and also help create discourse rather than black and white opinionating.
He clearly has no idea what problem a framework solves.
Framework is exactly designed so you don't have to build an entire factory yourself, you let other people do that, and you can concentrate on the specific challenges for your problem. In my eyes, a framework is the good old hammer approach. See frameworks like the different kinds of hammers. Different hammers for different jobs, just like a different framework for different jobs.
Frameworks sound great until you inherit a franken-app built using one. You might be able to understand bits if they religiously followed the dogmatic usage of the framework but more likely they just wanted to get stuff built and not wanting to learn someone else's idea of the perfect wheel maker framework and so ended up still building something unique, baroque, and possibly impenetrable.
Frameworks in the most case feel like straightjackets, so I understand why developers feel the need to abandon some of the magic and build bits that are actually simple robust and supportable, but it can become hell for subsequent developers.
I thought that OWL (at least the Pascal version) was pretty reasonable for what it did.
I can understand the frustration with Java, though. The first time I started reading through "web.xml", I thought it was a bit much. Then I read the EJB specs...
Struts, at least the older versions I've had to maintain, is a nightmare. RoR seemed to have a lot less BS to do the same thing.
Using the right framework for the right reason is a productivity boost.
I agree. The difficulty with this is in the long term. Things change: new opportunities, new technologies, new developers, new functionality. Even if you were 100% certain of your choice on day one, it's difficult to measure the precise point beyond which your framework is no longer the "right" framework. I'm interested in solutions to this problem.
but doesn't this happen anyway? Business requirements change, technologies change, the tool that you chose 5 years ago is probably not the best tool for the job today, regardless of whether it's a framework, a library or another piece of software in your stack.
A possible solution is to keep your business logic framework agnostic, and write thin wrappers to plug into the framework where required. In theory it should be possible to change frameworks without incurring a major rewrite. This is easier said than done of course.
I like your post. I agree with the fact that a framework does restrict your control and creativity. However, what you get in place of that is standardization.
So if you have 10 people working on a project you don't want them all to be doing their own thing. You want a very standardized code base that is easy to understand by everyone. Easier to maintain, change, and, upgrade.
