As many of you know, I'm a big fan of superhero movies. For the most part, I'm a fairly easy customer when it comes to this type of film. I don't really care if the movie conforms to the comic book that it was derived from. I don't really care if it fails to conform to the laws of physics or reality.
What I expect is that it have a decent story with a decent plot and isn't too convoluted. Some of my favorite superhero movies include Guardians of the Galaxy, The Avengers, and the Captain America Films. My least favorite films are Iron Man 2 and 3, Batman and Robin, and most of the Spiderman sequels. There's a simple reason the aforementioned films are not to my liking: too many plotlines. Each of the films have too many bad-guys (each requiring a sub-plot) that the protagonist has to deal with and none of the sub-plots is served well by the film, often making no sense whatsoever.
This is also how I feel about the current state of JavaScript frameworks.
Did you see what I did there? I went from superhero sequels to JavaScript Frameworks in one fell swoop. As software developers, we live in a world with too many plotlines, that is, too many JavaScript frameworks. Let's take a look at some of the big-name frameworks and the catch phrases that their developers use to describe them:
- Angular JS: A super-heroic JavaScript MVW framework
- React JS: A JavaScript library for building user interfaces
- Ember JS: A framework for creating ambitious Web applications
- jQuery: The write-less-do-more JavaScript library
- Aurelia: The most powerful, flexible, and forward-looking JavaScript client framework in the world.
You see, all you need to do to be a super-heroic, ambitious, forward-looking JavaScript developer is to pick one or all of these frameworks. Bleh! What's a developer to do? I say: Choose very carefully.
In the Sep/Oct 2010 issue of CODE Magazine, I spoke about technology risk in my editorial “So You Want to Be a Consultant: Risk Management” Specifically, I stated:
As a consultant, it's your responsibility to stay current on the technologies available. This responsibility comes with a high degree of risk. Learning new technologies takes a considerable amount of time and some technologies might "die on the vine."
This was true then and it's true today. When you choose to use one of these frameworks on a project, you're adding a huge risk to the cost of developing and maintaining your Web applications. Here are a few issues you need to consider.
Framework Churn
You need to look at the rate of change that happens on these frameworks. Every release of a framework has a chance of causing regressions in your applications. Do you have adequate testing procedures (automated and manual) to ensure that new releases of the framework cause no regressions?
Breaking Changes
Last year, there was quite a controversy regarding the changes being made to the Angular JS framework. As it happens, Angular-JS version 2 was a fairly radical departure from version 1 of the framework. What's the migration path for developers to move from 1.0 to 2.0? Is there a migration path or are 1.0 developers just stuck? This is a huge risk when adopting a JavaScript framework. You might need to be ready for “planned obsolescence” when it comes to your framework choices.
Community Adoption
The rate of adoption of contributes greatly to the success or failure of all developer tools. Before you adopt a JavaScript framework, you might want to check Google or Stack Overflow for support requests, tips, tricks, etc. It's guaranteed that you'll experience roadblocks when building with a framework. Will you be able to solve your problems quickly or will you be stuck being a pioneer solving each unique problem you face on your own?
Application Bloat
In his article “Why Micro JavaScript Libraries Should be Used in Your Next Application,” (CODE Magazine, Jan/Feb 2015) Chris Love wrote about the bloat of many JavaScript frameworks and why using a micro framework might be a good idea. Many of JavaScript frameworks are “fat” which increases the download size of your applications. If your website has a smallish set of users, this might not be a big deal. If your website has a large number of users, this could be quite an issue and needs to be considered in your risk assessment.
CODE Magazine's Commitment
As a magazine built by and for developers, CODE Magazine will continue to explore these frameworks in our pages. We'll work to create content to help you make decisions about using these frameworks in your Web applications. We'll remain agnostic to what framework we promote (for instance, we have articles discussing both Angular-JS and Aurelia in this issue). We'll do our best to help you guide your development practices through the numerous plotlines being written even as you read this issue.
