So – are you a server-side or client-side developer? What if I said that was an archaic way to classify application development. I believe that the clear red lines that used to separate client-side and server-side application development are increasingly blurring. In order to be an effective application developer in this day and age, you need to be at least comfortable (if not proficient) at both ends of the HTTP connection. Let me explain.

Not to go all ‘grandpa sitting on the rocker’ on you, but back in the day when I first started programming, you picked your sides early. You were either a server-side developer that worried about things like threading, database optimization and messaging, or you were a client-side developer that worried about things like layouts, page performance, JavaScript (or maybe Flash) etc. You were rarely both. I think that such a rigid distinction is increasingly an anachronism. There are several trends and technologies that are coalescing at the same time to drive this change, and here are a couple of them.

• AJAX and Responsive UI: There was once a time when a web page meant some static HTML markup, some data bindings (e.g. JSP tags) and a big ol Submit button that sent all the form data to the server synchronously while users waited around finding new ways to twiddle their thumbs. We’ve thankfully moved away from that to more responsive UI’s that combine JavaScript, AJAX and DHTML to exchange data with the server asynchronously and deliver faster page response times. I think that this is actually part of a broader trend that is moving more application logic to the front-end (i.e. browser) and so if you thought of yourself as a ‘server-side’ developer, you can no longer get away with dropping in a couple of data binding/templating tags into static HTML markup that your creative team sent over. You need to get over your JavaScript aversion (if applicable) and learn to develop responsive (i.e. asynchronous), rich UIs. The good news is that there are some great JS libraries like JQuery, Prototype and YUI and web frameworks like Play and Tapestry (for Java) and Rails and Sinatra (for Ruby) that make this relatively easy to do.
• Increasing maturity of JavaScript: Another factor that is contributing to the move to more client-side processing is the increasing maturity of JavaScript. This may surprise the legion of JavaScript haters out there (I know because I was one of them), but JavaScript is all grown up (well, kinda). With MVC frameworks like Backbone.js (and many others), you can now implement some the same patterns and best practices that you use on the server-side in the browser. There are also some very interesting client-side templates for JavaScript (like mustache, underscore.js, dust,js etc.) that let you render dynamic web pages on the client side (vs having the server return the assembled HTML markup). The next version of JavaScript (aka ‘Harmony’) that is currently making its way through the standards body should also go some ways towards making JS a truly first-class language. And if you’d rather not deal with the, oh lets just call them ‘eccentricities’, of JavaScript (case in point – can the real ‘this’ please stand up?), there is always CoffeeScript.
• ‘API First’ design – The move to a ‘thicker’ or ‘smarter’ client (using technologies like JavaScript) overlaps with another trend that is gaining traction – the notion of an API First design. With this approach, you first design your ‘server-side’ as simply a set of APIs (typically REST/JSON and stateless). You can then consume these APIs from any number of loosely-coupled clients – iOS, Android, browser etc. – thus providing different customized user interactions to the same set of backend data/processes. The API First approach doesn’t eliminate the client/server programming divide (designing a good REST API is a specialized skill for example), but it does question our assumptions of what a ‘client’ or ‘server’ should do. Some food for thought for developers that would rather live in their old client/server silos.
• JavaScript on the server-side: The distinction between client-side and server-side programming really starts to blur when you can run JavaScript on the server side. The most famous example of this is of course Node.js, but there is also Rino and SpiderMonkey. Yes, server-side JavaScript is not new, but it seems have gained critical mass with Node.js (the most watched project on GitHub) which has the potential to radially realign the old client/server divide. The asynchronous, event-loop driven nature of Node.js is not a good fit for all types of apps, and its still a bleeding-edge library in many ways, but its definitely here to stay. To be truly successful on the server-side though, JavaScript will need a rich ecosystem of libraries and frameworks that are optimized and designed specifically for a server-side environment (vs accessing/manipulating the DOM). There is progress to report on that front as well with the CommonJS project’s attempt to define a standardized set of APIs to access things like the file system, network etc.
• HTML5 + CSS3: Back in the day, developers had to use various proprietary plugins and technologies like ActiveX and Flash to implement rich UI interfaces. This was yet another barrier that kept server-side developers such as myself from doing anything serious on the client-side. With the advent of standards like HTML5 and CSS3 however, you can now develop compelling web applications that support push notifications (via WebSockets), advanced graphics (via Canvas, WebGL etc), offline access (application cache and client-side storage) and much more without having to resort to proprietary plugins or technologies. I see HTML5 as another key enabler of the broader trend of moving more application logic to the client-side and developers need to get on-board or risk getting left behind.
• Mobile development: The next frontier in enterprise application development is surely mobile. So if you’re developing a native (say Android or iOS) or web (i.e. HTML5) mobile application, are you a client-side programmer or a server-side programmer? A lot of mobile development involves dealing with UI elements and layouts (traditionally thought of as client-side programming), but enterprise mobile applications in particular also need to access backend services and data using protocols like REST and OAuth. Moreover, given the resource contained environment, native mobile app development in particular requires intimate knowledge of things like asynchronous processing, threading and memory management (in the case of Objective-C). The old-school client/server programming divide therefore largely doesn’t apply to mobile development.

Having outlined my Grand Unified Theory for application development, it is now time for some important caveats. First, I believe that the lines between client side and server side programming are being blurred, not erased. Most developers will still choose to specialize in one or the other. Rather, the key takeaway here is that modern web/mobile applications no longer afford you the luxury of focusing on any one ‘side’ exclusively. Second, not all applications are web or mobile apps and so this reasoning only applies to a certain subset of application development.

So if we can no longer think of ourselves as just client-side vs. server-side developers, how do we classify application development? I think that a better way of thinking about it is what type of applications you’re building. Are you a Social application developer who builds apps to connect users to their ‘social graph’? Are you a SaaS application developer? Or are you mobile application developer? Perhaps a Game developer (even in the Enterprise)? All of the above? Whatever your answer, just remember that the next time someone asks you whether you’re a client-side or server-side developer, you can answer ‘Wrong question’.