[carsongross]

Of course it is!

The way I build web apps is to use intercooler.js (which is built on top of jQuery) for my AJAX and then jQuery, or jQuery-based plugins, for UI needs.

Works great. Yes, the jQuery API has some aspects that haven't aged all that well, but it's a pretty well thought out and through library that provides great tools that should have been baked into all browser environments since the start, and that has a rich ecosystem around it to boot.

The jQuery haters are usually folks who tried to write an SPA with it, which they say, correctly, is a terrible idea. But then, building an SPA is usually a terrible idea as well.

[commentzorro]

> But then, building an SPA is usually a terrible idea as well.

Would you care to elaborate on this? I'm interested in why.

[carsongross]

I was obviously being flippant, but a long story short is that going to a JSON-based, RPC-style SPA app gives up a lot of the advantages of the original RESTful web network architecture, not the least of which being simplicity.

Long-suffering HN readers can skip all of this (sorry guys) but I expand on this in the following blog posts:

http://intercoolerjs.org/2016/01/18/rescuing-rest.html

http://intercoolerjs.org/2016/02/17/api-churn-vs-security.ht...

http://intercoolerjs.org/2016/05/08/hatoeas-is-for-humans.ht...

[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.