The internet is still a very young ecosystem of immature techn… Woah, the BS meter pegged there for a second. Forget the pontification, let me just spit out the two technologies that get me excited about billing myself as a Web Developer.

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.

Added support for MongoMapper in the sinatra-authentication gem. Grab it from http://github.com/britg/sinatra-authentication.

Be sure to require mongo_mapper before sinatra-authentication and everything should work peachy keen.

require 'sinatra/base'
require 'mongo_mapper'
require 'sinatra-authentication'

It’s no lie that I think highly of the potential of Cross Origin Resource Sharing. One of the great things about it is that it doesn’t take much re-wiring of existing server (or client-side) apps to start working cross domain.

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.

I’ve been hacking on a small project in my free time that I uploaded today: scriptstack.

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.

So, I’ve spend the last few hours debugging what seemed to be a tear in the fabric of the universe. I’m working this excellent javascript library, AjaxUpload, that, as the name implies, creates a no-pageload form upload. It’s easy to implement and makes an upload infinitely more usable in my opinion; definitely check it out.

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.

If you’re not familiar with Stack Overflow Careers, check out Introducing Stack Overflow Careers and Stack Overflow Careers: Amplifying Your Awesome.

In short, it aims to build a for-pay CV hosting and searching service on top of the success of Stack Overflow.

I have mixed feelings about Stack Overflow Careers.

No, I’m not questioning whether or not they should have built it, or whether or not they should charge money for it. I have no problem with Joel or Jeff using their interweb fame to make a buck like this guy seems to (Clarification: William’s beef isn’t with the for-pay aspect, but with the underlying system itself. See first comment.). If they want to, they should.

America++!

My quandary is whether I should make an effort to participate in Stack Overflow and Careers. I like the site and use it daily, but I don’t actually participate. I am a consumer, not a contributor. Should I eschew my natural introverted tendencies and force myself to contribute?

Maybe

The Stack Overflow group of programmers seem to “get it.” On the whole they are smart, pragmatic, and can communicate in complete sentences (skills listed in reverse order of importance).

As a freelance programmer, I would like to be attributed with those qualities when looking for work. That’s the true value in associating a job search with Stack Overflow and is the reason why they can charge programmers to list their CV. If you’re recognized as a member of that community, you’re much more valuable to job searchers that are Stack Overflow-aware.

Maybe there’s some value in participating in the site and quantifying my association with the Stack Overflow type of programmer?

Nah

But, ultimately what am I trying to accomplish? Sure, I want to be known as a competent and gets-stuff-done kind of programmer. Stack Overflow is an avenue to quantify that I have these skills; it isn’t the method by which these skills are obtained.

Joel Spolsky himself said,

The great software developers, indeed, the best people in every field, are quite simply never on the market.

He goes on to explain that if you’re a great developer, you’ll be recognized as such through your work.

I think this says it all. I shouldn’t force myself to participate in a contrived system attempting to quantify competence. Don’t get me wrong, if you enjoy interacting and contributing to Stack Overflow, more power to you! But for me, if I’m doing the right things to further myself as a developer, the rest will take care of itself. More do-ey, less talk-ey.

qTip - jQuery Tooltips

What is it? An easy way to create fancy tooltips that has (optional) customization options for just about anything you want to do. I had been using a pretty old and bland library before, so I was excited to stumble on this one.

Example: a tooltip positioned at the bottom left of a selector, with a green color scheme and a little tip pointing to the selector.

    $('#myselector').qtip({
        content: 'Eat my tooltip, sucker!',
        position: {
            corner: {
                target: "bottomLeft",
                tooltip: "topLeft"
            },
            adjust: {
                x: 10,
                y: 10
            }
        },
        style: {
            name: "green",
            tip: "topLeft"
        }
    });

Perhaps the best part of this plugin is the documentation. Just check them out and tell me that’s not the most well-documented library you’ve ever seen.

Google announces their DNS initiative: Google Public DNS.

I always thought it was kinda inconvenient that there’s a “DNS propagation” downtime. Looks like one of the things Google is doing is making DNS propagation fast and asynchronous to requests.

Google Public DNS independently resolves domain names and keeps the resolutions in the cache until their time-to-live (TTL) expires, at which point they are automatically refreshed. The cycle of caching and refreshing is performed offline, asynchronously with user requests, so that responses are almost always available directly from cache.

The other day I was chatting with a guy about the overly restrictive cross-domain request policy and how silly it is given the pervasiveness of cross-domain apps on the web today. Most devs get around this restriction with hacks like jsonp or nested iframes anyways. I told him that it’s high time we move past this archaic security measure and take web apps to the next level!

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.