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 JQueryPrototype 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’.

Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • ramanathan pachaiyappan

    Good write up but it holds true for people working in public cloud apps only. I think doing a infrastructure development still a great deal if you choose your own private/hybrid cloud model

  • http://twitter.com/Montagist William Saunders

    I agree that developers should be fluent in both, but I have a hard time agreeing with much more than that from Salesforce if it remotely resembles commentary on the proper separation of logic, as well as anything about rich, AJAX-enabled UIs. Salesforce’s made all kinds of architectural decisions that, in some ways, almost encourage one to load their controllers up with logic, not to mention the fact that all Apex code is likely to be littered with SOQL all over the place. This is bad for design. Also, I wonder if anybody at Salesforce actually understands the point of AJAX. It’s so you don’t have to send a large chunks of data back and forth just to re-render a small part of the page. Unfortunately every Action you call from Visualforce or section you refresh retransmits a large, encrypted blob of state that is stored at the bottom of your page. Isn’t that antithetical to the point of AJAX? Furthermore why is it that, despite every related list in the standard UI being AJAX loaded, the simple act of deletion (and addition) cause a page refresh? Again, THIS MISSES THE POINT OF AJAX.

    And Web “Standards”? Don’t even get me started – the very article you link to about Websockets makes it obvious how inconsistent the support is across browsers (if supported at all). Furthermore WebGL is not an official W3C or WHATWG standard.

  • http://twitter.com/Montagist William Saunders

    I agree that developers should be fluent in both, but I have a hard time agreeing with much more than that from Salesforce if it remotely resembles commentary on the proper separation of logic, as well as anything about rich, AJAX-enabled UIs. Salesforce’s made all kinds of architectural decisions that, in some ways, almost encourage one to load their controllers up with logic, not to mention the fact that all Apex code is likely to be littered with SOQL all over the place. This is bad for design. Also, I wonder if anybody at Salesforce actually understands the point of AJAX. It’s so you don’t have to send a large chunks of data back and forth just to re-render a small part of the page. Unfortunately every Action you call from Visualforce or section you refresh retransmits a large, encrypted blob of state that is stored at the bottom of your page. Isn’t that antithetical to the point of AJAX? Furthermore why is it that, despite every related list in the standard UI being AJAX loaded, the simple act of deletion (and addition) cause a page refresh? Again, THIS MISSES THE POINT OF AJAX.

    And Web “Standards”? Don’t even get me started – the very article you link to about Websockets makes it obvious how inconsistent the support is across browsers (if supported at all). Furthermore WebGL is not an official W3C or WHATWG standard.

  • http://profiles.google.com/luismgz Luis Gonzalez

    Very interesting thoughts. I’ve been thinking a lot about it lately, specially after having played with coffeescript and jquery (and Agility.js, which is a simpler alternative to backbone or knockout).
    However, I still find strange that most developers seem to remain stuck with increasingly complex server side frameworks such as Django and others, and paying very little attention to the client side.
    Today, mobile development is almost all client side. If you want a responsive UI,you must do it client side.
    Whole server side apps are so 2005… ;-)

    I cut my teeth with python, and I love it. This is the main reason why I stayed away of the client for so long, because I hate javascript and its verbose and clunky syntax. I simply didn’t enjoy writting javascript. It was a pain compared to the joy of python.

    But jQuery and Coffeescript changed it all. Coffeescript is not only very similar to python. It has some nice features taken from ruby that are a very nice and welcome addition.
    Right now, I’m playing with MongoDb (you can get a 240 MB free account in mongolab).
    What a pleasure! Only one language to rule it all, one data exchange format (json), simpler set up, less layers, more fun.

    • Anonymous

      Great points Luis. Coffescript is indeed manna for all those with JS allergy symptoms!