Alex Russell – “Google Chrome Frame”
Post: http://alex.dojotoolkit.org/
Slides: http://alex.dojotoolkit.org/10/jsconf/gcf.html

Francisco Tolmasky – “Socratic: Documentation Done Right”
GitHub: http://github.com/tolmasky/socratic
Slides: ?

Aaron Newton – “Programming To Patterns”
Slides: http://www.slideshare.net/guest2ee5e2c/programming-to-patterns-presentation (not up-to-date)

Jed Schmidt – “A (fab) approach to web apps”
GitHub: http://github.com/jed/fab
Slides: http://www.flickr.com/photos/tr4nslator/sets/72157623883700702/show/

Dmitry Baranovskiy – “Raphaël the Great”
Slides: http://www.slideshare.net/Dmitry.Baranovskiy/raphal-js-conf

Douglas Crockford – “Really, JavaScript?”
?

Tobias Schneider – “Flash is dead, long live Flash!”
GitHub: http://github.com/tobeytailor/gordon
Slides: http://www.slideshare.net/ConfEcho/flash-is-dead-long-live-flash

Makinde Adeagbo – “Primer: Facebook’s 2k of JavaScript to power (almost) all interactions”
Slides: http://www.slideshare.net/makinde/javascript-primer

Steve Souders – “The Best of Steve”
Slides: http://www.slideshare.net/souders/jsconf-us-2010

Jenn Lukas – “JavaScript and Web Standards Sitting in a Tree”
Slides: http://www.slideshare.net/JennLukas/javascript-and-web-standards-sitting-in-a-tree

Ryan Dahl – “Less is More in Node.js”
Slides: http://nodejs.org/jsconf2010.pdf

Billy Hoffman – “JavaScript’s Evil Side”
Slides: ?

John David Dalton – “All you can leet”
Slides: http://www.slideshare.net/johndaviddalton/jsconf-all-you-can-leet

Aaron Quint – “Making Bacon / Making Code”
GitHub: http://github.com/quirkey/sammy
Post: http://www.quirkey.com/blog/2010/04/20/making-baconmaking-code-jsconf-2010/
Slides: http://swinger.quirkey.com/#/preso/aq-jsconf/display/1
Video: http://bit.ly/9j7u3L

Dion Almaer, Ben Galbraith, and Matt McNulty – “The mobile web”
Slides: http://www.slideshare.net/dion/the-mobile-web-2010-jsconf

After a couple of months I’ve been watching the progress on the WebSocket protocol, which gives JavaScript developers full-duplex communications channels in the browser. This is a very exciting alternative to the COMET techniques we’re used to seeing.

Node.JS is a framework for networked, event-driven applications, where JavaScript has a natural fit. This particular implementation is built on top of the excellent V8 engine.

Running the server is as simple as:

$ node runserver.js

Logging (in the Redis storage, an excellent persistent key-value storage mechanism which will be subject of another post) will begin.
Writing a client is equally easy:

var a = new WebSocket();
a.onmessage = function(event){
   console.log(event.data);
};

As you might know or induce already, the wonder of WebSocket is only available to a few selected browsers. To my knowledge only nightly Webkit, Chromium, trunk Firefox (and possibly Opera) have a decent degree of support of WebSocket.

The bigger goal of this project is to provide an API that allows fallback on techniques such as XHR streaming, long-polling, forever iframe (+htmlfile), for cross-browser support and rapid development. Writing the server side modules for node.websocket.js is really pretty easy thanks to the excellent modules API Node.JS provides. And a bunch of projects that allow you to plug in Node.JS to a variety of data sources are already available.

Alexander Teinum also has a very minimal implementation meant for local use, with which he’s empowering tools of the impressive BrevityOS project. Other implementations include Jetty’s and Kaazing, both worth keeping an eye on.

At this point there’s no doubt in anyone’s mind that DRY is a principle we should stick to. However, let’s examine how to achieve this in the right way.

Natives extension

A script, no matter its purpose, deals with various native objects all the time. These may be native types, such as Strings, Arrays, Objects, Numbers, or objects that are not native to the language but are to the browser rendering engine, such as HTMLElement.

MooTools, as you already know, empowers us to extend these Natives really easily. To add a repeat() method to a String, this is all it takes:

String.implement({
	repeat: function(times){
		return new Array(times + 1).join(this);
	}
});

This is one of the pillars of code reusability within MooTools code. But, as I’ll explain later, it can be misused.

Self-invoking functions

Probably the most natural and straightforward way of avoiding code repetition is defining a function. The code above could have been written as:

function repeat(str, times){
	return new Array(times +1).join(str);
}

A downside of the snippet above is the pollution of the global namespace. The function repeat would be available to all your scripts within the window you execute it in, potentially colliding with other functions. Or making it harder to maintain when another programmer comes along and writes another repeat function, which may even do something different.

That’s when self-invoking functions come to the rescue. As you already know, the local variables defined within a function are only available to that context. If you decide to use functions instead of extending a native, this is the smart way to do it:

// we wrap our code in a self-invoking function
(function(){

   // local function within this context
   var repeat(str,times) = function(){
   	// ...
   });

   // notice we don't use var here, we want the Car class to be globally available
   Car = new Class({

      run: function() {
          var a = repeat('test', 20);
      }

   });

   ConvertibleCar = new Class({

      Extends: Car,

      display: function() {
          var b = repeat('some string', 20);
      }

   });

})();

// the repeat() we defined before is no longer accessible here

When to use which method

First of all, you might be wondering why you’d go through the trouble of defining a function within a sub-context if you could have extended String in the first place. That’s valid reasoning, but only because of the nature of the example.

If you’ve been writing MooTools code for a long time, maybe sometimes you found yourself polluting your own Natives, by extending them with functions that added little reusability value. An example:

Element.implement({

	doSomethingSoSpecificThatIevenFindItHardToName: function(){
        	// ...
	}

});

Sometimes extending the natives just doesn’t feel right, specially if it’s for a logic you repeat several times but only within a class or subset of classes, and it doesn’t award a public method within your class. That’s when a function wrapped in a self-invoking function described above is best suited.

To finalize, let’s see a real-world example that contrasts these two approaches, taken from the MooTools Core.

(function(){

var walk = function(element, walk, start, match, all, nocash){
	// internal dom walking logic
};

Element.implement({

	getPrevious: function(match, nocash){
		return walk(this, 'previousSibling', null, match, false, nocash);
	},

	getAllPrevious: function(match, nocash){
		return walk(this, 'previousSibling', null, match, true, nocash);
	},

	getNext: function(match, nocash){
		return walk(this, 'nextSibling', null, match, false, nocash);
	},

	getAllNext: function(match, nocash){
		return walk(this, 'nextSibling', null, match, true, nocash);
	},

	getFirst: function(match, nocash){
		return walk(this, 'nextSibling', 'firstChild', match, false, nocash);
	},

        // ...

});

})();

As you can see, it extends Element with methods that you reuse a lot, and that even MooTools utilizes in its other components. However, there’s no point in making the walk function available to the rest of the Core, let alone your scripts, since it’s used in a very specific part which deals with the DOM manipulation. Its only purpose is avoiding code repetition in the several methods it implements to Element.

An example of my implementation is seen on the Devthought sidebar, right next to this post. I’ll analyze next the different solutions that have been offered for this problem, and the upsides and downsides each has.

Solution #1: background-image

Upon the focus and blur events of the input, a background with the placeholder text is toggled.

Advantages

• The placeholder text is never submitted with the form

Disadvantages

• A change in the text, font, style or size means re-exporting the image
• The font rendering of the image and the actual text the user type will likely differ
• It becomes harder to support internationalization

Solution #2: overlapped element

A label or span element is positioned on top of the input. When the element is clicked, or the element is given focus, it disappears and the user can type normally.

Advantages

• The placeholder text is never submitted with the form
• Easy to change or translate the placeholder value, just by altering the markup

Disadvantages

• It’s very hard to position the text perfectly, in a cross browser fashion. Inputs should be padding less and border less to calculate the position perfectly, and styling becomes a problem.

I’ve seen this method in the new Yahoo! Mail interface search input. I tested with a couple of browsers and some displayed the text with a considerable offset, which depicts the aforementioned disadvantage.

Solution #3: altering the value

This is the most common solution, and in my opinion, the easiest to maintain and deal with its shortcomings.

Advantages

• The text will be rendered in the same position and style as the typed text
• Easy to change or translate the placeholder value, just by altering the markup

Disadvantages

• Unless you check the form before it’s submitted, the placeholder value will be sent. This is not a major issue with frameworks, because you can override the methods used to access values (like my solution)

The markup

The most straightforward way to implement solution #3 would be adding a placeholder attribute to the input like this:

This certainly won’t validate, but you can always extend your Doctype. The inputs would be easily retrieved with a CSS selector by Javascript (input[placeholder]).

Another more accessible approach would be to transform labels into placeholders. Thus:

Your email

with some Javascript becomes

// we remove the label from the dom, or set it to display=none

and then the placeholder behavior is added normally.

MooTools implementation

Please head to the project page to see this in action.

I came up with a document describing the projections, possibilities and capabilities of my creation, which you can access here. It includes different scenarios and variations of this implementation.

Go to the project page for download and other useful links.

Let’s revise some of the most remarkable scenarios.

Uploading

One of the most common Flash and Javascript interaction is probably file uploading in forms. There’s almost no way to customize the input style in a cross browser fashion. Firefox, for instance, makes it impossible (for security reasons) to trigger the upload file selection unless the user clicks the Browse button. Among many other limitations.

But Flash comes to the rescue, with some really stunning implementations. It’s worth mentioning open source implementations like Fancy Upload (MooTools), jqUploader (jQuery) and SWFUpload. Flickr’s new upload also takes advantege of this method.

Clipboard access

In most popular browsers, Javascript is not allowed to interact directly with the clipboard. The exception is the infamously insecure Internet Explorer 6:

Flash, however, allows developers to freely copy the text to the clipboard. Jeffrey Larson came up with the solution using a really small swf file from his Javascript code.

The code was further improved to support Opera, which results in complete browsers compliance. There is a MooTools implementation by Aaron Newton, and a Prototype one.

Photo editing / Drawing

Another area where Javascript is still not quite ready for is photo editing. Flash proves reliable for such a task, and it’s what is commonly used right now, while Javascript is being left behind.

Here is a quick example of Flash outputting SVG, and here is a full featured (but not freely available) image editor, Picnik, that really shows how suitable Flash is for this.

The main reason Javacript falls short here is its limitation to come up with most effects, which is the reason js-based editors will do that server-side, adding a delay and thus hurting the user experience.

Some cool effects can be achieved in Javascript alone thanks to the canvas tag. But we’re still far from close to full-featured image editing.

Sound

The only sure way to play a sound file in a crossbrowser, crossplatform way is nowadays Flash.

There’s a solution available for most frameworks: MooSound, GWT-Voices, jquery.sound. The most popular standalone ones are SoundManager 2 and JSSoundKit.

Persistent Data Storage

There might be certain scenarios where you’ll want to store large chunk of data in the client side (it could be for caching purposes, or for offline retrieval, for example. Flash is one of the most reliable ways, allowing you to store up to 100k seamlessly, and even more if the user authorizes it when prompted.

See dojo.storage for a nice implementation and proof-of-concept

Note: i’m currently working on a MooTools implementation of this.

Some scenarios where flash might be involved

Ajax: see the fjax project

Charts: see the YUI.charts project (and see flot for a sweet jQuery approach!)