I've been building websites for a very long time. When I first started back in the mid-late 90's there wasn't much of a distinction between front-end developers and back-end developers, we all had to know everything, you couldn't specialise as there wasn't really much of a need for that. "Build me a website" was about as much spec as you could expect.
Fast-forward a decade or so and the landscape became very different indeed, now specialism was where it was at, if you wanted to develop for the web (and didn't want to be full-stack) then your choices were clear, it was either 'front-end' or 'back-end'.
Back-end developers dealt with data, their joy came from manipulating numbers and strings, finding terser ways to create complex functions and do some truly amazing things with vast and complex data-structures.
Then came NodeJS and everything went wrong.
The job specification conundrum
Most of the problem rests with nomenclature, in the recruitment market front-end developer, web developer, front-end engineer, UI developer, UX developer etc... are all interchangeable terms. This confusion has spread so far that many developers don't really know what to call themselves.
The problem is compounded by non-technical people writing job specs. I suspect a lot of the time, job specs are filled with buzz wordy skills that people think they need, so at the moment nearly every job is calling out for React or Angular whereas, if you are technical enough to know these languages; you'll realise that it's highly unlikely that these projects would even benefit from using those technologies.
The amount of times I've seen a spec which lists several competing tools as requirements is too damn high, sure it's possible that a project uses gulp, grunt and webpack but it's unlikely. It's even more unlikely that a project will use React, Angular and Ember all together and yet they are all listed as essential skills.
This of course is not a new problem, I can't even count the times I've seen C# listed as an essential skill for a UI Developer, the issue probably began with the hiring manager asking a techie what sort of skills they need and they will have replied "someone who knows a JS framework, like React, Angular or Ember" and the hiring manager just writing "must know JS, React, Angular, Ember" in their notes. All subsequent technical projects will just copy/paste the same spec and edit the wording a bit and thus the problem persists.
Why this matters today
The problem with this is that back-end developers often have a massively different mindset to front-end developers. Take a look a this list of portfolio sites and it's not hard to see which ones are back-end and which ones are front-end, you don't even need to look at their skills list, the distinction is obvious, front-end developers have great UI's with content that cuts to the chase whereas back-end developers have a lot of text and a lot of lists. Why? Because back-end developers care about data and front-end developers care about interfaces.
Want an example? A backend developer would look at this code and possibly see no issue, a front-end developer would shudder in horror:
<div id="navigation"> <p> <a href="/link1" style="color: red"><span><b>Link 1</b></span></a> | <a href="/link2"><span>Link 2</span></a> | <a href="/link3"><span>Link 3</span></a> | <a href="/link4"><span>Link 4</span></a></p> </div>
That actually hurt to write.
So what's the answer?
This one is actually quite simple. Front-end and back-end don't really make sense as terms anymore, it was find when client-side code (the front-end) and server-side code (the back-end) were hugely different but now the waters have mixed a little it makes sense to chance the nomenclature.
So I propose we call them what they are: UI Developer, Front-end engineer and Back-end Engineer.
Back-end Engineers are the traditional back-end developers, they concern themselves with all the complex functions and systems that go hand-in hand with the manipulation of large amounts of data and the management of those systems.
Obviously there will be people with skill overlap (personally I'd consider myself a UI Developer with a bit of Front-end engineer thrown in for good measure) but most people specialise somewhere and that is what recruiters should focus on.
Nobody wants a world where everyone is a full-stack developer, it may seem good for the bottom line to hire one developer instead of two or three but that path has terrible websites at the end of it and a bad website = unhappy customers = lost money. A formula that I'm sure most businesses will agree, isn't a recipe for success.