YUI Theater — Dav Glass: “Using Node.js and YUI 3″ (36 min.)

By YUI TeamSeptember 29th, 2010

Dav Glass speaks about YUI 3 and Node.js at Yahoo on September 16, 2010.

Ryan Dahl’s work on Node.js — and the community forming around that project — has joined HTML5 as one of the big stories of 2010. YUI engineer Dav Glass has been working to make YUI 3 a powerful ally for Node.js implementers, and in this video he shows you what he’s done so far — including demos of progressively enhanced widgets running the same code on client and server. Don’t miss this one.

If the video embed below doesn’t show up correctly in your RSS reader, click through to watch or download the high-resolution version of the video on YUI Theater.

Other Recent YUI Theater Videos:

  • Alois Reitbauer: dynaTrace Ajax Edition — dynaTrace provides one of the most powerful tools for analyzing the performance of web applications in Internet Explorer. In this talk, dynaTrace engineer Alois Reitbauer walks through four specific analytic scenarios using the dynaTrace interface.
  • Ryan Grove: Achieving Performance Zen with YUI 3 — Following codified guidelines can help you build fast websites, but building applications that are clean, fast and extensible also involves taking a balanced approach to performance at every level of your F2E work. YUI 3 is designed to help you in this process, providing a right-sized abstraction layer with built-in performance magic and a variety of tools that make fast frontend code easy and fun to produce. In this session, we’ll explore the zen of performant JavaScript in the YUI 3 world and introduce you to some of the powerful tools YUI 3 puts at your disposal in every app you write.
  • Douglas Crockford: Crockford on JavaScript — Scene 6: Loopage — Software development is hampered by a specific set of design mistakes that were made in the first programming languages and repeated in everything that has been done since. And, somewhat miraculously, JavaScript is going to make it right, radically transforming the way we write applications. Again. In the Loop of History, it has all happened before, but it has never happened like this. This is why you should care about the emergence of server-side JavaScript and the excitement around projects like Node.js – not because they’re at the sharp end of a trend, but because they’re paving the road toward the next big revolution in software.

Subscribing to YUI Theater:

Tagged as:


  1. Here is a link to the code on github

  2. Jeffrey Gilbert said:
    September 30, 2010 at 1:40 pm

    cool demo. cookies should be small, though. i wouldn’t be pumping nav data into them where url params should be. I want to know how node.js works for all the things that ARENT obvious.

    local file access
    image manipulation
    database connection handling over common sql servers
    header manipulation
    pdf generation

    ya know, that sort of stuff. it’s not the meat and potatoes of a language, but it’s key to actually using this at some point

  3. Jeffrey —

    The nice thing about NodeJs is that none of that is *built in* to the system. Almost everything in the system is an external module:


  4. Jeffrey Gilbert said:
    September 30, 2010 at 1:57 pm

    Dav, thanks for the quick follow up. I do love the idea of the dom traversal on the server side (huge! like hpricot huge), json as the transport language, javascript on the client side, and a key/value storage engine for the db. One language to rule them all? and it’s event based from the start? massive potential.

  5. Yes, I totally agree. Hence my excitement in the video ;)

  6. Christopher Cliff said:
    October 3, 2010 at 2:47 am

    Was curious what your thoughts were on the accessibility and SEO implications of this approach. For example, the convention now is to load a page with semantic, meaningful markup, then load and execute a script that will manipulate the meaningful markup into non-semantic, functional markup for the sake of the UX.

    Using the approach you’ve described here, you’ve essentially loaded the page with the functional markup and skipped the semantic part completely.

    While I think this is great for user experience and DRY development, it will result in pages that are less accessible.

  7. Dav, Wondered if you have given any thought to using YUI on other SSJS platforms, namely rhino. I am working on a Java app that already has Rhino.

    How much of what you have done applies to Node specifically versus SSJS?

  8. @Andy —

    Yes, I have thought about it and it wouldn’t be that tough to do. With YUI3 being module based, we would simply have to “remap” the modules under the hood to point to different libs for things like loading, IO and DOM manipulation.

    I haven’t messed with other SSJS tools, because I primarily use Node.JS for the things that I work on ;)

  9. Dav,

    Just watched you second YUI3 on node.js video. It was clear during that session that you modified get and io.

    I am going to look at your proejct on github for those changes to get and io and see if similar things can be done for Rhino. If so, then I can post back with those changes to a github project for YUI3 on Rhino.

    btw, while investigating this the Rhino environment has a project env.js that has the features of jsdom in Rhino, so I think we are further along there.

    Will let you know…..

    As you are aware, the sign of success is when something gets ported over to other platforms not originally intended.

    btw, has any of this SSJS discussion forced YUI to consider differing directions for 3.x or 4.x and beyond? just curious.

  10. @Andy — I would welcome the port and be willing to help in any way possible.

    The modifications to the YUI modules are under the lib directory and are pretty easy to modify. The JSDom binding is done in the same manner as the others, so it’s just a module that get’s loaded to prep the DOM under the hood.

    Yes, there are some aspects of SSJS that has played a role in some key changes to the architecture behind YUI3. In general, we are looking into our Widget infrastructure to make it work even better on the server. Things like, splitting widgets fully into a render, sync, bind modal. So that render is the only code that needs to be done on the server and sync,bind the only parts delivered to the client.

  11. Using the approach you’ve described here, you’ve essentially loaded the page with the functional markup and skipped the semantic part completely.