The YUI contributor’s team is pleased to announce the first developer preview of the upcoming YUI 3.2.0 release. This preview provides an opportunity for developers and implementers to help test the release for potential regressions and to provide feedback on new features and components. If you have an existing YUI implementation, please exercise YUI 3.2.0pr1 in your development environment and let us know what you find.

There are three ways to get started with the preview release:

• Use from the CDN: YUI 3.2.0pr1 is available on the CDN via the 3.2.0pr1 version tag — so you can reference preview-release files like http://yui.yahooapis.com/combo?3.2.0pr1/build/yui/yui-min.js. If you switch to this seed file for the preview release, all subsequent use() statements will continue to load YUI 3.2.0pr1.
• Download the release: Download YUI 3.2.0pr1 from YUILibrary.com, including source code and examples for all components — including those new to this release.
• Explore the examples: As a convenience, we’ve posted the preview (along with the functioning examples roster) to YUIBlog. Feel free to explore the release there as a prelude to switching your CDN version reference (or downloading the preview) and testing it out in your own environment.

As with all YUI development work, you can track our current plans and progress on our YUI 3 tasklist, including a comprehensive list of YUI 3.2.0 (and some upcoming 3.3.0) changes; you can also check in on our progress addressing issues in the bug database. Here are some of the new and updated components featured in the 3.2.0 developer preview:

• Intrinsic support for touch events has been added (mynode.on("touchstart", function(e) {});). We’ve also added a Gestures module with two bundled gestures — gesture-flick and gesture-move — that work with both touch- and mouse-driven devices. Check out the API docs or the bundled sample page for ideas about how to start using Gestures.
• YUI’s intrinsic Loader now supports capability-based loading. This allows us to segregate, for example, IE-specific code into separate submodules and allow the Loader to bundle that code only for browsers that require it. We’re leveraging this new feature to avoid shipping IE-specific code in the Dom module to non-IE browsers, a performance/k-weight boost that will benefit all users of modern browsers with no code change required.
• YUI 3’s animation portfolio now supports transitions via the Transition module, providing browser normalization for this powerful, hardware-accelerated (where available) technique for handling transitions; check out the example for sample code. Animation, in its most basic form, has a streamlined dependency tree for modern browsers, significantly reducing the k-weight for simple animation in better browsers.
• YUI 3.2.0 will bring with it a new beta version of YUI’s CSS Grids component, and you can begin exploring this new approach to Grids in the preview release. The examples are the best place to start.
• We worked with Michael Johnston of the Yahoo! Mobile Engineering team to bring a new (beta) ScrollView widget to YUI 3.2.0. ScrollView provides a scrolling pane implementation familiar to users of native Apple iOS applications, emulating the elasticity of the element when scrolled to the beginning or ending limit. You’ll see in the 3.2.0pr1 examples for ScrollView that this component is device neutral, working well with a mouse as well as with touch events on your Android or iOS device.
  
• The Uploader component from YUI 2 is now part of the YUI 3 family as well, debuting as a beta in 3.2.0.
• The History module that debuted with YUI 3.0.0, which was a port of the YUI 2 version, has been deprecated (it remains available in YUI 3.2.0 as history-deprecated). A new beta History utility debuts in 3.2.0, based on Ryan Grove’s History Lite module from the YUI 3 Gallery. A preview-release example from the new component is a good starting reference.
• The JSONP and YQL Query modules from the YUI 3 Gallery have become canonical components, debuting as beta in this release.

The goal of a preview release is to make it as easy as possible for all of us in the community to evaluate progress of the upcoming release and provide feedback. Please take some time to test 3.2.0pr1 and let us know what you find by filing tickets in the YUI 3 bug database marked as “Observed in version” 3.2.0pr1. We’ll do our best to address preview-release questions on the YUI 3 Forums, too.

YUI contributor and former Yahoo Chad Auld emailed us to tell us about his latest project with his Brilaps group — a project that has brought YUI Theater to the TV screen via Boxee. In Chad’s words:

Boxee is an up-and-coming cross platform application that aims to help bring web content to the TV. It is based on the open source XBMC project and allows users to write new plugins to bring in additional content. We launched a new project about three weeks ago to build our first Boxee plugin, and we selected the YUI Theater as the content we wanted to bring from the web to the TV. There are so many great videos archived there (and growing), we think it is a terrific source of content for developers to have access to from their couch (especially since most of the videos are a bit longer than someone might have time to watch comfortably from their laptop). It took us about a week to build the plugin, another week to polish it up and sort out a few bugs, and about a week to get the application approved by the Boxee QA team and pushed into the public repository. I just got word that it hit the public repository this morning and so I wanted to reach out and let you know.

This is fantastic news for anyone who has been enjoying YUI Theater content and would like to catch up on the latest from Douglas Crockford, Brendan Eich and all the other great YUI Theater speakers from the comfort of his/her couch. Check out the video above for a tour of the UI, and then go grab Boxee and get started.

The Yahoo! Flex Force is currently looking to expand our team with a few talented frontend Engineers. As part of the Flex Force team, you will have the opportunity to work on multiple strategic projects of high profile and high visibility. These positions involve being an ambassador of best practices and sharing knowledge across the organization. We work closely with the different platform teams, including the YUI team, to ensure we’re using the latest strategies, techniques, and tools.

As a recent example, the Flex Force team was behind the implementation of the new Yahoo! Updates widget which is built entirely using YUI 3.

To be successful at this role, you’ll need to be a self-starter and fast learner with a positive mindset who can quickly ramp up and take on different challenges. A true passion for frontend technologies and best practices is also required.

If working with me and my colleagues on the Yahoo! Flex Force sounds interesting to you, head to the Yahoo careers site and check out the following positions:

• Frontend engineer position #1
• Frontend engineer position #2
• Frontend engineer position #3 — this is a more senior role, with more experience and additional skills required

For those of you that don’t subscribe to the YUI calendar or YUILibrary.com forum, the next installment of YUI: Open Hours will be tomorrow, July 21st.

This time we’re going to focus on a recurring theme for YUI community contributors that are just getting started building their own modules: How to build a Widget and how to build a Plugin in a YUI 3 way.

Anthony Pipkin, aka apipkin of #yui IRC channel fame, will be the guest, guiding us through his learnings over the last year and showing how to move from copying and pasting the YUI 3 documentation examples to feeling confident that you’re making the right choices for how to approach a problem in a “YUI 3 way of thinking”.

We’ll take a look at two of his simpler Gallery modules, the Button Widget and the Node IO Plugin. He’ll discuss what they looked like originally, versus today, and why they changed.

Then we’ll play around a while, maybe build something from scratch based on what the folks on the call want to cover.

Matt Sweeney (Node, Selector, TabView, Grids, etc) and Satyen “the Guru” Desai (Widget, Plugin, Base, Attribute, etc) from the YUI team will also be on the call. So there will be best practices in the house.

For YUI 3 consumers that aren’t (yet?) contributors, this call should still be valuable for understanding the thinking behind how YUI 3 widgets and plugins are built and what sort of patterns to expect from new YUI components. And no doubt there will be other great takeaways as always.

We’ll be online from 10am to 12pm PDT. The connection details are the same as usual.

1. Dial in to 1-888-371-8922 (non-US participants, email me for a local number)
2. Enter the attendee code 47188953#
3. Join the screen sharing session (this will prompt you to install the Adobe Connect plugin if this is your first time using it)

Here’s the forum thread for this Open Hours. I’ll post some of the interesting takeaways after the call.

Follow @yuilibrary on Twitter for the latest.

Hope to see you there!

About the Author: Daniel Barreiro (screen name Satyam) has been around for quite some time. The ENIAC was turned off the day before he was born, so he missed that but he hasn’t missed much since. He’s had a chance to punch cards, program 6502 chips (remember the Apple II?), own a TRS-80 and see some fantastic pieces of operating equipment in his native Argentina which might have been in museums elsewhere. When globalization opened the doors to the world, his then barely usable English (plus an Electrical Engineering degree) put him on the career path which ended in a 5-year job in the Bay Area back in the days of NCSA Mosaic. Totally intrigued by the funny squiggles a friend of his wrote in his plain text editor, full of <’s and >’s, he ended up learning quite a lot about the world of frontend engineering. It’s been a long journey since COBOL and Fortran. Now he lives quite happily semi-retired in the Mediterranean coast close to Barcelona, Spain. When he’s not basking in the Mediterranean sun, Satyam can be found among the most prolific and knowledgable participants in the YUI community on the YUI Forums.

In December 2009, editors at Packt Publishing asked me if I’d like to write the second edition of their book on the YUI Library. The original author, Dan Wellman, was engaged in other business at the time, and they needed an author who was broadly familiar with YUI 2. The first thing I thought was: aren’t you a little bit late? Much of YUI 3 was already out in GA and more was coming with every release. But the Packt team wanted to proceed, and I agreed to take on the challenge.

On July 16th, the new volume came out, YUI 2.8: Learning the Library, not as a second edition but as a new title. In the end, it wasn’t such a bad decision. While the book was going through the editing process, YUI 3 gained the ability to load YUI 2 components from the use() statement. This extends the usefulness of the extensive YUI 2 catalog while taking the pressure off developers to produce YUI 3 versions of all YUI 2 components.

• Sample Chapter: Packt has released a sample chapter from the new volume, covering YUI 2.8 Rich Text Editor, on their website, giving you a flavor of what the new book contains.

The goal with this new volume was to cover all non-beta YUI 2 components. This broad vision forced me to take a deeper look at components I had barely used in their most basic forms as well as others I’d not used at all. However, in contrast to the first edition, a project that began not long after the library had been made public, I had a few years of cumulative experience with YUI — my own experience paired with that of the many users who share their experiences and advice on the forums and the blog. I was also spared from many blunders by an excellent team of reviewers, two of whom, Caridy Patiño and Iliyan Peichev, are also well known YUI contributors.

To keep the book to a manageable length, I eliminated some images, long examples, and reference material that could be found at the YUI website. While the first edition had at most two components per chapter, the new one has up to four and has a couple of new chapters. Even so, some components didn’t make the cut.

I learned a lot about the YUI Library while writing this book, and the changes I made to Dan’s text were instructive about the library’s evolution since its release in 2006.

The programming style for example code has changed in these years. Instead of creating a namespace (or using YAHOO.example, which is always available as a placeholder), we now tend to fit everything within an anonymous function created when the DOM becomes available. (This style is closer to what we see in YUI 3.) We now use namespaces when we absolutely need to create globally accessible variables (including objects) such as when we create a custom library component. Sandboxing saves us some typing, since we can define functionally-scoped aliases for the objects we use more often from YUI (Dom, Event, Lang are common shortcuts) or variables of our own. This approach also lets YUI Compressor do a far better job.

Having a panoramic view of the whole of the library allowed me to notice how it developed over time. The architecture of the components changed and it is clear how everything has converged into what is now YUI 3.

Early components, like TreeView, had few dependencies. As certain patterns started to become obvious, some basic component infrastructure started to develop. The Container family had a Config object which allowed for getter and setter methods, and so have all the components that inherit from it. It also uses the Custom Event object, which is one of the two ways to work with custom events we have available in YUI 2.

With the release of TabView came the YUI 2 Element Utility, which provided improved getters and setters (via AttributeProvider) as well as better custom events (via EventProvider). Seventeen other YUI 2 components inherit from Element. Looking at the evolution the library, it’s easy to see how the ideas behind Element, as a DOM element wrapper, came to inform YUI 3’s Node. Element’s role as a basis for other components was broken out in YUI 3’s Base and Widget, though the new components are all far more powerful and complete, each in its own area. For example, Node’s all and one methods return Node instances while Element’s getXxxx methods return plain DOM element references, not completely abstracting the DOM.

The two models, Config and CustomEvents on the one hand and AttributeProvider and EventProvider on the other are not totally incompatible. In Menu and Split Buttons both models coexist, as Button inherits from Element and it hosts a regular Menu that inherits from Container.

Undoubtedly, YUI 3 benefited from all of this experience; but YUI 2 also benefitted from YUI3. Cool stuff came from YUI 3 to enrich YUI 2, such as event-delegate and element-delegate and other new events we can listen to (focusin and focusout, mouseenter and mouseleave). This also became possible because of the way we load components, which changed during YUI 2’s lifespan — most importantly with the introduction of the YUI 2 Loader — and became formalized as intrinsic support for client-side loading in YUI 3.

Loading affected how the components got designed and how the final component files are built. In YUI 2, to minimize the number of outstanding server requests, the components had to have as much of what they needed packed together. Thus, some components got loosely related objects in them just to have them handy when and if needed, others got a bunch of objects with a whole range of features packed in one file because loading the separate parts was too costly. Then came aggregates such as yahoo-dom-events.js or reset-fonts-grids.css since they are almost invariably used together or utilities.js which gathers all the often used components in the YAHOO.util branch. But the real change came with combo-handled requests, which allowed us to pull any number of script and css files each in just one http request. That makes it less necessary to optimize the packaging of the objects in the library into component files and those into aggregates based on a hypothetical ‘average user’.

In YUI 3 we no longer need to load the ‘container family’ all at once. We can load the separate widget-xxxx files on top of the basic widget according to the features we need. That approach is the standard in YUI 3, but it came as one of the steps in the evolution of YUI 2. Hence, more recent YUI 2 components like event-delegate and element-delegate are packaged separately from from their base components and so is Event’s mouseenter and mouseleave. We might see further splits in library components in future releases, allowing you to choose more specifically the feature set you want and leave unneeded code off the page.

This is a story of progress, a process that necessarily went though some failed efforts. Why doesn’t TreeView inherit from Element or why hasn’t Container, and thus Menu, switched to Element or, at least, to AttributeProvider and EventProvider? Technically, the answer is ‘backward compatibility’, but in more general terms it is ‘respect’. There are thousands of websites (and tens of thousands of developers) using the the published public interface of the YUI 2 components. Making those changes would break many applications or would cut them off the upgrade path, should they want to benefit from a code fix or a new feature. Being so respectful of the installed code base is a library feature in itself. Being respectful to us, who create that code, is a feature of the people in the YUI team, and I’m very grateful it is so.