Go to the profile of Antonio Bologna
Antonio Bologna
#UI evangelist and engineer at #Rapid7, father, geek, #technology addict.

Multiple JS Ecosystems within an Organization

Generally speaking, and in practice, having 15 year of JS experience, there is a tendency, more and more, to abandon/shift technologies in favor of the new sheriff in town (a.k.a. the new kid in the block ideology). Although this can be really addictive to some front-end developers, giving them a rush of adrenaline and enthusiasm, it can also be frustrating to some others, myself included, not to mention the fact that our very own foundation and strength on having lots of innovative technological shifts, also it is our dark side not-so secret, that us UI peeps, really struggle to catch on a daily/weekly/monthly-basis.

I’ve also noticed, when speaking to other mid to highly experienced UI developers, beginners to top leaders in various framework projects and libraries, that there’s is a common denominator when transitioning to the newest frontend trend. Besides making a transition or adding another layer of complexity within a company, having multiple ecosystems, for instance Backbone, Angular, React + Flux, and many more to come, because of the advantages such as speed or ease of use, there is one other thing that adds to the formula of why we do this very often and begins the convoluted architecture of the frontend for a system or product.

Fear…

Now why fear? I noticed that, although there’s a trend to always keep innovating which is actually good, to keep changing constantly and always adapting, there’s also the fear not to keep updating the technology stack and be left behind. By knowing about the “latest” we feel secure and feel the need to embrace it, rather to look back and ask ourselves what we did wrong and how we can make it better. The idea of forgetting the old, and embracing the new, which is practically something extraordinary, and in most cases the new, fixes the mistakes of their predecessors, let us not forget that potentially and most of the times, we are overlooking the core of the problem, and what simple solutions could fix major mistakes, adding more complexity to a system by means of shifting and leave behind legacy architectures and systems, is something that cripples my mind and my ability to move forward.

IMHO, there’s no reason or practicality of using multiple frameworks and ideologies for the same functionality and/or end goal, which brings me to my next question: What is Maintainable Code?

Now you see, there’s many aspects of what maintaining code within an organization means, but they all share some main characteristics:

  1. Continuity: Rather than an on/off toggle button, meaning a binary attribute of being maintainable or not, systems need to have a responsibility of continuous readability, consistency, cohesion, so and and so forth.
  2. Understandable: A System that is easy to read and dissect, understandable to any developer in a team, to just jump in and embrace the system.
  3. Extendability: How easy is to extend the core architecture of a given system, allowing its functionality to be extended in the future.
  4. Intuitive: Large complex web apps either becomes even more complex, and hard to understand, or they embrace fundamental concepts that make them intuitive for most developers on teams. By definition, a system is intuitive, no matter the complexity of the system, making it easy to understand and extend.

“At the end, what makes a system maintainable is how much does it takes a developer to make a change, inversely proportional to the added risk of adding useless fragments of code and breaking code.”

Getting back to the main topic (I always end up deviating from the main topic eventually for some mind control reason), one reason of why an organization or multiple teams of frontend developers may choose to have two or more Javascript frameworks/libraries, is when they complement each other, such as the case of Lodash/Underscore with Backbone, Jquery and any other framework, etc…

I believe that having multiple frameworks makes the frontend system not easy to maintain, be less intuitive over time as more and more UI developers join the team, and we do not expect for them to be able to understand multiple JS frameworks, perhaps over time, and after a huge learning curve experience, trying to glue the knots, one could easily pick any piece of the system and own it.

So what is an ideal solution to all this mess you may ask; there isn’t, but there are ways to mitigate risks and future architectural complexities by standardizing early on, avoiding pitfalls during development of modular components, which could be easily shared through out the organization within frontend development teams.

Standardization is a crucial piece of the software development process, which lets teams decide on the architecture of a solid system, the tools and technology stack that all can share, and at the same time learn reusable patterns, creating a harmony through all frontend development teams across an organization.

References

Software maintenance — Clarity in Code. 2015. Software maintenance — Clarity in Code. [ONLINE] Available at: http://clarityincode.com/software-maintenance/. [Accessed 23 November 2015].

React vs Angular 2 — final. 2015. React vs Angular 2 — final. [ONLINE] Available at:https://docs.google.com/document/d/1Ah9IJ72DhV4AzoZ1TJUnMzj42PzQrLrwQUkg9koO0dg/mobilebasic?utm_content=bufferb2325&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer. [Accessed 23 November 2015].

Backbone.js. 2015. Backbone.js. [ONLINE] Available at: http://backbonejs.org. [Accessed 23 November 2015].

Angular is a development platform for building mobile and desktop applications — Angular. 2015. Available at: https://angular.io/. [Accessed 23 November 2015].

A JavaScript library for building user interfaces | React. 2015. A JavaScript library for building user interfaces | React. [ONLINE] Available at: https://facebook.github.io/react/. [Accessed 23 November 2015].