Frameworks, libraries, dependencies and philosophies

In these days, at the company where I work, we are discussing about which front-end framework to adopt for our projects.
The two candidates are currently AngularJS and Backbone, but the discussion has stimulated my thoughts about libraries and frameworks in general and I want to speak about this topic and about opinions from colleagues and other people working in the IT whose I disagree . (I’m such a badass that sticks to his ideas until someone is able to provide me a far valid, far exhaustive and far more convincing list of motivations than mine).
So, in this post I would like to express my point of view about frameworks, libraries and dependencies in a language-agnostic way.
First of all I want to provide the definitions of “framework” and “library” in order to be sure that you (the reader) will consider these terms as I do. I’m providing them by taking inspiration from a relevant question on StackOverflow: What is the difference between a framework and a library? and by arbitrarily rearranging the responses in that discussion in order to provide a more personal and deeper definition.

Library:

A library performs specific, well defined operations like handling http connections, data serialization, cryptography and so on. It’s composed by several classes and/or functions and you (the developer) have the control over it, you decide when and where to call such “utilities” in your code.

Framework:

A framework is instead far more complex than a library and it offers a lot of different functionalities. It follows the so called “Hollywood principle” (if you love buzz words like many “chatterboxes” do) for which you (the developer) don’t have the full control over it, but instead you have to follow and agree to the concepts and procedures defined by the framework. A framework goes beyond the programming language, it has its architecture, its philosophy and is composed by different layers of code (and often also by different languages and technologies, it could be composed by a mix of Python + JavaScript + HTML + SQL + YAML for example).

So, by comparing AngularJS with Backbone we are comparing two different things, since the first is a complete front-end framework, it offers all that you need to create a JavaScript application (templating, controllers, data binding, localization…) and you don’t have the “low-level” control on the code, since you don’t manually create instances of your controllers neither you render your UI components (it’s the framework that does the work for you when it’s ready), on the other hand Backbone is just a library which provides an abstraction layer on the MVC design pattern, but you have to use several third party libraries to handle dom manipulation, templating, cookies and so on.

Now, I want to report a series of sentences coming from ideas/doubts/observations I heard/read on the web or by colleagues and below each one I will reply with my opinion.

1. Does I need a framework to do X?

If you are a professional developer (or you aim to be) which is implementing something else beyond an “hello world” demo, you should absolutely use some kind of framework to do your job!

2. …but I don’t want to use a framework, I prefer to write my code from scratch

Writing code from scratch is an useless waste of time and effort! Why should you re-invent the wheel each time? Why don’t rely on a tool which already exists and effectively solves common needs for an application development and that’s already developed, used and tested by a lot of people (who have a strong experience on the involved language and on several aspects of developing, like: performance, security, scalability, maintainability and so on)?
And if you choose to write stuff from scratch, unless you are writing a pile of shitty spaghetti code, in the end you will implement some kind of abstraction layer in order to reuse functionalities in your app… so you will build your own framework… so once again: why don’t you use something that already exists and it’s being actively developed, tested, patched and for which people are writing extensions, tutorials, plugins and are constantly reporting issues and experiences?
I have to say that I was myself guilty in the past, I was used to write all I needed from scratch, only because I’m able to do that and I felt somehow “stronger”, “smarter” by acting that way… but it’s not the truth. The truth is that using a framework consciously is an evidence of being a mature programmer, who understands that is better to invest time on application specific features rather than writing low-level common utilities.
If you are an experienced programmer who love to write low-level API, it’s more useful to contribute to these frameworks, since they are usually open source projects available on github or write “plugins”/”extensions” for them.
Don’t reinvent the wheel, even if you can do it better, please avoid it, it’s a waste of time if you are alone (the development it’s only a part of the work, you have to maintain it, document it, fix bugs and so on).

3. Frameworks are hard to learn, I prefer to use a bunch of small simple libraries

That’s true, frameworks require a considerable time investment in order to be mastered by the developer (I learned Python in 2 days by myself and it took some months to get confident with the Django framework for example), but definitely it worth! You will be far more productive once you get used to it, you will write less code, in less time and without to worrying about how to design your application skeleton because is the framework itself which provide you the path to follow. On the other hand, learning a library is quite simple, but that’s just because libraries are focused on a single limited scope.
I don’t like to introduce many dependencies in my projects, I usually rely on third party code only if it dramatically improves my productivity and this is where a framework comes into play! It’s just one dependency, yes an huge dependency, but I can trust that each components it provides works as expected, since they are tested by the team that developed the framework and by people that use it, on the other hand by choosing several libraries arbitrarily in order to compose my own software stack, I’m not sure that each component will works smoothly as expected.
Let’s suppose to use libraries: A, B, C, D… how can I be sure that C hasn’t some kind of conflict or subtle incompatibility with A, B or D? Theoretically if A, B, C and D are just simple libraries that handle one and only one specific task, there won’t be any issue, but from my experience I can say that theory and practice are two different things… such issues are a concrete problem and this is specially true if we are using a dynamic scripting language like JavaScript (or Python, Ruby, PHP and so on) in which you can write atrocious hacks like runtime classes/functions (re)definition, variables overriding and so on. The worst thing is that such issues are often very, very, very HARD to spot!

4. A framework is heavy and I think I will use just use a little part of it… it’s overkilling!

Someone talks about monolithic frameworks and considers projects like Django (talking about server side stuff) or AngularJS (talking about client side stuff) overkilling so prefers to use multiple dedicated libraries. In my opinion you will never use a framework at 100% of its capabilities, but if you are not taking advantage of at least 50/60% of its features, this means that your project is so tiny and simple that you really just need few things or, if that’s not the case, you are therefore writing by yourself functionalities that are already provided by the framework and you are not aware of (or that you deliberately decided to not use).
Adopting a framework is an important choice that must not be taken easy, it must be carefully considered, planned, discussed.
As I said in several occasions to other colleagues, the adoption of a framework is like a marriage, you know that won’t be the perfect one, like there won’t be the perfect woman/man of your life, but anyway you found the one you like the most and that provides all or many of the functionalities you need, but of course it has also some flaw or trait you don’t like.
So the point is that you have to evaluate all these aspects and once you choose a framework you have to “get along with it”, you have to share its philosophy and style and you have to use it like it’s expecting to be used, otherwise you’ll find yourself struggling with the framework in order to make it behave like it hasn’t been intended to behave, and you’ll waste time and effort you could spare.

5. Ok, let’s use a framework or a set of libraries… but I want to be able to switch from one to another easily, so I’m gonna write some wrappers/adapters!

Switching from a framework to another in a big project will never be easy (that’s why you have to choose it carefully)! Writing an abstraction layer by creating wrappers around original API is in my opinion a waste of time! Don’t get me wrong it’s not about laziness, but instead because I’m a pragmatic developer who doesn’t live in a magic world where ponies run on the rainbow, I decided instead to take the pill from Morpheus which brings me to the real world in which I’m aware of the difficulty/impossibility of maintain such code base (that in the moment in which you have actually to switch the underlying framework will probably reveal its fragility and uselessness).
In my opinion, this approach is not agile, this is not feasible at all… it looks to me just insane!

I think that I said all I have to say about the topic, I hope you enjoyed my post and I would like to read your point of view in the comments.

Django 1.6 has been finally released… these are the changes I introduced into my codebase

Django 1.6 has been finally released, but this update is quite obtrusive, in fact…

Issue n.1: tests not found!

the dev team has changed significantly how unit tests are discovered and my old approach stopped working (no tests to run found).
In my previous system I created a “tests” package for each app in my project, in these packages I created a test class for each tested class, named like “TestClassName” and I exposed these classes at “tests” package level by customizing its __init__.py file.
But starting with Django 1.6 the default test runner doesn’t care about “tests” modules/packages, it looks instead for file matching the pattern “test*.py” and since this pattern is CASE SENSITIVE (aaaarghh!!!) my test CLASSES (so they start with an uppercase letter) are ignored! Fortunately is very simple to override the default runner in order to match another pattern :)
This is my custom runner:

from django.test.runner import DiscoverRunner

class TestRunner(DiscoverRunner):

    def __init__(self, pattern=None, top_level=None, verbosity=1, interactive=True, failfast=False, **kwargs):
        super(TestRunner, self).__init__('Test*.py', top_level, verbosity, interactive, failfast, **kwargs)

and in the settings module:

TEST_RUNNER = 'myapp.TestRunner.TestRunner'

Issue n.2: PyCharm Django Tests configuration is now broken!

If you are using PyCharm as your python IDE, the “Django tests” run configuration is now broken (honestly I don’t understand why the guys of JetBrains have set up a such perverse way to run Django tests by writing their own python modules LOL)… so I defined a simple python run configuration in which I call “python manage.py test“… it’s not so pleasant, like the Django tests run configuration because is basically the same output of the shell script without the “green bar” and the red/yellow/green buttons that show the results of the run tests… but at the moment it does the job, and the important thing is that, differently from launching tests from the shell I can use breakpoints in the IDE to stop code execution and debug the situation! (like before)
Uh… the good part is that now my tests are executed ~40% faster!!! (10 seconds vs 14 seconds in the old run configuration)

Issue n.3: Where is gone GeoIP?!

Another problem I faced is that the GeoIP wrapper around MaxMind api has been moved from django.contrib.gis.utils to django.contrib.gis.geoip (and this change seems not documented in the release notes!)