Amazing description of a full stack web developer

when did “web designer” become “front end developer”?

It never did.
“Web Designer” was a loaded term which doesn’t accurately describe the modern division of work for today’s sites and web applications. The closest thing we would call someone today who still would fit what we imagined “web designers” to do would be a “full stack developer”.
Back in the day of what I call “brochure” sites (static content, basically putting your company’s brochure online), you basically had one guy make your little site. It was easy, very little design or focus on experience, and people simply wanted to know/imagine they had some degree of an “online presence”.
Today, that task is divided up into specialized individuals. For those whom are not actually managing the product, you’ll have UX and/or UI designers handling the design side, engineers or backend developers handling the server side, and front end developers handling resources that touch the browser. You’ll also likely have DevOps handling automation and deployment, as well as QA.
The role of the front end developer is specific, and it needs to be specific because the job is far more involved than it was back when we were just making brochure sites. You have a multitude of browsers to worry about (IE8, IE9, IE10, Firefox, Chrome, Safari), a multitude of devices to worry about (mobile, tablet, desktop), and with fun paradigms like client-side templating, you actually have a lot of logic moving to the client-side and the server becomes merely an API to your data.
Having a dedicated designer is great – these people focus on the trends of design, usability and ensure everything meets the branding requirements. This was previously a function your “web designer” would serve, but there’s simply an upper limit to the number of things you can give your attention to. As the general population has moved to the web, the expectation for a good user experience on your site has dramatically increased, so having dedicated designers for this task proved imperative.
On the other side, the server side landscape changed quite a bit. We initially started off with a lot of Perl to do server side tasks (anyone remember cgi-bin?), but that was shitty as hell. Then came the web-specific languages of PHP and ASP. Crappy, what I would call a mess of global function “languages” which seemed to encourage a lack of separation between your view and logic. Then the explosion of languages came about, as Ruby, Python, Java and even ASP.Net came along with their web focused solutions. You now have more newcomers like Go appearing and making quite the impression. Equally, an explosion of databases came about, an no longer were we only looking into MySQL or MSSQL, but PostgreSQL, Redis, Cassandra, MongoDB and so on, each quite different from the rest. The job of server side had to be specialized to keep up with all the action.
And of course we get to the front end. Responsive design opened up a whole new world, saving us from a native mobile client hell. Caching and performance became huge factors, and such things as dynamic asset loading were alien and weird to someone on the server side used to simply calling everything you needed up front. Client side templating and AJAX meant we didn’t need to make a full round trip to the server just to show you a tiny bit of updated information, we could issue a tiny request and get a tiny response back in a fraction of the time, reducing bandwidth costs and improving the overall responsiveness of the site. We moved away from graceful degradation to feature enhancement. We introduced @font-face, became concerned with typography and vertical rhythm. We introduced SVG’s and inline-data into our CSS. We started splitting up our Javascript into modules using the AMD or Common patterns, and moved away from ugly onclick handlers to proper event handlers. In some cases we switched entirely from server side routing to client side routing, making our entire sites single page applications – and making those sites an order of magnitude faster. We dropped browser detection and switched to feature detection. We became concerned with our markup and adopted HTML5′s semantic tags rather than XHTML’s div-only world. We started storing state in local storage. Steve Saunders made us paranoid about caching.
And deployment changed as well. No longer were you just pushing code changes up via FTP upon save in Dreamweaver, you now had Git repos (and prior to that, SVN, and to that CVS) with real multiple environments. No longer were you just dealing with Apache, but nginx now with reverse-proxies for passing non-static asset requests through to their interpreters. Node.js hit the scene and introduced the option of evented servers. We stopped deploying to a single dedicated machine, but to the cloud. We had to start managing load balancing, VPS’s, and all manner of security concerns. We started using virtual machines to ensure your development environment was the same as the deployment environment. Then we started using Puppet and Chef to manage all those server and VM’s software configurations. Then we started using Vagrant to manage virtual machine configuration and deployment.
We started using Jenkins for continuous deployment. Capistrano to facilitate deployment. We implemented unit tests and integration tests, and test driven development. We introduced the agile method with scrums, stories, points, sprints and backlogs.
“Web designer” never became “front end developer”. The role was politely split up, divided, and handed out to specialists. It was just too much for any one individual.