The price is that the PHP-only people won't be able to read the cross-language group's code effectively; but frankly I don't think they'd do much of that anyway

The price is that the PHP-only people won't be able to read the cross-language group's code effectively; but frankly I don't think they'd do much of that anyway. ...so why not just go ahead and make it impossibly difficult for the junior people to read your code? That should really encourage them to enjoy working with you. You are missing the forest for the trees. Let me outline the problems I foresee: You are going to create a huge political and management problem -- deliberately driving a palpable wedge down the middle of your team -- by implementing the "harder" parts of the app in a language that the PHP developers not only can't understand but aren't expected to understand, a language that they will have very little incentive to learn. (I know plenty of PHP devs who are curious about Rails or Django; I've met plenty who use PHP frameworks; I've never heard the word HaXe pronounced. It is not worth having on one's resume.) Why not just force the PHP devs to wear little dunce caps when they're in the office? Perhaps you can have a ritual where you throw eggs at them at every morning meeting. Surely that will help your team to gel. Meanwhile, be very careful about referring to your non-standard compiled extension to PHP as a "high-productivity language". Eternal optimism is the occupational hazard of software engineers. I bet you'll find that any gain in expressive power will be more than offset by: Waiting for the compiler; remembering to run the compiler; writing makefiles that remember to run the compiler for you; fixing bugs in the compiler; adding missing features to the compiler; justifying the need for the compiler to the PHP devs; justifying the need for the compiler to your boss; explaining your architecture to every new engineer that comes on board; trying to guess which bug is in which portion of the code (is it the HaXe, the PHP, the compiler, the PHP runtime... or perhaps even the language that the compiler is implemented in?) so that you can assign an engineer from the appropriate language background to fix that bug; spending your own valuable time finding and fixing simple bugs that an intern could fix, except that the interns can't read your code... Meanwhile the rest of your colleagues will conclude that you're just some sort of language crank. All this grief, because you're unable to bring yourself to write code in a language without closures. Just build it all in PHP and try to enjoy your (perhaps temporary) journey into another culture. Or make the case to build it in Rails or Django and tell the PHP developers that they're going to enjoy their journey into another culture. ;) Or make the case that the architecture divides cleanly into two components, one that is best built in Django and the other built in PHP. (If you find that the inability to call PHP routines from Django, or vice versa, is a liability, it's a sign that the architecture doesn't actually divide cleanly and you've got to pick one platform or the other.) Or find a different job. (And forget this crazy notion of cross-compiling your code into JavaScript. YAGNI. It's like claiming that it's going to be easy to cross-compile your pickup truck into a Honda Accord -- after all, they're both made of steel and auto parts, and steel is malleable, and auto parts are interchangeable. And that isn't exactly false -- I have a fun book called Build Your Own Sports Car which literally tells you how to turn an old pickup truck into a Lotus Seven replica -- but it's only for hobbyists, and it's very inefficient because you have to optimize the process by hand, particularly when it comes time to fix bugs.)