Async with William: When and How to Evaluate Tech Stacks for Your Organization

A Discussion About How We Do This for Clients, at Tonic

Hello and thank you for joining us for today’s episode of Async Weekly! This is a standard chat I, your host William Holt and a UI Engineer Lead at Tonic, lead for our various disciplines, prompting discussions on relevant topics to our team in a way that’s unobtrusive for their day. (Hence the Async nature.)

This week, Tonic’s engineering team dive into the pros and cons of evaluating a tech stack for a client. What should be considered? At what point do we take account of new technology available, and when should it be considered viable for a real world product? Let’s see what our experts have to say!

Have a question our experts should discuss? Drop us a line!

Kyle Weems (Lead, UI Engineering)

First off, there is a difference between inheriting a project with its existing tech stack and obtaining the mystical Greenfield projects where we bring the stack with us and intro to the client. Which avenue?

William Holt (Host)

Great clarification — As Tonic does both, we can discuss both, and throughout all applicable platforms and mediums. One involves evaluating our own team’s skill sets while the other regards how we fit into an existing stack.

There are instances of us bringing the frameworks and coding languages with us, relying on our current skills, but there is also the world where we are diving into a newer tech, Vue in that instance. What are the deciding factors on what is used, and why/when building a product?

Dusty Fields (Lead, Mobile)

A few things I look at from a mobile perspective — For Greenfield projects, is there a need for both iOS + Android? If so, what kind of architectural alignment can we do between the two platforms to ease development? Not just talking about feature parity, but actual architectural decisions. With Swift and Kotlin being very similar in many ways (and also different in others), it’s nice if devs can switch code bases and understand what is going on.

Are there any shared libraries between the platforms? What about the backend? Can it work for both?

As for new projects, I try to push for the direction Apple is pushing us. Mostly because I know Apple will build and enhance tools around that new technology, but also impose requirements for apps to adopt in the future in order to be in the App Store (this is a whole different discussion about what Apple should and shouldn’t do here — tune in to a future Asyc for app store requirements and regulations).

For existing projects, we’ll look at users. That’ll be the big driver for decisions moving forward. What devices are they using? What operating systems? Are there any dependencies in our stack that will affect decisions? What is the development and business cost if we keep legacy users around?

Chris Mancini (Chief Technology Officer)

And things to consider when evaluating tech stack for clients —

• Hiring capacity beyond Tonic, when we hand over the keys, can they find someone to hire internally or externally to continue working on the stack?
• Does the tech we’re considering have an active development cycle behind it or are the commits a year old and abandoned, etc?
• How well documented is the stack? Can a noob just jump in and code on it without prior knowledge if they have the right documentation?
• What are their competitors using? What skills are their competitors hiring for right now?
• What’s the upfront and long term monetary costs for the tech? Open source, one-time license, ongoing monthly payments, etc?
• Does the tech EULA fit with the clients business requirements/needs?

Kyle Weems (Lead, UI Engineering)

For web in general, JS framework discussions can get a bit intense and silly, to put it mildly. However, factors I like to think about are —

• How hard is this for new coders to learn?
• How much code do I have to write in different frameworks for the same task?
• How much of the skills refined on a project with this are portable to other web dev work outside of the framework (aka, does it promote JS skills or special framework-only skills?)
• How much developer satisfaction/dissatisfaction is reported in using it in yearly surveys? (aka, quality of life as a coder working in this codebase).
• Who backs it, how well do they support it, what’s its future roadmap look like for maintainability/compatibility in years to come?
• What does the framework’s compile and behaviors result in regarding download size and client-side processing? (aka, how much does this impact low-speed internet service customers and how much does it impact the climate?)

William Holt (Host)

All great perspectives to take and bring to a client conversation. Let’s say, a client is using a tech stack that has a technology that is unmaintained or otherwise no longer fit for use, how do we handle that conversation? For instance, we can argue not to use Express for several reasons, but mainly that it hasn’t been updated in 6 years. There are also still lots of companies relying on AngularJS. And I’m sure there are similar instances of dated tech in the mobile space.

...is there a need for both iOS + Android? If so, what kind of architectural alignment can we do between the two platforms to ease development?

Dusty Fields

Kyle Weems (Lead, UI Engineering)

There is a gulf between React/Vue/etc and Angular in a lot of respects on satisfaction and interest. Some developers and companies rely only on sprints and new features, not touching the underlying spaghetti since it was first laid down. That overhaul often is a lot of time and money, but can really harm the success of a product in the long run.

William Holt (Host)

Right when I got into development in 2015, there were all these competing techs coming out and it was truly a fight for the top with some of the tech falling into the abyss. I wonder if React is big and popular enough that it could be around for the long haul?

Kyle Weems (Lead, UI Engineering)

A lot of company’s use React in their own web applications, so I think it’s got long legs. It’s also a framework that keeps evolving to get itself out of the way of vanilla JS features so it’s far more re-usable from a skill set.

I like using React, and with the recent hooks and other behaviors they continue to encourage less code and simpler state management which means less dev time. Also, it’s easy to export with Preact which results in crazy small compiled code that’s like 1/10th the size of an Angular app or less doing the same thing.

• Easier to learn
• More reusable skillset
• Less code to write
• Less complex state management and behaviors
• Long pipeline ahead of it on well-supported development.

Every Twitter JS framework convo will have at least one Vue stan parachuting in with sparklers talking it up.

I’d say it looks perfectly fine and feels like a good framework overall. But it still has lower exposure, a much less mature ecosystem, and doesn’t have as large or well-funded of maintainers, so I can’t say for sure how its support or user-base will look in, say, 3 years. Especially since Svelte is apparently the new darling (there’s always a new darling). AKA: I’d use it and probably enjoy it. I’d probably propose React over it by default unless I saw more adoption/maturation. 

Bryce Hammond (VP, Engineering)

Vue is basically React with some syntactic sugar. I think Angular is really the JS framework that stands out as really different than all the others.

At some point we need to know for clients if they will be supporting the product in the future or if they will never have a dev team. I think that can dictate a lot in what technology we use.

Kyle Weems (Lead, UI Engineering)

Regarding mobile, it’s worth noting where the market share lies. I think anytime we’re thinking of making an application for just one operating system we should ask ourselves why. Especially since the income and racial disparity between iOS and Android adoption means those left without app access are often the same folks left behind by other market decisions that tend to skew demographically.

Dusty Fields (Lead, Mobile)

A great point and absolutely agree. That’s where having as much parity as possible between the platforms can help with the development process (knowing there are some differences between the platforms that will have deltas).

...For mobile, there are quite a few options for cross-platform development. Where the audience is and what platforms they utilize is huge in evaluating tech stacks.

John McKillip, Principal Software Engineer

William Holt (Host)

Well that feeds directly into a question I had, what are your thoughts on hybrid tools like React Native or Ionic? Some frameworks are great for one use case, but I can certainly see the limitations of a fully fledged app with only certain code partnerships.

Dusty Fields (Lead, Mobile)

Hybrid tools and native solutions both have advantages and disadvantages. When validating a hybrid tool, it’s important to ensure that it can successfully fulfill the clients’ needs. Some tools are more powerful and better supported than others. React Native is probably the best cross platform tool while Flutter and Ionic have less support. But there is a time and a place for each tool.

Native development will give you the best development experience because you are closer to the system (Swift on iOS and Kotlin/Java on Android). But you do need two code bases and two devs for one project.

You can still achieve high quality apps and features with cross platform solutions with careful planning and good experience.

Kyle Weems (Lead, UI Engineering)

I’ll politely disagree. Yes, there’s always a need for native-level dev and tinkering in a percentage of more advanced application’s behaviors. But an application written 100% in native is going to require twice as many devs and at least twice-as-many person-hours to develop.

Unless, again, you’re going only iOS. At which point, you have to again address the fact that you’re writing an application that will have a much narrower market, and one skewed to certain demographics.

Dusty Fields (Lead, Mobile)

That’s a great point. My situation where I had to rewrite the React Native app, they had to hire two devs instead of one dev. It always gets back to the wants and needs of a client.

William Holt (Host)

So this is diving into the intent of the application and the organization behind that app. Which is absolutely a valid concern and plays into how we evaluate tech stacks.

Kyle Weems (Lead, UI Engineering)

I mean, I’d rather make products that don’t exist for in-app purchases, frankly. Because those apps probably aren’t making a difference for the world, they’re making a difference for startup CEOs.

Which, I guess as William is saying, plays into how app intent may drive tech decisions.

William Holt (Host)

Exactly. And how our decisions and conversations with clients needs to take these things into consideration.

Dusty Fields (Lead, Mobile)

I like what Kyle is pointing out. And it makes me wonder about the social aspects here. Money is a huge driver and are users being left behind because of it?

Kyle Weems (Lead, UI Engineering)

Yeah, there’s plenty of evidence how decisions like this shut out the majority of potential consumers. There’s trade-offs. I think the exact amount is going to vary a lot depending on what features you’re looking for. A home solar power tracking app isn’t probably going to need a lot of advanced native features, for example.

John McKillip (Principal Software Engineer)

You can easily build cross-platform mobile apps with Xamarin, which is .NET. A single code base for any device makes a lot of sense to me. For mobile, there are quite a few options for cross-platform development. Where the audience is and what platforms they utilize is huge in evaluating tech stacks.

Dusty Fields (Lead, Mobile)

Discoverability for apps once they are created is also crucial in this evaluation. Right now there is a huge problem in the iOS App Store. It is hard to find good apps made by independent devs. Some of those apps do rise to the top organically, but Apple also has a bias where they feature apps that adopt the newest features first like widgets and app clips. Getting featured by Apple is a huge deal for new/independent devs. So they’ll rush to adopt these new features (debatable whether these apps need these new features or if users adopt them). Again, this circles back to making money and intent. I think a lot of that falls on Apple and how they curate the app store.

Kyle Weems (Lead, UI Engineering)

Another factor for consideration is our company and its desired client list and culture fit that kind of development mindset. Having a discoverable product is one thing, but making sure we are aligned on tech and missions is another conversation.

Key Takeaways

• Always consider the reach and audience of the application. What devices do they prefer to use? Can you create a mirrored experience on all mediums? What unique features might need to be built?
• Keep the future in mind, but don’t over optimize for it. We don’t want to hand over projects that client’s won’t be able to find support for.
• For an MVP launch, what do you need to have? What would be great to build and maintain next? And lastly, how do you iterate on your app to add the wow factor of user experience?
• Application and build intent are as important as evaluating the technology being used and humans used to build it. Why are you creating something? What is the longevity of your product?
• Ultimately the user’s needs and application features can dictate a lot of this. E.G. If you need the newest camera features on an iPhone or Android, your only option is native code as the hybrid tools like React Native won’t support those features immediately. On the flip side, if your users need a web portal with some forms, a standard NextJS app makes a lot of sense.

Thank you again for joining us for this week’s Async Weekly chat! We hope this was helpful to see how our team approaches tech stack evaluation and the many factors that can go into it. If you have any topics you’d like for our team to tackle, please send them our way!