Software Frames

1. As I read it somewhere, nowadays, there are more
frameworks than the developers.Now, this is an obvious
exaggeration. But observing the speed with which
especially Javascript is evolving day by day, and this thing
which was once used for chores like simple client side
validation, resizing and positioning of HTML elements etc.
have slowly crept at the server side and using browsers as
a playground, can do so many tasks for which, dedicated
software packages were required earlier is simply amazing.
Apart from doing traditional works , web developers are
supposed to do, they can carry out complex mathematical
1

2. and statistical operations, draw simple to complex
engineering drawings and other vector drawings, 2D and
3D. Physics, inorganic and organic chemistry?
Yes, there are libraries for that. Animation? Yess, there are
libraries like THREE.JS which do very detailed animation.
And so on.
I noticed, I have inadvertently mixed the terms "Library"
and "Framework". The difference between these two and
some anther terms like "Content Management System"
are subtle but important. And sometimes, hybrid words
like "Content Management Framework" are also seen.
What exactly is the difference? Will be elaborated in
another post.
With so many libraries and frameworks, although coding
has become easy, it is virtually impossible to know them all
at a time. So what should one do?
I will say, atleast for some kind of libraries, GO BACK TO
THE BASICS.
If you want to master some MVC (Model, View, Controller)
libraries, first know thoroughly what is MVC. MVC is here
for many years, and is used for not only web development,
but also for desktop development. If you are not familiar
with MVC, this is a golden two in one opportunity for you
to learn MVC using particular JS framework.
If you want to use some JS framework for implementing
2

3. OOP, then knowing what OOP is, is a must thing. The
better grasp you have on the basics, the better you can
work and swiftly switch between frameworks.
Majority, or almost all learn a concept by actually
implementing it. If, inheritance in OOP is implemented in
one way somewhere, and we tend to limit our perception
of inheritance only to that. If the need of the hour is to
implement it that way, we should do that, but we should
also keep us aware that there are other ways too.
To conclude, we should not perceive a thing based on how
a thing is implemented somewhere but should try to see
the broader picture and try to know what is the thing that
is implemented. Fast paced world and tight delivery
schedules not always allow us to do so, but we should
atleast be aware of this.
And this is not only true for software frameworks but
many other things as well. I am trying to avoid being too
much philosophical here and so not touching examples in
day to day life. But one more related example. In CAD or
Image processing software, various things are placed on
various layers. originally, layers are like a transparency
sheets stacked on each other. In some packages, one layer
can contain only one type of object ie. either texts, lines,
points etc. In some others, a layer can contain some lines,
some texts, some circles etc. Now, if you use some
package long enough, your mind is "framed" for that kind
of Layer. Now, if you change your package, it takes quite a
3

4. long to drag your mind out of that frame.
So, the bottom line is, although using framework saves a
lot of time, it imposes inflexibility and monotony in the
end product. And most important, your mind gets framed
for that framework.
4