When I first started this chapter the intent was to convince developers to favor the mastery of patterns over frameworks. As I began to write this chapter and explain more about frameworks, I began to rethink my approach. The content naturally lent itself to teaching about how to use both of these tools in a toolbox versus persuading to avoid one of them altogether. Now my goal is to teach you how to use both of these concepts to your advantage and further develop your ability to be a competent engineer.

There will always be a new kid on the block when it comes to programming. Taking part in this career means understanding this reality and learning how to navigate it. When I first started writing code, C++ was the probably the most popular language in the world. Then out of nowhere a new contender named Java came to challenge the throne. Like many upstart programmers, a sense of panic started to make its way into my mind because I feared that learning another language would be a formidable challenge (especially since I barely new C++). After some time, more new languages started to gain traction and visibility. Staying current with the flood of new technology ushered in the sense of playing whack-a-mole! As soon as I felt like I caught up with what was currently happening, more things started to pop up! I’d love to tell you that the engineering world has come to its collective senses and everyone decided to just stick with one language but I can’t. Not only would this be untrue I would even go so far as to say that the problem has amplified itself! With the widespread adoption of open source collaboration and the ability to publish whatever you want to the internet (yes, this book included) there are new languages all the time, and there seem to be no signs of this trend slowing down.

These days JavaScript is the new king (or queen if you fancy) of the hill. I’m confident that noses immediately jutted towards the sky upon reading my introductory statement. JavaScript has become pervasive in its reach and exposure. The JavaScript ecosystem is robust and still growing rapidly. There are hundreds of frameworks available to meet nearly any development need. With the vast number of options, only one thing is for sure - it is a daunting task to know which framework or language to choose, and even more daunting is knowing which are worth looking into and learning!

Angular by Google is one of the newest and most dominant JavaScript libraries in the world but right on its tails is React by Facebook. React is gaining a lot of ground and getting a lot of exposure. The story of “the new hotness” doesn’t end with React and Angular. Many other libraries exist with their dedicated communities and diehards. So what is a motivated developer to do? How would one know what to learn and what to ignore? The answer to that requires that we think about what’s at stake and choose a plan that has the most longevity. What is at stake in the JavaScript framewars (coined it!!)? Your time is what’s at stake. Time is a finite commodity and wasting it is undesirable.

Everything is about choosing the right tool for the job; choosing the right framework for the project/task. When buying into a framework, one has to acknowledge the impact it has on the codebase, the skills required to use it and the opportunity cost of having to remove it if (when!) that time comes. Remember to keep a keen eye on the larger picture.

It can be a significant challenge to know the impact a new library will have on your code base. I’d argue that this is all the more reason to remain gun-shy when it comes to committing to a new framework. For every one thing a new library does well, there is a less obvious use case that will be encountered assuredly in your project that exposes the significant shortcomings of said library. I’m not harping on a single library so much as sharing the modern reality of library-heavy design and development. Being skeptical about the promises of any tool is healthy. Oftimes a framework dictates code organization and structure. In other instances, it alters the build process or mandates the inclusion of new dependencies. The library works its way deep into your codebase like roots of weeds. As your use continues, the influence it has over your processes deepens. This may not be a bad thing, but we must remain aware and be diligent in the outset in identifying these changes. There are ways to organize code to mitigate the effects of this influence. These strategies require the implementation of some design patterns at the start. One such strategy is to do a partial buy in so that removing the framework is easy. Use the minimum features you need. Take TypeScript by Microsoft as an example. It offers syntactic sugar as well as transpilation allowing developers to use newer features of JavaScript now even though one may have to maintain support for legacy browsers. Perhaps the use of the proprietary features is not as appealing as the transpiling process. You can decide to use only the transpiling features while being mindful to keep out any other parts of the library. Therefore, when the circumstances change (i.e., no more support for older browsers), you’ll remove TypeScript from your build stack. This non-invasive approach gives you the best of both worlds.

Along with considering the impact the library or framework has on the codebase, we have to consider the impact it has on the team. One of the motivating factors behind JavaScript’s infiltration throughout every part of the stack (e.g., frontend, backend, database, mobile) is the realization that developers prefer to work within boundaries of things they already know. Many developers have vast amounts of skill reuse inherently within the JavaScript ecosystem. The amount of reuse isn’t limited to JavaScript. C++ developers, for example, can find cross-platform skill reuse as well. Being able to use a language one is familiar with breaks down many barriers to entry. The familiarity has an inviting sense to it. It can lead one to think, “what other things can I do with this language I already know?” Choosing a new library/language that requires your entire team to learn a new whole new skillset can be a deal breaker. Existing familiarity with a given language is a good start but not the end of the debate. We cannot unobtrusively introduce a library merely because all of the team uses the implementation language. It is important to understand where the library itself fits within the skillset of the group. As mentioned during the discussion on the impact of a framework on the codebase, we still have to consider that same impact on the workflow of our team members. The Spring framework by Pivotal offers a streamlined way to do many things, and one of those features is dependency injection. If team members aren’t familiar with how to use dependency injection or why it is beneficial, we find an environment in which misuse of the library is likely to occur. I am not above reproach in this scenario because I have avoided many a library feature that I didn’t understand!

What steps can we take to lessen the impact of the skills gap created by the technology? I say technology here because it can be the result of a new language, library or framework. First and foremost, the onus is on you as the champion of this change to come up with a roadmap for how the new technology will be used and how it will fit in with the team. Identify the problem it will solve and think critically. The fact that you are fond of the tool is not enough. Consider ways well to help your team members be successful during implementation time. This includes coming up with code samples, documentation and even a proof of concept using an existing problem your team faces. Be open to feedback and understand that this can be a sensitive process especially if there are people on your team that are resistant to change. Bringing in new technology to your team doesn’t have to be as challenging as passing a bill through Congress. Understanding your why helps to smooth out the process.

Though this chapter has focused heavily on languages, libraries, and frameworks it is certainly worth mentioning the role that patterns play in the grand picture. Software design patterns are long lasting, reoccurring parts of your learning and careers. If your team does not allow for adding a given technology to the process, it is always valuable to know the types of design patterns that you can put into practice to solve problems. Many times a library merely abstracts a design pattern and does the heavy lifting for you. While convenient this too can lead to trouble. What happens with the technology is malfunctioning? Having no understanding of the underlying foundation means that we won’t be able to do advanced debugging and problem-solving. Remember, libraries are written by developers just like us - humans.