Yahoo! User Interface Blog (YUIBlog)

Using Your App’s YUI Components on the Server

For my first sprint of 3.6.0 development I’m writing up (and showing by example) how to develop an app using YUI on the client and server, which works on both the desktop and mobile devices. Code sharing and reuse FTW! To start this process, I wanted to first build something using the development approaches that we want to promote. I’ve done that and I want to report in on my first experience running YUI on Node.js (spoiler: it was awesome!)

Photos Near Me, an app that shows you interesting photos near your current location, is a project I started almost a year ago to dogfood the YUI App Framework while Ryan Grove and I were writing it. I’ve been keeping the app up to date with the latest changes and additions to the App Framework, including the use of Y.App, the newest component in the App Framework. Photos Near Me has always been a client-side only app up until now!

My plan was to power the Photos Near Me server using Node.js, Express.js, and YUI, and I set two goals: share the app’s model objects and share its Handlebars templates between the client and server. Thanks to Dav Glass who has put in a ton of effort to make YUI run on Node.js in an intuitive, seamless way, I was able to easily accomplish these goals after several hours of refactoring the app. I was pleasantly surprised that my first try instantiating one of the model objects server-side and calling its load() method, which fetches data from YQL, just frickin’ worked!

Photos Near Me now renders the initial state for a request on the server then hands off control to the client-side Y.App instance. From there, in modern browsers which can use HTML5 History, all routing, data fetching, and page rendering will be done client-side; while older browsers will perform full page loads handled by the server. The time from request to seeing photos has been drastically reduced, it was especially noticeable on my iPhone when refreshing the page.

Being able to use the exact same code for the models and templates between the client and server makes following the best practices of progressive enhancement much easier to implement.

Check out Photos Near Me:
http://photosnear.me/

And its source:
https://github.com/ericf/photosnear.me

Watch for my comprehensive tutorial on building apps with YUI which will use Photos Near Me as an example to describe and show in detail how to use YUI on the server and client to build apps which run in desktop and mobile browsers while following the best practices of progressive enhancement.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

YUI Theater — Ryan Cannon: “There is no off-season: NFL.com’s move to YUI” (42 min.)

NFL.com’s Ryan Cannon (@rcanine) joined us at YUIConf 2011 to share the story of why NFL.com chose YUI over jQuery, how they migrated a large codebase from Prototype to YUI 3 on a tight schedule, and how they use YUI to create websites and mobile apps for one of the world’s most popular sports leagues.

Links

• View in HD on YouTube
• Slides
• Full YUIConf 2011 Playlist on YouTube

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

YUI Stories

At YUIConf 2011 last week, we set up a video camera and invited attendees to tell us how they use YUI and why they chose it for their projects. We were thrilled to hear their stories, and we’d love to hear yours as well! After checking out the video, leave a comment and tell us how you use YUI.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

Loader Usage at Quorus

Today, I’d like to talk about YUI Loader and how we at Quorus, Inc., use it to provide third-party websites with new features on demand.

The code we write powers features on other peoples’ pages, meaning we’re in the unenviable position of having not only no control over the browser environment, but heavy restrictions in how we use the document itself. Our customers put a Quorus bootstrap script on their pages; everything else needed for our functionality is loaded dynamically and on demand. We go to heroic lengths to make sure that our elements, styles, and scripts do not alter the behavior of anything we’re not responsible for.

We started our present code base two years ago, when YUI 3 was just taking shape. It was a risky decision at the time to commit to a codebase that wouldn’t hit beta for several months. In retrospect I can’t imagine how we would have accomplished what we have without it. I haven’t seen any other framework that has components approaching the power of Loader, Attribute, and CustomEvent.

The Quorus bootstrap script we provide to our customers does almost nothing. Its job is just to load the core of our platform without blocking the rest of page load, and to queue any API calls until we’ve done so. This core script file, called stage2, inlines yui, loader, and oop, as well as enough smarts to load additional libraries to respond to API calls, user clicks, and other conditions in the operating environment. Most other resources are served by a custom combo server that serves custom Quorus and stock YUI modules.

Bootstrap queues up API calls made in the host site’s code between when it loads and when we’re ready to go in an array on our global object, QUORUS:

QUORUS._callbacks = [];
QUORUS.use = function () {
  // turn the arguments object into a regular array,
  // so that it can be stored safely
  var args = Array.prototype.slice.call(arguments, 0);
  QUORUS._callbacks.push(args);
};

Once we’re ready to process API calls, stage2 runs them one by one in timeouts. This ensures we yield control regularly back to the browser, which makes the user experience more responsive. The behavior is a lot like Y.AsyncQueue, but simpler and doesn’t require YUI to be loaded:

// Put the real 'use' function in place for any subsequent calls:
QUORUS.use = function (feature, callback) {
  YUI.use('module-that-provides-the-feature', function (Y) {
    // find the API for the requested feature, and pass it to the callback
    callback(Y.APIs[feature]);
    // process another pending API call, if any:
    setTimeout(processAPICall, 0);
  });
};

// Play catch-up, running each callback in sequence:
function processAPICall () {
  var callback = QUORUS._callbacks.shift();
  if (callback) {
    QUORUS.use.apply(QUORUS, callback);
  }
}

// Start processing the queue:
processAPICall();

The bootstrap file is, by this point, mostly immutable: it’s something we hand off to a customer, who might require a month or more to deploy any new version we gave them—an impossibly long time for an agile startup company. The stage2 file, meanwhile, is small, loads from our own servers, and has a short cache lifetime. This ensures that no end user will have an old version for more than a few minutes. Nearly all the other resources we need are in permanently cacheable JavaScript libraries and CSS files.

When we release a new version of our code, stage2 automatically directs browsers to start downloading from a new location, ensuring that they use only the newest code. This setup allows us to deploy changes quickly without serving up assets more often than necessary. Not only does this keep our bandwidth costs low, but it provides a better user experience: the cached resources load very quickly while the page is loading.

If we were starting our codebase today, with the benefit of the YUI Gallery, there are a number of components we might use to make our lives easier. One of them is Eric Ferraiuolo’s Base Component Manager, which assists with wiring up components (typically Widgets) on demand. Another might be Storage Lite, to help us retain application state across page loads.

Many thanks to the YUI team for their great work, and to the community for their contributions. If you would like to read about our approaches to sandboxing or to coordinating asynchronously loaded components, please let me know in the comments!

About the author: Peter Abrahamsen writes Ruby and JavaScript, manages server infrastructure, and studies user-centered design in Seattle, Washington, USA. He can be found on IRC as Rainhead.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

Bringing YUI Theater to Internet TVs

I wanted to post a quick update on a few YUI related projects I’ve been working on with a friend of mine, Ozgur Cem Sen (@ozgurcemsen). Eric posted a few months ago about our efforts to bring YUI Theater to Boxee. We just finished reworking the UI for Boxee and added some new features such as browsing by tags and search. We are currently working with the Boxee team to get the app added into the new Boxee Box repository. That is in addition to the standard repository they have for the desktop version. The Boxee Box repository has some stricter requirements around performance and video quality. The new versions should hopefully be out within the next week or so.

While finishing up the Boxee app we stumbled on the Samsung TV platform and the timing was perfect because they are actually running a “Free the TV” challenge. We came across the contest pretty late in the game and nearly missed the submission deadline, but we pushed hard and successfully recreated the same experience for Samsung in short order. If you have a few minutes please vote/help spread the word about our YUI Theater submission for Samsung – http://www.freethetvchallenge.com/submissions/249. We’ve got 50+ other entries to beat.

Last, but not least — we also just recently completed work on a YUI Theater app for Plex. It isn’t in the official application repository yet, but the request is in. In the meantime you can download it from here if you’d like — http://wiki.plexapp.com/index.php/YahooYUITheater.

Here are a few videos of the applications in action:

• Samsung TV app – http://www.youtube.com/watch?v=e1kRicivfDU
• Plex app – http://www.youtube.com/watch?v=oxBPqVQqdnY
• Boxee app – http://www.youtube.com/watch?v=IK4i1DksuhU

You should expect to see similar efforts for Google TV and Yahoo! Connected TV in the not so distant future as well.

Hopefully these apps prove to be valuable resources for those that can’t typically attend the meetups and/or didn’t make the latest YUIConf. We’ll continue to add new videos as they are released.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

jQuery and YUI 3: A Tale of Two JavaScript Libraries

Recently I had the opportunity to build my first JavaScript front end application. What follows is a short story of the discovery and evolution that comes about when trying to use tools that aren’t suited for the job at hand. It is an account of the learning acquired through developing the same front end application using two very different libraries, jQuery and YUI 3. Details of the client and the project have been intentionally omitted.

Overview

The project involved the refactoring of several disparate Flash tools into a single interactive application based on open standards for a large content publisher. Of high importance, the application had to be highly optimised with a small initial foot print due the large number of daily page impressions the client receives. Several phases were involved, with the first being an initial proof of concept.

The concept involved the development of one view of what would be the completed application. It consisted of:

• An initial seed file (< 1KB) responsible for the dynamic loading of any frameworks (e.g., jQuery or YUI 3) and the initial application file.
• The development and inclusion of jQuery plugins to support form element styling and validation, and dynamic chart visualisations.
• The generation and population of UI, based on user inputs, configuration defaults and the application’s location within the publisher’s site.
• The calculation and presentation of information based on the user’s input.

In the interest of full disclosure, my own experience up to this point had been in developing small, standalone solutions, the type of which you could typically describe as plugins. These included dynamic UI components such as image carousels, interactive maps and Twitter / Flickr widgets. At the time of first dabbling with JavaScript, jQuery was popular, easy to learn and allowed me to quickly pick up the basics needed for the projects I was working on. However these were all standalone units and had no need to interact with other code or as part of a larger application.

First Attempt

On completing the first phase of the project, it became painfully obvious that I was dealing with a very different beast than what I was used to. Having had little experience in code organisation, my code quickly became disorganised, inefficient and repetitive. As a result, the first part of what would become a much larger application was slow to load. In fact it took eight seconds to generate that single proof of concept. A big change was needed and while I had considered using a small library like Dean Edward’s Base or John Resig’s Simple JavaScript Inheritance pattern to add class-based inheritance to jQuery, I decided to go one step further.

What I wanted was a complete, mature framework within which to develop my first OO application. Something that would effectively guide me through the process. In reviewing the available libraries I decided to adopt YUI 3 for the following reasons:

• Integrated, inheritance-based application development support including attribute and class management.
• Long term solution:
  • Support for standards and accessibility.
  • Funded by a large well known organisation, Yahoo!
  • Associated with respected names like Douglas Crockford, Nicholas Zakas, and Stoyan Stefanov.
• Performance optimisation:
  • Initial seed file of only 7KB.
  • Lazy-loaded modules on demand.
  • CDN delivery.
• Varied and comprehensive documentation:
  • Yahoo! Developer Network
  • YUI 3 API Documentation
  • YUI Theater
  • YUI Library
  • YUI Blog
• Mature, consistent evolution between releases.
• Integrated tools in YUI Compressor, YUIDoc, YUI Builder, and Console.
• Not just JavaScript, a CSS framework too.

Take Two

Integrating YUI 3 brought several direct and indirect benefits to the project:

• Inheritance-based architecture and class management through the Attribute interface, and Base and Widget classes producing performant, reusable and organised code.
• Separation of presentation from model and data using the Widget class to render alternate views (inline or overlay) based on the application’s location within the site.
• Sandboxing and dynamic module inclusion through YUI.use().
• Cross-browser console debugging using YUI Console.
• On save, performance optimisation using YUI Compressor in Eclipse.
• Easy inclusion and integration of pre-existing jQuery plugins.
• On save, automated code documentation using YUIDoc.

The final result was a happy client and a finished product with sub-second load times (remembering it took 8 seconds to load the initial proof of concept).

Lessons Learned

Select the right tool for the job

In reading this post I’m sure some readers will view this as anti-jQuery. Not at all. jQuery is a fantastic project responsible for many innovations. But, as with any tool, it has its strengths and an intended purpose. Its strength lies in normalising browser inconsistencies, lowering the barrier to entry for the novice and improving the efficiency of experienced programmers. The primary learning that came out of the project was that you can’t rely on one tool for every job. YUI builds on what jQuery can provide by also offering a well architected application framework. But it’s fair to say that it comes at a cost, see the next point.

Steep learning curve

You need patience, especially when writing your very first application with an unfamiliar library as I did. However the payoff is immense. By learning another library, not only will your core JavaScript skills improve, you’ll also develop a deeper understanding of how libraries work and the benefits they bring. I try to learn something new about YUI everyday and the more I learn, the more I’m in awe of the thought and sheer talent that’s gone into building YUI.

Only load content when you need it

While it’s certainly programmatically easier to just to load everything you may need upfront, the performance improvements gained as a direct result of lazy loading content only when you need it is huge. This was one of the key contributing factors for drastically improving the performance of the application.

Interact with the DOM as little as possible

This point doesn’t relate to the specific library used. By caching the required DOM elements and utilising HTML templates more, UI rendering time fell considerably. Nodes can be cached using Y.one() while node lists can be captured using Y.all(). Also Y.Node.create() was very useful in efficiently converting large text strings of HTML to DOM elements prior to insertion.

Learn by example, use a CDN

In using YUI’s CDN delivered library we decided to deliver all the project’s assets via CDN. This was probably the next largest contributing factor to the performance improvement.

Pub, sub hubbub

For those experienced programmers out there, try not to laugh at this one. Having been used to writing little more than plugins in the past, I had no idea how applications should communicate internally. Even after reading “Custom Events allow you to publish the interesting moments or events in your own code so that other components on the page can subscribe to those events and respond to them,” I still missed it.

As it turns out, YUI’s custom event publish-and-subscribe model works beautifully for inter-class and inter-object communication. You can even subscribe pre and post to events and include dynamic logic to suppress bubbling based on certain conditions.

Integrate best practice into your workflow

Using Eclipse we were able to integrate JSLint and YUI Compressor into the build process. Put simply, every time you hit Ctrl / Cmd + S your JavaScript code is validated and optimised. That means you’re testing against optimised, production grade code from the very first line of code. It also means that you won’t forget to optimise in the frantic final race to the delivery deadline.

Learning YUI on the Job

Although everyone has a different learning style, I thought I’d share what resources I used to learn YUI with a specific objective in mind.

• Watch the relevant YUI Theater episodes to get a general overview of the library or learn a specific module. I can highly recommend starting with:
  • Eric Miraglia’s Welcome to YUI 3
  • Todd Kloots on YUI 3 Sugar
  • Matt Sweeney’s YUI 3 Performance
  • Luke Smith’s Debugging in YUI 3
  • Isaac Schlueter on Solving Problems with YUI 3
  • Eric Ferraiuolo on Web App Development with YUI 3
  • Luke Smith’s Events Evolved
• Read up on YUI on the Yahoo! Developer Network. I try to read a little bit every week and learn more each time I re-read it.
• Read the API documentation. If you can’t find it on YUI Theater or on the Developer Network, dig into the API. It even pays to read the code directly.
• Read and post questions to the forum on YUILibrary.com.
• Play a lot and have fun!

Conclusion

YUI 3 is a full-featured, mature and constantly evolving library suitable for small to large projects. As front end web applications become more complex, the need for libraries like YUI will grow. While for the uninitiated it can be a daunting experience at first, if you stick with it you will be rewarded.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!

Building TipTheWeb with YUI 3

About the Author: Eric Ferraiuolo is a Director of TipTheWeb and Co-Founder of Oddnut Software. He writes on his blog: 925 HTML, and can be found on Twitter: @ericf. Eric was a featured presenter at YUIConf 2009.

TipTheWeb is a new service that lets people directly support their favorite web content by tipping it. For instance, if you find a great blog post, you could tip it 25 cents.

TipTheWeb is a non-profit organization promoting freely-accessible, high-quality web content by awarding publishers that receive tips. If you publish online, you can use your TipTheWeb account to claim the places you publish to receive tips and be eligible to receive awards from TipTheWeb.

TipTheWeb’s Use of YUI 3

The user interface of TipTheWeb is completely built on top of YUI 3 (we drank the Kool-Aid.) The approach we took was to use YUI 3 as the foundation and structure for our JavaScript code. We’ve built 33 custom YUI 3 modules (56 if you include submodules, plugins, and roll-ups), several of which we contributed the YUI 3 Gallery: Component Manager, Markout, Overlay Extras, and REST Resource.

Page-Level Classes

The core features of TipTheWeb are implemented on a few highly-functional web pages which communicate with the server over Ajax. For each of these pages we created a custom YUI 3 module that exposes a page-level class used to coordinate actions between the functional parts of the page.

In one of our application’s main pages, the Tips page, you can see how this approach is applied with the page-level class TipsWindow. The main functional parts of the page are the widgets: CreateTip used for creating tips, and the TipList widgets for editing, canceling, and funding existing tips.

A Lot of Overlays

We use Y.Overlays extensively throughout our application’s UI to implement user-interactions; this allows us to keep the interface clutter-free while still having the functionality for advanced features available on the page. We needed features that were not built into Y.Overlay, so we developed Overlay Extras, which is in the YUI 3 Gallery and being used by a lot of other YUI 3 powered sites. Here are some place where we use Overlays on TipTheWeb:

Current State of TipTheWeb

We’d love for you to try out TipTheWeb; right now we are in invite-only beta, so request an invite on our site and we’ll send you an invite code.

Be sure to catch our talk at YUIConf 2010 where we will be presenting (more in depth) on how we use YUI 3 and YQL at TipTheWeb.

Find conversations: bloglines | technorati

Share and extend: Bookmark with del.icio.us | digg it! | reddit!