"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?
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).