Response to John Resig’s comments about YUI
nczonline.net
nczonline.net
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.
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'm curious: what about YUI lends itself to scalability?
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.
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.
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 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 seen little YUI3 but as I seen it's kind of shifted into a more functional style than YUI2.