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.

Thanks!

Buy me a coffee to sponsor more cool posts like this!

My tags:
 
Popular tags: