Javascript Libraries

Here are some Javascript libraries I’ve written.

Http.js

For managing AJAX requests.

Clattr.js

For managing element attributes.

Alert.js

For managing good-looking, high-functioning alerts and notifications.

ScrollMonitor.js

For monitoring and responding to a user’s scroll position.

Informer.js

For better handling of forms and their data.

Monopage.js

For correlating URLs and element states on a single-page site.

Utils.js

Miscellaneous utility functions.

Notes

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.

And some problem sets are just more complex than others: http.js and clattr.js and simpler and smaller in scale than monopage.js, which requires the functionality contained in both.

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.

Also, I’m lazy, and I’m pretty stupid, so I’d rather stick with what’s worked for forty years than keep up with the framework of the week.