We’re big fans of split stack development. This is an architecture pattern that’s been developing for years now, but we think the new split is front-end to back-end. In fact, this is the same pattern that we used in our recently-open sourced Crunchinator. You can see the backend and frontend code on Github.

Here’s the gist: for very large applications, there’s always been a bit of a split on the backend. A high-scale application might be built with a Java API for performance, with a layer of PHP in the middle to generate the HTML and Javascript.

In the past few years, JS engines have gotten fast enough to support very powerful frameworks running in the browser: AngularJS, Backbone, Ember, Knockout, Meteor, D3, and others.

At the same time, the expectations for software have expanded. CSS has always supported abstracting data away from presentation to support different outputs, but the focus was simple presentation, and typically on a traditional computer. We’re now looking at dynamic UIs on desktop, but we’re also expected to support a bigger range of devices, some with built-in presentation layers that require interacting with the SDK on the device – you can’t get away with a mobile stylesheet anymore. CSS isn’t enough.

Here are some of the ways that data gets sent out in a modern app:

• desktop web
• mobile web
• native iPhone
• native iPad
• native Android phone
• native Android tablet
• Blackberry

Let’s also account for the Smart TV, smart watches, smart cars, Google Glass, Oculus Rift, and so many more that are just around the corner.

Out of the devices I just named nearly all require a solid API for the backend, but traditionally the backend was responsible for an API and the web app – as if they were the same thing. They’re not, and split stack development acknowledges this.

By building a solid API and a separate frontend (like with Angular) in the beginning, you automatically get the ability to plug new interfaces in without dangerous and costly rewrites to separate the HTML-generating backend code (not that it should have been written that way in the first place, but splitting the frontend completely from the backend enforces this good practice early on).

This also means page updates are faster and use less bandwidth, plus the UI and other assets can be easily pushed onto a CDN (which you can get for free from a plugin).

On a technical front, this is absolutely the future. It enforces good programming practices, makes it easier to build automated testing, and minimizes technical debt. But that’s not the only reason we like it. Split stack programming also makes sense when it comes time to grow the team and the app. It’s easier to hire people who focus on one area than to find someone who is truly full-stack.