I guess most programmers, using myself as an N=1 statistic [an inferior
habit but often a necessarily one in decision taking path of single
humans], don't need all the in's and out's possible with xmlhttp that are
envisioned with full-blown Ajax-containing libraries, and just want
["need"??] some form of one-way or two-way communication between the
browser-page and the server, that would be just as possible with repeated
form-submission and reloading of that page, but for speed and/or
smoothness of the intended action.
Clientside programmed intelligence as offered by clientside Javascript
makes such on-page communication possible cross-browser-wise in
interaction with whatever one fancies as a serverside programming
language/engine.
In the contect of this NG, I would fancy serverside Javascript for the
NG's sake also also because some functions can be written for both
serverside and clientside in one go, for instance validation routines.
So why not build your own clean and lean code for the problem at hand?
And improve on your code only the next time you need the functionality?
There must be some joy of programming left even in the most desillusionned
of programmers.
=======
In general, this not needing all the in's and out's possible, is a prime
argument against general libraries in this multi-engine landscape of
cross-browser [not forgetting aberrant IE and the miriad of mobile
browsers] and each of these browser's cross-version "needs".
The patchwork necessary to allow for this landscape, and updates needed to
cover up the unforseable present needs and earlier sloppynesses, without
disabling user-programmer code that even made use of such earlier errors,
makes it advisably so important to steer free from al this general-library
nonsense.
The good usability of lean libraries in a single compiler environment,
where only the executable is distributed to the users, is quite another
matter, however residual sloppyness would be a danger here too.