4 ms·

Does YUI3 have a similar resource footprint to YUI2? At my job we're transitioning away from YUI to jQuery UI partially because for what we're using–a slider a

Does YUI3 have a similar resource footprint to YUI2? At my job we're transitioning away from YUI to jQuery UI partially because for what we're using–a slider and a dialog–it takes an order of magnitude more included JavaScript (a few hundred KB minified)

grayrest 17y ago
YUI3 is MUCH smaller than YUI2. The rewrite was mostly about addressing this exact issue though everything-in-a-closure and pervasive query API were also major reasons. They basically took a fair number of the modules in YUI2 and sliced them up into very small functional bits (e.g. some of the modules are a ~80 LoC). This allows you to do fine grained loading of exactly what you need. Most apps I put together in yui3 are smaller than the jQuery equivalent because they're put together using only what they need out of the lib. There's a downside to this. The AlloyUI set of widgets was previewed this week which are built by a 3rd party but done using the same patterns core yui3 uses. The AlloyUI autocomplete widget does 58 HTTP requests pulling in modules. This is, of course, completely unacceptable for production. The way around it is a piece of server infrastructure called a combo loader. The combo loader takes a particular url crafted by the yui loader and glues all the requested modules+dependencies together in one request. By default yui will use the Yahoo CDN which can combo-load the core library plus whatever 3rd party extensions are in the yui-gallery. You can also pre-bake dependencies using a build script, but combo loading seems more pervasive. The other thing they did was change how the widgets work together. Now a widget just does what it says. As an example, the dialog will just display a div at a certain position. If you want functionality like being able to pull the contents in via XHR or animate the showing and hiding, you have to specifically include that and plug it in to activate that functionality on the widget. You might wind up with a couple hundred K still but you pulled that in yourself rather than having the library pull it in just in case you might want it. One thing they mentioned on their forum is that they might add support for pulling in dependencies on a per-browser basis so if you're on IE6 you get the extra shim code that isn't needed on, say Safari 4. Anyway, it's ongoing. The main drawback to the library is that the community is rather small compared to jQuery and YUI2.

grayrest 17y ago

YUI3 is MUCH smaller than YUI2. The rewrite was mostly about addressing this exact issue though everything-in-a-closure and pervasive query API were also major reasons. They basically took a fair number of the modules in YUI2 and sliced them up into very small functional bits (e.g. some of the modules are a ~80 LoC). This allows you to do fine grained loading of exactly what you need. Most apps I put together in yui3 are smaller than the jQuery equivalent because they're put together using only what they need out of the lib. There's a downside to this. The AlloyUI set of widgets was previewed this week which are built by a 3rd party but done using the same patterns core yui3 uses. The AlloyUI autocomplete widget does 58 HTTP requests pulling in modules. This is, of course, completely unacceptable for production. The way around it is a piece of server infrastructure called a combo loader. The combo loader takes a particular url crafted by the yui loader and glues all the requested modules+dependencies together in one request. By default yui will use the Yahoo CDN which can combo-load the core library plus whatever 3rd party extensions are in the yui-gallery. You can also pre-bake dependencies using a build script, but combo loading seems more pervasive. The other thing they did was change how the widgets work together. Now a widget just does what it says. As an example, the dialog will just display a div at a certain position. If you want functionality like being able to pull the contents in via XHR or animate the showing and hiding, you have to specifically include that and plug it in to activate that functionality on the widget. You might wind up with a couple hundred K still but you pulled that in yourself rather than having the library pull it in just in case you might want it. One thing they mentioned on their forum is that they might add support for pulling in dependencies on a per-browser basis so if you're on IE6 you get the extra shim code that isn't needed on, say Safari 4. Anyway, it's ongoing. The main drawback to the library is that the community is rather small compared to jQuery and YUI2.