YUI gets a bad rap because of YUI2. YUI3 was a ground-up rewrite that addressed all of the overkill from 2 and them built an awesome library that includes things like modules and models/views, as well as things you expect like DOM, really great custom events, animation, etc. It's a really great foundation when you are building a complex JS-driven application UI. Having worked in front-end development since before there were JS libraries, I almost never choose anything else. JQuery has a lot of the same stuff now via 3rd party libraries, but often I've seen the production schedules of those various 3rd parties lead to cases where you need a newer version of one but can't upgrade because it would interfere with another.
YUI3 also forces you to use at least the basics of good coding patterns and practices, where jQuery gives you nothing in that regard. My experience with the average designer/pseudo-developer person who is writing JavaScript is that they can use a bit of handholding when it comes to crafting maintainable code on projects.
"JQuery has a lot of the same stuff now via 3rd party libraries, but often I've seen the production schedules of those various 3rd parties lead to cases where you need a newer version of one but can't upgrade because it would interfere with another."
this is long solved.. i read your post twice and if you take this statement away, your argument for YUI seems to unravel. The statement also seems to demonstrate you think it's YUI vs jquery which is not an interesting comparison.
I'm interested in a pro-YUI argument when compared to Backbone, Knockout, Ember, Angular, ExtJS, etc, in the context of "enterprise intranet" apps. In my particular case we need to be able to work with arbitrary markup and widget toolkits such that our design team has minimal constraints due to stack choices, but I'm also interested in the case where the design team is able to be constrained, if that makes the argument easier.
Comments
YUI gets a bad rap because of YUI2. YUI3 was a ground-up rewrite that addressed all of the overkill from 2 and them built an awesome library that includes things like modules and models/views, as well as things you expect like DOM, really great custom events, animation, etc. It's a really great foundation when you are building a complex JS-driven application UI. Having worked in front-end development since before there were JS libraries, I almost never choose anything else. JQuery has a lot of the same stuff now via 3rd party libraries, but often I've seen the production schedules of those various 3rd parties lead to cases where you need a newer version of one but can't upgrade because it would interfere with another.
YUI3 also forces you to use at least the basics of good coding patterns and practices, where jQuery gives you nothing in that regard. My experience with the average designer/pseudo-developer person who is writing JavaScript is that they can use a bit of handholding when it comes to crafting maintainable code on projects.
"JQuery has a lot of the same stuff now via 3rd party libraries, but often I've seen the production schedules of those various 3rd parties lead to cases where you need a newer version of one but can't upgrade because it would interfere with another."
this is long solved.. i read your post twice and if you take this statement away, your argument for YUI seems to unravel. The statement also seems to demonstrate you think it's YUI vs jquery which is not an interesting comparison.
I'm interested in a pro-YUI argument when compared to Backbone, Knockout, Ember, Angular, ExtJS, etc, in the context of "enterprise intranet" apps. In my particular case we need to be able to work with arbitrary markup and widget toolkits such that our design team has minimal constraints due to stack choices, but I'm also interested in the case where the design team is able to be constrained, if that makes the argument easier.