Libraries vs Frameworks | Hacker News Reader

Libraries vs Frameworks

blog.orderharmony.com

81 pointsmarkokocic28 comments

A mistake I’ve seen in the past is that these types of decisions (i.e. which framework or library, should I even use a framework, etc.) are made for technical reasons rather than business reasons. What are your goals? Are you building an app for yourself as a hobbyist? Are you building an app to sell? Are you building a business around your app?

You need a house. You can:

- design your own

- build from someone else's plans and make mods as you see fit ( recognizing that too many mods may compromise the overall plan.)

- buy a prefab “kit” home that you assemble

- buy a mobile home trailer

What should you do? It depends:

- Do you need something right away?

- Do you want to win architectural awards and hopefully be profiled in a “beautiful home” magazine?

- Do you want your home to be mobile?

All in all, I’ve found that each decision has its trade offs. Pick your poison. You will always find reasons why you should have maybe gone another route. “Too bad we didn’t use framework X. It makes problem Y so much easier to deal with.” Oh? And what about problem A, B, and C?

My B2B Company started with MS Access. It got us our MVP very quickly, and our first clients. A good technical decision? No. A good business decision? Well, it worked out pretty well for me.. If I were starting again, (in the B2B space in which I am most familiar), I would probably go with Oracle’s Application Express, with which I could very rapidly build a functioning prototype and even run the business on for the first (perhaps long) while.

One of my favorite pieces of wisdom from Steve Blank is “Most often, business don’t fail due to a lack of technology but due to a lack of customers”.

“The speed of a non-working program is irrelevant.” - S. Heller (in "Efficient C/C++ Programming")

A "technically informed business decision" is probably the goal.

The selling point of these referred frameworks is the time to market. Do it in a way we know it has worked for so many people so far, and the framework code glues pieces together to make it good for you. Make it good for you until a particular reasonable scale.

No framework can claim to be the best fit in all the several dimensions on which they can be measured, one of which is, "time to market", today of all time.

At scale everything breaks down and need a custom implementation. If anything the framework needs to be good at, it is, how well it allows itself to be replaced and with how little effort.

Twitter is gradually moving all it's components into the "best production platform" JVM today. I don't think any body can provide convincing argument that building it on JVM right from the beginning would have been a better solution.

Outgrow a framework and roll your own at the points that are critical for your application. Do the common things like, sending emails etc, in a standard way and let it be handled the reasonably right way.

> If anything the framework needs to be good at, it is, how well it allows itself to be replaced and with how little effort.

Agree completely, its an obvious point but I do also think good frameworks allow plugging out smaller chunks elegantly

This article does not seem well thought out. It takes a condescending look on frameworks (and object-oriented programming) and contains many inaccuracies. For example, most ORM frameworks/libraries allow the developers to map an existing database schema with existing classes. They do not "force" you to follow only one type of mapping.

Now, what's the difference between a library and a framework? Hint: it's probably a continuum between no inversion of control and total inversion of control (not "reversion of control" btw). Many libraries provide some inversion of control mechanisms and "force" you to work their way (tyranny!!!). Is JQuery a library with all its callbacks and the use of $? Should you use JQuery then or "stay in control"?

As for: "So, our advice to you is to stay in control of the development path of your software and prefer libraries over frameworks for real-world projects."

Where is the nuance, the "it depends" in this conclusion? It depends on where you are in the product lifecycle, where your competitors are, how many developers you have, what your core features are vs. what features the frameworks can provide, etc.

For example, imagine that you invented a new programming language. Say clojure. Now you want to provide syntax highlighting, syntax checking, tab-completion, features that an IDE provide. Will you (1) write a completely new IDE or (2) write a plug-in/extension/script for vim/emacs/eclipse/netbeans? Are they, "real world projects"?

"reversion of control" was a joke on the authors part. Revert the control back to you, out of the framework.

Ooohhh. Thank you, it makes sense! (I still stand by my criticism of their article though).

How do you reconcile the need to move fast initially to release a product or service in order to build the market for it from a business perspective?

Does having to 'build your own framework' (my paraphrasing of your point) typically mean your software delivery is slower?

Is this detrimental to the business objective you're trying to achieve?

Does a 2-fold approach work - using a more substantial framework to begin with (for speed) followed by re-factoring into your own more specialised "framework of libraries" later?

Definitely some food for thought in your point - I presume it's based on actual experience of programming under both regimes?

> Does having to 'build your own framework' (my paraphrasing of your point) typically mean your software delivery is slower?

Possibly, initially. However, probably not significantly, since you should only build the framework that you need.

> Is this detrimental to the business objective you're trying to achieve?

No, since the business objective is to make money. The software is the means to do that, and the choices you make today limit the markets that you can expand into. If you decide that you're making a mobile app for android, then you are going to have to do a bunch of work (possibly including re-implementing the app) to get into the iphone or desktop market.

> Does a 2-fold approach work - using a more substantial framework to begin with (for speed) followed by re-factoring into your own more specialised "framework of libraries" later?

I think that taking the framework away is very difficult. Even when you've replaced all the code, and no longer depend on it, you still have the basic shape that lingers. I think that we generally call that a "re-write".

> Definitely some food for thought in your point - I presume it's based on actual experience of programming under both regimes?

yes

"Possibly, initially. However, probably not significantly, since you should only build the framework that you need."

OK, I have to throw a flag on this point.

Modern frameworks give you a lot of essential functionality OOTB. I've worked on enough home-brewed frameworks -- and indeed have been foolish enough once or twice to build my own. I've also used several great frameworks across a number of common languages.

If you can make an honest case that it's "probably not significantly" slower to roll your own framework as you develop an app than it would be to develop that same app on top of a great modern framework, then I'd love to hear it.

The software is the means to do that, and the choices you make today limit the markets that you can expand into.

I disagree with the whole sentiment around this.

First, the most critical market is the first one: until you get that, you aren't making any money.

Second, you can't guess what the changes will need to look like anyway, so any time spent preparing for the second market is time wasted from finding the first market.

The most i,portent factor in your decision really should be "How fast can I get done what I need to get done to survive as a business?"

Anything else is immaterial and really more about engineers focusing on technology instead of business.

>No, since the business objective is to make money. The >software is the means to do that, and the choices you make >today limit the markets that you can expand into.

I guess then it's a question of the benefit of taking a tactical advantage vs. the opportunity cost of that decision (including the subsequent re-write)?

I would say that the risk of limiting future markets (or more specifically a prohibitive cost of entry into said markets) is only one of many risks that need to be considered in the decision making process.

Surely there are downsides to the inevitable re-invention of what a framework does if you roll-your-own? It's not a one-way bet.

The software choices we make also enable options whilst at the same time limit others - it's a trade off.

>If you decide that you're making a mobile app for android, >then you are going to have to do a bunch of work (possibly >including re-implementing the app) to get into the iphone >or desktop market.

That's an interesting case (one I find myself peering at currently). Isn't the only real option to suck-up the fact that you'll need 3 versions on 3 platforms - or - build a product in a market that doesn't have diversity of platform as an issue (such as a browser-delivered app)? [That could be an argument against native apps on devices.]

I guess the best of both worlds for a beginner like myself is to find a framework (Django) that treats its parts as libraries (i.e. you can swap out any one part for another).

Granted, it's not completely seamless, but the option exists. Many Django programmers, for example, do not use the standard templating language available with Django.

Sadly, Django is both highly interconnected and has less than clean design. So while you can swap one bit for another, you'll still depend on all of django, and the stranger will be obvious.

A lot of useful stuff in Django also lives in 3rd party apps that depend on Django-specific things e.g. authentication or templates.

I think that point is kinda conceded in the post. The problems arise when you get to some part of the framework that cannot be swapped out. In my experience, almost every project I've worked on has got to this point. The ones that didn't were small things that were basically 'done' in under 6 months. Software being 'done' tends to be a sign of a failing business, as you've run out of places to grow into, or things to optimise. That said, I've learned a lot from working with frameworks, and I would support your statement that frameworks are great for beginners.

Disclamer: I wrote the article, but didn't post it to hacker news

Could you provide some examples? It's interesting to know what problems others come up against when working with frameworks...

This artile mentions that java is prone to the framework approach, but I found the library approach eas prevalent until around 2005. Remember the old oreilly "java cookbook"? Java developers often used the servlet spec, then went to recipes and libraries as needed. Now, the notion of a java cookbook seems to be extinct -it's largely been replaced by spring.

I actually think java's woes are largely due to the ramp up difficulties with elaborate frameworks rather than the language itself. It wasn't nearly so difficult to get started with web programming with java prior to 2005 (and I'm starting to detect a movement away from all encompassing frameworks even in java). Java will always be verbose and a bit lowish level compared to python or ruby, but I think it could be vastly simpler and easier to use.

I'm encouraged by this article, and I hope it gains more traction in other languages.

Isn't this the reason for the design of Spring (Java framework/library)?

You can work in the whole framework (slightly unusual), or just use components as a library.

There's a secondary and underlying factor important to consider: vm / language baggage. It's easy to use the cool, hip and shiny new languages, but I don't see it mentioned as an important precursor to disqualifying libraries or frameworks. I don't even think it can be dismissed as an orthogonal issue as it directly precedes the other.

As a non-experienced jvm developer,I wonder what is appeal to be locked in to a vm that eats RAM for breakfast? I tried the cool and hip frameworks in clojure and java. Just saying.

Eating RAM for breakfast is a symptom of two factors:

1. Garbage collection. It works better the more RAM it has to play with. And in return it provides pretty substantial benefits (eliminates many memory-related errors and nonproductive housekeeping tasks).

2. RAM being available in humongous amounts for very little money. Eating RAM for breakfast simply isn't a buisness-significant downside of a language/vm these days.

BTW, the Oracle JVM (and probably others as well) garbage collector can be tuned quite a bit to make it less memory-hungry at the expense of performance. Factor 2 makes this a rarely-necessary and thus little known option.

It's inversion of control (http://en.wikipedia.org/wiki/Inversion_of_control), not "reversion of control"

I think that was meant to be a joke.

It was - http://blog.orderharmony.com/2011/07/libraries-vs-frameworks...

neat! I came to a similar conclusion a while ago, but you've presented it better: http://dhruvbird.blogspot.com/2010/12/library-vs-framework.h...

Frameworks are framing, libraries are liberating :)

tl,dr: author is very happy to use clojure's ring.

"and it's the best production platform available today."

Am I wrong to be bothered when people state things this way?

Reply on news.ycombinator.com