Reign of the Front End

For the past five years, I have thrown myself head-first into the world of JavaScript, React, Meteor, Node.js and MongoDB, working on eight SaaS projects. Seven of those projects were greenfield MVPs, while one of them was a significant overhaul of an existing system.

I've seen first-hand how, in bold defiance of conventional wisdom, a single language, scrappy JavaScript, can be used to create enterprise-class systems. And because tools like Node.js and MongoDB reduce friction on the back end, I've seen how a JavaScript-only approach can free up intellectual horsepower to focus on the front end (UI/UX).

This could not come a moment too soon. Increasingly, modern websites are dynamic, responsive and reactive. They behave like installed apps. They push the limits of HTML and CSS, leveraging complex stacks of JavaScript code to deliver the best possible user experience. They use 3D animations, drag/drop, collapsible sections, momentum scrolling, popovers, type-ahead boxes, layer sliders, image galleries, maps, location awareness, video feeds and graphs. Modern systems are expected to work equally well on touch devices and desktops, across all browsers.

In my own experiences, when developing a SaaS application from scratch, a disproportionate amount of time is required to deal with front-end issues. I have been telling my clients a rule of thumb: 75% of the development effort goes into the front end. This of course will vary depending on the type of project, but I'm talking about a typical multitenant SaaS applications (e.g., Mailchimp, AirBnb, Uber), which are essentially fancy user-to-user communications systems without a lot of number crunching on the back. In my view, this brazen 75% estimate is conservative. With great tools like MongoDB, Node.js and Meteor, the back end practically takes care of itself, assuming you have good standards and patterns to deal with transactions, aggregate functions and security.

Why is the front end more costly and what can be done about this? The problem is that the tools and technologies for dealing with the front end are changing at a frantic pace. Just one clear example: React exploded onto the scene just a few years ago, effectively dropping a nuclear bomb on the Meteor community. Now there was a completely new way to express the entire front end, often requiring a total re-write.

User expectations about UX are being shaped by blockbuster applications like Facebook. This kind of real-time user-to-user experience requires a solid architecture, plus a dizzying number open-source packages.

As user expectations increase, so does the complexity of the front end. Each feature requires the integration of complex third-party offerings. Take for example location awareness and mapping: modern applications are expected to be able to deal with this, and that requires successful, careful integration with hefty third-party packages and external APIs.

Evaluating open-source offerings can be time consuming. Packages tend to be in a constant state of flux as developers struggle to maintain compatibility with other systems, while simultaneously dealing with bugs and feature backlogs. There are competing offerings, each with strengths and weaknesses. 

It is necessary to install the packages and use them first-hand to prove that they will work harmoniously with the rest of the stack. You need to dive into the JavaScript code, frequently single-stepping through it with a debugger to diagnose issues. This process can disqualify a tool, resulting in a new round of searching and evaluation.

Clearly, one of the costly activities is research, and in my view this cost of evaluating third-party packages is difficult to avoid. This is one of the key reasons that I'm a strong proponent of using a pre-written framework for developing new SaaS applications, particularly greenfield: the framework contains a variety of third-party packages that have been curated and are known to work well together.

Yet, even with a framework, it will be costly to evaluate and select third-party products which are specific to the problem domain. Budget accordingly, and be ready to compromise to get the best overall UX by artistically leveraging the features from your chosen packages.