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.


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.


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.

AIR applications logging… my own extension to Flex’s logging framework

Finally it’s time to release my little project and my first personal and public Actionscript library.
What I’m talking about? I realized a little “subframework” which goal is to extend Flex’s logging framework, in order to write log messages to files on the disk and provide a custom Flex’s UI component (which can be easy used into every AIR application) to read/filtering these log files.

Learn more here:

Just a note: although I tested the library (windows and mac) and it works fine, this project may contains bugs or doesn’t work under some circumstances. Comments and feedback are welcome!

Converting Java to Actionscript… maybe is not so hard (I hope)

After valuate my own realization of a certain library, I opted to try the porting of an already existent one… which is made in Java. This library has a lot of classes and interfaces and the manually translation would be very time-expensive, considering also that it uses a lot of classes and functions which are unavailable in Actionscript 3. Fortunately I found a small and useful AIR application which automatically converts .java files to .as files (the application is here:, this application anyway helps a lot but many extra-work is required to properly convert the classes… for example Actionscript has not the abstract key, variable can’t be market as final and so on, so we have to manually adjust these issues. Another useful stuff I found is an Actionscript library which aim is to provide to AS3 developers the same (more or less) features and power of Java Collection framework, which provide classes like HashMap, ArrayList, LinkedList and so on (the library can be found here: Despite these helps I’m still facing some incompatibility issues… classes/methods AS3 is missing, but implementing them by myself is quite simple. For example I implemented the Java’s System.arraycopy() in 2 minutes, by following the JavaDoc ).

In conclusion Actionscript and Java have a  lot of stuff in common, the syntax and structure is quite the same, except for some issues like abstract classes and methods, multiple methods and constructors declaration (override). The main difference is that Java provides an huge number of Classes that Actionscript doesn’t, however it seems not so hard to translate Java code and implement Java functionality in Actionscript.

I hope I won’t have to deny my words :)