Web Development, the back and front of it
Do you remember when Front-end was simple? I'd never have classified it as simple, but let's say it was, for argument's sake: HTML, CSS and some JavaScript. Even the latter wasn't all that common.
However, the practitioners of Front-end wanted more. They saw an opportunity in the rise of Web Development to adopt some of the approaches and tooling used to securely, predictably, and quickly build and deploy Web sites.
We knew copying non-versioned files via FTP to a web server wouldn't end well; something had to give. So we adopted things like Subversion, Gulp, bash scripts, and running deployments via Jenkins. It started to look like a real IT job!
Meanwhile, Back-end developers, or developers as they were then known, had to deal with the rise of the web and were, mostly, none too pleased with it. Web-focused development that often used PHP or Perl wasn't initially seen as proper development by many of the Java Developers I've worked with. Inevitably Java Web Frameworks started to pop up to make it all less painful. But the resulting web pages they coughed up were just terrible. The approach wasn't wrong, but the Back-end developers at the time didn't really get to grips with the Front-end; they didn't have the time or inclination. It became clear, especially with the help of the Web Standards movement, that Front-end was a thing and that it needed to become a separate profession under Web Development. And that's precisely what happened.
And then JavaScript blew up
Front-end didn't become more like the Back-end. It's the other way around. What happened was that Web Development became what many think of as Front-end today by adopting JavaScript over everything else. Tools like Backbone and Knockout kicked off the MVVM revolution. This pulled in a decent chunk of the work that used to be done in Ruby, PHP, and Java/.Net frameworks. Because the revolution was all about JavaScript, the Front-end scripting language, the Front-end became the new home for the disenfranchised Back-end Developers stuck in framework legacy hell. Because of this influx of other skilled developers, the notion of a FullStack developer came to life. When in reality, "FullStack" is just Web Development by any other name. The appeal for companies was to have just one developer instead of two. This was justification enough to ignore Front-end Development altogether. Hell, some even tried to get designers to code. Remember that shit?
Don't overthink it
To this day, Web Development remains essentially unchanged and consists of two main parts. A Back-end and a Front-end. They share tools, sometimes a coding language and are glued together through APIs provided by the Back-end and consumed by the Front-end. Of course, there are variations and subdivisions of the Back-end and Front-end, but this is the gist of it.
Just because development can happen within the same (mono) repo doesn't mean it's all one job. Frameworks and libraries can't replace the specific knowledge and skill of a particular discipline. Put the appropriate people to work for the product/solution you're working on.