For managing AJAX requests.
For managing element attributes.
For managing good-looking, high-functioning alerts and notifications.
For monitoring and responding to a user’s scroll position.
For better handling of forms and their data.
For correlating URLs and element states on a single-page site.
Miscellaneous utility functions.
I think frameworks are a poor investment for all the usual reasons: the skills required to effectively use a framework are typically framework-specific and therefore non-transferable, and they are subject to obsolescence by the framework’s developers; frameworks are projects that will likely change must faster than the language they’re written in and, as some wise man once said, only a fool would build a house on sand; they create bloat (every function a user downloads that is not used is bloat); they encourage dependence rather than self-reliance; etc. For many reasons, libraries are a better investment, a better development pattern, and tend to result in a better experience both for the user and for the developer.
So I was sort of upset when the libraries I was writing started relying on other libraries I had written. A great library should be self-contained, self-reliant, limited to one problem set, and easy to replace. But that self-containment can quickly result in repetition, which is A Bad Thing. So, rather than include a copy of a utility function in each library that needed it, I removed them all to utils.js.
It’s easy to see how a set of libraries can become a framework—what is a framework if not a collection of related, inter-dependent, and hopefully DRY libraries? But there’s a fundamental difference in the design philosophy: one is monolithic and maybe allows for modular components, the other is only modular components and you can use them however you want.