My friend and I come at programming JS from different directions: he's primarily a Web designer who uses jQuery to enhance pages that can stand on their own, while I'm a Python/Zope developer who's currently using ExtJS as the framework for a full-blown web application. I did a lot of thinking before our first session about how to approach the undertaking—should I teach to a framework, since that would yield the most immediate benefits? If so, which? Would I be able to explain best practices without going laboriously over never-again-used fundamentals of programming? Would our sessions even be worthwhile, since hundreds of tutorials are freely available?
A designer may be perfectly happy with a long jQuery chain that would cause a developer spiritual distress; a developer may confront a simple problem with an elegant but unnecessarily complex solution that only serves to frustrate the designer. Being primarily a developer myself, I had to realign a bit, to overcome my instinct to make things as useful as possible, instead of merely as useful as necessary. At the same time, I felt it was important to present the basic programming mores that guide the more technically minded scripter—jQuery chains be damned.
Creating a simple library turned out to be a fantastic learning exercise: it requires investigation of namespaces, presents plenty of scoping problems to overcome, and requires attention to consistency, organization and sane API design. It's immediately useful, so no worries about the student getting bored. A library is infinitely extensible, but can also contain the most trivial low-level utilities. Every library has its own style, and lets its coders be clever.
Most importantly, the creation of a library invites, and even insists upon, reiteration of what I find to be the most helpful guideline to keep in one's head while writing code: Assume a third party will one day attempt to extend everything you produce.
Personally, I've found the experience quite valuable, for one crucial reason: I'm not a designer. The interfaces and APIs I'd normally create would probably be most useful to somebody like me. Watching the thought processes of somebody in the thick of it by day as they design an API they'd like to use is enormously instructive.
Now, we're using jQuery as the basis for this library, because even though cross-browser issues are still unfortunately relevant, let's face it: frameworks are here, they aren't going anywhere, and they solve the problem without much effort, so it's not a paramount concern. Nonetheless, whenever we run into a problem, we write a solution from scratch before we use a jQuery shortcut (for example, we wrote a scope-setting decorator function similar to jQuery.proxy rather than just using proxy). When we've found a need to use something more complex, like class-like inheritance, we've studied many variations and written our own, and finally settled on a style that feels like jQuery but adds substantial value (no small feat, as the concept of class inheritance is nearly diametrically opposed to the jQuery ethos).
Probably nobody but my tutee's band of designers will ever use this library. But it's a great propadaeutic compromise, for both of us. I have an opportunity to share the best practices I've managed to distill from the pored-over source of other frameworks, and I get the chance to see things from the designer's point of view, rather than focusing on that of the implementer (me) or end user (actual end user).