The “Best” Tech Stack Doesn’t Exist

“Do you have a language or framework in mind?” The technology talk is a staple line of questioning in the pre-project phase for a potential piece of software. As an outside party, it helps us determine fit, pick out biases, and put the right team together.

“We’re not sure. Which is best?” is a common refrain. Normal and sensible, but a response that triggers an equally vague answer: it depends.

That’s right friends, it’s another software development article that dives into the muddy uncertainty of the phrase “it depends.” In this context, though, that less-than-helpful reply is actually good news — and we’ll start by unpacking that claim.

The Modern Tech Stack Secret

The patterns, libraries, frameworks, and languages behind today’s web applications are in constant motion. It’s still a young field, but there’s a reverse entropy of sorts: The underlying tools keep maturing, even as the goalposts of expectation shift further and further out.

It’s hard to pinpoint, but somewhere in the past decade we crossed an important threshold — the “secret” this section’s title alludes to. Leading web technologies have hit a point where they’re all viable options. Will Ruby work? Sure. PHP? Yep. Elixir? Awesome. Can we add React? Absolutely. Angular? Mmhmm. Could these examples continue for a while? Long enough to hit any term paper word count.

It’s a really promising state of affairs:

• The cycle of adoption and deprecation has slowed. Your dependencies eventually may not be en vogue, but it’s less likely that they’ll disappear completely before it’s time for a rewrite.
• The pros and cons of different options mostly come down to opinion. Take styling as an example, where atomic- and component-based methodologies are both perfectly correct, and largely chosen on preference.
• Every stack has a success story, underlining the most important thing: The end user doesn’t care about what’s under the hood.

Now, those are all reasonable-sounding bullet points, but developers everywhere are still pretty devout in defending their technology of choice. For someone setting a product’s vision, it’s a chore to sort out which biases are worth hearing out.

The Roots of Technology Bias

We’ve been guilty ourselves — Envy Labs was part of the Ruby on Rails or bust crowd at its inception. As far as we were concerned, the upside of Rails put it a tier above its contemporaries. Since, that stance has softened. Is it a viable choice? Absolutely. Is it the correct choice for every project? Nope. (But was it the best thing back then? Yep.)

If the field of usable choices is so wide, why are there so many articles, videos, conference talks, and random conversations that seem so… certain?

Technology as a Team Sport

Technology bias can partly be chalked up to human nature, as one of the authors of The Federalist Papers without a starring Broadway role (James Madison) pointed out: “The latent causes of faction are thus sown in the nature of man.”

We really like forming groups tied to shared beliefs and circumstances (and making them part of our identity). If you frame devotion to a coding language like you would sports teams or modern politics, the biases make a bit more sense.

The Company Behind the Curtain

Google backs Angular. Kubernetes, too. React is maintained in part by Facebook. Oracle owns MySQL. The industry-defining technologies tend to have a well-known benefactor, or become a large company in their own right. Whether you’re a fan (or detractor) of the company behind the curtain may flavor your opinion.

Sunk Costs, Opportunity Costs

There’s a journey that comes with learning a technology. Trial and error, schooling, meetups, reading, mentors: Proficiency in a language requires some serious sunk costs, and attachment follows the journey. Developers want to believe their effort was spent wisely, since there’s also an opportunity cost (the languages not learned) to the process.

The Surrounding Community

Specialization comes with a built-in community of people, companies, projects, and events that rally around a shared direction. Changing technologies can feel like losing friends — personally, we miss seeing the regular attendees at conferences like RubyConf and RailsConf.

Breaking Down Technology Choice

If the biases are stripped away, what’s left? In a vacuum, how do we sort through languages, frameworks, open source solutions, third-party software, and everything else that makes up a modern application stack?

It’s a lot like buying a new car. They’ll all get you from point A to point B, but with varying levels of fit:

• Do I need something that’s efficient on gas mileage, or a vehicle with more utility?
• How easy should it be to work on? Do I plan on having someone else maintain it?
• Which set of base options match up with my day-to-day?
• How fast do I really need to go?
• How long should this one last?

And so on. Further, there’s always some new advancement on the horizon — electric vehicles, autopilot — that are worth considering if you have the appetite for early adoption. The current standards won’t disappear in a hurry, but they’ll phase out eventually.

Tooling: the New Outlet for Change

Before diving into bias-free decision points, let’s take a quick detour.

The rise and fall of core languages, frameworks, and libraries has slowed, but that chaotic energy has shifted to the stuff behind the scenes. The tools and authoring environments — think webpack, TypeScript, snowpack, Babel, and a host of other technologies that end users never see — are maturing with the industry and with our understanding of team composition. So, there’s still forward motion, but in specific doses.

Platform Decisions That Matter

Just like our previous look into overengineering, viability doesn’t put everything on level ground. Which considerations do matter? How do you move from it depends to let’s use this? Here are a few factors we lean on:

What’s Being Solved?

With a large pool of options to choose from, grabbing the one that best fits the problem seems like a no-brainer: Where’s the complexity in this app, and which bit of tech tackles that best?

Through the Paces

Has the team actually applied this technology to a big enough problem yet? We’ve been there (more than once) — a new library sounds perfect to tackle a longstanding issue, and the seams don’t show until midway through the project.

Adoption Curves

How new (or old) is this bundle of code? Deprecation may be slower these days, but that doesn’t mean that we still need to bring jQuery along for the ride. Similarly, new libraries may need a bit more time to bake before you commit to them in production.

The Right Community

Which community best represents a given problem space? You can manage data science tasks in just about any language, for example, but the resources you’ll find with Python or R make the task much, much easier.

The Internal Ecosystem

It’s really tempting to try something new on a fresh application, but what other systems does it need to exist alongside? What stacks already prop up the rest of the organization?

Everything Isn’t a Nail

On the flip side, interoperability, integrations, and microservices make a distributed system — with distributed technologies — easier than ever. It’s more than ok to consider a new stack when there’s a clear advantage concerning the problem at hand.

Beware Absolutes in Web Technology

Conference talks, blog posts, podcasts: It’s easy to feel a bit of despair in keeping up with the software industry. Everyone’s talking about (and surely using) all of this new, specialized technology, and there’s no clear consensus on which is actually best.

In practice, everything’s way messier. Every large company we’ve worked with has a number of junk-drawer-esque apps running with different technologies. Heck, we’re using PHP for this site despite it not appearing on any client projects. The right choices continue to depend on circumstance.

With a field of viable options that’s wider than ever, developers are able to situationally pick an approach and draw ideas from the others. It’s rare to find something that’s just flat wrong, and with that, the idea of absolutes with web-based technologies continues to fade away.