YUI 3.6.0 PR2 Is Now Available
By Allen RabinovichJune 13th, 2012
YUI 3.6.0 PR2 is now available to the developer community for feedback and testing on the Yahoo! CDN. Please take a moment to check it out via CDN or download.
The remaining target dates for the YUI 3.6.0 milestones are:
- PR3 – July 17, 2012
- GA – July 31, 2012
As we have previously mentioned, we are in the process of condensing our development cycle in order to transition to monthly releases.
You can check out the list of issues addressed in 3.6.0 PR2 and the full list of issues targeted for 3.6.0 in our bug tracker.
Additionally, you can take a look at the current change history rollup for all components in the library.
We invite you to join the ongoing development discussions happening with the team over on GitHub. For support, visit our forums, or join other YUI developers live in the #yui channel on irc.freenode.net (a web client is here).
Thanks for all your feedback and happy testing!
June 13, 2012 at 2:17 pm
Hi there,
First of all – thanks for maintaining YUI. But YUI 3 is still below “enterprise” quality, unlike YUI 2.
- API keeps changing (this is a big no-no)
- YUI 3.x is far from mature – if you guys release 3.x without the pre-existing Widgets in 2.x, that’s still alpha quality. No paginator for datatable (even Yahoo team is still using 2.x for your ticket). What happened here?
Thanks for the great software and really awesome YUI 2.x. I just think that the new one is too rushed for 3.x. I’d rather stick with YUI 2 because it’s very stable than going with the copycats (extjs).
June 14, 2012 at 1:46 am
Does this mean the TreeView will finally get some love from you? We’ve all been waiting so long for this..
June 14, 2012 at 9:47 am
@LM
Thanks for your comments.
1. Do you have a specific API you’re referring to that we keep changing? We adhere to a conservative deprecation policy where we strive very hard not to break backward compatibility, and in the rare exception where we must, it is well documented over the course of several releases. Beta components are still in flux and we reserve the right to tweak APIs before getting to a GA release.
2. The foundation and infrastructure of YUI 3 has been mature, stable, and proven for quite some time, especially in the enterprise use case. We are continuing to work hard to add more widgets on top of this industrial strength core, including Paginator which is still on our near-term roadmap. That said, please keep in mind that we don’t plan to port every single widget from YUI 2 over directly, since some widgets don’t fulfill a core requirement and can be found in the Gallery instead.
3. Thanks for the kudos on YUI 2! We believe YUI 3 represents the next-generation of JavaScript that will keep your projects performant, extensible, and maintainable across all environments from desktop to mobile, server, and beyond. I hope you’ll find that these are great reasons to check it out soon!
June 14, 2012 at 9:48 am
@kenjiru
We are working hard on a preview release of TreeView for later this month. We look forward to you feedback on it!
June 15, 2012 at 10:39 am
Infrastructure is more important than out of the box widgets.
Nevertheless, pre-built widgets that come with the library is something to consider. For me the tipping point to switch from YUI2 to YUI3 in this regard, was when Overlay and Panel came out. Anything else you can either write your own, find gallery module or use yui 2in3.
I’m very happy that they had the guts to start fresh. The infrastructure pieces (modules/loader, custom events, widget/base, attributes) have been more important in helping me manage larger applications.
June 17, 2012 at 7:19 am
The choices in priority and the lack of certain key widgets for long periods of time, e.g. Huge efforts with datatable but no Wysiwyg editor, split button, extremely late entry into the mobile space without much focus, etc has been a concern for me also. That being said there is no comparing yui 2 and 3. 3 is so much better. it’s understandable when you consider that the goal of yui is to serve the people paying the bills, the other yahoo teams, rather than beating jquery and be the dominant player. But it seems a sometimes risky, and afaic wrong, strategy
June 17, 2012 at 3:32 pm
Sometime ago I was server-side enterprise developer. Now I’m planning my own project. I took a deep look into yui and mojito, and I think yui is really wonderful library (I reviewed a lot of others), and mojito is great server-side framework. But yui is infrastructure library. I found near everything I need in yui, except user interface :) I know, that in large project, a lot of stuff is selfmade, but pre-made widjets give ability to quick start. I don’t know, if you want to extend your influence on web developers, but if you want i can say you should(IMHO and I have not experience with library, but it’s what i found):
1) quick access to quick tips and recipes (yes, i know yuilibrary.com and rosettastone, but i found that i can’t start with yui after reading the documentation, it’s very academic, it’s commets in code (yui doc) but if i’m trying to start – i need architecture review). So Orelly YUI 3.5 cookbook seems good quickstart, but previous book was on 2.8? where are books? and where are links to samples in docs (like for example msdn with wich i was working for 5 years)? where are samples, not for make, but for touch (i mean why you have screenshots, but not a real sample on page)?
2) design. i know, in enterprise sometimes it doesn’t matter. but. yuiblog.com and yuilibrary.com – when i have seen it first time, i think that it’s abandoned project. your skins… i can say not modern looking (my opinion).
3) skinning for yui. i found only one article(body class=”skin-sam-…”). it(yui) doesn’t contains (i didn’t found?) even styling for basic controls like input or forms (for having everything in one style – yes cssbutton, but only button). why not less? less template with comments(like for example in kendo) can give ability to change yui style in 10-20-50 lines of code. it take… one day? of your designer.
4) cdn. why should everything be loaded from cdn? yes, i know, that i can load it from my own server, but i found it only in book. simple example. i’m trying yui. but last week internet is very unstable. and… yes. after refresh i typically get blank page because yui-min can not be loaded. i found way out, but somebody can say “oooh, it so hard to research” and he will take jquery.
5) gallery. why? how? why not to serve every version of every widjet? why have one repository with all widjets and tags? why not serve they one by one? i know, minifying will take much time(cache and dependency), but it much comfortable when you can load everything you need, how you need and resolve conflicts when you will by hands. I know about gallery version that can be said to yui – but it’s not so obvious like saying version of component you need(if it is not compatible with others, yui can say that there is problem with dependency resolution).
6) mojito. i think, that mojito is cool and minty! it is awesome. yes, yes, yes! but everything that was said about yui – can be said about mojito. docs!!! mojits compositions and where sample of base property? only one line, where i can’t even understand what it means, and later found in source, and got really happy with this feature. samples!!! yui cdn!!! ways to extend core (a bit but…)
It just my opinion. If I said something wrong – I really want links. I am not very experienced in yui so I want them, to save time. I’m take decision to take run for yui and mojito, but I took a lot time to start for me. Comments from somebody from yui team – will be great, i like discussion. If somebody is interested in, I think about blogging about yui and mojito – because some features are awesome, but hard to find. hope you will hear a voice from crowd. i want to use this product, and i want it will became better.
June 17, 2012 at 10:12 pm
I just hope that YUI can reach the widespread adoption of Jquery. Google Trends tell otherwise. The way your changing the API (e.g: delaying or not including treeview / pagination in 3.4 then including it in 3.7 or 3.8 when people have depended on other plugins in the gallery, etc – rushing it to call 3.x when it’s actually still a beta, not even close to 2.x stability, imho it’s not good). Back in 2.x you had Charts and other stuff as Beta but at least you still included it by default so people know what to expect. Now it’s just confusing :( I’m not willing to switch from YUI 2. The API is far more stable even though it’s lacking some of the nice 3.x features.
You’re telling people to switch to 3.x (and even put a huge banner in 2.x website) but then even YAHOO team is still using 2.x for its ticket system. It’s a proof that 3.x is unstable and not ready for production use.