The other question is what feature in webcore are you requesting? There are folks that update for new features that gather support - changes have been made for weather changes, improvements in web functions, attribute subscriptions, time parsing, execution performance, resource reductions, etc.
So what change is being asked for?
I've been using webCoRE exclusively for 18 months and it has been rock solid the whole time. Profile - nh.schottfam - Hubitat has done an amazing job of streamlining and I find it far better in performance than it ever was on SmartThings. Rule Machine is just as capable when dealing with home automations but when it comes to more sophisticated tasks, especially with the use of expressions, webCoRE excels. Of course I am bias because I knew webCoRE and was always frustrated with the Rule Machine interface. Now that I have tested and confirmed that the webCoRE WEB UI can run local I am not too concerned what happens to it on the SmartThings platform. And finally in the 18 months of use I have not had any occasion where webCoRE was lacking in anything I've wanted to do. It is a well developed app that has it all. Oh, and one more benefit of webCoRE is you can choose to update it separately from the Hubitat platform. This is not to poo poo Hubitat but inveritably whenever there is a platform update there is usually some quirk or bug that presents discussion in the forums. Of the many, many platform updates I have only seen once where it interfered with webCoRE operation which was fixed within an hour or two, primarily because that update caused significant issues with other Hubitat applications. As Rule Machine becomes more mature I'm sure what I speak to here will be less and less of an issue.
I hope this helps you to decide on what is best for your situation.
Not sure if your reply was directed at me, but if so, I wasn't asking for any change. Was only asking as a noob about the pros/cons of WC and RM as it relates to Hubitat, before I go too far down one path. I've been using WC on ST without any issues (other than the poor documentation).
Thanks, it does, especially the reference to the maintainer of the Hubitat port, which led me to the 'webCoRE for Hubitat Updates' thread, something I clearly missed in my prior search. My comment about no updates to WC was based on looking at the repo at ady624/webCore, which hasn't had any commits in over a year. I didn't realize there was a separate repo for Hubitat, which seems to be very active.
After playing around with RM for a couple of days, I'm ready to tear my hair out. I'm sure it's quite capable, but the UI leaves something to be desired. Even though I can't directly enter code, WC's presentation looks enough like C++ or C# that I can immediately grasp the piston's structure without having to think about it
Wonder why Hubitat didn't adopt WC (or fork it) as its built-in rule engine.
Personally I have kept with webCoRE after a brief foray into RM.
The main reason was that I just imported my ST rules in and changed the devices and fine tuned them to work with HE.
TBH I don't think there is much difference between RM and WC in functionality, but I do find the WC UI much easier to use. (Probably as I've been using it since Ady introduced it).
You pays your money, you takes your choice............... 
Below is a brief history lesson. It seems that RM created originally for ST was the genesis for the creation of Hubitat and is Bruce's "baby".
Not mentioned is that WebCore filled the gap left in ST when RM was pulled.
Rule Machine was first on SmartThings and for certain reasons there was a fallout and the author along with others left SmartThings to create their own platform, Hubitat. webCoRE was born out of the Rule Machine vacuum left on SmartThings. I was using Rule Machine even after they left the platform because it was the only game in town. I got used to the UI and got pretty good at it but making changes was a real indever. Understand the Rule Machine UI is not the fault of the author but has everything to do with the constraints of Groovy language. webCoRE could never be what it is without the WEB interface. It is totally possible the Hubitat hub could host the webCoRE interface directly on Hubitat but it's been explained that is not likely to happen because of the added security issues running the http server. Maybe someday things will change but for now we have webCoRE that works and should continue to do do so even if they pull the plug on SmartThings, which IMO is inevitable. I think there will be a webCoRE like replacement but if Groovy is going away, so will webCoRE
They've never said anything about this publicly, but my guess is that they probably considered this once, at least as a supplement to RM. Long before I knew what Hubitat was going to be, I noticed references to something "hubitat" in webCoRE's source code (I can't remember where now...) and didn't think much of it other than wondering what it was. Further, when the platform was brand new to the public (January of 2018) and the similarity of Hubitat's development environment to that of SmartThings was a selling point for a lot of early adopters, staff bragged that it was so similar that someone in the "community" had managed to adapt webCoRE, probably the largest and most complex SmartApp out there. That being basically day one, someone clearly had a leg up--but whether it's because staff was working with the idea or Ady himself was just one of their alpha or beta testers (presumably before going to work full time for ST, which may have also affected the trajectory of this story)--or if it was another intrepid tester entirely--we don't know. All just guesses based on what we can observe...
Further, staff seem quite familiar with how webCoRE works, and that's actually one of the things they've commented on and probably a reason they aren't interested in supporting it: they consider it inefficient in that pistons get stored as JSON and then interpreted via the webCoRE piston app (though with the latest Hubitat fork updates, many people find it to perform well; writing a Groovy app directly would certainly be a more difficult task, even if more efficient).
Rule Machine itself has changed quite a bit on Hubitat. The Rule 4.0 UI we see today allows the creation of automations that more or less is what you could do on webCoRE: an ordered script, actions to perform, possibly conditionally. I know it's hard to remember now, but older versions of Rule Machine just let you choose actions and ran them in a pre-determined order, usually based on the truth value of a "rule," which was then actually a specific concept in RM (a specific combination of conditions evaluated for truth), though other types of rules like "Triggers" (basically what we've got now with more power behind them) also existed.
Oh, and don't forget that CoRE predated webCoRE--and personally, I find the "web" thing to have helped a lot. I could not wrap my head around CoRE. 
Part of the limitations of both RM and CoRE have to do with the UI model that that they're using (more or less the same) and that RM in particular is pushing the boundaries of. Some day, we might get something more flexible here that would allow better UI's--they have conceded that webCoRE's UI would indeed generally be considered better.
Not necessarily: all that needs to happen is that webCoRE would need to adapt to the ST changes. In a recent-ish developer video, they actually very specifically mentioned that webCoRE (the editor portion) could be just a front end that uses ST's new Rules API behind the scenes--so instead of interacting with your ST hub/account via classic Groovy SmartApps (creating pistons that get interpreted by webCoRE on your account), it uses ST's new Rules API instead (creating Rules for you, something new in the "new" ST model). ST even toyed that Rules might be able to run locally some day. How far along the development of this API is, I don't know...and I think it's safe to assume the second thing is still years off if it even happens. 
That's kind of what I was imagining with WC being the default rules system for HE. The front end would just generate whatever back end output is optimal for the given platform.
Far as pistons being stored as json, perhaps that's been retained so pistons can be copied from one platform to another. They don't necessarily need to be interpreted by the piston app though; maybe they could be precompiled to platform-native code at the time the piston is saved. Or perhaps they are on HE, and that's why they execute faster than on ST. But modern code interpreters (or jit compilers) aren't necessarily inefficient either.
I personally think in a manner closer to WC then to RM. Because of this, WC makes more sense and its easier for me to write automations.
I used RM when it was on ST, and I found it easier to use / more intuitive at that time, but it has obfuscated the traditional if/then/else to triggers and actions as it has gotten more "mature".
Technically it's not a constraint of the Groovy language, but instead a constraint of the app UI APIs provided by the platform (which happen to be in the Groovy language).
The UI is HTML/javascript, which is served up by Jetty, an embedded web server that runs on Java. Your browser is doing all the heavy lifting as far as rendering the UI and executing javascript libraries such as jquery and datatables.
Whether the HE hardware has sufficient power to generate the HTML and handle the ajax calls required for an interface like WC is probably the issue, if it's even an issue at all. Much of the WC UI is probably static HTML, and the dynamic part can't be all that compute-intensive to generate. For that matter, you could just pass a json representation of the piston to the browser and have the UI generated via javascript.
Yes, but app UIs in Hubitat are generated by methods provided by Hubitat's app UI framework. These are pretty limited, being inspired by the same methods on SmartThings that were basically intended to allow inputs for SmartApp UIs in the SmartThings mobile app. You could not get something like WebCoRE directly from that. For people's best attempts, see things like the original CoRE (not WebCoRE)--or really RM on Hubitat, too.
You could serve arbitrary HTML (not just HTML; a full web page) from an OAuth endpoint. I do wonder if anyone has ever tried something like that for user input in a Hubitat app...
But in the meantime, if you prefer WebCoRE, it's still pretty easy to set up, especially if you use their cloud Dashboard. Even if that goes away, you can host it locally (or not) yourself...just not directly on the hub as it currently stands.
Not sure what UI framework you're referring to. The only evidence of any framework is HE's use of material design lite, but that's all client side css and js.
In any case, the underlying support on HE that WC needs must already be present or it wouldn't work. Whether the onboard web server has the power to serve up the same HTML that dashboard.webcore.co does, who knows.
Maybe they're just not interested, given that we have WC and a few others if we don't like the built-in solution. The RE UI is easier to maintain given its relative simplicity compared to WC, and is probably good enough for a lot of users.
I'm not complaining, BTW. Copied over my first (and most complex) piston from ST to HE. It works just fine and I have EchoSpeaks back. Life is good.
The one by which app (and to a lesser extent driver--there aren't as many options there) UIs on Hubitat are created. This would be for the built-in and user apps you actually use--not what the platform itself uses throughout for the actual output it gives to the browser (though this of course eventually feeds into that).
It's substantially similar to that of SmartThings, which is better documented, so I'll point you there if you're not familiar: https://docs.smartthings.com/en/latest/smartapp-developers-guide/preferences-and-settings.html
Ah, ok. But that's the documentation for the ST smart apps UI. That would be used by the WC UI that runs within the ST mobile app, used for configuration. That's not used for creating pistons.
The WC dashboard itself isn't a smart app, right? Or does it somehow use the same API?
Correct...but if you're writing a Hubitat app, custom or built-in, you are subject to the same UI. Perhaps you mean that staff could do something, outside of this UI framework, to host the webCoRE Dasbhoard locally. That is certainly true! (But it would require Hubitat staff do add something.) I wouldn't count on that happening. However, staff have indicated that they're not opposed to revamping the app UI framework--they're well aware of its limitations. I wouldn't count on that happening soon, either, but you never know. 
This is why I am a huge fan of the Maker API. Sooo much potential.
As a programmer I really loved WebCoRE in ST. I ran my own WC server and the UI + debugging was really cool. After migrating to RM due to early WC HE performance issues I was disappointed at first but that was mostly because I did not really understand the process. After a while things clicked and I realized how powerful it could be. When HE introduced the lighter weight apps that was even better. Now my "rules" were a lot less resource intensive.
I have since moved on even from there (I use Node-RED) but I do appreciate the power and flexibility of RM and its siblings.
Some in this community are also coding their rules directly into groovy apps. This is probably the most optimal way of creating fast/reliable and lower resource usage rules if you are into it.
Are you talking about an app which runs within the HE UI? If so, sure, I can understand that the UI implemented by apps running in the HE UI would be constrained by whatever environment the HE UI provides.
Running the WC UI in that environment would probably be a challenge, unless you ran it inside an iframe. I wasn't really thinking about WC running within the HE UI, although if it was a built-in app I suppose it would have to, and that would probably entail a fair amount of work.
In any case, I like the fact that we have choices here, and those choices actually work. I feel like ST is like living in a building that's being torn down around you while you're still living in it.
I imagine for that to be useful you would have to have some understanding of the internals of WC. Other than a better debugging experience, is there any other benefit to hosting the WC UI locally?
I want my automations to work independently of having internet access, but creating or editing pistons is not something I personally need to have available 24/7.
UI issues aside, do you find RM to be more powerful than WC as far as capabilities go? I haven't found that anything I wanted to do so far was beyond what WC can do.
Download the Hubitat app
