December 03, 2018   |   5min read

Choosing a tech stack for a web application

The process of choosing a tech stack for the new web project can be a challenge. Let’s face it, JavaScript fatigue is real. The State of JavaScript 2018 survey proves that the whole ecosystem is evolving faster than any other field in software development. The goal of this article is to provide some starting points for choosing the best technology stack for web application.

I’ve extracted 3 main questions you need to answer before starting:

  • What is the best programming language for my project?
  • What UI framework/library should I use?
  • How the app will manage its state?

Secondly, every project is different. To address that, I picked a tech stack for two different types of web projects: maintainable, production-ready project and weekend project focused on learning.

Obviously, my choices are very subjective and skewed by the fact I’m mainly focusing on React ecosystem as far as web development stack is concerned. Like always, your mileage may vary.


Tech stack for maintainable, production-ready project


There are basically 3 options that are worth considering in terms of a programming language in web development projects: plain ES6, Flow or TypeScript. Having a type system in a project that will last for quite some time is really convenient. Lint rules and unit tests are of course still needed, but there are many validations that are provided more effortlessly just by having the types. That leaves us with either Flow or TypeScript. For a long time I was sticking with the former, because back then it had better support for React API. Right now TypeScript is not only a great fit for typing React components, but has lots of type definitions for JavaScript libraries via DefinitelyTyped. That cannot be said about the similar project flow-typed, which, although provides some definitions, is nowhere near in terms of the number of contributions.

Apart from providing a type system, TypeScript has a great tooling and editor support in VSCode.


According to State of JS 2018 “the front-end space is all about React and Vue.js”. I’d stick to React, but both of them are production-ready. React has a huge community, tons of libraries to choose from and very mature API. I feel that this choice is less controversial than the one that follows it, namely how to navigate in a vast React ecosystem. That leads us to the topic of state management.



Despite all the “you might not need Redux” movement, I would still say that’s a good fit for a large-scale web application. There are some trade-offs that come with it. Redux imposes some constraints of how the app is structured. It needs quite a lot of boilerplate code. But with its popularity come many plugins and patterns that were researched by the community. The idea of a central store goes extremely well with having types, just because you get a constant feedback on what type of actions you can make.

Of course Redux is not a silver bullet – other, similar solutions are always worth considering (mainly MobX or Apollo, if the app is using a GraphQL API).

Tech stack for a weekend project focused on learning

This kind of project is aimed at predicting “the next new thing”. It will involve a lot of issues and creating new concepts. Here come two new and emerging solutions. Incidentally, both of them could be used for the maintainable project, however not right now in my opinion. Without further ado…let’s take a look into the best technology stack for web application in weekend project focused on learning.


ReasonML is a functional, strongly-typed language that compiles to JavaScript. Under the hood it’s the new javascript-like syntax for OCaml. It uses BuckleScript to compile OCaml code to JavaScript. Just from this brief introduction you might get a bit of a headache, but each piece of this puzzle brings real value.

OCaml is a matured functional programming language with a great type inference. It has a rather pragmatic approach to side effects. Although it defaults to immutable and functional approach, there are escape hatches to write mutable or imperative code if needed.

Now we need some way to use OCaml code in the browser and that’s the job for BuckleScript. It takes OCaml as an input and compiles it to performant, readable JavaScript. ReasonML is the last part that addresses the pain of OCaml, which is a bit weird syntax.

(* OCaml *)
let ten = 10
let _ = imperativeFunc ten ten
let _ = imperativeFunc 0 0
/* ReasonML */
let ten = 10;
imperativeFunc(ten, ten);
imperativeFunc(0, 0);

With ReasonML comes reason-react, bindings for React. Its API is a bit different than the JS counterpart, but in my opinion it’s closer to the initial idea of React (made by the creator of ReactJS). Since JavaScript interop is well-thought, Reason components can easily use existing components and vice-versa.

To answer the last question of how the app will manage its state, I’d suggest storing the state only in reducer components. If that’s too extreme and using GraphQL API is an option, then I’d experiment with Apollo for both the local and remote state.



Elm is a functional language inspired by Haskell that compiles to Javascript. On top of that it provides strict app architecture, package manager and functions to build UI. It’s still a nichè and there’s a good chance it will stay there, but learning Elm is a good way to learn new concepts.

It can be treated as an intro to Haskell or functional programming in general. Building an Elm app is a great entry point for doing that without needing much setup. Secondly, when Dan Abramov was creating Redux, he got inspired by The Elm Architecture and added concepts like “model view update” architecture and immutability. The popularity of Elm is still rather low, but IBM decided to build their Decision Composer with it. You can read about their experience here.

Conclusions about web development stack

I hope these propositions are a good start for researching your next web app stack! The process will definitely take some time but it’s definitely worth it. This article just scratched the surface of choosing the best technology stack for web application but remember—the most popular web application framework doesn’t have to be the best for you. Stay curious and consider all the pros and cons for every decision!

Sources: State of JS Frontend master GitHub Discourse

Piotr Dubiel

Senior Software Engineer

Did you enjoy the read?

If you have any questions, don’t hesitate to ask!