Friday, November 20th, 2009

Full Frontal ’09: Stuart Langridge on HTML5 Features

Category: IE, JavaScript, Presentation

>Stuart Langridge introduces us to some of the up-and-coming features we’re getting with current and future browsers, a nice complement to Robert Nyman’s talk, which covered the advanced features of “mainstream” (IE6-compatible) Javascript. After introducing the features that are there today, he also talks about how we can deal with the browser many of us are still having to support.

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

javascript
< view plain text >
  1. [1,2,3].every(function()) // run for all items
  2. list.filter() // find elements in the list that pass the function
  3. list.map() // apply function to each item

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″.

javascript
< view plain text >
  1. globalStorage["kryogenix.org"].visits = visits+1

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

  1. <event -source src="getTime.php">
javascript
< view plain text >
  1. document.getElementsByTagName("event-source")[0].addEventListener("server-time", eventHandler, false);
  2. function eventHandler(event) {
  3.   alert(event.data);
  4. }

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.

Related Content:

Posted by Michael Mahemoff at 10:52 am
1 Comment

++++-
4.2 rating from 14 votes

1 Comment »

Comments feed TrackBack URI

I’m currently migrating the cookie settings in my app to localStorage / userData (using PersistJS), with flash as an ultimate fallback. Only the session token will remain in a cookie. The advantage is that the UI can really go overboard in preserving its state on the client. Collapsed state of every panel, dimensions of every popup window, sometimes even the expanded state of each node in a tree. Because the local storage doesn’t get sent along with the request, it’s not a problem if there are 10+ KB of local settings.

Comment by Joeri — November 20, 2009

Leave a comment

You must be logged in to post a comment.