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."
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."