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 nginx since 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.
Top comments (21)
Thanks for a lot of good info, Fredinand. I still default to Rails for brand new projects that need early momentum, with the intention of breaking out into polyglot services as the need arises. The rational being the maturity of the Rails stack and community, combined with the ease of rapidly building out features. Rails doesn't exactly make for great software and it's easy to stub your toe and create technical debt, but in practical terms it is very easy to be productive.
Otherwise, I'd have a look at going all in on functional programming with an Elixir/Phoenix app with Elm on the front end. It makes for a logically and technically scaleable application by default.
The Changelog recently wrote about their process building a Phoenix app and open-sourced it. I think it made for a really helpful look because their app needs were pretty typical CRUD behavior and it's easy to know where to look in the code even if you are completely unfamiliar with the stack.
Another open-source Elixir/Phoenix app I've come across is the very well-documented Code Corps app. That uses Ember on the front end.
Thanks for that comment! To be honest, I haven't even written a single line of Ruby code, but I know that Rails is pretty popular for web backends, especially because of its ease of use. However, I've recently read several times that Ruby + Rails is on a downside trend and losing popularity.
Elixir and Elm definitely fit into my topic of a cutting-edge, "fancy" stack and are certainly worth getting at least a little more familiar with their concepts, if you're a web developer. But I don't know if they're production ready, yet...
I've come to see the "losing popularity" thing as a feature and not a bug. Rails really blew up and was the new hotness for a long time. I think being old guard technology with a stable community that takes its time to make important choices and a BDFL who still really cares about developer UX. I'm glad that a lot of bootcamps are moving away from the stack because it was probably getting saturated, and teaching Rails is probably not the best way to teach good software practices.
Rails remains a great stack for being super productive on new projects.
I have no experience in PHP or Rails. But am familiar with Java, Swift, JS (have built simple websites with jQuery). What would be the best way for me to get into back-end development?
Any comparisons for Elixir/Phoenix and ASP.Net with F#?
Thanks!
So many different choices out there and nearly all of them were good :-)
In your case I'd first say that (1) wouldn't be the best option, probably. I'm not against Rails or something, but as already mentioned in one of the above comments it's on a downtrend on the one hand and doesn't necessarily teach coding best practices on the other. I'd say if someone is familiar with Ruby and Rails it's totally fine, go for it. But when learning something new from the ground up, I wouldn't take that as a choice.
If you're somewhat new to backend development, I'd first learn something more common as a solid base and then pick up on the functional stuff you mentioned in (2) afterwards. If you're a Java developer, you could absolutely take a look at either Spring Boot or Jersey. However, these things are pretty comprehensive and not that super-lighweight. Something to get started with much more easily in the backend would be either Node or Python + Django (or Flask). If having to decide from one of your three options, I'd pick the third one, although I heard that .NET Core isn't completely mature enough to be production-ready, yet.
EDIT: Btw, what works best for me for learning new stuff is to watch video tutorials and courses on YouTube, Pluralsight or Microsoft Virtual Academy (the second one isn't free for non-students, but the quality is better). Maybe you want to try that.
Thanks for the detailed reply, Ferdinand! Really appreciate it. I might go the node / flask route to get familiar with backend dev process (probably start with express).
I have a 3 month trial of Pluralsight so I might make use of it now :) Thanks for the advice, again!
I'd go with django and django-rest-framework on the backend, and angular 1(because i have never worked on angular 2, although I think now would be a good time to start) on the front end along with bootstrap 3
The "I'm doing X, because I'm good at it and have never worked with the newer Y" thing is fine if you need to build something quickly. Like if somebody asks you to build an app for her to be released until the of the month or so. But if you're doing a private project without being pressed for time, I'd always try something new and rarely rely on what I already know just because it's comfortable... ;-)
Right, I would just go with these because these are the only frameworks i know. But this article makes me want to learn and try out the other stuff you have mentioned :)
Ben, I'd agree with you on Rails for the backend, and I'd suggest a mix of Rails views on the front end when you need quick development plus React. I'd suggest looking into github.com/shakacode/react_on_rails for the integration of React and Rails. It's a mature project with over 2400 stars and very heavy traffic. We're the number one solution in the Rails community for using React and Rails via Webpack. It includes support for server rendering. In case you have questions on React on Rails, I'm the author and ShakaCode is my company.
Pretty solid list.
FYI, I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at github.com/markerikson/react-redux... . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a source of solid info on more advanced topics.
If you've got any questions about React or Redux I can help with, let me know! You might also want to check out the Reactiflux discussion group on Discord (reactiflux.com ). Plenty of people hanging out there happy to discuss ideas and answer questions about React, Redux, and more (including myself).
Thanks! I'll remember those resources when getting started with the React ecosystem some time.
Nice blog @fredinand
I always get confused in choosing javascript framework, i think it will be difficult to choose a JS framework and learn it from scratch... How you guys manage to lean new JS framework don;t you find them difficult to learn new framework?
I feel like Amazon services would be a better choice than DO. The super high speed backend network, private networking, virtual networking, CDNs, storage systems, DBs, auto-scaling, pricing model, management tools, etc etc etc, would be better for a modern app.
I think it depends on the use case. The bigger (in terms of scale) your app gets, the more you'd benefit from AWS and all of its numerous features and services (load balancing, monitoring, DNS services, ...). However, I think it's also more expensive. So for small to medium, non-enterprise projects it may be overkill.
You might want to recheck your usage for Go framework as iris is known to be a questionable project: reddit.com/r/golang/comments/57w79... and reddit.com/r/golang/comments/57tmp...
Hope it helps.
Thank you for that hint! Crazy story... With that additional knowledge I definitely wouldn't use or recommend Iris anymore. I've even updated my article.
Can we build it together? 😁
I don't have much experience concerning monitoring, technical analytics, etc., but it's definitely an interesting point. So if any of you guys have suggestions on that, please let us know!