Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YUI3 and a Quiet Revolution

andrewwooldridge.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: YUI3 and a Quiet Revolution

#11

Post by rgrove »

moe wrote: post #9
rgrove wrote: post #8

Earlier quoted context omitted.

"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 point…

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…

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

Re: YUI3 and a Quiet Revolution

#12

Post by moe »

rgrove wrote: post #11
moe wrote: post #9

Earlier quoted context omitted.

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…

"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) { //…

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

Re: YUI3 and a Quiet Revolution

#13

Post by 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)

Re: YUI3 and a Quiet Revolution

#14

Post by rgrove »

moe wrote: post #12
rgrove wrote: post #11

Earlier quoted context omitted.

"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) { //…

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 -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, quic…

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

Re: YUI3 and a Quiet Revolution

#15

Post by moe »

rgrove wrote: post #14
moe wrote: post #12

Earlier quoted context omitted.

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 -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, quic…

"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.…

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?

Post reply on HN