Option 1: do this for "end user" - that we're shooting for the use case where user follows the "the few shots" and gets his custom app to work, with properties:
code sharing is to provide more examples mostly, not as end artifact, millions of apps created & "published"
no "settings" in apps, apps are simpler and "just do the job"
to change the app, the user will continue this 'few shots' approach to change whatever setting he likes
Option 2: do this for "developer" - the 'few shot' approach helps the developer to create & package the app for "conventional usage scenarios", props:
installable packaged app is a final artifact of the flow
apps contain familiar interfaces, settings, menus, etc.
when developing app feature, this becomes "enhanced copilot"
I'm for option 1 - although this "end user" is probably still a developer enthusiast but personally for me it is exactly the fun I'm looking for, and it shoots directly into the vast space of unknowns of what the future interface would look like.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
I agree. So there are two options:
I'm for option 1 - although this "end user" is probably still a developer enthusiast but personally for me it is exactly the fun I'm looking for, and it shoots directly into the vast space of unknowns of what the future interface would look like.