Response to John Resig’s comments about YUI
Earlier today, someone posted the following question on Quora: How could YUI improve its image compared to jQuery, MooTools, etc.? It’s an interesting question that got some interesting responses. The most interesting response, as many now have seen, came from jQuery creator John Resig. He wrote a very thoughtful piece that gives some great insights into how jQuery created such a large and vibrant community. However, there were a few points that are factually wrong and others on which I strenuously disagree.
Before diving into this topic, I want to be upfront: I work for Yahoo! and I’m a YUI contributor though not a core team member. Therefore, my opinion here does not represent the opinion of Yahoo! or YUI; this is simply my points of view on John’s feedback. I should also mention that I have a lot of respect for John, the jQuery core team, and the entire jQuery community, so please don’t take any of my comments to mean anything different.
First, I completely agree that the documentation fragmentation is a problem. More than one person has been confused about whether to go to the Yahoo! Developer Network or YUILibrary.com, that’s a definite problem that needs addressing. John also has a great suggestion on narrowing the focus of the YUI landing page to sell using the library over other messaging. Excellent idea.
John’s next section goes into ways that YUI can compete directly against jQuery. I’ve been saying for a while that I don’t see these two as competitors. Making YUI more like jQuery isn’t something I want in any way. Both libraries have their strengths and the overlap is minimal. 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 don’t believe you can serve both audiences effectively with the same product, and since jQuery does such a fantastic job at its focus, I would much rather have YUI focused on the web application problem.
My main disagreement with John’s post is around this statement:
The YUI project has always had the advantage of having a large number of paid, full-time, contributors to the project. As far as I can tell it’s always had more paid, full-time, contributors than any other JavaScript library. This is awesome and it’s benefited the library as a whole. However it can also be crippling. Yahoo completely controls the direction and destiny of YUI. This should not be the case – YUI should be split off from Yahoo and become its own, separate, Open Source project.
This is a sentiment I’ve heard from time to time while giving talks, and it’s something that I don’t understand and seriously disagree with. There seems to be a notion amongst the open source community that nothing can truly be “open source” unless it is purely autonomous and not tied to any particular company. This is a conversation I had with someone after one of my talks about YUI:
Him: You know, I really like YUI and want to use it, but it’s the “Y” in YUI that makes me uncomfortable.
Me: What makes you more uncomfortable, is it that there are people paid full time to develop and support it or that it’s been battle tested on some of the world’s most highly-trafficked web sites?
To me, what makes YUI valuable has been and will continue to be the affiliation with Yahoo!. It’s through the experience of working with teams within Yahoo! that the YUI library has grown into the rock-solid product that it is today. I say this having worked closely with the YUI team during the early days of YUI 3 as we used the new Yahoo! homepage as a testing ground. How many other libraries can say that they were testing on a top-5 web site? And how many can say that they are constantly getting feedback from some of the world’s most popular web destinations that handle millions upon millions of requests per day?
Removing YUI from Yahoo! cuts off the library’s main strategic advantage. When working on top-secret projects, it’s impossible to involve a public community in that process. At Yahoo!, we can get in touch with the YUI team, explain what we’re doing and the help we need, work to come up with solutions to these problems, and then all YUI users benefit from that interaction. All of the hard work of Yahoo! engineers gets poured back into YUI as a whole.
As for the belief that Yahoo! controlling the library’s destiny is a bad thing, I can’t disagree more. Once again, this is what makes YUI valuable. Every open source project has a core team whose job is to maintain the original vision of the project as well as guide its development and roadmap. The fact that the YUI core team is paid by Yahoo! doesn’t change the basic structure of any project. You can only look to the next city over and the Mozilla Foundation as a great example of a similar system. The core Mozilla team decides how Firefox evolves, and the fact that Mozilla writes their paychecks doesn’t mean that an inferior product is being created. There’s a reason that Firefox is the #2 browser, and that’s because of dedicated individuals who are passionate about their work and who want to create the best possible product. When the product is your full time job, it’s much easier to do. Believing that a community can’t form around an open source library that’s funded by a large company is silly; communities are formed through outreach, communication, and collaboration, not by non-profit status.
The YUI team worked very hard to develop a third-party contribution model. Yes, it’s had some growing pains, but the results have been fantastic thusfar. Certainly, YUI hasn’t had anywhere near the number of outside contributions as jQuery, but YUI is trying. Matt Snider, formerly of Mint.com, has a full-fledged component shipping as part of YUI 2, a component on which he gave a talk at last year’s YUIConf. To me, that’s a great thing. It’s a sign to others that if you’re willing to approach the YUI team with an idea, you absolutely can get support and get your component into the library. Matt put a lot of work into that component, and hopefully YUI can find more people like him who are willing to take the time to collaborate and make meaningful contributions to the library. Also, the YUI Gallery is quite possibly the most awesomest thing I’ve seen: a way for everyone to easily publish their YUI additions into a listing and have those made available on Yahoo!’s content delivery network. Right now there are 227 gallery modules, all benefiting from Yahoo!’s edge.
Can the YUI team improve it’s community outreach and contribution model? Absolutely. Does YUI have to split from Yahoo! to do that? No. YUI 3 is a great product, supported by great people and a growing community. If the team can be accused of anything, it’s ignoring marketing and public relations in favor of developing new features. That’s an area in which jQuery excels, and there’s a lot that the team can learn.
YUI is not jQuery, and I think trying to be like jQuery would be a mistake. Does that mean YUI can’t learn from jQuery? Absolutely not. The jQuery community is absolutely amazing and there isn’t an open source project in the world that wouldn’t love to have the same type of community. YUI doesn’t have to become jQuery for that to happen, nor does it have to cut ties with Yahoo! to that end. jQuery is but one example of how to build a community, and as I’m rather famous for saying to my colleagues, there’s always more than one solution to a problem – it’s choosing the right solution that’s the real challenge. I believe that following jQuery step-by-step would be a mistake for YUI because the two libraries have different origins, different strengths, and different target audiences. YUI needs to find its own way, one that embraces the company from which its insights and experience are gathered. And I believe YUI can do this.
Disclaimer: Any viewpoints and opinions expressed in this article are those of Nicholas C. Zakas and do not, in any way, reflect those of my employer, my colleagues, Wrox Publishing, O'Reilly Publishing, or anyone else. I speak only for myself, not for them.
Both comments and pings are currently closed.
22 Comments
Really well put together (as usual), couldn’t agree more. I really believe that the one of main reasons why YUI isn’t as popular as jQuery is because most people aren’t building the kind of applications that would really benefit of YUI structure/features – you can only experience it if you are building bigger/scalable applications – the learning curve is way stiffer and the number of “casual coders” is way bigger than the number of “application developers” – popular doesn’t mean better.
cheers.
Miller Medeiros on November 3rd, 2010 at 10:56 pm
I’m an avid user of YUI but John’s quoted comment will continue to hold true until there is a person with commit access who does not work and has not worked for Yahoo. Firefox evolves in the open with the direction being clear to the whole community. YUI’s direction comes from a conference room in a locked building. I’ve seen it. I learned more about what was going on with YUI by sitting in one status meeting by invitation than I ever did trying to participate online. That is not an empowered community. The third-party contribution model you’re so proud of is a pain in the butt that has produced results easily counted on one hand. I love YUI and deeply respect the people working on it, but Yahoo hinders it almost as much as it benefits it and will continue to do so until it can learn to let go of absolute control.
Chris Griego on November 3rd, 2010 at 11:21 pm
Very interesting article, thanks for sharing Nicholas. I’m a jQuery user in personal and 9-5 scenarios but as I move toward clientside JS driven web applications I keep meaning to give YUI a shot. I know the jQuery Core isn’t aimed at this use case but I know of plugins such as corMVC and JavaScriptMVC that build on top of it. In my mind these are my options along side YUI for such projects.
As for the direct comparisons with jQuery and YUI; my view is that it’s simply for the uninformed. The only worry is if the community will pick and chose a framework for each project that best fits or instead select on popularity/past experience.
Denis on November 3rd, 2010 at 11:24 pm
@Chris – First, your frustration is about communication and not about YUI being associated with Yahoo!. This is exactly my point, people seem to get so wrapped up in the “it’s a Yahoo! problem” that they don’t realize the same problems can exist regardless of where a project starts out. Are there communication problems? Yes. Is that because of Yahoo!? No. The very fact that you were able to sit in on a status meeting should be a sign that it’s not the company holding things back.
As I said, YUI could learn a lot about community involvement from jQuery, but it doesn’t have to do the exact same thing. And yes, I’m extremely proud of the third-party contribution model that’s available now. Why? Because before that, there wasn’t one. I’m not saying it’s the best process in the world, I’m saying that you don’t go from zero to awesome overnight. The best way to improve the process is to provide feedback, say that something sucks and you’d be more likely to contribute if it didn’t. Cursing the company for something that has no direct correlation is not only inaccurate but also ineffective.
Nicholas C. Zakas on November 3rd, 2010 at 11:39 pm
@Chris: It’s true that YUI’s status meetings (and many other core team meetings) are held in conference rooms on the Yahoo! campus and are not open to the public, but this is primarily a matter of logistics, not an attempt to exclude the community.
It would be impractical to hold all of these meetings in a publicly-accessible forum, and this is something we’ve tried to address through things like YUI Open Hours, where we invite the community to join us for code reviews, discussions about upcoming changes to the library, and even brainstorming sessions for new components like YUI 3 DataTable.
In addition, you can almost always find YUI core team members hanging out in the #yui IRC channel on Freenode and in the yuilibrary.com forums. These are both great avenues not just for keeping up to date on the latest status meeting scuttlebutt, but also for kicking ideas and code around and for advocating changes.
I do agree with you that YUI’s development could be more transparent than it is, and I think that’s something we should continue to work on. But I’d ask you, and the rest of the YUI community, to give us the benefit of the doubt here: we’re certainly not trying to develop YUI in the dark, and if it seems like that’s the case, it’s more likely to be either a logistical limitation or an oversight on our part than an intentional act of exclusion.
Ryan Grove on November 3rd, 2010 at 11:53 pm
I’m of the opinion that JS toolkits / libraries such as YUI and Closure actually benefit from their nature as corporate-owned code turned open-source rather than suffer because of those attributes. Having full-time developers working on the code base that are screened by companies who know what they are doing leads to a more substantial amount of battle-hardened code.
I also believe that it’s important to consider the very apparent differences in the composition of the community. As you noted, whereas YUI community members generally tend to be building JavaScript-heavy web applications, jQuery tends to attract a lot of designers. That difference tends to change both the essence of the questions as well as the number of questions and amount of involvement per user.
I do believe that jQuery absolutely has its advantages over more comprehensive libraries for certain projects, but I also believe that the amount of functionality that YUI encompasses hasn’t yet been shown to be replicated and maintained by a part-time army of volunteers. Perhaps it’s true that corporate-owned projects (or whatever you want to term them) have more of an uphill battle in terms of community and “openness,” but in terms of the breadth and depth of the actual code, it appears that they’ve set the standard.
Andrew Mattie on November 4th, 2010 at 1:18 am
Yahoo definitely has many of the best JavaScript people in the world, and I’ve seen some really cool presentations and articles in the Yahoo developer community that have blown my mind, but I think the Yahoo brand still leaves a taste in the mouth of so many developers. Many see it as a huge, lumbering corporation, struggling for relevance in a changing world.
jQuery was a “rooting for the underdog” preposition for a long time, and that’s an exciting thing to get behind, especially when it was usable by a large number of developers and designers. Now that’s not the case but that heritage has evangelized it to the greater majority.
Choosing YUI still feels like choosing an “Enterprise Solution” and that’s not any fun to blog about.
Jethro Larson on November 4th, 2010 at 3:07 am
IMHO I think the Yahoo name does give me pause, maybe its related to the perceived success and momentum of Yahoo company as a whole. When adopting a JavaScript framework, you’re not just adopting the current framework but also the direction and momentum behind that framework.
Maybe I convinced of Yahoo’s superiority if someone lists a best-of gallery of ajax sites built with it?
Personally I feel that Google has the better Ajax software and websites built with their Closure Library JavaScript framework. I can also rest assured that Google’s engineers will do whatever is possible to make the fastest JavaScript implementation available for each browser – speed is something engrained in Google’s DNA, thats something I don’t feel when I think about Yahoo.
Regardless I hope YUI the most success as all JavaScript developers end up benefiting from competition. It is a shame that most frameworks promote fragmentation as they have an ‘all or nothing’ approach where mixing and matching of different JavaScript libraries is discouraged.
Demis Bellot on November 4th, 2010 at 11:03 am
To play devil’s advocate, part of the implication of “paid developers” is also, what would have happened to YUI if Microsoft bought Yahoo!? Point being, if something happened to Yahoo!, my multi-million dollar project leveraging it’s framework may be at the whims of a business decision.
Rob on November 4th, 2010 at 11:27 am
@Jethro – That’s an excellent point that I think is often overlooked. Everyone loves an underdog, and an open source project born in a vacuum without corporate backing definitely seems like a more interesting and appealing story than one born from a big company,
@Demis – You’re right in that the perception of Yahoo! itself may affect the perception of YUI. Yahoo! unfortunately doesn’t get a lot of credit for the excellent front end engineering culture and tools that we have. We were the first to publish an authoritative reference of performance guidelines, along with the creation of YSlow to help measure site performance. Interesting anecdote: Google’s personalized homepage uses YUI Grids.
@Rob – Don’t mistake the fact that there are paid developers of YUI to mean it’s not open source. The source is available, you can download and fork it right now. You can continue to make changes and improvements in your fork and decide whether or not to submit those changes back. Regardless of what happens to Yahoo!, YUI wouldn’t automatically disappear. There is a community (though admittedly not as large as jQuery’s) that has evolved around YUI. I have no doubt that this small and scrappy community could keep the project alive if necessary. I know I, for one, wouldn’t stop contributing.
Nicholas C. Zakas on November 4th, 2010 at 11:36 am
jQuery and YUI are different beasts. jQuery is for adding interaction to webpages. YUI is geared towards developers writing rich web applications. I think jquery is cool, but I’ve never used it since I’m not a web designer trying to add animations.
YUI is a lot more like ExtJS and google closure, providing a Component framework for developing javascript based reusable widgets for web applications.
This rant just to say your post is on the money; learn from some of Resig’s points but do not try to be as popular as jquery… or maybe you could follow ExtJS’s lead and create something like Ext Core, and maybe make that more public…
Juan Mendes on November 4th, 2010 at 8:14 pm
Your post makes it clear that the Yahoo team is more preoccupied with what they want or need, than what the whole community is looking for. Maybe there’s something to learn from jQuery here.
@Ryan Grove: you’re a funny guy! Have you heard of distributed teams and video conferences?
Christophe on November 5th, 2010 at 1:22 am
This was an interesting post. I don’t like to mix and match libraries too much in one project, but it is always a struggle to make the right decision.
One thing that I have always loved about YUI is the very thorough documentation. Many times, I have dug through jQuery’s plugin library just to find that a plugin site has been taken down… so what if I was already using that on a site? I’d be stuck or re-writing for another plugin. Not a situation you want to be in on a large site.
So, I think you may be right in saying that the Y in YUI is exactly what gives it value, and makes it unique.
Martin on November 5th, 2010 at 8:36 am
@Christophe – That’s a pretty major overgeneralization of what I said. The fact that YUI works with Yahoo! teams doesn’t mean they don’t work with anyone else. If you take a look at the YUI bug tracker, you’ll find that most of the bug reports and feature requests come from outside of Yahoo! (and yes, internal bugs are mirrored to the public bug tracker so long as there’s no confidentiality issues).
Also, Ryan is actually a remote member of the YUI team who’s not located at the main campus. He definitely knows firsthand about distributed teams. I’d also like to remind you that Yahoo! is a global company, so we all have a lot of experience working across time zones and languages. Lastly, YUIConf is next week, where we open the doors at Yahoo! and invite the community in. Hundreds of non-Yahoos will converge to discuss YUI and front end engineering in general. It’s too bad it’s sold out, as you could stop by, too.
Nicholas C. Zakas on November 5th, 2010 at 12:53 pm
@Christophe: As Nicholas points out, I have heard of distributed teams and video conferences. The YUI team is spread across three states. Most of the team works from Sunnyvale, but a couple of us (myself included) work remotely. We use video conferencing heavily.
Holding a virtual meeting with a few remote participants is very different from holding a meeting in which the entire Internet is invited to participate. Not just in terms of the technical limitations involved, but also in terms of meeting dynamics. Nothing would get done. I don’t know of any open source project that opens all of its core team meetings to the public at large; instead, most projects invite the broader community to participate in special sessions or via websites, email, and IRC (the latter being particularly useful given its real-time nature).
The YUI team often invites individual external contributors to participate in meetings, and we hold special meetings, like Open Hours, where the entire community is invited to participate. And of course, some of us are almost always on IRC, which is one of the best real-time open source collaboration tools there is.
As I said earlier: we can do better, and we will. If you want to see this happen faster, we’d love your help.
And, just as a sidenote to @Rob: As much as I enjoy getting a paycheck, I’d still find a way to contribute to YUI even if the paychecks stopped.
Ryan Grove on November 5th, 2010 at 1:12 pm
I plan on addressing this separately elsewhere, but I also strongly disagree with John’s viewpoint here.
I’ve actually found the interactions with the core team much more productive when working with YUI. Guys like Satyen, Adam, Dav, Eric, Matt, Ryan, and even long standing folks like Thomas Sha, have all been insanely helpful to the point of absurdity.
It’s insane to see how much help to the community they provide, how much feedback, support AND still write code.
The fact that they’re YUI employees means that you’re interacting with battle tested, intelligent engineers, whereas in some communities, it’s can range between intelligent engineers and people with more opinions and free time than ability.
That’s not to disparage any specific community, and I think YUI could always do more to improve, but as you said, the commercial side truly augments and improves the experience.
Nate Cavanaugh on November 5th, 2010 at 2:24 pm
I just put this article into Chinese
http://ued.taobao.com/blog/2010/11/06/yui3-vs-jquery/
jayli on November 6th, 2010 at 5:57 am
@Nicholas and Ryan:
I appreciate you taking the time to reply to my comment.
I am well aware of Yahoo’s size and reach, that’s why Ryan’s logistics comment sounded so funny. Between Yahoo only and the whole internet, there is certainly a middle way.
I am like “Him” in your post, I am very careful when a tool is tied to single company. In a different context, I see what happens with Google (Wave) and Microsoft (Silverlight). The fact that it’s open source and – as you say – “wouldn’t automatically disappear” just eases the pain.
Granted, what I wrote was a “pretty major overgeneralization”.
Christophe on November 7th, 2010 at 6:39 am
“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.”
The problem YUI has is that most Web applications don’t start out with “scalability” as a primary goal. The primary goal is simply to find an audience of any size at all. Once that audience is found, the developers work on growing it, and then one day they wake up and find themselves hitting scale walls.
This is actually a completely rational way of working when you realize that most Web apps fail to clear this first hurdle. Only a few will ever grow to the point where scale is an issue; most will launch, flounder about until the money runs out or the founder gets bored, and then quietly die. So “designing for scalability” isn’t a priority at the outset; “designing for survival” is. Anything that delays your time to market or complicates your effort to clear that first hurdle gets pushed aside as something you can deal with later.
The reason why this is a problem for YUI is that YUI poses a tradeoff — increased complexity for increased flexibility — that cuts against this logic. When you’re just starting out you don’t need the additional flexibility, and the additional complexity makes it harder to get to 1.0. jQuery, on the other hand, is designed to be easy to pick up and get productive with quickly. So you grab jQuery, roll it in, and figure you’ll deal with any shortcomings it has later. Then when “later” comes the YUI folks say “hey, our tools are perfect for your needs!”, but now you’re running a live app with tons of users, and ripping out jQuery is a non-trivial project. It’s easier to just live with it, or build around it.
All of which is a long-winded way of saying that if the target audience for YUI is high-traffic Web apps, its appeal is always going to be limited, because most high-traffic Web apps aren’t born that way. They start off as low-traffic hack jobs and grow to meet their destiny. And if YUI doesn’t have a pitch that’s appealing to them while they’re in that larval stage, it’s always going to be finding itself coming in second to tools that do.
Jason Lefkowitz on November 10th, 2010 at 11:26 am
My worry with the ‘Y’ in YUI is a combination of what @Rob says in the comments, and what John says in his post. Yes, I know the code is open source, but what John says about the community doesn’t really ease my pain, because he is right. I don’t see the YUI community driven by the community, I see it driven by Yahoo!. Usually, if something happens to a company that heads an open-source project, you can count on the community to keep it going. If the community also happens to be run by the company, what happens to the community if something happens to the company? If something happens to the community, what happens to the code?
Paul on November 10th, 2010 at 11:28 am
[...] etc.?“. John Resig, of jQuery fame, gave a great answer on his thoughts to the question. Nicholas Zakas responds with another great explanation of why he doesn’t think the comparison is needed. Both have [...]
YUI => jQuery? on November 19th, 2010 at 5:16 pm
[...] By far, the most interesting question I saw was “How could YUI3 improve its image compared to jQuery, MooTools, etc.?“, and the respective answer from John Resig, pointing out that the lack of community commits, leaving YUI completely under the umbrella of Yahoo!, along with a few other issues, is what makes YUI lag behind its competitors. Given the controversy the answer generated, Nicholas C. Zakas posted a nice follow-up on his blog. [...]
Selected questions from Quora and Stack Overflow regarding JavaScript | Raphael Pereira on January 2nd, 2011 at 2:19 am
Comments are automatically closed after 14 days.