In praise of the monolithic web app
Many web apps these days are hopelessly over-engineered.
In particular, over the last few years, building a web application with separate frontend and backend has become all the rage. But for a startup building the first version of their product, this is rarely a good idea.
From a user perspective, running code in the browser primarily improves the responsiveness and user experience of a web application (all those slick real-time form validations and animations). That’s nice, but not mission critical for a cash-strapped startup still trying to establish product-market fit.
Things that are mission critical: a quick launch, fast and frequent adaptations to changing requirements, a low bug count, measuring everything, and the flexibility to grow or change your development team.
An unnecessarily complex application architecture negatively impacts all of these:
- It will slow you down. Even with an experienced developer or team of developers, just the necessary duplication of functionality in two different code bases will significantly add to the development time of all but the most trivial features.
- It makes you less responsive. For the same reason that have already slowed down the first release, every subsequent change and bugfix now needs to happen in both the front and backend.
- It will cause more bugs. Apart from simply increasing the surface area for bugs to creep in, frontend code errors happen in the browser and can be very difficult to detect, not to mention diagnose, reproduce and fix. They can easily go undetected for a long time - by you. Your users will definitely notice them.
- It requires more skills. Chances are you will need more than one developer working on every feature or bugfix. That will cost more, plus require constant coordination with the potential for additional delays.
- It increases the learning curve for new team members, making it harder to grow your team, and much harder to replace contractors or freelancers.
All of this applies regardless of who develops your product - your in-house team, a freelancer or development agency. If anything, I have a hunch (completely unsupported by research) that the cost increases will be more pronounced with the latter.
Of course, there are many benefits to a sophisticated frontend/backend architecture, mostly to do with scale and integrations. I won’t go into those here, because they almost exclusively require a certain scale of product and team to outweigh these downsides, all of which kick in from day one.
Keep It Simple Stupid is one of the most undervalued pieces of advice for a startup. In terms of web application development, this means: Start your app with a simple architecture and build on top of that as needed, bit by bit. You can always switch to a more complex setup later, when the benefits outweigh the cost.
The simplest architecture is a server-side application that renders HTML/CSS and sends it to the browser. What little client-side processing is absolutely necessary can be mixed in to that without going full frontend-framework.
Personally, I’ve dabbled with a variety of frontend frameworks as a “modern” extension to my basic Ruby on Rails application setup. I’ve experimented with Vue, React, Angular and a few lesser known ones. In the end, I’ve never found a need for any of them that justified the overhead for the scale of applications that I’ve worked with.