I agree that YUI can be seen like this, with its relatively deep object relationships and manipulations required for its mvc, widgets, etc. -- but does not have to be used as such. I've been using YUI the last couple of years in a lighter way. My code uses as much modern JS as practical, and dips in to YUI for things that are tedious to do by hand. Most of my modules can be swapped out to work with requirejs, jquery, underscore, handlebars, etc. without too much fuss. I've done that a few times when YUI was slowing down and showing signs of neglect, but then went back to YUI because I saw no noticeable signs of improvement, but rather found the code more difficult to maintain -- multiple dependencies vs. 1, and each of those libraries has a multiplicative effect (different documentation locations and styles, following the updates, engaging the community, finding workarounds, etc.) For a long time YUI had great docs, great participation from core devs, and a nurturing attitude towards 3rd party modules. It is when that love began to fade, without explanation -- the promises of improvements in the future began to gather cobwebs, and the community infrastructure began to crumble (forum, gallery, web site), yui dev participation plummeted -- that I and I'm sure many other YUI users began to disengage with the YUI project, even if we were still using it.

What I mean is that YUI is a large, monolithic framework, which can be replaced with a number of smaller libraries/frameworks. This is modularization, which reduces the risk of a large monolithic framework losing maintenance support.