Closed kennedymwavu closed 1 month ago
Totally agree with your analysis.
I'd like to keep the flexibility and unopionated nature of ambiorix but making it easier for users to setup an application would certainly help.
@kennedymwavu do you have suggestions as to how to approach that? We should probably detail how we a plan to do that in the proposal.
There is a way to use htmltools tags in Ambiorix but it's probably not clear and the API could be improved.
I think users are also confused about "inputs" as done in shiny. I think your work with htmx could help tremendously here as it looks possible to design basic inputs as shiny features using htmx. I could imagine something akin to shiny modules: a UI and a server component.
What are your thoughts?
For a start, we can build a library that packages bootstrap components eg. accordions, buttons, cards, etc. The lib can also bundle commonly used inputs eg. text, email, password, checkbox etc. This is similar to what {bslib} does, but a lightweight version tied to neither shiny nor ambiorix.
Then the components can be used like so:
Card(
class = "p-2",
Form(
method = "post",
action = "/login",
EmailInput(
id = "email",
label = "Email"
),
PasswordInput(
id = "password",
label = "Password"
),
Button(
class = "btn-primary",
label = "Submit"
)
)
)
If that's successful we can then build another one for tailwind.
The only challenge I foresee is having to keep up with updates in those CSS frameworks.
You're right about inputs, yes we can use websockets + htmx to implement them and have them work like in shiny.
Also yes, this will certainly involve a UI + server architecture. Similar to what's in the index.R
file of ambiorix-htmx/websockets.
Regarding initial setup effort of a project, we would need to do more fine-tuning of ambiorix.generator, especially for frontend projects.
Several users have raised concerns about the time and effort required to start a project with Ambiorix, particularly asking if there could be a more streamlined way to get started and if pre-built components or UI elements could be provided.
After further discussion with John, we have agreed on the value of enabling quicker app design while retaining the framework's flexibility. Enhanced development ergonomics and speed, without imposing constraints on developers.
That said, we'll replace the book item in the proposal with a focus on tools & packages that facilitate rapid app design. This shift aligns with user feedback.