The arguments against web frameworks

Summary: We explore three arguments against frameworks, address them, then turn them into challenges to be overcome.

Although web frameworks are extremely popular, they are not without their detractors. I would like to go over three common arguments against frameworks. Each argument, when taken as a challenge to be overcome, points the way to a better framework---one that scales better, teaches better, and reflects the values of the language. This article is a continuation of a line of thought which started here.

Frameworks don't scale. We often reject frameworks after working on a project that outgrew the framework. Code changes became difficult. The very structure that helped you get so far now seems to be holding you back. The thought inevitably crosses your mind: if I had only written this myself without a framework, I wouldn't have these problems now.

Of course, we know this is hogwash. Imagine if I said "my factory won't fit in this warehouse anymore. If only I had built my factory in a bigger warehouse from the beginning." But could you have afforded the bigger warehouse at the beginning? Wasn't having a smaller warehouse part of your early success? Scaling problems are good problems because something is going right.

The fact is: programming is full of nonlinearities. That's a fancy way of saying that nothing scales forever. Exponential curves look linear before they hit the elbow. But you never know where you'll encounter elbows until it's too late. Elbows lurk everywhere.

We can choose to see elbow ubiquity as a reason to reject frameworks, or we can see it as a challenge. A framework can aggregate knowlege from multiple apps and try to give you a long linear runway in several dimensions. Some problems are known not to scale within the framework, so we should document those and make evaluating the framework easy.

Some fear that frameworks teach people the wrong stuff. We all have seen those questions on Stack Overflow where the asker obviously doesn't know where Ruby ends and Rails begins. Rails monkey patches a bunch, so it's really hard to know what comes included in the language.

People say that frameworks encourage such ignorance. But that's balderdash. The people who don't know the difference are called beginners. They, by definition, don't know as much as experts. Everyone starts somewhere and the fact that they're even playing in the same sandbox as experts should send shivers of gratitude through the experts' spines. Be nice to beginners and help them solve their problems. If it really is important to distinguish the language from the framework, it is the framework's job to teach them to distinguish it on their own.

Some people claim that a framework disgraces the art of programming. By enforcing a process and standards, and by removing decision points, the craft of programming is lost. The craft, they say, is the act of making all of those decisions.

I'm quite sympathetic to this argument, but it's baloney. Experts want control because they know what to do with the control. A "real programmer" doesn't need niceties, and to prove it, goes without. These arguments have been made since the beginning of symbolic assemblers.

Imagine if I said "a real farmer digs with a shovel; a real dweller builds their own house". Give me a break. Of course the expert wants control. They've mastered the parts and they want to put them together in precise ways. But in no way does empowering someone with a tractor or a pre-made house detract from the craft of farming or householding.

On the contrary, a framework can elevate the craft. You can focus on the functionality of your app instead of the mundane work of wiring up the low-level features. We often confuse the motions with the craft. The farmer is not a dirt digger. That is simply the motion a farmer must make to cultivate crops. The farmer who is not toiling with a shovel, who instead moves dirt with a tractor, can care more for his or her plants---which is the real work. Similarly, a good framework may free up the programmer's mind to build more beautiful software. We shouldn't confuse the motion of gluing libraries with the craft of solving problems with computers.

Conclusion

Frameworks have problems, that is for sure. But they also enable so much! Instead of seeing the shortcomings of existing frameworks as strikes against the notion of frameworks in general, we should see them as warning signs for what to avoid. We know that we want a learnable process and we know that it should scale, should help people learn, and should elevate the craft of software engineering. So what would a Clojure web framework look like? We'll get to that next time!

There are probably more. Please let me know which ones I've
missed.