A Framework Author’s Case Against Frameworks

It’s the year 3018 for a programmer these days, yeah a 1000 years from now is what it feels like when my proclivities now involve constantly digesting new information not in seconds, but in hertz. Now hertz is the unit of measure we use to measure frequency. Since frequency is measured in cycles per second, one hertz equals one cycle per second. Where am I going with all this? Well what I’m really trying to say is that as we add more abstraction or more information to a particular thing, the more unnecessarily complicated it gets – and in some ways this ‘thing’ actually starts to become increasingly unstable.

This post is nice and light actually, it was an arbitrary find while I undergoing my usual subconscious bombardment of various programming concepts – namely, data structures, control structures and machine language. In this video A Framework Author’s Case Against Frameworks, Adrian Holovaty, the creator of Django gives a high level example of how frameworks can further complicate things for a developer.

I’ve used Django once in my life for a start up company – I can’t really say I’m proficient with the framework, I was on a really short contract. But this isn’t really about Django really as Adrian explains in his video, this is about frameworks in general. In the javascript world, there are an overwhelming amount of frameworks, not to mention libraries that make up the javascript ecosystem, I mean check out the image I chose for this post – you’ll see npm, babel, react, vuejs etc. How’d our 1’s and 0’s turn into this? Javascript is probably the most popular highest level programming language that exists today.

Keeping up with the tech industry is like running on a treadmill as Adrian explains and I agree. You remain at a static constant pace while information grows at an exponential rate, how does one keep up?

The answer, well you you don’t necessarily need to struggle to keep up and you don’t need to run on a treadmill – well sometimes you do, exercise is good for you but you know what I mean. If you know where to spend your time, if you understand economics then you know where you should be investing your time. A method in which to use a tool is just as important as learning how to use it – this sounds a bit synonymous but things can be learned in an inefficient way and implemented in an ineffective way.

I’m not against frameworks at all – when talking to other programmers who have a technology stack dilemma, I say pick the right tool for the job. This framework isn’t necessarily better than that framework nor is this language necessarily better than that language.