4 hidden costs in building out your tech stack

By Joe Eames

Choosing a tech stack is simultaneously one of the most exciting and dreaded tasks when building a software product. It’s a time of exploration, where your business tries new things, leaves ancient technologies behind and moves to the bleeding edge. 

It also requires facing the demons of your technology organization head on: Wiping the slate clean of stained, moldy and aging technology and ridding yourself of "technical debt" or bad code created in the name of limited resources.

While the prospect of a new project can create a buzz around a product team like nothing else can, it can also cause some anxiety among the team members. Some may wonder who will get to work in the new technologies immediately, and who will be left to maintain the legacy product. But the biggest contributor of angst when starting a new project in a new tech stack is deciding on the right technologies. 

Lately, the choice between Angular or React frameworks—or another alternative such is Vue—has become one of the most hotly debated topics. And the question “Which one is right for your project?” doesn’t always yield a straightforward path. So, let’s help you get to the bottom of your questions. Here’s the breakdown you need to choose your front-end framework.

The thing to know about front-end frameworks

First, let’s get on the same page about most modern front-end frameworks: They are all about the same. They all have essentially the same performance profile, they all have pretty much the same feature set and they all can build nearly the same applications. They’re like offshoot religions; the practitioners and pundits will argue vehemently over their differences, and may nearly come to blows, but to an outsider, the differences can be inscrutable.

The place where they differ is in popularity. This is an interesting thing to consider, because there are a variety of numbers, rankings and measures you can use to determine a technology’s popularity. One way is basing it off of GitHub stars—and by that method, Vue wins the day. But if you look at open job listings, you will quickly find that Vue is decidedly not the most popular framework except in a few areas of the world. You can look at NPM downloads, but NPM has a very low correlation to actual usage. Surveys are another place to look for metrics, but they can suffer from self-selection issues, as can Stack Overflow.

The number that really matters here is the number of professional developers using a given framework in their job. Unfortunately, this data is challenging to come by. Although it’s difficult to determine a relative measurement, one thing is certain: Angular and React are both extremely popular, and Vue is gaining traction as well. Other frameworks still exist and shouldn’t be dismissed out of hand, but these three have a significant usage from any absolute measure.

So, if you can’t choose a front-end framework based on technical differences or popularity, how can you make better decisions? By understanding the source of costs.

In software development, especially nowadays, costs are almost exclusively centered around people. Companies don’t spend as much on hardware or software as they do on salary, so being knowledgeable about talent cost can help us make the right decisions.

Determining the people cost of your tech stack

If talent is the biggest cost, then when it comes to choosing a front-end framework, the cost effects on your employees must be your primary concern. 

So how are so-called “people costs” incurred? The three big areas are hiring, retraining and lost productivity. To take a look at how front-end framework choices affect those costs, ask yourself these questions:

1. "Will my current staff stay if I choose this framework?"

If you answer “no,” this is a good indicator that the framework you’re evaluating is not the right one. The costs of rehiring and retraining will be significant.

2. "Can I find people who will willingly work in that framework?"

If so, how easily? Are they more or less costly than others?

The answer here should be “yes” and “fairly easily.” Again, the cost of finding talent is so significant that it should be a major consideration when choosing a framework.

3. "If I have technical issues, how easily can my team find answers?"

Is the framework commonly used, such that most problems can be solved with some Googling? If not, do you have a developer who can dig into the source code and find the issue effectively? 

No matter what framework you choose, you will have issues. When those inevitable problems arise, you’ll want to make sure you’re able to quickly find a solution. This is when framework popularity comes in as a big consideration factor. Is there enough usage that most common problems are already documented and solved? If so, that’s the framework you’ll want to use.

However, you can also feel confident in selecting a less common framework if you have a talented team that can dig into the source code. You’ll want at least two developers who can adequately do this. It’s rare, but not impossible to find this.

4. "Is the framework choice obviously wrong for the task?"

Is it so old that all the above are moot? Is it absolutely unequivocally unsuited to the task you need? Is it so bleeding edge that you’re essentially an unpaid beta tester? If any of these answers are “yes,” it is absolutely a poor choice. No debate.

Choosing a front-end framework doesn’t have to give you a stomach ulcer or cause chaos for your team. Using these four questions as a guide to unearth the hidden people costs of your tech stackwill provide you with a relatively straightforward way to choose the clear winner for your project—or at least avoid the absolute wrong choice.

About the author

Joe Eames began his love of programming on an Apple III in BASIC. Although his preferred language is JavaScript, he has worked professionally with just about every major Microsoft language. He is currently a consultant and full time author for Pluralsight. Joe has always had a strong interest in education, and has worked both full and part time as a technical teacher for over ten years. He is a frequent blogger and speaker, organizer of ng-conf, the AngularJS conference, and a panelist on the JavaScript Jabber podcast. Twitter: @josepheames LinkedIn: