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 Javascript way too seriously.
"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
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?
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.
"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.
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.
"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).
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?
I agree completely. My company's site was set up with yui2 before I came on board. Maintaining that old code and being forced to write new features with yui has not been a pleasant experience. I am transitioning the site to jquery as soon as possible. I've looked at yui3 over the last few months and while it's better than 2, it's still a mess to work with. There's also performance issues. Jquery is simply more capable and more efficient than yui3 according to recent benchmarks
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.
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)
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)
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.
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 Javascript way too seriously.