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.
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.
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.