With the availability of small JavaScript engines such as Moddable's XS it would make sense to allow the use of JavaSciprt as an app language. Even better if there were a TypeScript definition library
Of course full Node would be nice but that might be a bit much for the platform.
Hubitat isn't a Development Platform.
Not sure what you mean by "not a development platform".
I'm just suggesting JavaScript as well-supported alternative to Groovy.
Bruce has said:
"it is not our business objective to create and support a developer platform. Our primary business objective is to create a home automation platform upon which people can create the automations to elevate their homes."
In other words, Hubitat is focusing their time and effort on improving Home Automation, not on fulfilling developer's language preferences.
Supporting JavaScript would go a long way to making Hubitat a useful production and delivery platform for home control. I'm not sure the source of your strong reaction.
It already is... I'm not sure how adding the ability to write automations in Javascript would impact that in any way.
Why not just put node on a Pi and use the maker API to do exactly what you want? You can do that right now.
I'm completely positive the list of "useful production and delivery platform" improvements is 6-8 years long. 
I want better UI, RM, New User wizards, on and on, over yet another language option.
I'm puzzled by the negativity to the idea of providing a better-supported alternative to Groovy.
Agreed! Though I hope Maker API could get a little love, too.
Probably because it is viewed as "nice", but not "needed". And there are many "needed" enhancements that would not get done if they work on your "nice" request. Developer resources are limited/finite.
I don't think anyone is against options, per se, except that they use resources we want to be used for other things. 
I don't think there is any negativity but rather that the HE system is built with Groovy. Adding another compiler, layer to support another language could cause negative performance and more difficulty in troubleshooting.
No negativity here. Groovy was chosen as it's an easy path to port from SmartThings. Nothing wrong with alternatives, but as the core language of choice, I believe most of us would strongly prefer greater device support along with a focus on fit and finish before other languages are added.
If the maker API is too limited, create an oAuth endpoint and send the events to your NodeJS box. You can do anything you want to do that way, and you don't have to wait for the devs to get around to adding that support.
I'm trying to understand the hostile reaction. Increasing developer effectiveness is important. I've been limited by the need to master yet another language, Groovy, that lacks tools and support.
JavaScript can increase the size of the community and the ability to add capabilities.
I just want pizza. Can Hubitat provide?
I think you can do that with Dominos IFTTT channel 
I should add that I'm thinking more in terms of TypeScript with intellisense than simply JavaScript. My goal is to make it simple to do simple things. That creates an incentive to learn more to do more.
I'm not looking to automate as much as to be in control. Much of the mechanism inherited from Smartthings is based on the idea that their engine is necessary and valuable. I did write Groovy code to work around it.
The maker API is a good example of doing simple things simply. Having similar capabilities running on the Hubitat with the added ability to respond to events would be very powerful. Even more so if I could use tools like Visual Studio to get leverage and save debugging time.
I hear you, but you have to accept that from a development sense Hubitat likely WANTS the system to be closed - that's why they won't give us the SSH password 
. If they start letting users run other things on it, support questions go up exponentially as they interfere with the core system.
Doing it on an external system via Maker API is fully supported, and can do it in a way that isn't potentially painful for them, or compromise the core function of the hub.
Again I don't think anyone is being hostile but rather just accept the environment that is being presented to the community. Groovy is actually a pretty good language which gets its language similarities based off JavaScript. BUT, that is truly where it ends. If you research other home automation systems you will see none of them use JavaScript or Java. Honestly probably because how easy it is for many "developers" to write very bad code. Java/JavaScript sorta just lets it happen and can bring operations and reliability to its knees.
Some examples from leading home automation systems that are thriving:
So it is what it is. Most of your knowledge about JS will naturally work in Groovy. Where Groovy falls short is what has not been exposed by HE. Web Sockets just became available to the community. Telnet just became available. So you just have to take what you can get and make requests for advancements in Groovy that makes sense. One advancement that has not been implemented is the ability to make remote class object calls to community groovy code hosted outside of HE. But eventually as the HE team continues to meet their goals in delivering the best on-premises, local execution and most reliable smart home automation solution they bring new features to the environment. Some are apps. Some are app advancements (Global variables in Rule Machine [YES!!!!]). Some are development environment advancements. If you have a need ask the support team publicly and privately...BUT keep it positive and explain what you would like to do that you can't do today. They are very responsive and if the addition makes sense and supports the community then most of the time they divert efforts and invest in community recommendations.
Overall....embrace Groovy if you wish to use HE. But also contribute where you can.
We're coming at this from different perspectives. I've been writing my own home
control software for a few decades and see Hubitat as providing leverage in a larger context and not as a self-contained platform.
On SmartThings I did use Groovy to implement something akin to a MakerAPI (with notification). JavaScript would make it easier to tap into the larger world of tools and to contribute to the Hubitat community. (Even more so with TypeScript definitions).
Download the Hubitat app
