Table of Contents
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.
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.)
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.
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.