VMware Cloud Community
Tocano
Enthusiast
Enthusiast
Jump to solution

Why Javascript?

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.

1 Solution

Accepted Solutions
cdecanini_
VMware Employee
VMware Employee
Jump to solution

The first reason is as you mentioned architectural since vRO is build using Java. The vRO plug-ins are Java plug-ins. These plug-ins expose a JavaScript scripting API (objects and methods) using the Rhino Engine.

You can use the PowerShell plug-in but then this require running the scripts on a Powershell host, leading to a less integrated, less reliable solution.

The second reason this was a good choice is simplicity. I could teach Javascript to System engineers who never scripted easily - Perl / Python / Powershell are a lot more cryptic, difficult to read / understand (I used to be a Perl scripter before and it would take some efforts for me to get abck to my old scripts). vRO need very little of the language (just knowing the basic if/else, for statements, getting to object properties is already getting you a lot accomplished). Chances are likely a vRO workflow developer will interact with a third party web service using REST / JSON (JavaScript Object Notation).

Also it is not because Javascript is used predominantly for web front end language that it is not popular for back-end development. Javascript is the most popular scripting language and its use for back-end development is growing quickly.

A lot of the apps you may be using on your phone will likely have a node.js backend.

I have found out that the persons asking this question are the one who already invested a lot in the other languages you mentioned. But then if you are able to do one of the 3Ps scripting languages JavaScript is going to be very easy to learn if new to you and most of the time irrelevant since most of the workflows are about getting / setting properties on the object since a lot of the logic is in the workflow itself.

Christophe.

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter

View solution in original post

2 Replies
cdecanini_
VMware Employee
VMware Employee
Jump to solution

The first reason is as you mentioned architectural since vRO is build using Java. The vRO plug-ins are Java plug-ins. These plug-ins expose a JavaScript scripting API (objects and methods) using the Rhino Engine.

You can use the PowerShell plug-in but then this require running the scripts on a Powershell host, leading to a less integrated, less reliable solution.

The second reason this was a good choice is simplicity. I could teach Javascript to System engineers who never scripted easily - Perl / Python / Powershell are a lot more cryptic, difficult to read / understand (I used to be a Perl scripter before and it would take some efforts for me to get abck to my old scripts). vRO need very little of the language (just knowing the basic if/else, for statements, getting to object properties is already getting you a lot accomplished). Chances are likely a vRO workflow developer will interact with a third party web service using REST / JSON (JavaScript Object Notation).

Also it is not because Javascript is used predominantly for web front end language that it is not popular for back-end development. Javascript is the most popular scripting language and its use for back-end development is growing quickly.

A lot of the apps you may be using on your phone will likely have a node.js backend.

I have found out that the persons asking this question are the one who already invested a lot in the other languages you mentioned. But then if you are able to do one of the 3Ps scripting languages JavaScript is going to be very easy to learn if new to you and most of the time irrelevant since most of the workflows are about getting / setting properties on the object since a lot of the logic is in the workflow itself.

Christophe.

If my answer resolved or helped you, please mark it as Correct or Helpful to award points. Thank you! Visit http://www.vcoteam.info & http://blogs.vmware.com/orchestrator for vCenter Orchestrator tips and tutorials - @vCOTeam on Twitter
Tocano
Enthusiast
Enthusiast
Jump to solution

Thanks for the insight. Though I don't get what being written in Java has to do with anything. Java and Javascript have little in common beyond their name.

You're right that this question was spawned due to the investment our group has made in trying to focus our systems to just a handful of languages. Yes the JS syntax is fairly easy to get into - though trying to bounce back and forth between Python, Powershell, etc and now Javascript, just keeping simple things like the proper concatenation syntax seems to require a lookup again.

The biggest challenge so far has been largely with object introspection. Powershell, Python, PHP are dead simple to see what properties and methods an object has and their types. Javascript always seems to make it a battle. I seem to have to write some complicated loop to see what property pairs exist and methods are even more difficult. Deeply nested objects? That may take me 20-30 minutes of running, selecting sub-object, re-running, and repeat, just to find the specific piece of data I'm looking for.

Oh well, I guess I'm just ranting whining now. I do appreciate the explanation. Thank you.

Reply
0 Kudos