[commentzorro]

All of these seem to imply discoverability and queries are the biggest pain point in web apps. For me, in creating specific purpose business apps, the biggest headaches are presenting the data in ways that minimize the user's unnecessary actions and, even more of a pain, wiring things up so an event in one location triggers the proper client display changes in another location.

For my use cases, discoverability and ad hoc queries just don't apply.

[carsongross]

Mmm, this is probably a long conversation, but I don't disagree with what you are saying. I think discoverability (in API terms) is different than the flexibility that HATEOAS, with a proper hypertext gives you.

The query issue just depends on how complex your data consumption needs are. The closer they get to levels requiring SQL-levels of expressivity, the more you will need to either churn your API or expose expressivity (and security risk) on the browser side.

In the old days, the way we dealt with changing the UI in another location was by simply replacing the whole page. This actually works pretty well, except for those FOUCs, and we are heading back that way, but now people are starting to do DOM diffs to avoid the blinky-blink. intercooler has a few options for solving it as well (either expanding your replacement target or using dependencies.) I imagine eventually I'll end up adding DOM-merging as an option as well.

Anyway, it's a long conversation.

[commentzorro]

> I imagine eventually I'll end up adding DOM-merging as an option as well.

This will be nice. I was playing with some of the examples on the site and noticed a number of them tended to "jump" a bit when the response was returned.