No worries, just trying to present another option that may \give you what you want now.
I guess my point is that if you can do js, you can do groovy. 
The debugging tools if there were js on the hub wouldn't be any different/better than the groovy debugging tools on the hub. And if you do the coding externally, there are groovy add-ins for VSC among other editors for syntax checking anyway.
Regardless, I hope you find a solution that works for you!
I recognize that I need to work with Hubitat as is and am trying to find the highest leverage path.
I understand debugging with print statements. I did that a lot when I wrote my equivalent to the Maker API for SmartThings. Having Maker was key to my switching to Hubitat.
But .. hmm ... ah-ha .. pressing a button does generate a device event to the Maker API. At least a push does -- I don't seem to get a long hold message. But now I can indeed program my own responder.
Thanks for encouraging me to think more about this.
I still think better rule utilities would be useful but the path of least resistance is to listen for such messages.
I looked at Node Red and others and learning their worlds is much harder than writing my code from scratch using base APIs. I just need to revisit some design decisions I made 25 years ago.
Node-red is going to be 50x faster than what I read into your plans.
You can copy and share like cooking recipes. The export is JSON.
As long as you have an always on computer that can run NodeJS, you can have Node-Red turning on lights for you in under an hour. If you have an available Raspberry PI, there's an image built specifically for "us" to speed you to success very quickly.
If you want to pursue it, there's lots of help here.
Ah, I see what you mean now. Sure, every event in hubitat is exposed by maker api. If you want to write something external to interface with those events from maker api, and do stuff - of course you can. If it makes an event in the device details page of the device, it will get sent out via Maker API. If it logs something, but does not make an event (deduplication reasons, or other) it will not get sent out via maker api.
That's how the Home Assistant, Node-RED, and many other external integrations work.
I did and connected to my own app. Far simpler. Should've been my plan A.
You can use Javascript to listen to the eventsocket and push commands to the hub using MakerAPI so it seems to me there is massive flexibility here already if you don't want to get into Groovy. I'm doing this with my custom dashboard and it's frankly a piece of cake. Then you can code whatever logic you want in the Javascript if you like. I'm doing this in some cases but still find that the hub is the best place to put the logic/rules and when I'm finding performance issues then I use Node-RED (for motion lighting in particular). Node-RED is great but yeah does take a bit of effort to learn.
Better yet would be the ability to create a set of rules/scenes so I can apply devices to them with out having to copy or manually re-create multiple rules/scenes for each room. IE a rule template. Have the room with devices. Apply the template/profile to the room. If i make changes to a profile, NBD. It is absorbed by all that is attached to it.
As an example, in order to make a daylight scene/evening scene, and a couple dimmed scenes with an off control. I have to make 5 simple automation rules and 4 scenes per room. And every one of these rules/scenes are duplicated in every room. 8 rooms means 72 rules. It gets out of hand fast. And changing a value to one room and then updating the rest of the rooms becomes an all night task. Pretty annoying.
Clone your 1st rule then edit. Or use Node-RED 
Download the Hubitat app
