Rise of frameworks & programmers' frustration

July 14, 2016 0 Comments

Rise of frameworks & programmers' frustration



Rise of frameworks & programmers' frustration

Hey have you used this X library/tools/framework it is so awesome that it lets you do Y stuff in less time and with less code and it has so awesome API, I am in love with this and I think everybody is going to use this in future.

I guess all of us have heard this one before, and due to the explosion of libraries/tools/frameworks we have seen or heard in the last couple of years, it has pissed of many developers, I have read many articles in the last few months regarding the confusion it has caused in the community and especially people are pointing out that it is happening most of the time in JavaScript, which now God knows why everybody has started hating.

First of all this is not a JavaScript problem lets get deeper into the problem

It has been caused by three main things

  1. Github (which made code sharing and so easy)

  2. Npm (default package manager of node.js)
  3. JavaScript's insane popularity (it is known as the language of the web)

Due to this reasons the problem seems too magnified for JavaScript but what many developers miss is that if any language who does not have a good package manager and who is not so popular wont have this problem because well many people wont be using it duh!!

Bad parts of Modern Front-End Architecture

At the same time we cannot ignore the rise of so many JavaScript libraries that it has created certain kind of confusion and fatigue(yes fatigue read this to understand). Gone are the days when you could just add a <script>to add JavaScript and a <link> to add CSS to HTML file and you were done. Currently if you are going to work on a production level project you will at least need

  • grunt/gulp

  • coffesript/typescript,
  • postcss/less/sass
  • jade/handlebar/ejs
  • Angular/React/Backbone/Ember
  • underscore/lodash
  • bower/npm and finally
  • browserify/webpack

Just try to understand a beginner level developer coming into your company he/she would surely get overwhelmed by this.

So should we throw out those frameworks?(and go back to stone age??)

Not really,all the tools mentioned above are tools/frameworks developed by really smart engineers and if you look under the hood the code is well documented ,easy to understand and the engineering that they have done while developing sometimes inspires me. if you have doubts click on the below links to find how many awesome web applications have used these tools/frameworks.

This list goes on and on, the problem that happens most of the time is that developers end up using hammer (not hammer.js!) for screwdriver, we decide frameworks and tools even before we know what exactly what we are supposed to build! That becomes the biggest problem.

I have seen some applications which is a multi page application, has back-end rendering, doesn't really need data binding and still uses Angular.js and I don't know how they have used it and why they would want to use it?

And in the past one year I have seen die hard React fans who have decided in advance that they are going to use React no matter what. Sorry guys but React is not a God tool, It is a very good and has multiple use cases but you don't need to fit your application into the structure of React/Angular/Backbone but it should be the other way around. A wise man famously said:

Know Exactly what are you building before you decide to use any of this cool stuff. (credits : John Doe)

When you don't Exactly know what you are building

"Yes these are some nice thoughts but my friend works at this ACME corp where they have those requirement documents and they know what they are really going to build, but I work in a startup and the thing we are building constantly changes".(said a friend of mine)

Slack/instagram/Groupon/pinterest and many other successful startups have one thing in common they intended to build something and the final product they came up with was something quite different. They failed fast and pivoted to something else and the rest is history. If you are working under such circumstances of uncertainty, MVP or prototyping is your best friend.

Prototyping/MVP(minimum viable product)

Is something that can come to the rescue for all of us. Build a prototype as fast as possible and test it out with your users (not your team) to see if it is actually working or you need to make some dramatic changes in your tech. That is the best you can do but don't try to fit your application inside a framework or you will regret when you will be 60-70 % into your development cycle and there will be no going back.

So which frameworks/tools to use when prototyping or while building MVP?

The tools or technologies that you and your team knows and are comfortable using it and don't use many of them while building MVP only use technologies that if not used will make your life harder!

Is this a full proof way?

No, after you have gone through this process and you still choose wrong technologies to work with then that will be on you and your team(who will blame them on someone else afterwards!) but at least you will have an informed decision, Now if product/service does not work the way it is supposed to you wont be able to blame the technology and wont spread the poison on web with your thoughts on why Angular is bad or why using typescript is too much or why there is too much to do just to start using React!!

Hope you have enjoyed the article, thoughts and suggestions are always welcome

Found this post useful? Kindly tap the ❤ button below! :)


Shashwat, Software Eng. Gridle

Tag cloud