The stack you use to build your next app is irrelevant

How to choose the best stack for your app?

Rash words to begin the article, but if you think about it, it’s hard to deny the fact that it doesn’t matter what tech we use to build the app. What matters more is solving the needs of your customers and getting paid for it enough that you can sustain the costs of your app.

I understand that its hard to choose the correct one today. There are a lot of established frameworks and out of the box solutions alongside the new and flashy frameworks and no-code approaches. All will work similar (or won’t) depending on what you decide to build with it. You can spin off a very profitable web app with Airtable and automation apps. If you want to build a more complex web app like I usually do, you will start looking at frameworks to help you on your way.

Most frameworks are very similar because they all borrow ideas and technology from each other. The difference lies in their underlying programming language they and what the majority of the community is using them for. I’m going to focus on basic and semi complex CRUD apps here, which have been my bread and butter for the better part of the past 2 decades. As I go further, I want to dumb down the development stack as much as possible. I’m not perfect here, my friends and ex coworkers will say that I left some wild heritage behind me, but I guess it’s what growth looks like. Experimenting with different thing and figuring out what works for you.

The main mistake we make is trying to replicate what FAANG is doing. Regardless whether it’s in development, operations and sometimes even sales and marketing. Let me be completely honest, it makes no sense comparing ourselves with those companies. I know everyone can dream, but it’s best to leave that unicorn dream behind us and do the best we can do serve our customers. The quicker we realise that, quicker we can start implementing stuff that solves real problems.

Our customers don’t care much whether we use React or Vue.js for our frontend. You can even write an app using Backbone.js (Those who remember this one shoot me an email) and be super successful with it. What you should focus is to reduce the complexity as much as possible so you will achieve the following goals:

1. Hiring is much easier if you hire for one thing. It’s hard to find someone who is an expert in both Rails and Ember.js or Django and Vue.js, or Laravel and React. And if we add some esoteric database + ORM to the picture, you introduce too much complexity in your stack. Everyone already has to know about HTML/CSS and at least basic JavaScript to do web applications.
2. Less complexity means you can deliver features faster with less bugs. Okay, the amount of bugs is dependent on your engineering and testing capabilities, but if less things can go wrong it will reduce the possibility of bugs.
3. Every framework has its own deployment guidelines and best practices. If you mix up a couple of them in your stack, you have to figure out your own deployment strategy instead of serving your customers’ needs.
4. Testing one tightly coupled and integrated thing is much easier than testing 3 loosely coupled things.
5. Server rendered apps can be just as fast and even faster than single page apps. They can also be easier to secure. Did I already mention that you can develop them faster?

The last point is what I’m aiming at here. Server rendered apps are enough for most of the stuff we are building now. You don’t need micro services or single page applications because you can always live without the additional complexity. You want the “boring stack” - something proven, battle tested and known to work. You want Wordpress, Laravel, Django and my favourite, Rails. There might be a JS solution available for you in the likes of Next.js if you prefer JS as your language of choice.

Now I’m not against experimenting with new and flashy technologies, or using them when they become necessary. What I’m advocating here is being prudent with the choice of technology you build your app with. Scala was once a very popular language, so was Clojure and now I don’t even hear them mentioned. While Python, PHP and Ruby are still alive and doing very well. Not on the top of the lists, but not forgotten like those other “killer languages”. I like Clojure because of its lispiness, and I’m sad I never got to use it on a project.

Languages and frameworks come and go, but the good ones stick. If you are a Microsoft fan, Asp.Net MVC is a good choice, or Spring MVC in Java, whichever makes you happy. If you don’t over-engineer it when you start, it’s gonna be easier down the line.

If you ever upgraded one of your frameworks to a new major version, you know how hard it can get. Do you want to stick your team (or yourself in the start) with having to manage 2 or more frameworks. Think how hard it will be to upgrade 2 or 3 of them (sometimes at the same time). Just keeping on top of security advisories can be overwhelming.

Let’s end this one remembering the spirit of KISS and YAGNI, and using those as a guideline in choosing our stack.