Gears Future APIs: Crypto API Rise of the Guitars: Air and Traditional
Jan 07

The connection between Hope and Web innovation

Gears, Google, Tech Add comments

There are a couple of pet ideas that I have had with respect to JavaScript and Gears. When you think of Gears as a base platform that can upgrade the Web, you think about the ECMAScript 4 fun in a new way.

A common thought pattern starts with optimism:

*ding* Wow, wouldn’t it be cool if my browser could do X?

or

As a developer, I would love to be able to do Y.

And then you often get to disillusionment:

Bugger, but if IE doesn’t support it, I am screwed.

I think that there is probably a good connection between Hope and Web innovation. I have felt this many times. If I feel like I can do something, I go after it with vigour. On the other hand, if I know that after a ton of work it won’t work for a large number of people, then I am far less likely to take her home.

How does this relate to JavaScript again?

What if JavaScript 2 (ECMAScript 4) comes out at a subset of Web developers are really excited about the new features. They want to get into packaging/namespacing/programming units. They grok optional types and like them. The pythonista in them enjoys the generator-like support. And, I could keep going with the large number of features. After you get over your initial excitement, you think about how a new set of libraries could make life a lot better. Prototype 2 is born that supports JS 2.

And then you start thinking about deployment. Darn it, maybe Microsoft doesn’t support it. Hmm. Of course, this is where the monkey comes in from Mozilla, but I immediately thought that Gears could help here. We could see if a script is asking for JavaScript two, and on demand install Action Monkey or anything else. Maybe together, Gears and the monkey could push out JavaScript 2 in a way that would push Microsoft to implement it themselves at some point (IF they don’t right away!).

What about the script of JavaScript?

I have talked about this a bit before, but I would also love to do smart work with respect to registering libraries enabling sites to not have to re-download and compile them all the darn time. We register Dojo, Prototype, jQuery, YUI, GWT, and [insert your favourite library] in a versioned way, and these versions can even be optimized for a particular browser. Instead of the if (thisbrowser) crud that we still see now and then (instead of the if (FEATURE)) we could have browser specific code, and all of the code can be compiled to be super fast.

When an application loads Dojo v1.0.2, it is swapped in with crazy speed.

If we ever get to this reality, then think about how things change. All of the optimizations and “keep my library to 3kb” arguments change. We always want nice small libraries, but we won’t have to make the compromises that we have had to in the past. We can do more in these libraries.

Gears isn’t the only solution here of course. Browsers can do this too. Ideally, browsers would do it, and Gears would be there to once again mop up for browsers that don’t implement it.

Wot no server?

There is also the server side of the equation. I have long thoughts that:

JavaScript needs a CPAN

It needs to be:

  • Crazy fast
  • CDN (see: crazy fast)
  • Access is given to the projects themselves to manage (not run by one company person)
  • Community driven

We have had JSAN, and other sites out there, but we need a big guy to come along. Yahoo! does it for YUI. AOL does it for Dojo. I want someone to do it for everyone. Of course, I would love Google to be that place, but I don’t care who actually does it. Google already has a bunch of people using Google Code to hotlink to their libraries, as it actually fulfills most of the requirements. There are some issues such as the fact that it only works for open source projects, and how it isn’t explicitly made for this purpose.

With script registration, and a fast distributed server for the script, we have a much better place. Add to this new JIT JavaScript VM’s, and 2008+ looks like a different place.

And there is more…

You can also take the case where Gears swaps in a JS 2 engine and generalize it. What if someone came up with a new CSS engine? Or any other library that makes sense to be cross-browser-platform. Hmm.

Other Future APIs

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'ajax'