I like that you were able to factor out constructor functions. Instead, types are just plain objects that inherit from other plain objects. I used that style myself once. The downside, however, is that after all the JavaScript browser optimizations that have been happening over the past few years, the native constructor function style got the lion's share of the optimizations, so this plain object style unfortunately won't run as fast. And since derived objects will likely permeate every aspect of an application, this turns out to make a significant difference.

3) If your library gets shared enough, then eventually someone will try to use it in NodeJS or some other non-browser environment, where the "window" object doesn't exist. If you're not interacting with a browser DOM, then it's better to not reference window. The module pattern is usually better.

This pattern also comes with some extra perks. It plays nice with JavaScript module managers. Sometimes you want a library, such as MUI, to be scoped to only a defined module, or only to some other private scope. Declaring your library with just a simple "var" allows your library to exist in whatever scope the user wants it to exist in.

A couple other suggestions:

It would be nice if there was a defined place for object initialization. Normally that would be handled in a constructor. But since you don't have constructors anymore, you'll need to provide some kind of alternative.

The JavaScript community has largely settled on certain style guidelines, sometimes for readability, and sometimes for code safety. I'd recommend running your code through JSHint and consider it's suggestions.