Do people really pigeon-hole themselves into being just back-end engineers? Or just front-end? I can imagine a designer-type person picking up HTML, CSS, and eventually JavaScript and calling him/herself a front-end engineer in a limited way. But as a programmer I work on all of it, both server-side and client-side portions. (So I'm a full-stack engineer I guess.)
It seems to me that a designer who picked up some JavaScript would still not be a programmer. Lots of apps require advanced JavaScript to run a UI client-side. I would not expect anyone who was a full programmer to be just a front-end engineer and be completely unwilling to learn PHP or Ruby to also work on the back-end. If I met a person like that I would think the person a horrible programmer and not hire him/her. (Unable or unwilling to learn, lack of passion for software engineering excellence.) A designer with a few extra skills is one thing, but a restricted programmer is something else entirely.
But what do I know? Hence I ask whether this is common.
At the expense of being flamed, I'd say that every back-end engineer can do front-end work even if the end result is terrible from a user experience perspective. You may even find cases in which a person can be equally adept at both.
That being said, I believe that there are more front-end specialists and designers who cannot do what it takes to build an efficient back-end tool.
Try showing your latest application around an office. Few people will comment on how you are grabbing the data, but everyone and their mother will tell you how to make it prettier.
There are also back-end specialists who cannot do what it takes to build an efficient back-end tool :)
The skills involved in web development and software engineering are so varied that I'd hesitate to define too few buckets to categorize people. Traditionally I think the reason designers get away with learning a bit of JS is because of the simple request, pageview and DOM semantic of the web makes it easy to hack on things until they work without the danger of really screwing things up too bad for 3 reasons: 1) you don't worry about persistence, 2) you don't worry about scalability, and 3) any problems you created only live as long as the pageview does.
Newer APIs like client-side storage and pushstate are allowing browser js to quickly evolve into the realm of serious software engineering with even a few twists of its own (like no easy production logs.) Of course a web designer can still come and do a tutorial and duct tape some things together, but this is equally true of PHP, rails or node. There is an inherent learning curve in learning how to operate at various levels of abstraction well enough to engineer a system that meets latency, scalability, correctness and maintainability requirements for a non-trivial app.
From the other end of the spectrum there are a lot of backend engineers who don't want to touch the frontend.
IMHO aside from javascript, there's a huge tedious side to frontend engineering involving html, css, browser incompatibility and ugly hacks that aren't really programming in a sense (more just endless debugging). It's all very domain specific knowledge that doesn't translate well onto other facets of of traditional programming. Hence a lot of backend devs want to stay away from that so they build a wall of separation between the people who do want to deal with it and the ones who don't: "Frontend" and "Backend" engineers.
It depends on the employer but I find it quite common. Non-technical hiring managers might see a full-stack developer as a both a backend and frontend developer and it seems very attractive. Top tier employers usually want the best of the best and can afford to have multiple members on a team and thus allow that specialization.
If you specialize in a certain skillset, focusing on that skillset gives you time to be even better. Sure, there's developers that can write both back-end and front-end code but they've given up a level of specialization in order to do that. It's not a reluctance to learn but a different focus of what to learn. It has nothing to do with passion.
Most full-stack developers I've met are really backend developers that can also write some front-end code. They don't spend the time to learn all the intricacies of CSS/HTML or stay up to date with changes in spec / new tools and methodologies. I don't know you at all so I can only guess but if you think about it, do you find yourself better at either the frontend or the backend? It's very rare for someone to be a top 10% backend developer and a top 10% frontend developer. I could call myself a full-stack developer because I'm capable of writing both portions of an application but I know that I don't write one end as efficiently or securely as a specialist.
It's just a matter of specialization, is all. Not exclusivity. My interest in web development originally stemmed from design, and I am much stronger working on the front-end, as my passion is in UX.
That being said, I absolutely aspire to be a full-stack engineer, and I'm having fun working towards that goal. I agree that somebody unwilling (let alone, not enthused!) to learn the full stack would make for a horrible programmer.
When your application gets big enough, you'll need to split these roles and find more specialized people. Web is a big thing, and it's getting bigger with the introduction of MV* front-end frameworks.
I call myself a front end engineer. I could easily write an essay about it. In lieu of that, here are a few reasons why.
I came from so-called full stack development. I, unlike many engineers (though the percentage seems to be trending upward), took an early interest in the client-side stuff. As I learned more, I found I was answer more and more of my peers' questions. So that interest turned into a full time job.
The thing about the front-end is it's very easy to pick up in part because it's extremely flexible. You can write horrible, horrible markup, for example, and the rendering engine will bend over backwards attempting to make sense of your mess. And it generally does a pretty amazing job. But, is that code going to be robust? Given that that code has to run on thousands of permutations of environments (different versions of different engines/parsers, on different OSes, on different hardware), how confident are you that it will render correctly? Lets say it doesn't render correctly somewhere, is it because of something you did or is it a bug in the engine? How do you figure that out? If it's a bug, how do you circumvent it?
Many people I work with like the thought of building for one environment. You write code. If it compiles / parses without throwing, you know that execution path works. You cover the different execution paths with test and, if those pass, you ship it. Case closed.
The front-end isn't nearly as clean. It's definitely getting better but there will never be one universal engine / parser. You could argue this is similar to the situation with Ruby, having multiple interpreters. The difference, however, is you choose the interpreter. Front-end guys don't have that freedom as it's controlled entirely by the client.
But lets say you've written bulletproof code. You've got it rendering everywhere. Does it make sense for that platform? Is that same bit of code appropriate for the device it's running on? What about if the network drops out? What if the user has difficulty seeing, will the screenreader bark nonsense or will your site be intelligible? What about if the user is on a touchscreen? Or using a input peripheral for someone with limited mobility? You can be sued for having a site that isn't accessible (discrimination); would your application pass muster?
And that's just the presentation piece. I could go into JavaScript stuff but this is already long. Let's just sum it up by saying there is a lot of terrible, TERRIBLE JavaScript out there (again, mostly due to how simple and flexible it is). Just like anywhere, it takes work to write good, clean, performant, and maintainable JS.
I would argue that the front-end should be considered another tool in a polyglot programmer's toolbelt. Specialization should consist of knowing the edge-cases and gotchas that your typical polyglot won't necessarily know or have interest in but that shouldn't mean you're incapable of developing elsewhere, or are in any way less apt at being a "back-end engineer."
It seems to me that a designer who picked up some JavaScript would still not be a programmer. Lots of apps require advanced JavaScript to run a UI client-side. I would not expect anyone who was a full programmer to be just a front-end engineer and be completely unwilling to learn PHP or Ruby to also work on the back-end. If I met a person like that I would think the person a horrible programmer and not hire him/her. (Unable or unwilling to learn, lack of passion for software engineering excellence.) A designer with a few extra skills is one thing, but a restricted programmer is something else entirely.
But what do I know? Hence I ask whether this is common.