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?
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:
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.