1. Employers don’t train on languages/frameworks. In most circumstances employees are expected to learn on their own or from a prior employer before applying for a job. Worse, the last place I interviewed only asked about learning from the current employer while never asking about self learning outside the office.

2. Employees, in many cases, believe they can cheat learning by using a tool or framework. That is largely due to a lack of boundaries and experience in a given environment or platform resulting in low trust of peers and the technology.

If you want to require learning then provide sufficient learning material expecting a predefined structured outcome.

How often is it really only a few days, though? If you're talking about learning a different programming language, that's no small thing for a junior developer. For a senior who knows multiple languages already and has a few years of experience, learning the new language itself might only take a matter of days to be productive, as long as it's still a similar style of programming to something they've done before. But then you need to find your way around the ecosystem so you can make informed decisions, and that ecosystem might be huge and mostly low-quality, even if the good parts that you eventually want to use are not.

For similar reasons, in the case of web development specifically, I think people often have unreasonably high expectations from using JS/TS both front and back. Yes, it's the same language, more or less. Yes, sharing code can sometimes be useful. But the JS standard library is limited, and the ecosystem beyond that has almost nothing in common on the front and back ends. In practice, assuming you have some decent senior devs on your team, that ecosystem jump is still likely to be the biggest time sink even if you're running something in Node on the server.

So I kind of agree with both the parent and GP comments. It is beneficial to use familiar tools and reduce the need to learn new things before you can be productive, but you are going to have to learn new things sometimes anyway and that might require significant time no matter what you decide to do. When it comes to making fundamental architectural decisions for a new project, it's wise to keep the potential costs of using new things in mind, but it's foolish to disqualify choices that might be better in the long term because of small differences in up-front costs.

Depends entirely on what you expect the devs to do, naturally. Junior devs are IMO not supposed to make informed decisions of significance in any language, that's what you have senior devs for.

GP's use case of having frontend devs do small changes to backends and vice versa to avoid having to wait for The Other Team to have time, is very easily covered with really minimal training.

Sorry, but I can't really agree with that, certainly not for anyone below senior.

Asking juniors, who don't have much breadth of experience yet, to jump from front end to back end is a good way to end up with subtle SQL injection vulnerabilities, or passwords being hashed with non-cryptographic hashing algorithms, or secrets that should be handled at the environment level being hard-coded and committed.

Asking juniors to jump from back end to front end is a good way to end up with code that runs fine in Chrome but breaks in iOS Safari, or a subtle interaction between promises or awaits that deadlocks the whole UI if the server is unreachable, or styles that break when someone updates the theme six months later because two elements were the same blue at the time but the stand-in dev looked it up from the wrong place.

Either way, there's significantly more for them to learn if they need to know a whole new programming language as well as the specific libraries and the general principles about security and so on. And either way, The Other Team are probably going to be involved and therefore a potential bottleneck anyway, as surely at the very least someone senior from that team will be required to review code changes being requested by someone from outside the team who doesn't normally work in their part of the code.

And to parse the data arriving in a request from the front end.

And to validate the parsed value.

And to perform the necessary security checks. Wait, shouldn't they have been done already?

Where do we keep the validation logic in this design, anyway?

Hang on, what type is this field? Is there a native way to represent that in this back-end language, or some convention we've adopted? Did the parser already handle that?

It's never just adding a field to a structure.

Sometimes the field isn't part of the request. Or maybe part of the minimal training was wrapping ValueError in BadRequest. Or maybe part of the minimal training was we have an exception handler do it automatically.

Often there aren't any new security checks.

Sometimes field types are documented. Sometimes you have an integer in the database and need the same value as an integer in the front end.

Most of the issues you brought up don't go away if you use JavaScript everywhere. Learning a little of another language is comparatively simple.