Web Development in 2017
During the past months I’ve been working with many people on really different projects, and my own opinions got changed quite a lot while cycling though loads of technologies. This post aims to be a short sweeping blow about how modern web developers work, what technologies are used und how it might play out in the coming months.
Frontend Development
Your users nowadays do not accept high loading times, require interactive hand-holding immediately and have quite powerful smartphones to access online stuff instead of desktop computers. Also the “App” model is on the decline, since users want to access content immediately without cluttering their phones with apps they never use again. You can already see where this is leading: Single Page Applications (SPAs).
The technology and ecosystem is there now for ambitious SPA frontends, even in enterprise scenarios. Especially when doing things in larger teams, it’s really useful to have many pure frontend-teams with their designers make rapid visual progress, while dedicated backend-teams provide solid APIs as a foundation, not knowing much about each other.
In my opinion there are now 3 major frameworks one can choose from: Vue.js, React and Angular. All of these are viable and have all the features needed, but there are some con’s: Angular has already lost to React no matter how hard google tries to hide it, React has a really dangerous license rendering it obsolete for serious enterprises and Vue.js is mainly driven by a single genius developer (high bus factor). I vastly prefer Vue.js, since it feels like the next-generation love-child of Angular and React and has the lowest learning curve of them all.
Once you have a frontend in place, you can then compile it into native mobile apps (businesses really still want to have this) with Weex or React Native or (for backoffice stuff) into desktop apps with Electron. And of course, there is a real need to counter the biggest disadvantage of SPAs: the initial page load. You really want to instantly render complete HTML on the first request for your users and search bots, but subsequent navigation taken over by the browser via JS. To really achieve this (easily), you need some node.js on your backend systems, which executes the frontends and delivers the pre-rendered initial page (no, phantomJS is not an option any more, since it’s basically dead).
Opinionated TL;DR: choose Vue.js for a hassle-free experience down the road.
Backend Development
Once there were servers. You put all our dependencies on them, upload your files or some kind of archieves, configured everything, and then you were good to go. But one server is barely enough for anything nontrivial nowadays, so the loadbalancers and server-clusters came into play: doing the configuration over and over again (you love bash, right?). Then suddenly docker came and eased the pain significantly. Configure something once, and deploy it as often as you want. Now you have a bunch of uniform containers and on top the glorious docker-compose glued it all together. You can deploy your whole application stacks with a click once everything is configured properly. But… then again servers cost money, and different parts of your stack have vastly volatile load phases, so it would be great to scale up and down on demand. You’re now in the world of swarm and kubernetes, throwing more and more DevOps into these problems, while actual feature development gradually slowed to a halt. Been there, done that. And you know what is even more expensive than servers? Developers.
Ideally, you want to have all the advantages and features of modern backend technologies and the “complexity” of old-school PHP deployments (where FTP uploading some files were a thing) and skip all the hassle of the last paragraph alltogether. Luckily there is a (currently) final solution to backend problems. And once you “get” it, whole fields of problems and discussions just implode. It is called serverless, or Function-as-a-Service (FaaS). You write a function that does what you need, upload it to one of the cloud providers, point an URL to it, done. Zero servers and configurations to manage, with a pay-by-execution model.
Every FaaS provider supports a few different languages, but all of them support javascript. Node.js, it is. That bastardized language everyone uses to hate, but knows and uses nonetheless. Performance and scalability are non-issues with FaaS, and the “node isn’t parallel!!1” discussions are moot, too. It turns out: javascript is just good enough for all things backend. Let the junior developers battle screaming and kicking whether Go is better than Java and Ruby is much more comfortable, Rust being safer or Swift cooler, it just doesn’t matter any longer. Javascript has already won.
But wait! Configuring stuff for FaaS cloud providers is still manual DevOps work that could be automated… and it is. It seems that the serverless framework is already winning the developer mindshare, abstracting away the nittle details of FaaS configurations between providers, and we’re really back to an incredible simple development workflow we had 20 years ago. But in fact it’s even simpler now, really cheap, much safer and highly scalable for most businesses out there (not everyone manages acres of server houses at google or amazon). And to go full circle: these frontend guys from above do want their stuff prerendered on the server, requiring you to use… javascript. Whew.
Opinionated TL;DR: Just go serverless for your backend needs and be done before others have figured out how to start.
Language Choices
As a language itself, Javascript used to suck. hard. And today: mostly still sucks. There are a bunch of really great additions (like async/await) to eliminate callback-hell once and for all, but at it’s core: the flaws of the past are still there, and will probably continue to stay.
But Javascript nowadays is not merely a language, but the web application platform. And slowly people are realizing it. Of course there are loads of developers out there, preferring vastly different languages, so here’s the good news: you have plenty of languages to choose from, all of them transpiling to javascript at the end of the day. You can go “pure” JS, or have some stability with typescript, or get lispy with clojurescript, or hack something together quickly with coffeescript, or … . There is a small solid core hidden within javascript, and people are leveraging it to great degrees, building many languages ontop.
Most developers do find one dialect that they can tolerate working with, or even have fun writing it. And while we’re at javascript everywhere, it’s obvious why managed NoSQL document databases (eg: DynamoDB) are rising, since they’re conceptually just a shiny json-storage in the eyes of backend developers. All this stuff is way easier to grasp than the old days of PHP, MySQL and jQuery plus Linux server management.
The Future
We are in the dawn of actual ubiquous cloud computing, and a single team of node.js backend developers can satisfy all your backend needs, pumping out features for many independend teams of frontend developers, designers and marketing people.
I still can’t fully believe it by myself (used to hate javascript, loving Elixir and Rust), but I must reiterate it again: JS has won. It’s also no coincidence that these “cloud developers” are called “solution architects”, since they’re going straight to solutions instead of circlejerking nerd-porn-topics like scaling, syntax and performance. Oh, and we can already see stuff like “Machine Learning” getting a cheap commodity just a few clicks away on AWS.
I really hope this bitter recap article does not invoke too many knee-jerk reactions deep inside you, developer reading this, but acts as an eye-opener. You can decide to earn a living maintaining tons of legacy applications with technologies you might love, or you begin to accept the future and start embracing the future (teeth-gnashingly).
