The Shifting Definition of Front-End Developer

Until the advent of the web, professional software development didn't have a front-end/back-end dichotomy. There were C programmers, Pascal programmers and FORTRAN programmers, but the language they used was a detail rather than a reflection on their background and career path.

Then the web came along, triggering the influx of a massive new community of developers who didn't have the inclination, background and/or mindset to hack traditional imperative code. Initially they were mainly writing templates in languages like PHP and ColdFusion (and later JSP and ASP.net) to generate HTML that was rendered by the browser. Although web developers were technically still coding on the server tier, the seeds of the front-end/back-end split were sown.

Round about the turn of the century, two major innovations accelerated this trend: Ajax and CSS. Ajax made it possible to push much of an app's logic into the browser, with the server exposing APIs for retrieving and updating data via SOAP or REST. This new paradigm gave rise to jQuery, which essentially created a whole new language to replace vanilla JavaScript, tailored to the needs of front-end developers. Browser incompatibilities were abstracted away, the crappy DOM API (including the weirdness that is XMLHttpRequest) was replaced by a sane one and built-in functions made it easy to produce eye-catching animations and transitions.

Successive versions of CSS, in turn, have made it possible to create ever more sophisticated page layouts while significantly raising the skill level needed to do user-facing web development. This led naturally to more specialization. Suddenly a formal computer science education and a grounding in algorithms, system design and imperative programming languages were no longer necessary to work as a professional programmer. Great design sensibilities and a knowledge of user experience fundamentals, in additional to a technical mastery of HTML and CSS, were sought instead. The schism between front-end and back-end developers was complete.

In recent years, however, the situation has become muddier. No longer is it true that all heavy lifting happens on the server. The trend towards single-page apps has given rise to libraries like Angular and Ember that in their scope and ambition are much more like back-end frameworks. Companies that pulled out the stops to hire qualified front-end devs suddenly find that they are not able to master all the intricacies of the latest front-end frameworks. These developers, meanwhile, sputter in frustration that Angular has a "problem" because it was designed by back-end devs who just don't "get" how client-side development is done.

This is not to say that hacking Angular is beyond the ken of every front-end dev. Software development skills are not discrete but can be plotted roughly on the following continuum. (Note that this is not a workflow diagram—in which case UX, for example, would precede graphic design—but rather indicates the proximity of any two skills. The closer they are, the more likely a given individual is to possess both of them.)

(Based on this illustration alone you can probably guess where I lie on the spectrum.) In my experience almost all developers occupy some contiguous segment of this continuum. There are some devs who can handle broad swathes of it, and I am totally in awe of them. I'm sure that somewhere out there is a guy or gal who does world-class graphic design and codes Unix device drivers. Nonetheless, most of the front-end devs I've met occupy roughly the range from UX to jQuery, maybe with a dash of design or (non-jQuery) JavaScript thrown in. The rise of web development has greatly expanded the pool of potential programmers by opening the door to those who fit this profile.

Now that single page apps have pushed a lot of the work that used to happen on the back-end tier into the browser, the UX-to-jQuery folks are suddenly being asked to do hardcore software engineering. Meanwhile what's actually happening on the server has in most cases become pretty boring and mundane, authorizing API calls and serving data out of a database via REST. Approaches like CouchApps aim to get rid of the server entirely, and it's not implausible that something like this will go mainstream in the next few years.

So the problem isn't with Angular. Granted it's a bit dated by now in the fast-moving world of JavaScript frameworks, but the idea of single-page apps, with most application logic running in the browser, is fundamentally sound. And the problem isn't with front-end devs. The world still needs developers who can synthesize customer requirements, work with graphic designers and navigate the ever more labyrinthine CSS standards to produce gorgeous, responsive and functional user interfaces.

The real problem is the perception that any code running in the browser is front-end code. This is patently no longer the case. Either we find another term to describe the UX-to-jQuery crowd or we redefine what we mean by "front-end".

For what it's worth, our company has chosen the latter. We divide our developers into two groups: front-end and full-stack. Front-end involves the same skills it always has: UX, HTML, CSS and jQuery, nowadays with a smattering of Angular directives and the like thrown into the mix. A deep mastery of CSS is particularly important, as modular responsive stylesheets have become a vital part of modern web apps. Full-stack engineers work on everything else, which often means building big complex software architectures using Angular or some other "front-end" framework with a Node.js backend that does little more than serve up data.

Angular and other big-iron web frameworks are not an affront to front-end devs. They are just the latest manifestion of a long-term trend: code moving from the server to the browser. Let's define "front-end" to mean the parts of the app relating to user interface, rather than those that happen to be running in the browser's JavaScript VM. If we assign tasks to our developers accordingly, we will see that the new world of single-page web apps is very much like the old one. Plus ça change...