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).
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.
I don't have any special knowledge of the internals just followed some howto instructions online. The main reason I did this was the same reason I own a Hubitat - local control. I prefer my systems be as independent from cloud services as possible. The other nice thing is it is faster thanks to being on the local subnet.
I don't consider one more powerful than the other - just different strategies to accomplish the same thing. Since RM (and sibling apps) is HE's system of choice it will understandably be more efficient for most things. As a programmer I really liked the IDE/UI for WC though. To me it just seemed more logical.
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).
