I'm old enough to have experienced at least 2 full thin-client-fat-client cycles and I'm certain the current one won't be the last (at least it seems to have been a recurring pattern since the beginning of modern computer science).
While the front-end / back-end paradigm might make some sense right now because the technologies used for each of those layers conceptually seem to be quite different from each other I doubt it's really that much of a benefit. On the contrary, it might even be detrimental to effective software development:
I'm not in the business of creating either front-end or back-end code. Neither is useful without the other. I'm in the business of creating value and solving problems with software. Depending on the problem at hand this can involve different tools at varying degrees.
Focusing on just one tool or layer can lead to a potentially harmful mindset. A mindset in which you just throw your part of the work over the wall thinking that it's not your problem anymore.
The arguable benefit of having specialists churn out stuff in their respective layer more quickly than a generalist would quite likely is offset by communication and interface overhead: The difficult problems in business applications nowadays mostly arise at their boundaries. Software development for the most part means communication.
I'd much rather work in an environment where I can touch what needs to be touched to make something work, be it green or a feature. Also, there are so many things one needs to have knowledge over as a developer, it's never a true specialization anyway. On the backend you will have your backend language, the runtime environment, the serialization and service boundaries, as well as the persistence, caching and communication layers to the backing systems. On the front end you will have some aspects of interactive/evented design, domain logic and serialization and communication to the backend, along with perhaps another type of caching and persistence on the front end.
Beyond that the more tightly you can couple and work in front and back, the more effective you can be in implementing cross-cutting feature concerns.