Well, as with everything:

Before using a library blindly 1. Ask yourself which problem you want to solve 2. Educate yourself 3. Does the library solve you problem 4. Use with caution 5. Learn from you mistakes :D

Those are great steps to follow for yourself and to reach new members of your team :)

I still hold that sparing use is important.

The overhead for steps before your controller action method can often be a significant portion of the overall response time.

It does seem somewhat dangerous to use on a collection. But for scenarios like a few parts of the page which depend on the logged-in-user, it seems pretty safe.

In a way that scales horizontally; run all of those web workers!

Browsers usually limit the number of requests to a certain domain (around 8 requests if I'm not mistaken, but it may vary). So I don't think it'd be the cause of a self inflicted DOS. Also, every solution must be used carefully where it makes sense, if it doesn't make sense, then a different solutions must be thought of.

True, though note that the limit is on active requests on the browser end (obviously). If your subrequests are "heavy" and the user refreshes a bunch, you're now going to have 6x (or 8x or whatever the limit is on their browser) the number of "zombie" requests still being processed on your server.

It takes the total cost to a server to render a page and multiplies it.

Under low load, it could make it faster for one user.

Under higher load, each initial page request will be more expensive and therefore will result in exhausted resources sooner.

Only over an HTTP/1 connection. Chrome and FF limit it to 6.

That's incorrect. Browsers limit request to 8 req/domain at the same time.

Don't know why I was downvoted. For reference: https://en.wikipedia.org/wiki/HTTP_persistent_connection#Use...

The limit applies only to persistent connections.