There’s something important to note here. I’ve separated out “Discovery and Branding” (old school, monolithic apps) into their own category of client. Make note that we’re not throwing the baby out with the bathwater. Server-rendered HTML pages still have their place, but they should communicate with your database via your API. They should not have direct database access. These old “servers” are actually part of a client, a bridge layer between basic browser functionality and our API servers. They’re just like modern fully-JavaScript web apps, with the rendering layer living on another machine we own.

Rethinking Development

In order to properly decouple these application layers and clients, it is extremely important that we give each client its own development, deployment and delivery pipelines. Why? Because each of these layers has completely different request load, scaling and technical requirements. The best API server, best React app server and best traditional web server are unlikely to ever be built using the same technologies. They’re just too different, and their individual infrastructure requirements vary greatly.

This means that we must build individual application servers for all of our React, Angular or Vue apps. While it might seem like a lot of effort, we want to keep our concerns separate. For example, an API server needs a live database connection. An application server does not. Conversely, an application server needs an asset compilation pipeline where an API server does not.

The Emperor’s New Dev Tools

Looking at this decoupled ecosystem (an abundance of clients and a single API server) we begin to immediately see a problem — developer tools are generally poorly equipped to deal with the problems that pop up around multiple application environments, deployments and app distribution. The recent obsession with realtime connections everywhere poses scaling and synchronization issues between machines. “Universal JavaScript” — tightly coupling your server logic and client logic — places an artificial binding between technologies growing at different rates, sometimes orthogonally to each other. It also naively continues to treat the browser as the client, not your application.

We have a ton of tools that let us quickly run a server in our console, but we’re left utterly clueless when it comes to how to manage hardware behind the scenes. When does your deployment process involve uploading to a CDN? How do you set that up? It’s no wonder we’re so slow to adopt a completely decoupled architecture — running everything in one place is just easier. If we run a web monolith, we don’t need DevOps engineer to manage every piece of our application. This is a naive approach to development, and we need developer tools that help to remove these sorts of headaches, specifically focused around decoupled architectures serving multiple types of clients.

Without understanding these problems, much of the community is simply looking at a naked Emperor —we see the tools we’re using as sufficient, and we don’t disagree for fear of seeming left out. Many toolchains we utilize aren’t adequately solving the most expensive problems we all have, instead opting to create more abstraction layers on top the code we write — not the architecture we build. Many have had the courage to say, “this doesn’t look quite right,” but we need to act together. The development community must collectively put aside their egos and biases to agree that, hey, the Emperor isn’t wearing any clothes. Let’s give the guy some pants.

Building the Future of Dev Tooling

What does the next generation of web tooling look like? David Heinemeier Hansson began us on the “path of enlightenment” with Rails. Hand-picked design and architectural patterns, a curated technology stack. Open source. The popularity of Rails speaks volumes to its utility. What does the future look like? We need to start thinking of curation in terms of more layers of the stack, outside of just writing code — if only so that we can make sure developers are focused on what they’re best at, working at the layer of computation.

This means that developers should be expected to be developers, not a miniature IT department. We write code. We build product. Every minute we’re not taking advantage of our core competency is a minute of productivity loss. Let’s try to figure out how to abstract away the metaphor of hardware completely so we can focus on writing more code and shipping products people love.

Where Next?

These sorts of problems are the ones I’m focused on solving, and I’m excited to work with others to create the best solutions to new and emerging problems in architecture and infrastructure. I built Nodal, an open source framework for creating, deploying and distributing decoupled API services to focus on providing the best API layer possible and remove the headaches associated with infrastructure management. In adjacent spaces there are sole developer projects like Vue tackling giant ecosystems (React), generating alternatives that seem like good targets for delivering promising results.

This is a space we can make better, together. I recently founded a startup, Polybit (literally “many bits”), to craft the best open source software to tackle these evolving problems. This is only the beginning of many new, creative and thoughtful solutions to help support a changing ecosystem and the newest frontiers of web development.

Let’s build the future. E-mail me if you’d like to help — keith@polybit.com.