The Ajax revolution saw a sea change in web application development. By taking advantage of long-dormant browser capabilities, we were able to take our craft to new levels with HTML5--reinventing well-established genres, challenging desktop applications, and jump-starting a renaissance in web start-ups. The new frontier of application development is mobile and devices. How will the industry handle the massive fragmentation that we are now experiencing? Most devices require proprietary SDKs and porting between them is expensive. This is where the mobile Web comes in. Together we can make it a unified solution that lets you take your experiences cross device using the platform that you know and love. In this session, we will explore how you can take Web skills to mobile right now, and we will share tips, techniques, and exciting tools that will help you get there.

Steve definitely won the contest of most submissions to JSConf and so we made him a deal. You can present BUT you have to do all of them in a single time slot. Consider it the Best of Steve. Example topics include:

• Ads, widgets, and analytics - Oh my!
• Make My Mobile Fast
• Even Faster Web Sites
• Even more craziness

What if new browser features were usable in months instead of years? What apps would we build if V8-level performance were ubiquitous?This talk discusses the role of Google Chrome Frame in breaking the logjam of browser progress, quickly shows how simple it is to implement GCF for your sites and applications, describes how GCF will let us all write less JavaScript, and ends with a quick overview of the HTML 5 and JavaScript features available today to sites that are opting into GCF.

Implementing a design pattern in JavaScript isn't very difficult - image galleries, tabbed boxes, date pickers, etc are relatively straight forward. But it's also very tempting to just select some elements out of the document and enhance them as part of your web site's basic functionality and to not think of these things in a structural way. Architecting nearly everything you author into reusable objects that can be extended and reused presents a lot of benefits. Breaking up components into smaller reusable chunks lets you develop some small bit of functionality (like, say, dragging) for one task, then reuse it later. The speakers will each tackle the same problem with code examples in MooTools and Dojo to illustrate the concept.

At 280 North we've been developing a new documentation tool built on top of Common JS to help new JS projects quickly overcome the initial hump of being documentation deprived. Unlike most documentation tools, the act of documenting is completely divorced from the source code, allowing the creation of media-rich docs with a wiki-style workflow, while maintaining versionability and tracking the changes that take place on the branches of your source. Additionally, this tool uses git and textmate as its core, so we will be announcing some cool new JS wrappers for accessing both of these powerful tools.

I would like to talk dirty : ). More precisely I am going to talk about a little key-value store of mine called dirty. Dirty is a love child between Redis and CouchDB. The result is a very fast (750K doc writes / sec, 14M docs filtered / sec), node.js-based NoSQL store written in < 250 LoC. Admittedly dirty is a quite a cheater to make those numbers possible. That's because dirty does not do any networking. But that is by design. I think that sending trivial questions like "What value does key x have?" over a network is rather stupid. Instead one should ask a db questions like "How many pirates does it take to send out all available ships?". Dirty makes it really easy to build special-purpose databases like this and give them a REST interface using the underlaying powers of node.js. This makes dirty an excellent choice for:

• Rapid prototyping
• Small databases (dirty stores all docs in memory, you need to partition in order to expand storage)
• Databases where speed is one of the most critical factors
I'm currently hacking away over here: http://github.com/felixge/node-dirty

If you think Flash is the only choice for cross-browser graphics on the web, think again. In this session I will introduce you to Raphaël, a JavaScript library for vector graphics, and walk you through its API. We will discover what possibilities for web applications it opens and what limitations still exist.

First misunderstanding, then huge semipopularity, and now, respect. Despite its many obvious deficiencies, JavaScript has gotten something profoundly right. What does the future hold for this duckling?

Let me introduce you Gordon, an open source Flash runtime written in pure JavaScript. This talk will give you a deep insight into the inconvenient technics and ambitions behind the project, the progress it has made in the last months and the limitations of current web technologies - if there are ones - in realizing a fully compatible Flash alternative in HTML5. Maybe this will push the whole HTML5 vs. Flash discussion to a new level, but will certainly enrich it with practical experience.

Despite having access to advanced JavaScript frameworks, many web developers continue to write very similar boilerplate code to setup AJAX interactions. Facebook, in particular, peaked at nearly one megabyte of JavaScript on its homepage. The team then realized that 90% of our interactions could be boiled down into a very small set of steps: (1) User clicks on a link or submits a form, (2) an AJAX request is sent to the server, (3) some markup is put into the DOM. By framing all interactions in this manner, we have been able to put a small snippet of JavaScript, Primer, at the top of all pages that can listen and wire up these interactions. Built atop plain links and forms, we have created a simple, fast, accessible way to implement most interactions on our site. The talk will include a breakdown of the various Javascript techniques (event handlers, asynchronous loading of JavaScript files, etc.), server side integration, metrics gathering, and future work to build our AJAX pageload systems on top of Primer.

The growth and innovation around JavaScript recently is intense. The features of the language are expanding almost as quickly as the new places it appears. However there are several fundamental flaws with JavaScript and some core web technologies that allow for some serious evil. Function and constructor hijacking, cross domain spoofing, web history theft, search history theft, porting scanning and fingerprinting intranets, deanonymization, self propagating code, self mutating code, and detecting sandboxed environments are just a some of the threats that can be done now. They cannot be fixed, they are now built into the web, and their impact grows critical as we move from web pages in a single domain to mashups and interactive applications. This talk will demonstrate some truly evil tricks and help todays JavaScript ninjas advance JavaScript while keeping it safe and secure.

Overview and examples of how to rock progressive enhancement without sacrificing functionality or alienating your users. I will be showing examples of neat functional implementations that we made at Happy Cog, that also work well without JS enabled. They also double as examples in which we opted to use JS for the effect instead of Flash. In this crazy internetz world of web apps and pushing the tech to the exxtremez limits, often website makers overlook proper implementation of the behavior layer and lose accessibility and ignore user needs.

Node is a program for scripting 'server-side' event-loops. It has exploded in popularity since Ryan gave an introduction to it at JSConf EU 2009, with many programmers now attempting to use it in real-world projects. But as many have quickly learned, there is a world of difference between a cute idea and a mainstream development platform. In this presentation, Ryan will discuss how the Node team is carefully fixing and building out the software; what false steps were taken, how the goal is being modified slightly, and how sitting on top of one of the most advanced virtual machines eases the struggle considerably.

Coding for performance by utilizing feature testing, method forking, lazy method defining, and avoiding unnecessary abstraction. The second topic discussed is what I look for in a CSS selector engine. Engines should be chosen based on how they maintain consistent results across browsers, follow specification, and support the browsers required by your project. The third topic discussed is the who/what/when/where of sandboxed natives. I will explain the history, process of creating, and the advantages of using sandboxed natives.

With all the talk and hype over server side platforms and technologies, somehow we've been neglecting the most ubiquitous and widely used javascript platform - the browser. Differences aside, the web browser and the desktop are becoming more and more entwined and just generally faster. Now is our chance to make web applications that surpass the usefulness and awesomeness of desktop counterparts. Sure, there are technologies that allow you to bring desktop style code to the web. With Sammy.js, I'm more interested in creating web style apps that can compete as desktop experiences. Sammy.js is a very simple framework for organizing browser based javascript applications. Despite its size, when combined with other cutting edge technologies, (CouchDB, other RESTful DB's, Comet) it becomes a very powerful way to write entirely front-end, entirely JavaScript applications. I'll walk through the basics of Sammy, show some cool examples of Sammy in production, and talk about new features and technologies that make this all a pretty exciting time to be writing JS.