The “Best” Tech Stack Doesn’t Exist
“Do you have a language or framework in mind?”
For a development agency, talking technology with a potential client on a potential project is a staple line of questioning. Since we’re an outside party, it’s a means to determine fit and what biases may already exist. And there’s an answer we hear more often than not:
“We’re not sure. Which is the best?”
A perfectly reasonable response, but one that demands our best lawyerly counter: “It depends.”
That’s right friends, it’s another software development article that dives into the muddy uncertainty of it depends. Here, that unhelpful-sounding reply is actually good news. Let’s take a look at why that’s the case.
The Modern Tech Stack Secret
The patterns, libraries, frameworks, and languages behind today’s web applications continue to change and mature. Somewhere in the past decade, though, we quietly crossed a threshold without much fanfare. Something that was easy to miss, even for those of us making decisions about stacks on the regular.
The major technologies — the ones on job postings everywhere — 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? Without a doubt.
And that’s a really promising state to be in because:
- 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 a given approach lean on opinions more than ever before. 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, reminding our industry of 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 considering.
The Roots of Technology Bias
A decade ago, Envy Labs was part of the Ruby on Rails or bust crowd. The upside of Rails outstripped its contemporaries in the back-end technology category, as far as we were concerned. Since, that stance has softened. Is it a viable choice? Absolutely. Is it the correct choice for every project? Nope.
If the field of usable choices is so wide, why are there so many articles, videos, conference talks, and random conversations that all seem so… certain?
To Faction is Human
Technology bias can partly be chalked up to human nature, as one of the authors of The Federalist Papers without a starring Broadway role pointed out. We really like forming groups via shared beliefs. Ultimately, stack biases make more sense if you think of them like sports teams or modern politics.
There’s a journey that comes with learning a technology. Years of trial and error, schooling, meetups, reading, mentors; proficiency in a language requires some serious sunk costs.
With a journey comes attachment. Developers want to believe their effort was spent wisely, since there’s an opportunity cost (the languages not learned) to the process.
Specialization has a community: People, companies, projects, and events that rally around a shared direction. Changing technologies can feel like losing friends — which we’re all too familiar with, having run Ruby Heroes for nearly a decade.
The Company Behind the Curtain
Angular is backed by Google, which also originated Kubernetes. React is maintained in part by Facebook. Oracle owns MySQL. The industry-defining technologies tend to have a well-known sponsor (or become a large company in their own right). How someone feels about the company behind the curtain can definitely affect choice.
Breaking Down Technology Choice
If the biases are stripped away, what are we left with? In a vacuum, how do we sort through languages, frameworks, open source solutions, third-party software, and everything else that makes up a modern stack?
In reality, 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 offers more utility?
- How fast do I really need to go?
- Which set of base options match up with my day-to-day?
- How easy should it be to work on? Do I plan on having someone else maintain it?
- How long should this one last?
And so on. Further, there’s always some new advancement on the horizon — think electric vehicles and 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.
Large Version Numbers
There’s an important distinction between viability and improvement, though. These technologies aren’t standing still: As we’ve pointed out before, much of the modern maintenance process involves keeping dependencies up-to-date.
Instead of rolling the dice on a bunch of libraries that haven’t left beta, we’re now leaning on libraries with version numbers in the double digits and proven track records.
Tooling and Authoring
At the same time, there’s a bunch of movement behind the scenes on quality-of-life improvements for developers. The tools and authoring environments — think webpack, TypeScript, snowpack, Babel, and a host of other technologies that the end users never see — are maturing with the industry and with our understanding of team composition.
So, there’s still forward motion, but it’s in specialized doses. And, this narrow progress can often be applied equally across technology stacks.
Platform Decisions That Matter
Just like our previous look into overengineering, viability doesn’t put everything on level ground for a given situation. Which considerations do matter? How do you move from it depends to let’s use this? Here are a few factors we lean on:
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.
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
You can manage data science tasks in just about any language, 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 okay 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.
While traditional apps and sports apps have similarities, sports software development presents unique challenges. Learn valuable tips to meet these challenges.