Which tech stack should I choose?

This content originally appeared on DEV Community and was authored by Émile Perron

Are you looking to build a website for your product or company?

Or perhaps you already have a website and you're thinking about revamping it?

In this article, we'll help you understand:

• What a tech stack is;
• How the stack you pick affects you and your users;
• What matters most when selecting technologies.

Ready? Let's dive into it!

‍

What's a tech stack?

Simply put, a tech stack is the choice of technologies you use for a particular project.

Every technology you use to build, deploy, test, maintain and update your project is a part of your "tech stack".

Are you building on a website builder like Squarespace or Wix? Are you using a no-code or low-code hybrid like Webflow? Are you setting up a Wordpress website? Are you creating a complex web app with React? Are you using a CSS framework like Bootstrap or Tailwind? Are you connecting to external APIs? Are you managing a web server yourself? Are you hosting your site on GitHub pages, or perhaps Netlify?

The landscape of web technologies is evolving quickly, with new technologies being released just about every week. There is a near-infinite number of combinations to choose from.

So before starting development on a project, you need to decide which tools and technologies to include in your tech stack.

‍

What should I take into consideration when choosing a tech stack?

Before we go into more details, here's a summary of things to take into consideration:

• Speed
• Speed again
• Security
• Accessibility
• SEO
• Maintainability
• Platform limitations
• Community
• Ease of use
• Pricing

Let's dive into each of these elements to help you better understand what to look for.

‍

Speed

Speed is paramount on the modern web.

You want every user interaction to be as fast as possible:

• Pages should load and become usable as fast as possible;
• Loading of data within a page or component should be as fast as possible;
• User-created content (ex.: a blog post, a comment, etc.) should be posted and displayed as fast as possible;
• Emails and text messages (ex.: 2FA, email confirmation, etc.) should be sent and received as fast as possible;
• ... you get the point.

Every technology you use should therefore be well optimized to reduce unnecessary processing and connections.

This applies to both backend and frontend technologies and solutions, as both will impact the user's experience.

‍

Security

Just about every language and technology used on the web is secure when used as intended.

However, when adding external solutions and integrations into your project, you'll want to make sure they're secure.

Additionally, hacks and data leaks are always a possibility, no matter how secure a product might seem.

To defend yourself against potential attacks or leaks, you need to make sure that the services and technologies you use:

• have access to as little of your users' data as possible;
• safely hash and/or encrypt any sensitive or personal data;
• do not share your data with other services or platforms unnecessarily.

‍

Accessibility

Speed is an essential part of the user experience, but it's not all there is to it.

When choosing user-facing technologies and solutions, you want to make sure that they allow you to build good-looking interfaces that are functional and intuitive. You also want to make sure that people can actually use these interfaces.

When evaluating technologies with which to build your app or website, make sure they either generate accessible interfaces and features by default or that they allow you to freely edit the HTML to improve the accessibility yourself.

When evaluating an external tool, service or integration where you don't have any control over the interfaces and the code behind them, you'll want to make sure these interfaces and features match your accessibility standards.

‍

SEO (Search Engine Optimization)

Just like accessibility, your technologies should either be SEO-friendly right off the bat or allow you to edit the code so that you may add search engine optimizations yourself.

This relates to meta tags, usage of semantic elements, pre-connection to external origins, and many more.

If indexability and SEO are important for your project, you'll want to make sure you either go for a server-side or statically generated website / app, or with a SPA hybrid that allows you to render meta tags and other such elements on the server so that they're available without Javascript. This will allow crawlers who don't execute Javascript (which is... most of them) to find the data they need to display your site correctly in search results and social media previews.

‍

Maintainability

If you are planning on updating and maintaining your site or application over time, you need to make sure that the technologies you choose won't die out in the coming years.

A good way to determine if a technology will still be maintained and viable is to:

• check if it is still maintained right now (this may seem obvious, but you would be surprised at how many people start using "archived" technologies without knowing it);
• check if it has a public release schedule with plans for the upcoming months or years;
• check how many people are contributing to its development and maintenance (the more active and recurring contributors, the better).
• check if it heavily depends on other technologies that are likely to not be maintained in the near future.

You also have to look into what it takes to keep the system up to date and running smoothly.

Here are a few more questions you can ask yourself when thinking about the maintainability of your new site:

• Can I update it myself?
• Do you need an expert to take care of it?
• If we have to bend this platform out of shape to do what we need, how easy will it be to maintain?
• If I need to find someone new to maintain the project in the future, how many capable people are available in the market?

‍

Known limitations

We've touched on that before, but you need to know a technology's limitations before you can decide if it can work for you.

For example, a no-code / low-code website platform like Webflow doesn't have a backend you can access and develop on. It doesn't have an easy-to-use file uploader and manager if you need to manage documents outside of its Collections feature. It also includes the jQuery library by default on your site, and you can't remove it.

For some people, these limitations are deal-breakers. For others, they won't ever be an issue.

At Koalati, we use Webflow to build and run our marketing website (the one you're on right now). Some of the limitations are minor pain points, but we knew about them ahead of time, and we decided it was worth the trade-off for the speed of development it offers.

Because we knew the limitations ahead of time, we were able to make that decision knowing full well that there would be minor pains, but never any major issues.

This is the type of decision you're about to make, so researching the limitations ahead of time is a must.

‍

Community

Many people aren't aware of this, but most web developers and designers heavily rely on online communities in their daily work.

Communities are useful to help debug an issue, to find inspiration, to ask about best practices, to get a second opinion, and much more.

Communities also contribute to the development and improvement of a platform or technology.

Finally, the size and level of activity of a community are also good indicators of how large the talent pool for that particular technology is. This may be important if you need to find new people to help you maintain the project in the future.

That is why it's important to make sure that there is a thriving community around a platform or technology before building your project around it.

‍

Ease of use

It's important to make sure that the end result will be easy to use by both the users and the project's maintainers.

A good example is a blog platform that requires the maintainer to use Markdown or HTML to write a blog post. This might be great for the person who's maintaining the blog at the moment, but what if that person quits or has to delegate that task? Wouldn't a regular text editor have been a better option?

There is no one-size-fits-all answer here: ease of use varies based on the target audience. So think about who will be using which tool and which feature, and plan accordingly.

‍

Pricing

Different stacks come with different price tags.

Before building your entire project on top of a technology, you need to make sure that you understand the pricing implications and that you can support this price for the lifetime of the project.

You also need to consider how much time a platform or tool can save you (or how much more money it can make you!), as well as what the tradeoffs are.

For example, you can easily find a hosting provider that will charge you $1.99/month and give you the domain for free. But:

• Is that price going to change after your first year or two?
• Is that domain only included for the first year?
• Does that hosting have any significant limitations? (speed, server location, server resources, etc.)
• Is maintaining your site on that platform taking much longer than on an alternative platform?

Just like platform limitations, understanding pricing is important as it's something you might be stuck with for a very long time.

So make sure you understand the pricing structure and requirements before making that long-term decision.

‍

Your tech stack doesn't matter.

Now that we've covered all of the elements that do matter, let's skip to the hard-hitting truth: your tech stack doesn't really matter.

The truth is that most technologies can deliver good speed, security, accessibility and SEO when they are used correctly.

Of course, we're talking about actively maintained and updated languages, frameworks, libraries and platforms - you don't want to use COBOL (an ancient language used in many legacy systems) to run your backend.

But X is better than Y!

You might have heard that technology X is better than technology Y!

Some technologies have a bad rap, but a lot of that is based on personal preferences and experiences (which are often biased and/or out-of-date).

Unless you are building a high-availability platform with thousands of simultaneous requests and you plan on maintaining that platform for 10+ years, it's unlikely that you'll run into major technical issues, no matter which major technologies you use.

Just keep things as simple as possible while ensuring fast speed, accessibility, SEO and maintainability.

‍

If the stack doesn't matter, what does?

The most important part of a project's development and maintenance is the team behind it.

Experience, motivation and care

A non-experienced team (or an experienced team that doesn't care) might deliver horrible results, even if they use the "best and latest" technologies. On the other hand, an experienced team who cares can deliver an outstanding experience to your users, even if they don't use the newest tech available.

If your project is handled by a motivated and experienced team who truly cares about what they are creating (and the people who will use it), your tech stack doesn't matter.

Let me say that twice, just to make sure it sticks in your brain.

If your project is handled by a motivated and experienced team who truly cares about what they are creating (and the people who will use it), your tech stack doesn't matter.

Whenever a choice has to be made, the team will decide what's best for the project and its users based on the criteria laid out above (along with other context-specific criteria).

If your team is skilled and cares about the end-user, chances are the stack they choose will work just fine.

‍

Summary

A tech stack is the combination of technologies with which your project is built, deployed and maintained.

But the specific stack you go for doesn't matter a whole lot, as long as you go for technologies that:

• are actively maintained (and that will be maintained in upcoming years);
• have an active community behind it;
• match your needs;
• can deliver a good experience to end-users.

What really matters most is the mindset, intent and experience of the team that builds your website or application.

A non-experienced team (or an experienced team that doesn't care) might deliver horrible results, even if they use the "best and latest" technologies. On the other hand, an experienced team who cares can deliver an outstanding experience to your users, even if they don't use the newest tech available.

If you have access to skilled people who know what they are doing and who really care about the end-user, chances are the stack they choose will work just fine.

We publish these website audits not to shame the teams behind the sites, but to educate creators on how to audit and improve the websites they build.

This content originally appeared on DEV Community and was authored by Émile Perron