My teck stack if I had to build an app today

What technology stack would I choose, if I had to develop a web application completely from scratch? That’s the question this article will cover.

First of all: by saying web application I’m referring to something between a plain static HTML page and an entire Facebook. Basically, an application that fulfills a certain domain of tasks for the user and that requires the usual features like user management, a backend database, multiple UI views and controls, etc. The size of application I’m thinking of could be a browser-based chat app, password-manager or something similar. Neither too simple, nor too complex.

Back to the topic. Choosing the right technology for a web app feels much like customizing a new PC or even a new car. There are nearly endless options to be weighed to finally pick a bunch of them for a new web application. This super famous article How it feels to learn JavaScript in 2016 complains about the confusing and ever-growing, chaotic jungle of new JavaScript frameworks in an ironical way. Indeed, I hear similar arguments from many developers these days. Many of them claim that code quality was getting worse in the web and that every newbie JavaScript programmer threw out his own new framework on yet another .io domain. Although that might be true to a certain extent, I personally still like the great technological variety and innovation. I love to browse GitHub, Reddit, Hackernews and Co. to discover new cool libraries to try out in a project some day. And here’s what I would pick if I had to realize such a project right today and if there weren’t any restrictions.

Of course, the technology choice depends on the concrete project requirements to a certain extent, but not completely. Consequently, a new project is always a chance to try something new. ThoughtWorks just published their new technology radar for 2016, where they separate into categories adopt, trial, assess and hold. Of course, hold-techs are not an option for new projects and I actually pretty much agree with their views on what has to be in the hold category. Adopt basically are things that are modern, but also well-established enough to avoid too much risk. Trial-techs are more experimental and assess are the latest fancy s***, so to say. Since I’m extremely eager to try out new things, my stack would probably mostly consist of technologies from the last category. So what would my stack now look like? Actually, I couldn’t decide on one stack, but set up two: the fancy one and the super fancy one. Additionally, I define their intersection as the base stack, which consists of fundamental tools etc. that both have in common.

The base stack

First of all, I’d use Git for version control, Visual Studio Code as code editor and GitLab for repository hosting and as build server. If I didn’t had to implement user management myself, I’d pick Auth0 for that. For deployment, I’d use containers with Docker on DigitalOcean machines and if I needed multiple instances, Rancher would help me to manage them. As reverse proxy in front of the backend I’d choose nginxsince it’s extremely efficient, performant and has HTTP/2.0 support. For bundling, Webpack would be my choice and task automation would be done using plain npm scripts. For styling the UI, I’d simply use Bootstrap 4 and SCSS.

The super fancy stack

The key point here is that I’d want to abandon a traditional REST API in my project and use GraphQL instead. The backend would be written in NodeJS with Graffiti as GraphQL implementation. I don’t know much about the latter one, yet, except for that it’s the de-facto GraphQL solution for Node. Why Node? Because it’s simply the best choice for the web (my view…). It’s performant, comfortable to develop and especially brings consistency by having JS in front- and backend. By always being quite up-to-date with the latest ES* features, Node doesn’t get boring. Since GraphQL is told to work best with other Facebook technology, I’d not be that experimental here and build the frontend on React plus Relay (which is still completely new for me). Database would probably be a MongoDB (JSON everywhere!) with Waterline ORM. To put a cherry on the cake, I’d also introduce Redux in addition. I haven’t worked with it much, yet, and I heard that it’s kind of mind-blowing in the beginning. However, I consider its concept to cover a large potential to manage consistency in my app. The last thing here is that I desperately want is ES6 syntax. It isn’t supported by the React compiler afaik (please correct me, if I’m wrong), so I’d use Babel to have latest JavaScript features. If having to go mobile, React Native would be the rational choice.

The fancy stack

This stack differs from the super fancy stack in a few points. A key point is that it would not use GraphQL, but a good old REST API. This API would be written in Go, since I like the language — especially its efficiency and its good suitability for web development. More precisely, I’d use the Iris framework. I’ve read the documentation and it looked incredibly powerful to me (in terms of both functionality and perfomance). (EDIT: It’s not what it seems! Please see my comment below!). For the frontend I’m balancing between Angular 2 and Aurelia. Angular 2 is guaranteed to work for any potential case, is extremely powerful and has great community- and library support. However, Aurelia look promising, too, and probably is even more clear and less boilerplate code. Consequently, I’d give it a try. But if having to go mobile, I’d still favor Angular 2, since it perfectly aligns with Ionic 2.

Two other options, which look really interesting to me are Meteor and HorizonJS. However, I’m not sure, if it’s a good idea to commit to only one comprehensive framework through the full stack.

So these are my two alternative ways through the webdev jungle — btw, this good article describes another one, especially for newcomer web developers. Sorry, that I haven’t justified all choices. Actually, as you probably know, if you’re a developer, subjective views like these often aren’t even based on pure rational considerations, but are rather emotional and spontaneous.

Please feel free to give me feedback on my tech stack of choice!

EDIT: Another framework I’d really like to try out is InfernoJS, because it claims to be extremely lightweight and performant. However, before using Inferno, one should probably be familiar with React, since it uses very similar concepts and syntaxes.

EDIT 2: After having read this article and having done some further research on the Iris framework I really have to retract my above statement that I’d use it as a web backend. While it looks nice on paper, after diving a little deeper I really have to admit that it’d be morally tenable to support the authors of that project. So please forget about Iris and take a look at Beego instead.

Originally published at ferdinand-muetsch.de.

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.

To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!