I know there must be some rationale and reasoning behind the decision to choose Javascript as the language underpinning vRO. I'm sure there's some architectural tie-in that I'm overlooking that allows it to all make sense. However, I am struggling to see or find any explanations for this choice, which makes it feel somewhat arbitrary. Is it simply based on some popularity matrix? Is it because vRO's primary "partner" application is vRA - a web application? Is the assumption that the primary automation engineers of a virtualization environment are going to be web developers?! Is this just some remnant of some orchestration software VMware acquired a decade ago?
Of all the languages that could have been used for this, Javascript is one of the last, in the back of the bus with languages like ColdFusion and PHP, that I would have considered. This is not because Javascript is not popular or frequently used, but because it is predominantly (I realize not exclusively, but predominantly) a front-end/display language (i.e. the View in MVC), and far less a back-end/automation language. I could have understood Python or even Perl - languages used by both developers and sysadmins (usually for various automation and scripting tasks) alike. Java also would also have made sense due to 1) how much Java applications (Tomcat, etc) are used throughout the vR* suite and 2) the Orchestrator Client itself is written in Java. But coming from a sysadmin (who is Not-A-Developer(tm)) that has learned enough Python, Perl, bash, Powershell, etc to be able to automate many aspects of our environment, and that has to manage our vRA/vRO installation, Javascript seems like such an odd choice.
Again, I'm sure there's some architectural piece I'm not seeing that necessitates Javascript as the obvious choice. I just can't see or find any explanation for it.