Naming of process.jsEngine

[orangemocha]

As raised in nodejs/node#4765 (comment)

Sorry to bikeshed, but I'm still not totally happy with the name of process.jsEngine. I'd rather have it be process.engine for simplicity and it's more neutral towards the es vs js naming debacle.

cc @silverwind @isiahmeadows

[benjamingr]

What is the es vs js naming debacle?

The implementation is JS, the spec is ES, do you really believe people would confuse it because it's JS?

[jasnell]

@orangemocha ... perhaps process.engine.js ? Doing so would allow for the possibility of other "engines" in the future without the ambiguity.

[silverwind]

What is the es vs js naming debacle?

I personally would prefer it to be called ES everywhere, but that's like never going to change. My point is if the ES name is ever going to get significant traction, we're better off with engine in the long run.

[kunalspathak]

I agree with @jasnell . process.engine.js is self-explanatory and gives room for other engines/frameworks.

[orangemocha]

I am not sure we need an engine object to make rooms for other types of engines. Making a name unambiguous doesn't necessarily require making room for all the other possible things that could be called "engines" in the same object 😄

I also doubt that process.engine.js satisfies @silverwind concerns, as it still mentions js.

Regarding that original concern, I am not sure if I agree that we need to be neutral between ES and JS. I would say that we can safely commit to calling the language JS everywhere, given that the name of the platform is Node.js.

As alternative, we could consider the term vm, which is already used for the vm module: https://nodejs.org/api/vm.html. I am not sure though if in that context vm is used to signify the entire engine, or the sandboxing functionality on top of it, in which case this could introduce confusion.

One more thing I would suggest is that we might want to leave room for additional properties of the engine, like capabilities, etc. So we might want to consider process.jsEngine.name / process.engine.name / process.vm.name.

[silverwind]

You're right, I wouldn't be happy about process.engine.js either. Not because of the .js, but because of the unnecessary complexity. Node.js has been following the concept of short and simple method names and I'm sure would not have liked to end up with a fs.GetFileInformationByHandleEx over fs.stat. Devs love short an memorable API names 😉.

[silverwind]

Looks like there is no general consensus for engine, so I guess jsEngine is fine.