December 03, 2018 | 5min read
Choosing a tech stack for a 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.
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).
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.
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.
(* OCaml *) let ten = 10 let _ = imperativeFunc ten ten let _ = imperativeFunc 0 0
/* ReasonML */ let ten = 10; imperativeFunc(ten, ten); imperativeFunc(0, 0);
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.
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.
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!
Senior Software Engineer