2009-Jul-27, 7pm: July 27 Bayjax Meeting at Yahoo

Satyen Desai - YUI 3: Design Goals and Architecture

Why YUI3 when YUI2 is perfect?

• lighter, finer grained, emphasis on code reuse
• easier: each, bind, node list, chainability
• faster

YUI2: global YAHOO object
YUI3: Y = new YUI() - multiple instances coexisting, even from different versions of YUI3. This enables mashups of pieces of code which use different versions of YUI to function properly.

Self-populating

Automatic loading: YUI.use("anim").

script src="yui-min.js">

Under the hood, that loads the dependencies: oop-min.js, js-min.js

Code reuse

YUI2 is the kitchen sink. YUI3 let's you use just the features you need.

• io: All IO functionality (7.4K)
  • io-base - can use independently
  • io-form - can use independently
  • io-queue - can use independently
  • io-upload - can use independently
  • io-xdr - can use independently

Similarly, plugins and extensions are split into standalone, discrete classes. For example, in YUI2, if you wanted to extend Overlay to create a Tooltip class, you'd have to carry over from Overlay: Advanced Positioning, Shim etc.

With YUI3:

Y.Tooltip = Y.Base.build("tooltip", Y.Widget, [
    Widget-Position,
    Widget-Stack
]);

Other features

• Notification flow: event bubbling
• Detaching listeners is much easier

Node facade

A single convenient location to work with HTML elements:

YUI2:

var elms = YAHOO.util.Dom.getElementsByClassName("task", "li", "actions");
for (elm in elms) {
    ...
}

YUI3:

var elm = Y.Node.get(".actions li.task.selected").chained_method();

Bulk node operations

Node list:

var items = Y.Node.all(".actions li").
items.addClass("disabled");
items.set("title", "Item is disabled");

Core language conveniences

• isString
• isNumber
• Bind
• Each
• etc.

Q&A

Q: Was jQuery an inspiration for some features, e.g. chaining?
A: Not specifically, but users' requests for concise code were. We didn't go to the lengths jQuery has gone into, in returning something chainable. If it makes sense for a method to have another type of return value, it'll return that.

More notes on this talk on Erik's blog

Nicole Sulivan: Object Oriented CSS

   ul {...}
   li {...}
ul li {...}

We've focused so far on the code between the braces. OOCSS focuses on the architecture - selectors.

Considerations

• Reflow and rendering are much less important for performance than HTTP request size
• Duplication is much worse than stale rules

Guidelines

Don't repeat the same code in every module

Bad:

#weatherModule h3 {color: red}
#tabs h3 {color: red}

Problems:

• there is no default for h3
• h3 will look different if reused in a different document

Better:

h3 {color: red}
#weatherModule h3 {color: black}
#tabs h3 {color: blue}

Issues:

• ?

Best:

h1, .h1 {...}
h2, .h2 {...}
h3, .h3 {...}

• Global values defined
• Semantics respected

Other guidelines

• Define structure in separate classes
• Style classes rather than elements
  • ...and if there are exceptions, define only the little bits that are different from the default definition
• Avoid styling elements
• Give rules the same strength. Otherwise, you'll constantly fight specificity. For example, all rules for headers should have the same number of selectors:

.MyHeader .hd {...}
.MyHeader2 .h2 {...}

• Avoid specifying location: .sidebar, .header are bad. Use ".mainNav" and ".subNav".
• Avoid overly specific classes.
• Avoid using singletons. If you style with ids, you can only use the id once in any given page. Instead, style with classes.
• Use mixins to avoid repeating code.
• Encapsulation: don't access sub-nodes of an object directly: Bad:

.inner {...}
.tr {...}
.td {...}

Good:

.weatherMod .inner {...}
.weatherMod .tr {...}
.weatherMod .bl {...}

More notes on Erik's blog.

Jonathan Leblanc - Building scalable YQL widgets with JavaScript

Please see the excellent notes on Erik's blog.

Douglas Crockford: The JSON Saga

(below is an approximate quotation of Crockford, as best as I can remember it, and partial to the things that I do remember)

I did not invent JSON. I discovered it, because JSON "existed in nature".

The first use of JSON happened around 2001, to transmit a message between a server in my friend's garage and my laptop:

{do: "test", text: "Hello world"}

It also failed because "do" is a reserved word in EcmaScript 3.

Later, when I wanted to use JSON in the applications I was writing for my customers, they complained they couldn't use JSON because it was not a standard. But it was - it was part of JavaScript, which was a standard (EcmaScript). "No, that's not a standard". So I went ahead and bought JSON.org and made it a standard. Since it would be stupid for a standard to list all the reserved words in JavaScript, I decided to enclose the key in double quotes. I also put up a reference Java implementation of a JSON parser.

Later, I took a break from the Internet business and went into consulting for consumer electronics. So that's how JSON started: a standard in a bottle, thrown onto the Internet.

But people started writing their own parsers, in one language or another. And they asked me to put a link to their implementation on the site. Sure, I could do that. One advantage of the standard being so simple is that it was very easy to write a parser for it. Now JSON has parsers in almost any language you can think of.

I licensed it under the MIT license, which basically says "You can do whatever you want with it, just don't sue me". But since this happened after 9/11, I did my job of fighting evil and added a clause "This software may be used for good but not for evil". Sure enough, I got letters from people who said "But I should have the right to use it for evil! I won't use it until you change your license." Which means that I had done my job - I had stopped the evildoers.

Other people asked me "I'm not sure if this is is good or evil, what should I do?" But the best e-mail came from a company whose name I'm not going to disclose; I'll instead disclose only their initials: IBM.

[roars of laughter]

An IBM staff attorney sent me a letter asking for a special license so that IBM's customers could use JSON for evil. I granted him the following license: "IBM's customers may use this software for evil". Sure enough, I got a letter back saying "Thank you Mr. Crockford".

In the end, business cards were available with the JSON specification fit on the back.

More notes on this talk on Erik's blog.