Languages and frameworks are tools, but they're tools that require significant time investment to master and there are too many of them to master every one. There are many, many cases in which a given person's "optimal" language to use for the task is different than the "optimal" language would be if the user were somehow equally skilled in all.

Obviously, if the project is far outside the sweet spot of a given programmer's favorite language, it's worth it to learn a different one. The larger the project, the more often this is true. If for example, a Java specialist wanted to build a webapp, it would likely be worth it to invest the effort to learn how to do so with JavaScript instead of sticking to the familiar GWT. But for a smallish text manipulation task, it's just not worth it for an expert user of Ruby (a pretty good text manipulation language) to learn Perl (a language really designed for text manipulation).

The sweet spot, in my opinion is to work at getting very good at one language per major domain area and change focus only for large projects, for projects far from the sweet spot of any already known languages or for fun.

Becoming a "JavaScript developer" surely pigeonholes you, and that is not good, but early in your learning process it can be good to pick a bread-and-butter language to master first.

That way, you aren't spread thin as you learn everything for the first time, and when you learn new languages you can relate them back to your first language, of which you have a complete grasp.

Naturally in the long run you want to be totally language agnostic, but early on I think that's putting the cart before the horse a bit.

Also, you have guys like me, who code as an ancillary function to our actual job. For us, one or two workhorse languages are all we really need to invest our time in. Think of a physicist who knows Fortran, for example. He is a "Fortran guy", but that's ok. He's a physicist, not a developer.

The other nice thing about picking a "bread-and-butter" language is that it qualifies you for opportunities where you can leverage it to learn other skills. It's so much easier to learn, say, machine-learning if you enter a company where there are machine-learning experts that you can observe at work and ask questions of, rather than just trying to read all the online course material. That requires having something to bring to the table, and if you're really good at frontend stuff you can get hired at places that do that and work on projects where people are doing really interesting backend stuff.

If you want to point out that the way the world works is crazy - well, alright. But the rest of us have to make a living, and the way hiring works is that organizations hire in part based on your experience with a certain language or platform. "Well, they're doing it wrong". Okay, let's say I agree. Then what?

"Right tool for the job" is getting to be a very tiring orthodoxy. It seems to come around whenever people don't want to get into the nitty-gritty of comparing tools. I say stop the handwringing, pick something that feels right to you, and start doing stuff.

No it is standard way to work in the consulting world.

Every project I work on tends to have a complete different technology stack.

"The trouble with computer science today is an obsessive concern with form instead of content."

Interestingly, literature has the same problem.

You have to start somewhere.