Web Development, the back and front of it
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.
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.