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


PiotrSenior Software Engineer


Sign in and expect sharp insights, recommendations, ebooks and fascinating project stories delivered to your inbox

The controller of the personal data that you are about to provide in the above form will be Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: 0048 795 536 436, email: (“Polidea”). We will process your personal data based on our legitimate interest and/or your consent. Providing your personal data is not obligatory, but necessary for Polidea to respond to you in relation to your question and/or request. If you gave us consent to call you on the telephone, you may revoke the consent at any time by contacting Polidea via telephone or email. You can find detailed information about the processing of your personal data in relation to the above contact form, including your rights relating to the processing, HERE.

Data controller:

The controller of your personal data is Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: [0048795536436], email: [] (“Polidea”)

Purpose and legal bases for processing:


Used abbreviations:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

ARES – Polish Act on Rendering Electronic Services dated 18 July 2002

TL – Polish Telecommunications Law dated 16 July 2004

1)        sending to the given email address a newsletter including information on Polidea’s new projects, products, services, organised events and/or general insights from the mobile app business world |art. 6.1 a) GDPR, art. 10.2 ARES and art. 172.1 TL (upon your consent)

Personal data:name, email address

2)       statistical, analytical and reporting purposes |art. 6. 1 f) GDPR (based on legitimate interests pursued by Polidea, consisting in analysing the way our services are used and adjusting them to our clients’ needs, as well as developing new services)

Personal data:name, email address

Withdrawal of consent:

You may withdraw your consent to process your personal data at any time.

Withdrawal of the consent is possible solely in the scope of processing performed based on the consent. Polidea is authorised to process your personal data after you withdraw your consent if it has another legal basis for the processing, for the purposes covered by that legal basis.

Categories of recipients:

Your personal data may be shared with:

1)       authorised employees and/or contractors of Polidea

2)       persons or entities providing particular services to Polidea (accounting, legal, IT, marketing and advertising services) – in the scope required for those persons or entities to provide those services to Polidea


Retention period:

1)       For the purpose of sending newsletter to the given email address – for as long as the relevant consent is not withdrawn

2)       For statistical, analytical and reporting purposes – for as long as the relevant consent is not withdrawn

Your rights:


Used abbreviation:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

According to GDPR, you have the following rights relating to the processing of your personal data, exercised by contacting Polidea via [e-mail, phone].

1)       to access to your personal data (art. 15 GDPR) by requesting sharing and/or sending a copy of all your personal data processed by Polidea

2)       to request rectification of inaccurate personal data
(art. 16 GDPR) by indicating the data requiring rectification

3)       to request erasure of your persona data (art. 17 GDPR); Polidea has the rights to refuse erasing the personal data in specific circumstances provided by law

4)       to request restriction of processing of your personal data (art. 18 GDPR) by indicating the data which should be restricted

5)       to move your personal data (art. 20 GDPR) by requesting preparation and transfer by Polidea of the personal data that you provided to Polidea to you or another controller in a structured, commonly used machine-readable format

6)       to object to processing your personal data conducted based on art. 6.1 e) or f) GDPR, on grounds relating to your particular situation (art. 21 GDPR)

7)       to lodge a complaint with a supervisory authority,
in particular in the EU member state of your habitual residence, place of work or place of the alleged infringement if you consider that the processing
of personal data relating to you infringes the GDPR
(art. 77.1 GDPR)

No obligation to provide data:

Providing your personal data is not obligatory, but necessary for Polidea to provide you the newsletter service

Refusal to provide the above data will result in inability to receive the newsletter service.


In the process of providing the newsletter service, we make decisions in an automated way, including profiling, based on the data you provide.


“Profiling” means automated processing of personal data consisting of the use of your personal data to evaluate certain personal aspects relating to you, in particular to analyze or predict aspects concerning your personal preferences and interests.


The automated decisions are taken based on the analysis of clicked and viewed content. They affect the targeting of specific newsletter content to selected users registered to receive the newsletter service, based on the anticipated interests of the recipient.