I have chosen the wrong JS framework, now what?

I have chosen the wrong JS framework, now what?

Over the past few years there have been drastic changes in web development, lot of JavaScript frameworks have popped up. Some stayed and some have gone into the dark. Oftentimes, developers either choose the wrong framework or use the right framework incorrectly. Choosing the wrong JS framework is something that occurs often but you can avoid by simply educating yourself on the various principles, methods, and practices that you can use to make sure your framework has the functionality you need without bloated code to slow you down.

Downsides of choosing the wrong framework:

With demanding additional functionality, developers are finding quite comprehensive to handle the architectural challenges and implement their ideas with frameworks which are limited. Though they opted for wrong framework to get their things done, it is not fully secure and 80% aren’t delivering what should have been. One of the most frustrating thing is they get in trouble building applications which is far more time-consuming. By choosing the wrong one, they are finding the projects weighed down by restrictive assumptions and masses of code that they don’t understand. There is often a large percentage of code that will never be executed, or find dependency on obsolete or legacy code.

Generally there are various integrated set of tools to enable developers to develop for different types of web applications. This include usage of various javascript frameworks like AngularJS, Backbone.JS, EmberJS, and Nodejs to develop more flexible and less error-prone applications in a more effective way. Also developers given too many choices have a tendency to either not choose anything at all, or to be deeply dissatisfied with their choice. This particularly applies to choosing frameworks, because there are just so many choices, and the cost of switching is painfully high. But do we have a choice? What are the precautions one should follow ahead of choosing a framework that is not the scope of this article. The point is how to handle the wrong framework, a.k.a, OMG! moment. Let’s see what’s the opinion of developers we came across in conferences/casual encounters.

The OMG! Moment

Most of the cases, a developer will know that you chose a wrong framework only after 30%-40% of the application implementation or exposure. He/She would be stuck at a point where either the performance degraded or end up with too much of stale code or helplessly stuck with adding one more custom-helper function to the big list of “ many custom-helpers()”. That’s the OMG! moment where one would bang the desk cursing the framework (Argg!). That’s it, that’s the point where you should immediately re-think. Lot of us move ahead trying to find a work-around “fix”. Don’t! It’s going be a lot of struggle later on.

What choice do we have?
Two approaches brand new framework or write a custom library that would enhance the current framework

Yeah, true we may not have too much choice at that moment, but if and (only if) you have enough resources/time at hand. Have certain % of the time to explore other JS frameworks Let’s come to “a framework evaluation” topic in a moment. Once we narrow down on a JS framework, do couple of POCs (Proof-Of-Concept) that addresses the current concerns or a “fix” is readily provided/available in the new JS framework. It’s going to seem like an herculean task, but lot of developers have secretly agreed that it’s one of the best approach. Identify the components that are already developed and that are in the pipeline. Take a sample complex component and implement it in the new framework. Perform a quality control test or a load test with a (dummy) high volume POC.

Next, have a proper transition plan in place. Check whether such framework has enough support, documentation and resource talent available. Spend more and more time research the forums about problems developers are facing with the framework.

These frameworks add the value based features in different websites and web application development process. Most of them will have unique features specific to that particular framework in terms of platform compatibility, portability, database compatibility, general performance, security, web services, language support etc. and are suitable for key development functions. So before diving in, it’s necessary to have an idea of the most commonly used frameworks that can significantly result in more secure applications. When choosing the correct framework it important that the developer is knowledgeable about the different frameworks in terms of ease of use, rapid application prototyping, scalability, code maintenance and look and feel.

Considerations When Choosing a framework.
• Choose a framework that can be tailored and extended.
• Stick to framework ground rules: follow the documentation and don’t overwrite framework code.
• Build a framework by means of a prototype: a static internal website that includes all the page types and elements you need.
• Focus on quality assurance during the development process, and quality control to find and fix framework issues.
• Diligently maintain and update your framework, whether it’s for internal or external use.
• Anchor your documentation right where development happens.

However, each project is examined from several different perspectives including maturity, size, dependencies, interoperability, and features. If a developer does find him/her self using the wrong framework, the best solution would be to figure out which one you absolutely need, that way the mistake won’t be made again. Developers that are knowledgeable about the various frameworks and how they operate have no problem choosing the correct one and avoiding the wrong one, depending on what type of project they are working on. So take the time to educate yourself, that way you won’t find yourself backtracking and or redoing application from scratch.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>