

YUI3 and a Quiet Revolution - triptych
http://andrewwooldridge.com/blog/2010/03/27/yui3-and-a-quiet-revolution/
YUI3 is developing an 'apt-get' for extensions and web services.
======
moe
Can't see much revolution there.

So they now have a plugin-repository and allow you to directly reference those
scripts from your pages. That's great and all, except I don't _want_ to embed
external code that may change silently (or not so silently..) at any time.

Here's a tip: People flock to jQuery not because of some bells & whistles like
a plugin-repo, but rather because it makes one hell of a lot of sense at the
very core. It just feels right™ and allows for very short and elegant code.
YUI? Not so much.

YUI feels more like someone took the "Java" in _Java_ script way too
seriously.

~~~
rgrove
"So they now have a plugin-repository and allow you to directly reference
those scripts from your pages. That's great and all, except I don't want to
embed external code that may change silently (or not so silently..) at any
time."

YUI 3 gallery modules are hosted on Yahoo!'s CDN, and are versioned. Once a
particular version of a module is on the CDN at a particular location, it will
never ever change, and URLs pointing to it will always point at that exact
version.

"YUI feels more like someone took the "Java" in Javascript way too seriously."

This is a common criticism of YUI 2, but have you tried YUI 3? Carlos Bueno's
jQuery - YUI 3 Rosetta Stone is an excellent source for comparing common
jQuery syntax and idioms with YUI 3. If you haven't looked at YUI 3 before,
you may be surprised: <http://carlos.bueno.org/jq-yui.html>

~~~
moe
_Once a particular version of a module is on the CDN at a particular location,
it will never ever change, and URLs pointing to it will always point at that
exact version._

Well, I still don't see the revolution. Javascript hosting is not exactly
rocket science. So, okay, they have a shiny plugin store now. Great. Pig +
lipstick?

 _you may be surprised:<http://carlos.bueno.org/jq-yui.html> _

Thanks for that link, interesting comparison.

I'm sorry to say that I was not surprised, though. There is not a single
snippet where YUI is less verbose. In every non-trivial snippet YUI is more
verbose, often significantly so.

The difference may seem small in these trivial snippets but it hints at what
happens in real-world codebases: YUI complexity _does_ pile up exponentially,
not so with jQuery.

~~~
rgrove
_"Javascript hosting is not exactly rocket science. So, okay, they have a
shiny plugin store now. Great. Pig + lipstick?"_

The "revolution" is not that third-party modules are hosted on the Yahoo! CDN.
That's been the case for a while now. The cool part is that in YUI 3.1.0,
using third-party gallery modules is as easy as adding the module name to your
YUI.use() call:

    
    
      YUI().use('gallery-history-lite', function (Y) {
        // Boom, I'm using the History Lite gallery module.
      });
    

The real power here is not just that it's easy to use third-party modules,
it's that it's easy to use third-party modules in conjunction with official
modules, and YUI intelligently concatenates and loads them using combo-handled
requests for optimal performance. And you don't need to worry about any of it.

 _"There is not a single snippet where YUI is less verbose. In every non-
trivial snippet YUI is more verbose, often significantly so. The difference
may seem small in these trivial snippets but it hints at what happens in real-
world codebases: YUI complexity does pile up exponentially, not so with
jQuery."_

You seem to be asserting that verbosity === complexity. This is untrue.

Where YUI 3 really shines is in large applications with many loosely-coupled
components -- exactly the kinds of "real-world codebases" you mentioned. In
these environments, YUI 3's modular architecture, flexibility, and consistency
make it possible to keep your codebase maintainable while also ensuring
optimal performance by allowing you to easily tailor the components loaded for
a given page to suit the specific needs of that page, rather than having to
load huge monolithic chunks of code that will never be executed.

~~~
moe
_And you don't need to worry about any of it._

Well, call me a cynic but I'll believe it when I see it.

The concept is definitely neat tech-wise, but even if it works as advertised;
for me it's solving a non-issue. I wouldn't like to depend on the YUI servers
like that and I don't see how adding a <script>-tag to load a plugin is too
much work.

I can see this being a handy helper during testing ("let's check this one out,
quickly"). But revolutionary is too big a word for that...

 _You seem to be asserting that verbosity === complexity. This is untrue._

Well, we'll have to agree to disagree there. Different mindsets I suppose. YUI
clashes fundamentally with my all-time favorite programming quote:

    
    
        Good code should be like a miniskirt:
        long enough to cover the subject,
        short enough to maintain interest.
    

Shoehorning javascript (a prototype based language) into a class model might
have seemed like a good idea _before_ jQuery came around. But now jQuery
exists and I don't see why I should settle for less. Modularity and
consistency are strong in jQuery land, too. JS code doesn't have to look like
java to obtain these properties.

Now as this has turned into a framework rant (sorry) let me do YUI some
justice, too. As said, I don't see why _I_ should settle for less but I do see
at least one reason why others do. YUI does indeed have a strong (perhaps the
strongest) library of unobtrusive modules and widgets. I'm absolutely looking
forward to see whether they can sustain that edge. In my biased eye it seems
like jquery UI is catching up fast, but time will tell.

 _ensuring optimal performance by [...] rather than having to load huge
monolithic chunks of code that will never be executed._

That's wrong. Normally you _want_ that one monolithic chunk because it will be
fetched once and then be cached. You don't want each page to fetch various
bits of javascript for the same reasons why performance-obsessed sites combine
their images into a single sprite-file.

~~~
rgrove
_"Shoehorning javascript (a prototype based language) into a class model might
have seemed like a good idea before jQuery came around. But now jQuery exists
and I don't see why I should settle for less. Modularity and consistency are
strong in jQuery land, too. JS code doesn't have to look like java to obtain
these properties."_

YUI doesn't shoehorn JavaScript into a classical model. I'm curious why you
think it does. Is it just because the namespacing makes it _look_ like a
classical model at a glance?

 _"That's wrong. Normally you want that one monolithic chunk because it will
be fetched once and then be cached. You don't want each page to fetch various
bits of javascript for the same reasons why performance-obsessed sites combine
their images into a single sprite-file."_

There are very few absolutes in the web performance world. In some cases,
using a single monolithic JS file will be beneficial. In other cases, it will
not.

I speak from experience, having worked on Yahoo! Search for the last 3 years
(using YUI, no less) where we have a single page (the search results page)
which has millions of possible feature combinations that depend entirely on
the results for a specific query, and which can even vary for different users
searching for the same query. If we loaded a single monolithic JS file, it
would be many many megabytes huge, and even when cached, parsing and execution
would be painful. Worse: changing a single character in a single component
would require pushing a new version of the file and invalidating every cached
copy (and we push changes _very_ frequently).

~~~
moe
_YUI doesn't shoehorn JavaScript into a classical model. I'm curious why you
think it does. Is it just because the namespacing makes it look like a
classical model at a glance?_

Well, yes. Not only at a glance. You seem to call them modules and components,
but overall it's a plain old Class hierarchy.

Again, that's a completely valid way to use javascript - I just think the
jquery-way is the more natural route.

 _There are very few absolutes in the web performance world. In some cases,
using a single monolithic JS file will be beneficial. In other cases, it will
not._

Well, having the flexibility to dynamically load js-snippets is a good thing.
I'm just saying that 99,9% of sites don't need that and would even harm their
performance by implementing it that way.

 _where we have a single page (the search results page) which has millions of
possible feature combinations that depend entirely on the results for a
specific query, and which can even vary for different users searching for the
same query. [...] many megabytes_

As said, how many sites have that?

My most javascript-heavy site makes excessive use of jquery.ui, 65 jquery
plugins and ejscharts. The minified js-blob is 410kb + 100kb for ejscharts
(ironically: minified using yui compressor).

Yes, that's pretty damn heavy, but we see no performance issues at all and I
can only wonder what kind of javascript monster weighs in with multiple
megabytes?

------
skennedy
Not to mention YUI 3.1 is released this week, 3/30/2010. On top of some new
functionality, the development team is porting a lot of YUI2 widgets, fixing
memory bugs, and cleaning up some of the abstraction.

------
scorpioxy
I am patiently waiting for YUI3 to finally reach the feature level of YUI2.
I've used version 2 on a few projects and it was a pleasant experience all-in-
all.

The only downsides were it was too heavy and too verbose.

I often resort to JQuery when i need DOM manipulation because its nowhere near
as verbose as YUI2.

As for the too-heavy thing, it was a compromise because it provides one of the
richest widgets in all JS libs out there.(plus YUI3's module system is
supposed to help)

------
parasctr
Lots of people that have been using YUI2 will appreciate the new YUI3 modular
concept. While using YUI2 if you wanted to use a basic version of a YUI
widget/component you would have to include the all of that widget library. Now
that has that behavior has changed and most of the widgets/components/modules
have been divided in several smaller chunks that make sense. For example, YUI3
IO has io-base, io-xhr, io-form, io-queue etc. You could load any one of them
depending you needs. No need to load all of IO.

YUI3 has chaining similar the jquery (not as clean, I think) which makes is
less verbose and pleasant to write JS.

------
krosaen
YUI3 is much better than YUI2, and they learned a lot from jquery in making it
expressive / terse. I even spent the better part of a week learning about YUI3
thinking I might use it instead of jquery. But then I found, and it's hard to
explain exactly why, that I was much less productive with YUI3. I think that
jquery is just so damn intuitive to use, I usually can guess how something
will work. With YUI3 I was often left looking up something in the docs, or
looking for an example (which wasn't so bad given YUI's excellent docs, but
still, it's a hit when you can't just guess how something is going to work)

------
mcav
YUI 3 has a very cool module system. I'm really looking forward to when jQuery
provides $.require() so that it can do something similar.

------
mildweed
"Imagine for instance someone writes a little snippet of code that lets you
use jquery plugins in YUI3."

Is that even really feasible?

