Frameworks are for hacks, libraries for seeds

When you're using libraries, you're actually making your own custom framework.

Because a framework is basically a set of libraries that work together to help you get to a certain goal.

If there's already a framework that helps you get to a certain goal, it can save you a lot of work to use that existing framework instead of making your own. It can also save you a lot of security issues.

But if your requirements don't really connect to the things existing frameworks provide, you'll have to build your own custom framework by collecting all the libraries you need and making them work together the way you want. Maybe you can make a framework out of it so the next person that has the same requirements as you doesn't have to go through this process again.

Frameworks are also good in a long run. When a new member on the team starts to work on a project, it is much easier to pick up on some popular framework like Rails than your own one. First, because you can easily find a guy who worked with Rails framework and knows it inside out, unlike yours custom-written one. Second, the whole infrastructure, like regular updates, documentation and community is also a major factor.

The problem with libraries is that they might not match. For example, what if one library you use uses another String class from another library you use. You'd have to write a lot of glue-code to let these libraries talk to eachother. It gets especially tricky if one library uses a garbage collector, and another library uses a different one. You could get cycles between objects managed by different libraries, which would never get collected (ouch!)

But in any case, I prefer that over working with a framework. Frameworks pretend to have everything figured out, but in reality they have not, and they are a pain to work with if you deviate the slightest from the "master plan".

Also, libraries are more easily replaced than frameworks, which is a huge advantage. And they invite you to think modularly, rather than monolithically, which helps to keep complexity down.

Libraries by definition have a narrower scope and hence are more easily adapted to new situations.

Frameworks by their nature affect the whole codebase.

This is the low-coupling/high-cohesion benefit of libraries as seen in many places in software engineering.

A codebase with low coupling is inherently more flexible and maintainable. Libraries and well defined, sensible interfaces are critical to good engineering.

Great article. It puts into words something that I've been feeling for many years, but have been struggling to express.

It's not that frameworks are bad; they quite clearly have their place. It's that they are short term hacks, and as such there is a time and a place for using them, but they aren't a long term solution to a problem.

I agree with the sentiment of the of the article. Dependencies should be isolated and not spread out all across your application. Even though both don't have tight definition, I think it's fair to say that a framework is usually larger in scope and API surface area than a library and usually impose a certain way of coding (and toolchain) on you. Isolating your dependencies (gui, persistence, ...) is a lot easier when you use a small library than using a framework that pretends to have all the answers.

It is true that you have to lay out more infrastructure yourself working this way but I feel that this is a really good thing because it makes you really think about the problem you are trying to solve, and don't just think in terms of the patterns your framework offers (e.g. MVC: "I have some logic, so I'll put it into a controller!"). This usually leads to code that is a lot easier to understand and is easier to test. Also, every application is different and with the framework way of doing will always end up having to shoe-horn things.

If indeed that's the case, then welcome to the era of the quick hack.

From the nanosecond the user hits the power button on their little box, and the BIOS loads 0x7c00 and executes it (loosely defined, frameworks call your code), we're in framework world.

You want your browser loaded? Better hope that the user clicks it, and the OS calls your code, because otherwise you're malware (and you were still loaded by the OS). Want users to visit your site? Unless you're a virus, you're gonna have to wait for their browser to navigate there. Another framework.

The idea that frameworks are not for writing software to me is just ridiculous. It's the only way useful modern software can be written. Unless of course you yourself have created the hardware, OS, and layer upon layer of userland software that you're going to rely upon, you really need to acknowledge that your code is 99% dependent upon frameworks.

It depends on the language. For example, in PHP there's the 'framework interop group'[1] who are working on a set of standards that enable developers to easily take code from one framework and use it in another (so long as it's written to the standard). Framework modules become libraries. So you choose the framework that suits your project best, develop your code in that style, but you're able to pull in modules from other frameworks as and when you need them.

It seems to be a really good idea. It solves the exact problem that the author has.

[1] http://www.php-fig.org

I’ve heard this argument over the years many times. It’s actually a hard discussion to have the more general the terms that are used. What exactly is a “Framework”? When does a library cross the boundary and become a Framework? What is the original author’s definition of “develop software”? That perspective matters here, because if what he’s saying is create a novel solution to a problem that hasn’t been solved before, that is a lot different from creating a webservice that inserts or retrieves some data from a database. Frameworks are essentially just a tool to get the job done. Some are better than others, and they come in all sizes. You really have to get specific to have a discussion like this that makes sense. If I tasked a Java developer with building a webservice that took some information and put in a database, I could reasonably expect them to use some implementation of jax-ws or jax-rs. If used properly those frame works are very powerful and convenient. Most implementations are well documented, and the communities around them are vast and experienced. Assuming the programmer was relatively experienced and had somehow never heard of either of those frameworks, I might expect some kind of servlet solution (arguably still a framework). Now if what the author is saying is that building a webservice isn’t development, that’s a different discussion. Many paths are heavily traveled. Using a Framework if you have to follow one of them is taking advantage of the knowledge gained by a large number of people that have already made the trip.

There is some truth to what the author is saying. Frameworks do tend to be opinionated, and they will tell you to write your code in a particular fashion to play nicely with the rest of the kids in the framework's playground.

However, I think there's more here that the author skirts around. He laments the fact that "in-fashion" changes to a framework force you to refactor your code. I'm not so sure that this is purely a negative thing. Let's take the upcoming Laravel 5 as an example; on the face of it, Laravel 5 is a drastic departure from Laravel 4.2. The directory structure is completely different, and the way you interact with The System is changing in a subtle but significant way (middleware). Is this cause for consternation? Perhaps. It requires developer time to upgrade, which is not free. But the gain is twofold: you benefit from using newer and, ostensibly better, structure around your app; and you grow as a developer, because you learn a new way to do something familiar.

I'm not saying here that the author's assertion that this is unnecessary is incorrect; just that there are benefits to being forced into change.

Also, regarding libraries: just because two libraries deal with the same topic or technology does NOT guarantee that they'll make the same assumptions about abstraction. Even on the device driver level, you can't take that for granted.

The first few truly complicated frameworks I learned were very useful. IIRC, they were Borland's OWL, MFC, Win32/kernal stuff, and .NET internals.

They were useful because learning them and walking through code while debugging showed me all sorts of best practices (and worst practices). When I wanted to use the GDI I grabbed a handle, basically a hash in a lookup table somewhere. This made sense. When I was programming custom VBX controls, I used the USER part of the WM_ space and sent messages back and forth. Loved the message loop paradigm.

But then something funny happened. Frameworks no longer helped me complete a complex project, they actually got in the way of doing it, by adding a lot of intellectual overhead for very little return. I started seeing new programmers pick up some training, start using a framework, and then get completely lost when their work took them anywhere off the "happy path". People would spend a hell of a lot of time learning framework X, only to eventually realize that the next job required framework Y.

As I got older, my recall isn't what it used to be, which actually turns out to be a good thing -- it forces me to focus on important things instead of minutiae. I got much more radical about web apps. I'm happy with static web pages that are interactive for most everything. I don't code things that do deep-dives into the guts of the stack. I'm looking to provide the most value in the least amount of time (and cognitive overhead). I moved to pure FP.

So now my order is: 1) Code it myself, 2) Use a precanned library, 3) Use a framework

The frameworks I use are very small: JQuery, .NET, maybe one of two others. I like it that way.

It depends what you're developing. If you develop a product (startup) that will change the world, you spend a lot of time, you put your heart into this product, you should understand every line of code, so you develop a product not framework. If you create site by site every week or day for your clients, you need a framework.

I wouldn't really trust a Haskell programmer to be able to identify a hack.

There are a lot of platitudes here whirling around a central point: Frameworks are more restrictive than libraries.

But, omgwtf, that's exactly the point of frameworks - they enforce convention in exchange for faster development. Also, newsflash, any large software project is going to have its own conventions. Okay, so, if you're still following me, get ready to take a leap. What if we have conventions that can apply to more than one project to reduce the ramp-up time for programmers to contribute?

The neophytes on HN eat this kind of stuff up, without ever considering that the thing the author is whining about is exactly the intent.

That's one of the reasons I like the Node ecosytem: the culture is really about finding the right library and designing clean interfaces so that you can switch when you need to. Having worked with Grails in the past was such a pain in comparison ...

I think this is also about choosing your battles wisely. When you build something new you will find it is hard. You will have a lot of flexibility choosing how to go about it. It's not necessary to reinvent the wheel on every front. That's why I love frameworks (Bootstrap, Ruby on Rails, templates, even spreadsheets for business plans etc.).

Frameworks quickly allow you to go from 0-80% without having to start from scratch. You just take something that already exists and then fill in the gaps with your values, colors, content etc.

I agree with gitaarik that in the grand scheme of things libraries are also like a framework.

You never needed a framework until recently when you had to deal with the conceptually disjoint modern web and the pile of languages it takes to do anything reasonably complex. We never had to use frameworks when writing against Win32, Swing, iOS, Android, etc. Certainly, there were frameworks -- such as MFC. But they quickly fell out of favor because the structure they imposed wasn't helpful at all. (Way back when, we figured out that the framework superclass is an anti-pattern.)

Win32, Swing, iOS, et al aren't really frameworks in the same sense that something like Rails is. Win32 doesn't care if you name your code something that clashes with The Revelation Given To Great Prophet DHH; all it cares about is that your WNDPROC behaves like it should. The OO variants of this only care that you derive your UI classes from the framework's classes so you can be notified of relevant events. Nor did these old 'frameworks' (as often incorrectly stated) prescribe the underlying architecture. They didn't force you into MVC for every single project, they didn't force you to use a database for persistence.

Monolithic frameworks are a modern fetish; borne out of a Stockholm Syndrome for the Business: "how will we hire easily replaceable workers?" / "how will we spin someone up in the minimum amount of time?". The answer: programming by MadLibs.

Developers advocate for them because they provide immediate gratification for doing very little work. They confer a mediocre architecture on all projects, which is perceived as preferable to the hard work of designing and architecting a system from scratch. They are a form of blame-shifting by developers: they can offload some of the risk and the Hard Parts of development to a Smart Person/The Community and run to them for help when it breaks. This is not a bad thing, but it does stunt the design impulse, and limits their growth as developers.

In the case of Rails, choosing Rails is no guarantee of project quality, or even conventions. Are you using Postgres, Mongo, or a combination of data stores? If it's the latter, then AR's transactional niceties are out the window! Are you using regular Rails views, presenters, or decorators? When you structure your controllers, are you using The Rails Way (fat models), or services, or more Bernhardt-esque design (app lives in lib/)? All of these things require spin-up time to learn the where and the why.

I do think frameworks are a symptom of propping up conceptually weak abstractions (e.g. the web) and languages. It should be concerning to you that all the metaprogramming in the world + a fully dynamic runtime cannot produce a framework that makes it easy to produce minimally coupled run-of-the-mill business software that doesn't require horrendous hacks like Rails' Spring.

Buy a copy of Growing Object Oriented Software, Guided By Tests. The author builds something sans framework, letting the construction of the software guide him to the best design. The resulting software is lean, supple, and easy to extend.

That's very well put! I think it's the same for me; I just haven't been able to verbalize it so fluently.

I have another quip about that "Frameworks are framing, libraries are liberating" :)

Roundabout way of justifying the reinvention of the wheel.