> Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.
Replace "C++" with "JavaScript/client-side processing" and "script" with "server-side scripting" and I feel like this adequately describes web-development.
Completely disagree. Server-side and client side are two completely different environments — different architecture, different security concerns, different user interfaces. Indeed, there's pretty much nothing shared.
Attempts to hide this have thus far all been leaky abstractions, and we're still in the research phase (e.g. Meteor). I'm not convinced that it will be possible to create a coherent web environment which abstracts the server-client boundary effectively.
Note that this doesn't preclude e.g. using Javascript as a server-side language. That's not related.
You also need to add the dark magic tribal dance of making CSS/HTML/JavaScript work in a coherent way across all target browsers in mobile, desktop, TV, settop boxes and whatever else...
At least that is how it feels for guys like myself that lack designer skills.
JavaScript only survived on client because we have to support legacy code across different platforms. There is no reason to pick same crappy language for server-side as well, unless you happen to be more familiar with it than modern languages.
Replace "C++" with "server-side processing" and "script" with "client-side scripting" and I feel like this adequately describes web-development.
FTFY
On a serious note:
I've recently started using Clojure on the backend and ClojureScript on the frontend and while its not quite 100% of the way there, its close and quite pleasant to work with.
Replace "C++" with "JavaScript/client-side processing" and "script" with "server-side scripting" and I feel like this adequately describes web-development.