Sure. Using things like loops and conditionals to stitch parts of the specification together is not a very declarative way to do things, imo. Regarding a better system I don't know, they all have their quirks, I guess. My point was that purely declarative approach has its limits and often times breaks when facing real world complexity.
This is the case with any other declarative programming system: while you only care about "what", i.e. the end result matching your declarative specification, you are living a dream. Once you need to fine-tune the details of how you get there (e.g. performance, resource use), or tweak the end result in a way that is not easy to describe within the constraints of your declarative dream land, things get ugly pretty quickly. Query hints in some SQL dialects, vendor-specific hacks in HTML/CSS, Kubernetes YAML templating, etc. are all sad stories about it.
Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?
Well, being able to identify potentially locally optimal solutions without having to go through an entire optimization process yourself is a pretty powerful heuristic in my book.
> I get back an empty string without runtime errors. If I get an empty string during dev in my UI, I know to go handle the case,
Well, in your example, with default params, you get back an "undefined undefined", not an empty string, so even simple code is sometimes easy to get wrong. Proper amount of typing actually helps a lot to avoid it.
This is so nicely formulated, thank you so much! I'm just thinking, isn't what you describe the general problem of agile methods/processes, and not Jira's, as it's just one of tools built to assist in agile implementation?