Response to John Resig’s comments about YUI(nczonline.net)
nczonline.net
Response to John Resig’s comments about YUI
http://www.nczonline.net/blog/2010/11/03/response-to-john-resigs-comments-about-yui/
3 comments
jQuery is great for smaller sites and it’s easy for anyone to pick and use, which is why there is such a strong designer community...but I wouldn’t want to use it to create the Yahoo! homepage. For scalable web applications, YUI really excels.
I'm curious: what about YUI lends itself to scalability?
I'm curious: what about YUI lends itself to scalability?
I came here to post that too. The only thing I can think that means is that it is laid out better for large teams to program on without stepping on each other's toes. Sort of like a Java argument against dynamic languages - those cool scripting languages are fun and productive for an individual, but large teams would just screw each other up with that.
There really isn't "scalability" in client-side JavaScript. Scalability is usually thought of as the ability to serve many users at once (as opposed to speed which is how fast you serve one person). So, sure Ruby is slower than Python, but it doesn't matter too much since you can have 4 web servers and a load balancer rather than 2 web servers and a load balancer and you're fine.
However, client-side JavaScript isn't serving multiple users at once. It's trying to serve one user as fast as possible.
Maybe someone has a better explanation? It's early and I haven't had my coffee.
EDIT: It seems like YUI might allow you to pull independent pieces by calling YUI.use(some-cool-piece-of-functionality). That could reduce download times, but it could also increase HTTP requests and the associated overhead. That's pretty cool. If 90% of your users aren't going to be using a piece of functionality, it doesn't load that code, but can load it dynamically if needed. While cool, I don't think I'd call this more scalable - this is about speed. And I don't know if it would be faster in a meaningful way since JS can be nicely cached. I shouldn't have said that - in the absence of evidence from testing, I shouldn't make assumptions. Maybe someone else can shed some light on how well this works in the real world.
There really isn't "scalability" in client-side JavaScript. Scalability is usually thought of as the ability to serve many users at once (as opposed to speed which is how fast you serve one person). So, sure Ruby is slower than Python, but it doesn't matter too much since you can have 4 web servers and a load balancer rather than 2 web servers and a load balancer and you're fine.
However, client-side JavaScript isn't serving multiple users at once. It's trying to serve one user as fast as possible.
Maybe someone has a better explanation? It's early and I haven't had my coffee.
EDIT: It seems like YUI might allow you to pull independent pieces by calling YUI.use(some-cool-piece-of-functionality). That could reduce download times, but it could also increase HTTP requests and the associated overhead. That's pretty cool. If 90% of your users aren't going to be using a piece of functionality, it doesn't load that code, but can load it dynamically if needed. While cool, I don't think I'd call this more scalable - this is about speed. And I don't know if it would be faster in a meaningful way since JS can be nicely cached. I shouldn't have said that - in the absence of evidence from testing, I shouldn't make assumptions. Maybe someone else can shed some light on how well this works in the real world.
I took that to mean scalability in the sense of UI complexity. Building something like some of the denser Yahoo pages in jQuery would be painful.
However, most of the YUI-based stuff I've seen struck me as overly complex and slow and heavyweight, like Ext/JS. If you want to build something that looks and feels like a desktop app those libraries are probably the right choice but I almost always prefer something lighter and cleaner in a web UI.
However, most of the YUI-based stuff I've seen struck me as overly complex and slow and heavyweight, like Ext/JS. If you want to build something that looks and feels like a desktop app those libraries are probably the right choice but I almost always prefer something lighter and cleaner in a web UI.
That's exactly my experience as well. I recently worked on two "enterprise rich web apps"(I hate that term) that were desktop-like.
App A: the UI was mostly composed of HTML glued together with JQuery components, with a custom Model/Controller implementation (similar to Backbone.js) for the data. The view did have a lot of glue, but the data separation ended up a lot cleaner, and was easier for designers to maintain (HTML/CSS).
App B: Was taken over from another team that used ExtJS. App B, had full UI without much effort, but ended up with a lot more cruft and direct view/model dependencies.
Plus the ExtJS documentation is terrible.
App A: the UI was mostly composed of HTML glued together with JQuery components, with a custom Model/Controller implementation (similar to Backbone.js) for the data. The view did have a lot of glue, but the data separation ended up a lot cleaner, and was easier for designers to maintain (HTML/CSS).
App B: Was taken over from another team that used ExtJS. App B, had full UI without much effort, but ended up with a lot more cruft and direct view/model dependencies.
Plus the ExtJS documentation is terrible.
I'm more interested in the opposite side: why can't jQuery scale? If it was served via Google and Yahoo CDNs the way that YUI is, what's the issue?
I don't think scale in that sense is applicable here, though my first reaction was the same "Why does statically front end code have any issue on scaling?"
I think it's more in terms of if your goal is to make a large JavaScript component suite, what core framework would keep you in clean and functional code through the lifecycle.
I think it's more in terms of if your goal is to make a large JavaScript component suite, what core framework would keep you in clean and functional code through the lifecycle.
I evalutated JavaScript libraries for my current employer and obviously had jQuery and YUI as two of first on the list before I even did any real research.
For me, YUI ended up being too much like a solution architected and run by people coming "down" to JavaScript from more high level languages, whereas jQuery still works like a framework built by people who use JavaScript a lot and wanted a way to make their lives easier (though granted the jQ UI stuff is a bit off the mark). Immediately even the way the YUI documentation hub is written and managed put some of our more designery-developers off and once they felt intimidated by that then their next reaction is to come up with reasons why they don't want to use it, or other developers end up wasting time supporting them.
I thought YUI would make a more suitable choice for us in terms of the approach the YUI team expect YUI code to be architected and written, but if the entire team can't get behind it then rather go with something less architected and at least have everyone on board from the start.
jQuery is popular because it gave a solution to "I was always told to avoid JavaScript but now everyone is using it, how do I get into it easily?". YUI solves the slightly different issue of "I want to base my entire codebase off a well architected JavaScript core that I can extend in a way that my OOP front end engineers will feel at home with".
Sabre wrattling not required.
For me, YUI ended up being too much like a solution architected and run by people coming "down" to JavaScript from more high level languages, whereas jQuery still works like a framework built by people who use JavaScript a lot and wanted a way to make their lives easier (though granted the jQ UI stuff is a bit off the mark). Immediately even the way the YUI documentation hub is written and managed put some of our more designery-developers off and once they felt intimidated by that then their next reaction is to come up with reasons why they don't want to use it, or other developers end up wasting time supporting them.
I thought YUI would make a more suitable choice for us in terms of the approach the YUI team expect YUI code to be architected and written, but if the entire team can't get behind it then rather go with something less architected and at least have everyone on board from the start.
jQuery is popular because it gave a solution to "I was always told to avoid JavaScript but now everyone is using it, how do I get into it easily?". YUI solves the slightly different issue of "I want to base my entire codebase off a well architected JavaScript core that I can extend in a way that my OOP front end engineers will feel at home with".
Sabre wrattling not required.
To me, YUI smells like a big bloated "Enterprise software" while JQuery is small and "Made by hackers".
I have used them both and when I run into bugs, the ones in YUI are still open and waiting for the time until their "paid" developer has time to fix it..
I have used them both and when I run into bugs, the ones in YUI are still open and waiting for the time until their "paid" developer has time to fix it..
I seen little YUI3 but as I seen it's kind of shifted into a more functional style than YUI2.