Comparing Pyscript to AppDaemon

Overall the goals of pyscript and AppDaemon are similar - allowing users to implement powerful Python-based automation, triggers, logic and actions with much less scaffolding, overhead and expertise than HASS internals or Python Scripts require, and with a lot more flexibility and richness than the builtin yaml automations, triggers and templates.

Broadly, pyscript has a higher-level of abstraction than AppDaemon and it is more tightly coupled to HASS, meaning it has less details the user has to code or worry about. There will be many cases where pyscript and AppDaemon are relatively similar in terms of user implementation complexity. There will be cases where pyscript is simpler and easier. There will be cases where AppDaemon can do things that pyscript cannot (at least not yet). Please tell me about those latter cases since I'm happy to implement new features.

Here are a few more specific differences:

• Pyscript allows state triggers to be full Python expressions involving multiple state variables; AppDaemon allows callbacks to be attached to each state change event, so it can implement a trigger expression involving multiple variables, but it requires a couple more steps - attach a callback to each state variable and put the trigger logic inside the callback.
• An automation with multiple steps (eg, do something, wait a while for something to happen, then do something else) can usually be implemented as a single function in pyscript, which can sleep or wait for new triggers in the middle of any Python code without needing to split things up using callbacks. In AppDaemon, each step typically will need a callback to wait for some time or another event like a state change. (AppDaemon also allows yaml sequences to execute several automation steps, but generally they don't include conditional logic.) It's usually more difficult to split up logic across multiple callbacks, especially when some callbacks can involve two outcomes (eg: handle either outcome of waiting for a state change within a timeout) versus just an if statement based on the return value of task.wait_until().
• Pyscript allows HASS state variables to be directly used as Python variables, versus the helper functions in AppDaemon. Pyscript provides helper functions too in case you need to set attributes or dynamically compute the state variable name.
• Pyscript is fully async based and runs inside HASS, without the user having to use await or even know what async is. AppDaemon supports threads and it supports async tasks too, although the AppDaemon documentation notes that the user needs more manual control and expertise to use async correctly.
• Pyscript has some richer time triggers, like cron.
• AppDaemon supports random duration time triggers, which I would consider for pyscript if there is interest.
• Pyscript interprets the Python code, which is how it hides almost all the scaffolding and complexity, but long pieces of user code will run slower because it's an interpreter (all imports are native, so they run at the same speed as real Python, so you can always put longer portions of your code in a package that you then import). AppDaemon uses native Python code, so it will run faster. Offsetting that is that pyscript runs inside HASS, but AppDaemon is a separate process, so all events and state changes have some IPC and context switch overheads.
• Pyscript's interpreter implements almost all of Python, but it doesn't (yet) support yield and generators. AppDaemon is native Python, so the whole language is available.
• Pyscript supports Jupyter frontends, which makes developing and testing code, functions, triggers and automations fully interactive, which greatly accelerates development and debugging time.
• AppDaemon has some clever testing features like accelerated time to debug your time trigger logic. Using Jupyter you can interactively test your pyscript code.
• AppDaemon has a lot of other interesting features, including an admin dashboard showing detailed status, direct access to MQTT, plugins and more.