WebGL

This is a new spec that’s being developed by the Khronos Group (the group behind OpenGL) to expose OpenGL to browsers through the canvas element.

Why is it exciting? Three words: Javascript. Hardware. Acceleration. Damn, I need three more: In. The. Browser.

The concepts should speak for themselves, but if you still need some convincing follow the steps below and be sure to take a look at your CPU usage while running these demos. (Hint: CPU usage will be very low because you’re riding your GPU).

• Grab the latest nighly of Chromium here if you are not already running it.
• Start Chromium via the command line:
  • Windows: chrome.exe --no-sandbox --enable-webgl
  • OSX: Chromium.app/Contents/MacOS/Chromium --no-sandbox --enable-webgl
  • Linux: ./chrome --no-sandbox --enable-webgl
• Follow this link to some examples of WebGL in action.

Again, check your CPU usage while running the demos. It should be very low (if you have a GPU) as the demos should be hardware accelerated.

Web Sockets

Comet? Long-Polling? Forever Frame? In two years we will all be sitting around a trash barrel fire laughing about the days of yore when we had to use such hacks.

Why are we huddled around a trash barrel fire? Because it’s post-apocolyptic New Zealand, the last bastion of humanity. Anyways, that’s another “In This Decade” blog post…

From websockets.org:

[The Web Socket Interface] defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in compliant browsers

Here’s the spec in case you want to read it… haha, me neither.

Again, the concept here should speak for itself. Two-way communication with web servers in an easy-to-use interface.

var websock = new WebSocket("ws://www.websocket.org");

websock.onopen = function(evt) {
  console.log(evt)
  websock.send("Hello Web Socket!");
};
websock.onmessage = function(evt) {
  console.log(evt)
};
websock.onclose = function(evt) {
  console.log(evt)
};
websock.close();

Fortunately, there are already many projects implementing the web sockets protocol. To name a few,

• node.websocket.js
• em-websocket (Ruby)
• pywebsocket

One thing to note is that the web socket protocol will adhere to the cross-domain security restriction that XHR has. The good news is it will ship with support for server-side origin discretion using the same Origin headers in CORS.

It’s all about the gaming, stupid

I’m going to predict that in 2 years, we will see current A quality games developed in-browser ontop of these two technologies. Don’t get me wrong, AAA quality console and PC titles won’t be disrupted like the music and print industries any time soon. But, the “casual” label on browser games will go away.

This is what has me really excited about being a web developer in this decade. Parity with desktop development is inching closer, and all ontop of open technologies.

No plugins. No corporate owner.

Win. Win.

Enabling your server app is as simple as including a few extra headers when you detect a cross origin request. How do you know it’s a cross origin request? You’ll see the Origin: header — all CORS requests will have it. From there, response headers depend on the specifics of the request, but I won’t go over those here — check out the Mozilla Developer Center treatment for in-depth information.

I’ve been working with Sinatra a lot lately, so I put together an extension for Sinatra that makes enabling Cross Origin requests even easier.

sudo gem install sinatra-cross_origin

There are two ways to use the extension: globally or per-route.

Global

For when you want to share all your endpoints cross-domain.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  enable cross_origin

  get '/' do
    "This is available to cross domain javascript requests automatically"
  end
end

Per Route

For when you want to share only some of your routes cross-domain.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  get '/' do
    cross_origin
    "This is available to cross domain javascript requests"
  end
end

Configuration

You can mix and match app-wide config and request specific config.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  configure do
    # Comma separate list of remote hosts that are allowed.
    # :any will allow any host
    set :allow_origin, :any

    # HTTP methods allowed
    set :allow_methods, [:get, :post]

    # Allow cookies to be sent with the requests
    set :allow_credentials, true
  end

  get '/' do
    # Only available to GET requests originating from
    # http://example.com.  No cookies allowed.
    cross_origin :allow_origin => 'http://example.com',
      :allow_methods => [:get],
      :allow_credentials => false
    "This is available to cross domain javascripts"
  end
end

Grab the source at Github: britg/sinatra-cross_origin.

What is scriptstack?

Well, if you’re like me you probably have 4 or 5 javascript files you include in just about every new project or site your start. jQuery. Tooltips. Lightbox. qTip. Or, you just put together a nice portfolio site for a client and you want to save that specific set of javascript plugins for the next time you do something similar.

Scriptstack aims to be an easy and social way to organize your “stacks” of scripts. You can:

• Upload scripts.
• Click and drag them into the order they should be loaded in the browser.
• Tag them with a few keywords to make them indexable for future search.
• Download the concatenated stack in minified or raw format.

That’s about it for now, haha. Release early, release often, right? I should note that there’s no permissions on the stacks. If you create one, it’s editable by anyone right now. I plan to add User accounts and ownership soon.

Warning: the site probably only works in Firefox.

Under the hood

I took this opportunity to expand my horizons as far as the technology under the hood. I’ll go in-depth on these as I continue to develop, but a quick rundown of the tech stack (pun intended but probably shouldn’t be):

• MongoDB (via MongoHQ)
• MongoMapper
• Heroku
• Sinatra
• Haml
• Compass

I also open sourced all the code that runs the site here incase you are interested in what poorly written Ruby looks like.

If you happen to check it out, let me know what you think! And as I said, I will expand on different parts of it here in the near future, so stay tuned.

The upload works by pointing the target attribute of a multipart form at a hidden iframe. When the iframe updates with the results of the upload, an event listener reports the response to the parent page, and voila — you have an upload without a page refresh.

The only problem with this iframe approach is that your response is being fully rendered by the browser instead of passed in the response body of an XMLHttpRequest like most ajax interactions. Combine this with a server-side upload script that returns JSON and here’s where the fun starts.

If you’re using the JSONView Firefox plugin (and why the hell aren’t you!?) the JSON gets rendered with some wrapper html and styling to create an interactive and human readable version of the JSON.

See the problem here? What gets reported to your upload-complete event listener isn’t the original JSON, but the HTML-wrapped JSON. This can lead to what can only be described as multiple hours of FAIL in which you try and figure out why your JSON response can’t be parsed and used in your javascript.

He just said, “Uh… do you want to upgrade your coffee to a venti for only 35 cents more?” Always the salesman that guy…

Cross Origin Resource Sharing

Recently I stumbled across this article on the excellent Mozilla Hacks blog. Cross Origin Resource Sharing (CORS). Sweet! Finally a true implementation of cross-site XMLHttpRequests.

The CORS standard works by adding new HTTP headers that allow servers to serve resources to permitted origin domains.

They’re getting everything right with this one:

• it’s completely opt-in server-side, so browsers can implement CORS without opening up a bunch of security holes,
• it uses the existing XMLHttpRequest object so current code can easily start working cross-domain,
• and it’s totally transparent to the client-side developer — validation, pre-flighting, and access control is all handled within the XMLHttpRequest object without any additional code!

Apparently it’s been in the works at the W3C for a couple of years (formerly known as ‘Access Control‘). But only the most recent versions of Firefox and webkit based browsers are starting to support it. Of course Microsoft, in their infinite wisdom, decided it would be best to implement their own spec, XDomainRequest. Some things never change…

The Holy Grail

Not the knights who say Ni

Why? For one, there isn’t a good, non flash-based way to implement cross-domain long-polling/comet. If there’s one thing that’s going to define the next generation of the web, it’s real-time apps. CORS enables efficient real-time “mashups” (hate that term) that don’t rely on iframe hacks or flash.

Psh… cross-domain, real-time? Nothing more than a niche application, right? Not so fast.

The web will soon (if not already) start its industrial revolution. A “building up” versus the “building out” if you will. New web development will progressively become based around existing sites, rather than the creation of new sites. A true cross-domain solution is vitally important to this.

No, no, I’m not saying that people will stop creating new sites — that will always happen. I’m saying startups will turn more and more to building apps targeted at sites users are already invested in instead of trying to get them to some new property.

Examples:

• The Disqus comment app on this blog.
• The Meebo Bar
• Those little ‘Feedback’ widgets you see all over sites now.

A new ecosystem is emerging: apps built with web technologies that run on other sites. But they’re mostly iframe based with all the restrictions that iframes have (no access to the DOM, slow, etc). With CORS, developers can almost seemlessly develop apps cross-domain with all the power of same-domain scripting, making it the most important development to come along since the XMLHttpRequest!

In future posts I’ll delve into this “industrial revolution” of the web, but for now… back to that grail.

In my previous post on server-side javascript (SSJ) I took a quick look at Jack, a project that aims to implement the Rack/WSGI pattern for javascript. I still think this approach is great as it opens the door for more traditional Rails/Django-esque frameworks for SSJ.

But, lets face it, the next gen web is all about real-time interactivity, and current popular environments and servers just aren’t ideal for that. It’s not their fault, up until recently we only cared about getting that request handled and out the door as quickly as possible with nothing shared between requests. Unfortunately, it’s no longer just about number of requests/sec — we now need high concurrency, long-lasting connections, and shared persistence over these connections.

Node.js

Enter node.js – a high performance javascript project built ontop of Google’s V8 runtime. From the author’s description:

Node’s goal is to provide an easy way to build scalable network programs. … Each connection is only a small heap allocation. This is in contrast to today’s more common model where OS threads are employed for concurrency.

Nice, but does this pan out in implementation? After spending a few days with Node, I truly believe that this will be the go-to project for the future of the real-time web.

A Simple Game Lobby

Let’s take a look at a simple example I put together. The following is a very basic game lobby that is based on a more complex project I’m working on with node. (You can checkout this script from github as well).

The script accepts new players through a url like /join?player=joebob. Then, the client can long-poll the URL /wait and receive a notification in real-time when new players join!

First, lets define a couple of Arrays that will hold our persistence in-memory.

// our in-memory list of player
var players = [];

// our in-memory list of players waiting
var waiting = [];

Next, lets define a set of URLs our server will respond to. Notice that the /wait response does not take place immediately. Instead, the response is captured in a callback function that is held in-memory until it is called. These callbacks are called whenever a new player hits the /join URL.

// define a set of paths that respond to requests
var paths = {

  /**
   * Requests to /join add players to our
   * player list, and fire off a notification
   * to all our waiting players
   **/
  "/join": function(req, res) {

    // extract the player from the request
    var newPlayer = req.uri.params.player;

    // respond to this request with a list of players
    // already in the lobby
    server.respond(200, players);

    // add this player to list of players
    players.push(newPlayer);

    // notify all of our waiting players that
    // a new player has joined
    while(waiting.length > 0) {
      waiting.shift().callback.apply(this, [newPlayer]);
    }
  },

  /**
   * Requests to /wait holds the connection
   * open until another player joins
   **/
  "/wait": function(req, res) {

    // define our waiting player and the notification
    // callback to trigger when another player joins
    var waitingPlayer = {
      "player": req.uri.params.player,
      "callback": function(newPlayer) {
         server.respond(200, newPlayer);
       }
    };

    waiting.push(waitingPlayer);
  }
};

Finally, we define our server. We tell the server to map requests to the paths we defined above, and to listen on port 8000.

// Define a new HTTP Server
var server = node.http.createServer(function (req, res) {

  // tell our server to look at the paths definition above
  // for a responder to the request
  paths[req.uri.path].apply(this, [req, res]);

  // respond to a request
  function respond(status, obj) {
    var body = JSON.stringify(obj);
    res.sendHeader(status, [ ["Content-Type", "text/json"]
                         , ["Content-Length", body.length]
                         ]);
    res.sendBody(body);
    res.finish();
  }
});
server.listen(8000);
puts("The game lobby has started!");

To run the script, first download and build node, and then download this script from my repo. Execute the script with:

> node gamelobby.js

Why? Maybe we don’t want Back-button accessibility, or as in my case, we are running our scripts on a 3rd party domain and we want to minimize our impact.

So, how can we maintain the organization that URLs provide, but prevent the actual URL from changing? Use a proxy!

You can find my fork of the Sammy project here.

Usage

var app = $.sammy(function(){ with(this) {

  // denote that we will be using a location proxy
  use_location_proxy = true;

  get('#/home', function() {
    //... do something
  });

  //...
});

And the corresponding link would look like:

<a onclick="app.setLocation('#/home'); return false;" href="#/home">Home</a>

Even though we are preventing the URL from changing in the browser (with return false), the Sammy framework still activates the ‘#/home’ routing.

Some things to note: if you define use_location_proxy in your application, it will no longer listen to the browser URL. Future versions may have more flexibility with this.

I’m sure Microsoft will try to make up for this lack of speed with extremely aggressive caching…

IE8 RC1 javascript performance courtesy of ZDNet

The results may or may not surprise you.  With a sample size of 1, most if not all of those surveyed responded that they very strongly dislike working with timestamps!

I strongly agree with the person surveyed, so that’s why I’m so elated that I stumbled upon this repo on github the other day — jQuery timeago.  Yes!  Finally I can just dump my timestamps straight from the database onto the page, call $.timeago(’selector’), and bam — a perfectly human readable, self updating time representation.

If you’re one of the many that agree with the extremely scientific survey above, then I highly recommend you give this jQuery plugin a try – here’s the plugins homepage.

I’ve also seen a lot of “Should Mozilla be pissed?” or “How will this affect Microsoft?” etc.  But I haven’t seen a lot of coverage on who I think is affected most by this move: Adobe.  Why?  Because the whole concept behid Chrome is to spead up web applications, namely Google’s style of web applications which all happen to be using AJAX instead of Flash.

So, if Google has completely revamped it’s javascript engine in Chrome so that each tab operates javascript in it’s own thread, and you can run AJAX applications like google docs, gmail, etc. continuously without worrying about your browser bringing down your entire computer, we’re likely to see a renewed interest in AJAX as a platform.  Also, we’ll see a renewed effort from other browser vendors to make their javascript engines comparible.  This is all bad news for Adobe Flex/Flash.

How are you, as a web developer, going to build that next business app?  Using Adobe’s Flex/Flash platform that requires users have a plugin installed (although most do) but has all the limitations of Adobe’s Flash plugin running in the browser?  Why would you when for most business applications, AJAX can meet all your needs AND be optimized to run as well as desktop applications?

No matter what the outcome, it’ll definitely be fun to see how this plays out!

Oh, and I’m writing this blog post through Chrome – it’s so new and shiny, go get it now!

Update: Chrome doesn’t have to gain huge market share for this scenario to play out!

Chrome is open source and hence their Javascript Engine is open source! (http://chromium.org) So, Chrome doesn’t have to make a huge dent in market share to make a huge dent in how the other browsers support javascript and AJAX apps.

From limited testing over about 2-3 hours I could noticeably tell a difference in performance running Gmail, Google Docs, Google analytics, and google reader in separate tabs as opposed to doing this on firefox.

This tells me that their javascript engine technology is superior to others out there – and since it is open source, I can imagine a scenario where other browsers, especially mozilla, adopt this engine.

So, google chrome may never ever gain market share but I’m willing to bet their javascript technology will! This is what bodes poorly for Adobe in my opinion – a new browser market that isn’t dominated by Chrome per se, but is dominated by fast and multi-threaded javascript engines!