The news of the past 24 hours is ChromeOS. For the first time in years, someone's re-thinking how an OS should work. With Chrome, you turn on your computer and you're in the browser. What's really interesting is to contrast it to the introduction of the iPhone, where Apple's apps used native APIs while they expected developers to write web apps running in the browser with limited abilities. Here, Google's apps are using the same web platform...it's a level playing field.

Javascript combined with JSONP makes it real easy to write quick and dirty apps. An example of a quick app is Tweetersation Simon wrote with Natalie Downe. Simple app, 200 lines, written in an afternoon. At a larger system level, there's Google Moderator, which is essentially a pure-Javascript solution with a no-op in the noscript tag.

These pure Javascript apps are great for experimenting and prototyping. The problem with this style of development, though, is you're completely breaking web standards. The web Simon "felll in love with" is one where you point to a URL and you get content coming back.

With server-side Javascript, we can get the benefits of the things we like about Javascript, but without throwing away with the things we like about the web. Simon has been playing with node.js, and evidently the results were important enough to throw out the old talk and make this new one.

Take a step back and look at the interaction patterns with a web server. The conventional model is straightforward request-response, where the server tries to respond and disconnect as quickly as possible. But ... there's also the event loop model. As in Comet; it's generally considered to be more efficient, so why do web developers avoid it? Simon says traditional server-side languages aren't designed to deal with event-driven programming. It's more like "do A, do B, do C, exit". Javascript, on the other hand, is well suited to do callback-driven event programming.

Brave Simon now proceeds to live code with node.js. He shows a "Hello World" daemon, where the code looks like Ajax in reverse, and runs extremely fast. But where it gets really interesting - and useful - is with Comet. Another demo. The code is tiny and the benchmark looks good.

Simon's built his own framework on top of node.js: Djangode takes the best features from Django and sticks them on the server.

The more interesting example is Comet, which he's demo'd here.

Moving on to persistence, there's the NOSQL trend of the past 18 months, and he shows how simple it is to write CouchDB queries from node. It's easy to talk to CouchDB from Node.js apps. Redis is another interesting database, which could lead to pages being rendered very quickly, given its performance benchmarks.

Jake's slides and research are online.

Optimise Where it Matters

Jake explains the importance of speeding things up where it really matters.

Doug Crockford has pointed out that in Javascript, bitwise operations aren't close to the hardware, which stands in contrast to other languages. In fact, if you look at it, bitwise operations can still be faster than alternative operations; Jake shows an example where bitwise parsing of hex codes is faster than bitwise. The question is, how much faster? In many cases, such as this example, your energy is better spent on optimising big things.

Avoid eval() Where Possible

Jake says avoid eval() where possible. Thinking about what functions eval, here's a brain teaser: what will the following output?

Wait for it ... the answer is "undefined". Javascript does look ahead and create space for the local variable. So during the running of the function, there's no need to allocate space for the variable and the browser can optimise for that, but if you use "eval", the optimisation goes away. So avoid eval().

Prefer innerHTML to DOM

Jake shows a comparison of innerHTML versus DOM Level 1. In IE, DOM manipulation is much slower, because of the sync process between the two. The differential gets even worse when creating elements. Webkit has optimised sync between HTML and DOM, hence less difference, so it's not as bad, but create example is still slower with DOM. So from a performance perspective, best practice is construct the HTML and use innerHTML.

Selectors

It's educational to look at the implementation of selector libraries. Jake shows a comparison - IE7 is vastly more slow in this case. It doesn't support getElementsByClassName, querySelectorAll, evaluate; and it does support getElementById, but that's not used by sizzle for this query. So getElementsByTagName is all that's left; and if you knew that, and the implications, you could have made the query much faster.

Benchmarking

Pretty simple.

However, timing isn't so accurate, so stick it in a function and run it many times.

Too easy ... so go benchmark and report your findings.

Can We Do ARIA Today?

Yes.

Firefox and IE (he didn't say which version) have really good support for ARIA. And Opera, Chrome, and Safari. Likewise for the screenreaders - JAWS, Windows Eyes, NVDA - also have good support. An the libraries - YUI, Dojo, JQuery-UI - all have good support baked in, one of the benefits of using ARIA is automatic support.

Improving Perception - ARIA and Screenreaders

Websites can have problems in perception when rendered with a screenreader; it's hard to get the big picture about what the words refer to. With ARIA, we can close the gap in perception. This is another example of progressive enhancement - augment the item by adding properties, markup or Javascript if required:

Improving Usability - Keyboard Focus, ARIA, and YUI support

Keyboard access. For some people, it's a necessity, and for others it's still an option or preference (think Vim). To support it, you must be able to tab to the element to get focus, so you should control tabbing with tabindex. A good application of controlling tabbing is, amazingly enough, moving through tabs. Another is modal dialogs; the browser doesn't "know" it's modal, so we have to control focus to make sure it doesn't slip out of the thing that's the only thing users should be able to click on!

Todd shows us just how many steps are required to perform a task in a complex application like Yahoo! mail, using just tabs to navigate through - 19 steps in this example, walking through the toolbar; and even more, when you consider the wider picture of entering the app in the first place. To help with this, he introduces a pattern whereby tabIndexes are updated dynamically to control what comes next, as you move through a toolbar. A negative tabIndex will ensure the element is skipped over.

You can also use the "focus" pseudoclass to ensure focus appearance is consistent for all elements. But, and it's a big one, it's not very well supported; even IE8 doesn't support :focus on <a>, for example. Doing it manually with Javascript has problems, in particular performance. Fortunately, PPK has worked out how to handle focus and blur with event delegation, so that it's much more performant, and the resulting technique is built into YUI3.

Device-independence with markup was also advocated to further improve accessibility:

Improving Discoverability - ARIA

Essentially, this is about "random access" and keyboard shortcuts; jumping straight to areas in this page and activating them. The key ARIA feature here is "landmark roles" to identify particular points on the page. This is still something where users aren't aware of the feature, and Todd points out it's not surprising as most screen reader users are self-taught (just under 75% according to the study he showed). Also, not every user is a geek, and the same applies to screen-reader users.

The Goodies

Here are some of the things we can look forward to. (Having been part of the large crowd who charged the pub across the road at lunch, I was a bit late getting back, so I missed one or two of these.)

Lists

It takes a mental shift to start taking advantage of features like this. "Certain browsers" *cough* don't yet provide these conveniences, but you can take advantage of them straight away. Or another example is the base2 library - use it now and you'll be ready for the time when it's present in all browsers.

Getters and Setters

As our Javascript apps get increasingly bigger and more complex, we need to borrow principles, patterns, and techniques from "real programming". Getters and setters are the kind of thing we'll need more of. More generally, we'll need to be in the mindset that we're building APIs to components, which others might use; not just an individual making a one-off web app. Stuart shows a couple of techniques for getters and setters: (a) manually defined; (b) using

Storage

We can now do global storage - globalStorage works similarly to cookies. "Like cookies turned up to 11".

He notes that like XHR, Microsoft did it a long time ago with userdata.

There is also the possibility of SQL and a consistent database API, somewhat supported today but not yet standardised.

Server-Sent Events

Only in Opera right now.

Great. So Do We, Can We, Use it Now or Later?

You can use these features now if you're in a single-browser environment that supports them: app for one mobile; Air app; intranet app (where you've amazingly got Firefox exlcusively on your intranet); HTA. This isn't the sinful act of coding to weird proprietary APIs; it's coding to browsers that happen to support the technologies of tomorrow, today.

The libraries help us get to the future today, as long as they can support APIs compatibly across all the browsers. But it's all a little difficult when the market leader doesn't play ball. Hopefully, Dean Edwards will continue working on Base2 to plug the gaps, but we still have the problem. Around a year ago, it felt like the anti-IE6 might be at a tipping point, but that's died down a bit, and it's not clear how much longer we'll be held back.

What can you do then with IE6? If a number of major websites really held back and stopped supporting IE6, Stuart reckons corporations would upgrade. Imagine what would happen if Google stopped working on IE6...immediate upgrades. Show of hands indicates perhaps 20% of the audience would agree to mass dropping IE6 on their public sites. In Q&A, Stuart later clarifies he's not really proposing an IE6 shutdown switch, more like a helpful suggestion to upgrade.

Silverlight and Flash. Proprietary, not open. If everyone started using Flash, the future is Adobe's future. Let's make it our future instead - we're building the open web. A call to arms for showing strength in numbers.

Mobile CSS Quirks

So many platforms. Take just WebKit; there's iPhone Safari, Android WebKit, Bolt, Iris, different versions, etc. "If someone says my 'app should work in WebKit', laugh in their face. There are just too many versions of WebKit, so as PPK says it, there really is no "WebKit for mobile".

That said, it's good that things are starting to converge towards WebKit. As for the others: Blackberry browser "is dead" as they'll be switching to WebKit; Mozilla is very late to the game; NetFront "is not very good". Windows Mobile 6.5 is a big improvement on 6.1, and with an improved browser, but it's still IE6 based. ('Nuff said.)

There's also a large legacy share, and if users are used to it already, that may be what they want to keep using.

Landscape versus profile mode is an interesting one for those of us desktop developers whose users don't flip their heads around on a regular basis. NetFront has some very surprising and idiosyncratic ways of dealing with it.

The modes don't stop there. There is also mobile versus desktop mode in some browsers; sometimes users can switch these in some obscure corner of their mobile browser preferences. Again, some surprising things happen in Opera and Android. Perhaps of more concern is the difficulty he had diagnosing the situation at first, when Android was showing three divs of the same width in one mode, and not in the other.

@media to the Rescue

Okay, what can we do about all this? Media queries are extremely useful and fairly well supported in modern mobile browsers.

max-width and min-width have subtle issues which PPK is currently researching, but max-device-width and min-device-width give more reliable results. orientation, aspect-ratio, and dpi (also needs research).

Mobile Javascript

Performance-wise, IE Mobile and Blackberry extremely slow. iPhone is middle ground. The really fast browsers are Opera on Samsung and N97, and S60 on Nokia E71 and N97. The bottom line is take your time with mobile Javascript development; you generally can't expect it to "just work"; you'll have to optimise. Also, don't use iframes - they're major performance hogs.

Mobile Connections

Tempting fate, PPK informs us that if someone in the room starts downloading movies, the network gets slower for the rest of us.

Fortunately, browsers give us events to determine when user is going online and offline. Unfortunately, they're doing it wrong. Only Firefox automatically detects offline; all the others require the user to explicitly say "I'm offline now"!

W3C Widgets

In general mobile development, best practice is to put all the core files on the moble phone, and only download the data. But how can we do that with web apps, where the code comes down with the data? W3C widgets offer a solution. You just create a single HTML page with the CSS, Javascript, and images you need; add an icon and config; zip it up; and deploy. PPK reports it works in practice, and works in a "write once, run many" fashion. There are still problems to be sure, but he says it's the best interoperable solution we have today. But still many outstanding platforms: Blackberry (already talking about it), Nokia Maemo, Palm Pre, Android, and of course, iPhone.

Device APIs

Security risks mean critical device APIs will generally remain off limits to general websites for a while. Widgets have a better model, because they're more self-contained and can be verified, although not perfect either.

Amazing what folks do with div overflows :)

All in a few lines of MooTools-used-JS:

Comparisons: Understanding identity (===) versus equality (==).

Boolean expressions: Understanding how short-circuit logic (if a && b won't eval b if a is false);

Types: Type coercion ("1"+2+3); "falsey" (false, null, 0) versus "truthy"; the importance of using operators like parseInt and instanceof.

Functions: Anonymous functions; self-invoking functions - function() { })() ; using the arguments collection to get all arguments to the current function, important to note it's not a real array with all the array methods, and using arguments to overload arguments.

Objects: Using object literal notation { a:b, c:d } instead of setting up properties individually; equivalence of ben.arms and ben["arms"], and how useful it can be to use the latter in conjunction with a function argument, ie let the caller pass in a variable which will be set; using "in" to check if a property exists (if "arms" in ben).

Inheritance: Using the prototype chain for inheritance from subclass to superclasses up to Object. There are various implementations - e.g. Resig, Edward's Base, Dan Webb; if you understand these implementations, then you understand Javascript. However, Robert's arguing for the native way of doing it - as Doug Crockford says, "I now see my early attempts to support the classical model in Javascript as a mistake".

Global scope: Avoid using global scope where you can. For example, nesting functions. R
obert later points to the Yahoo! module pattern.

Binding this: Using call and apply; these are useful for setting this and also can pass arguments through from the current function to another one without having to manually copy them out.

Sugaring: Adding syntax sugar, e.g. extending String.prototype.

Currying: As illustrated by Doug Crockford's curry implementation.

Chris walks us through the history of javascript. The days of building complex systems with document.write() are over thankfully, though some people still think that's what it's all about. Having annoyed people with all the js bling, Ajax came around and suddenly javascript is seen as a tool for useful stuff. But...a little too much Ajax perhaps? People using it where it didn't need to be and how it shouldn't be used, hence the security fears.

According to a pie chart Chris presents, browser problems are responsible for only 8% of vilnerabilties; the biggest problems are SQL injection and XSS, where the server should be locking down.

Don't judge the language by its implementation. it does have intrinsic issues like global variables, but the right implementation can keep things secure. As well as poor practice, the browsers bear responsibility. And the cool kids - safari and firefox - are the most vulnerable according to this survey. And it gets a lot worse when you start playing with browser extensions.

So do we turn javascript off? No, the experience of google maps etc is just too good. We don't have to learn just by "View Source" anymore. There are plenty of resources out there to learn how to do it and how to do it properly (not just with a magic code-gen tool). Use javascript for the right things, not all things. e.g. Slicker UI, data validation warnings, UI controls not native to HTML, visual effects not native to CSS.

What if you're sharing content from third parties, as the yahoo homepage now allows? Caja is presently the only way to do sandboxing in the browser. It doesn't output pretty code right now, but it does cut out many risks. Caja prohibits eval(), iframes, * and _ hacks, an many other dangerous features. The latest YUI is caja-compliant code, and Chris reports John Resig is open to the same thing for jQuery, if it turns out there is demand out there.

Chris presents various examples of Javascript outside the browser - Air, web widgets, server side, even TV sets. It's a very useful tool here, and shows it doesn't have to be limited to the browser and the security risks that come with browsers.

Even PHP developers can write web applications that use all sorts of fancy long-polling.

That is what Leo said about his NGiNX HTTP push module:

This module turns Nginx into an adept HTTP Push and Comet server. It takes care of all the connection juggling, and exposes a simple interface to broadcast messages to clients via plain old HTTP requests. This lets you write live-updating asynchronous web applications as easily as their old-school classic counterparts, since your code does not need to manage requests with delayed responses.

NHPM fully implements the Basic HTTP Push Relay Protocol, a no-frills publisher/subscriber protocol centered on uniquely identifiable channels. It it an order of magnitude simpler and more basic than similar protocols (such as Bayeux). However, this basic functionality together with the flexibility of the server configuration make it possible to reformulate most HTTP Push use cases in Basic HTTP Push Relay Protocol language with very little application- and client-side programming overhead.

Configure NGiNX and write some code to talk to it.

Adam Beynon just released Vienna and we were very excited to hear from him:

Over the last few months I have been developing a ruby compiler directly targeting Javascript, to run more advanced applications in the browser. Blocks, classes, modules, symbols etc are all included in the runtime. More specifically, the runtime is HEAVILY inspired by macruby. My aim with the project is to bring rich app development to the browser, with the open source framework. I am porting Cocoa to ruby, just as Cappuccino, and to a lesser extent Sproutcore have, by directly targeting ruby developers who wish to program for the browser. The project is still very much in experimental stage, but I think its worth a look for any ruby and cocoa developers.

It's out there, but fun. I look forward to seeing more docs and info on it.

Dean Hachamovitch, IE general manager, gives us an early look whirlwind that discusses:

Performance Progress

The JavaScript engine team members John Montgomery, Steve Lucco and Shanku Niyogi give us an early look at the new JS engine that will ship with IE 9.

Standards / CSS

Although the Acid test score is low:

It is early days, and we do have rounded corners and CSS selectors!

Dean and his team talk over the work they are doing wrt standards.

Hardware acceleration

Finally, IE 9 will surf on the GPU using DirectX/D2D. As well as speeding up performance all around, setting the platform up for CSS transforms etc, we also see side benefits such as nicer fonts.

What else have you heard from PDC?

It is all the rage to build a perfect button and you can get some nice ones via SimplyButtons.init()

What if we could agree on a simple backwards compatible approach to packaging Web resources so the browser could suck down the puppies in one go?

Alexander Limi (of Plone and Firefox UX fame) has been thinking about this for awhile, and has gotten his latest proposal out there which defines a simple way to package things.

It builds on existing tech: zip, manifests, and the like.... and degrades nicely.

This is so much nicer than spriting hacks, but does have its own issues:

• In theory the browser could sometimes render faster by grabbing items in parallel
• Mobile caches may be messed up (as larger than a cache size, like say iPhone's 256k)
• What if the zip gets out of date with the other resources?
• Ideally tools (and in fact even web server modules) would auto generate this stuff

Although not perfect, for the majority case this could be a real boon to performance. What do you say Steve?

Oh, and it sounds like Firefox will implement this in 3.7!

Kris Zyp has announced the 1.0 of his Persevere uber-server:

Persevere is JavaScript storage and application server that uses standards-based interface of HTTP/REST, JSON-RPC, JSONPath, and REST Channels. Persevere is designed for rich clients application and can be used with any framework or client. The Persevere Server runs on Rhino and provides persistent data storage of dynamic JSON data in an interactive server side JavaScript environment

No sooner than it is released than we hear about the next generation version that goes behind Rhino at the low level:

With Persevere 1.0 finished, we are already working on the next version which will be based on the new Pintura architecture. Pintura is the new JavaScript core for the Persevere HTTP interface that is based on the CommonJS and JSGI API. Pintura will run on any CommonJS/JSGI capable JavaScript engine (support for V8, JSCore, and Spidermonkey coming).

Learn more:

• Persevere Documentation
• Download Persevere
• SitePen Persevere Support
• SitePen Persevere Blog
• Getting Started with Persevere Using Dojo
• Persevere Mailing List
• Persevere + Dojo (using Comet) demonstration

The long awaited 280Atlas keeps marching on to its full release. The milestone that the awesome 280North team have accomplished this weekend was paid beta.

The tool is Mac only right now and the team interestingly created their own framework for taking a Web app and making it run on the desktop. Note the scrollbars and feel of the application when you run it. Tom talks about the architecture on the beta blog:

At first glance Atlas appears to be a typical desktop application. However, under the hood it’s actually a Cappuccino application. This article talks a little bit about how and why we took this approach.

When we set out to build Atlas, using Cappuccino to create a web application was the obvious choice. However, most developers prefer to work with files on their local filesystem for many good reasons, including convenience, security, and offline access.

We considered a number of solutions, including syncing with the local filesystem or integrating with source control, but packaging the Atlas application as a downloadable desktop app was the easiest solution for everyone.

So how does it work? Atlas functions remarkably like a typical Cappuccino web application.

Instead of a web browser Atlas uses a custom (though generic) native application built around WebKit to bridge to Cappuccino. The application handles things like creating native windows instead of the “inner” windows you see when loading a Cappuccino application in a normal web browser, and using the native menu bar.

Atlas spawns a small web server, which serves the Atlas application, Objective-J and Cappuccino, and other static resources, as well as an application server to handle backend functionality, such as reading and writing to the filesystem.

The “backend” (actually running on user’s computer) is built on Narwhal, a general purpose JavaScript platform, which implements the CommonJS standard APIs. Narwhal provides an environment to run JavaScript (and Objective-J, of course) outside the browser, in our case as part of a desktop application.

On top of Narwhal we have Jack, a web application platform modeled after Ruby’s Rack. Jack implements the JSGI portion of the CommonJS specification, and a lot more. To handle communication with the filesystem we use a Jack-based WebDAV server, called JackDAV. Atlas uses Cappuccino’s CPWebDAVManager class to talk to JackDAV.

Congrats to the entire 280 North team. They are all fantastic blokes and I wish them great success as they help Web developers with great and fun tools.

A new article by Michael Bolin looks at inheritance patterns in Javascript, with a special focus on Closure. He does a thorough job of weighing up Closure's use of the pseudoclassical inheritance pattern against what Doug Crockford labels the functional pattern.

Pseudoclassical inheritance (Closure):

Functional inheritance:

Lunascape 6.0 Orion is the latest version of the "triple engine" browser that lets you select between Gecko, WebKit, and Trident on Windows:

The latest version supports Firefox Add-ons as well as IE plugins, and they are quite bullish on their performance:

It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression.

We started working on SPDY while exploring ways to optimize the way browsers and servers communicate. Today, web clients and servers speak HTTP. HTTP is an elegantly simple protocol that emerged as a web standard in 1996 after a series of experiments. HTTP has served the web incredibly well. We want to continue building on the web's tradition of experimentation and optimization, to further support the evolution of websites and browsers. So over the last few months, a few of us here at Google have been experimenting with new ways for web browsers and servers to speak to each other, resulting in a prototype web server and Google Chrome client with SPDY support.

So far we have only tested SPDY in lab conditions. The initial results are very encouraging: when we download the top 25 websites over simulated home network connections, we see a significant improvement in performance - pages loaded up to 55% faster. There is still a lot of work we need to do to evaluate the performance of SPDY in real-world conditions. However, we believe that we have reached the stage where our small team could benefit from the active participation, feedback and assistance of the web community.

It is great to see this in the wild. We have seen delta compression from Google before (used in Google Toolbar but not talked about too much) but I am glad to see this getting out there early stage, which gives all browsers/servers a chance to participate and play.

However, I have an issue with one line of code.... ;)

Great write-ups here:

• Alex Russell: SPDY: The Web, Only Faster
• Mark Nottingham: Will HTTP/2.0 Happen After All?

Jacob Seidelin has brought us amazing Canvas work in the past. Now he gets into WebGL:

In my quest to get to know WebGL better, I've gradually been building my way up from the standard "paint one triangle" tests to more and more advanced things. Never having touched OpenGL before, this is all a nice learning experience for me and I can now render not only one but two triangles at once as well as cubes, spheres and what have you. There's been some nice progress around the web as well, most recently with Yohei Shimomae's Cube Defense, a tower defense like game built with JavaScript and WebGL - probably the first WebGL game ever but hopefully many will follow!

Without further ado, here's my own first, small pet project: A solar system of dancing planets.

I found out about it over dinner in Berlin at the great JSConf.EU. At the table were 6 people from 6 different countries. Go JavaScript diversity :) I first asked "BDD?" and Tobie spat out "No, I friggin hate BDD, especially for JS" before I had even finished the question.

Tobie gave a talk on Evidence at the show, and explained the focus of the library:

• Library agnostic (the scripty based one in Prototype was based on Prototype which is weird when you test yourself)
• Environment agnostic (e.g. not just in the browser)
• Self contained (no global pollution)
• Built with async in mind (in JS / client server / anything real, you gotta do async)
• Easy to automate