I respect what Google’s trying to accomplish with Gears very much, and appreciate that they’re helping draw attention to the need to build out the client-side of the Web a bit more, and that they’re doing it with open source. They’ve nailed the what perfectly.

Then again, Web services nailed their requirements perfectly too.

I think the how of what Gears is doing is, frankly, misguided. There’s minimal reuse of existing Web technologies, and it’s overly imperative when it could be easily be far more declarative. Each of these issues raise the bar for the kinds of skills a Web developer needs. Not a good thing.

Interestingly, the Web services analogy doesn’t stop at the requirements. When I talk about “minimal reuse”, what I’m referring to is that the Web already has a mature and general API for accessing and manipulating local data-oriented services – the DOM – and no “gear” I’ve seen has yet to use it for data access. So instead of a Javascript GeoLocation object that might expose method calls such as getCurrentLocation() or getLockedSatellites(), why not make the object a DOM Node and treat the data contained within as a document? Something like;

<Location>
  <Current>45.234,-120.999</Current>
  <LockedSattelites>4</LockedSatellites>
</Location>

(or better yet perhaps, microformatted HTML – though there’s issues there)

Then you could use the DOM itself to get at those values, or perhaps even a CSS selector. Simple!. You even get events for free.

Why is it that the industry continues to overlook the value of reusing pervasively deployed generic abstractions, be they network oriented or local? It couldn’t be a case of NIH, because the DOM is unavoidable if you’re a Web dev. I guess it just didn’t occur to the them, though that doesn’t explain the push back.

Trackback

7 comments until now

  1. On the comfort scale, DOM programming ranks somewhere between a root canal (no pun intended on the “root” term) and an endoscopy.
    I am with you on the value of defining a simple XML doc to convey data rather than defining a set of getter methods, but why focus on DOM as a way to access it? Isn’t XPath much more direct?
    BTW, I know close to nothing about Google Gears, so I have no opinion about them. Just reacting to what you describe.

  2. Hi Mark,

    We definitely do try to reuse as much as what we can as possible. This is why we provide small little components that try to do one thing well, that developers can’t do yet. We aren’t trying to provide a separate platform, rather you do your usual Web app, and you have access to a few new APIs.

    With the location API, as we work with it in real-world cases, we have found that people like to have a JavaScript API that can just make a programmatic call when they need location information. That being said, you *could* store results in the DOM and have an interval that keeps it up to date. The JavaScript API is there for you to build on.

    Also, this data isn’t related to the document in question, but relates to the users browser geolocation, so I don’t see it as a good fit personally.

    Cheers,

    Dion Almaer
    Gears Team

  3. Hi Dion, thanks for commenting. I appreciate that you’re trying to reuse what you can, but I think you can and should go further. But I think that last paragraph of yours indicates that we’re not yet on the same page, so allow me to address that now…

    What I’m proposing is that there be more than one “document in question”.

    Currently, as you know, the common case is that a Javscript developer has access to a single document – window.document – and they can use the DOM API on it. I’m not suggesting changing that at all, nor adding any information to that document. I’m just suggesting that we give that same developer a reference to an *additional* locally resident document which encapsulates client-side data and data-oriented services.

    It’s like the /proc pseudo filesystem on Linux.

  4. Mark,

    Thanks for explaining further. That makes more sense, and is an interesting idea…. having documents that an API can pull up and manipulate like this.

    I still think that I personally prefer just having a simple JavaScript API that says “give me the current location” and such, rather than working with the DOM, but I do see how it is interesting.

  5. […] Google Gears: the SOAP approach to Web app development […]

  6. Thanks Dion, I’m glad you appreciate it.

    I agree that with a custom API you have much more flexibility in terms of deciding how “simple” (or name any desirable property) you can be, because you’re not bound by the constraints of a DOM model. On the other hand, by reusing the DOM you get a lot for free including events (as mentioned), selectors, and integration with other 3rd party DOM JS libraries, as well as the aforementioned lower barrier to entry for developers.

    As you mention simplicity though, I would also add that I believe that simplicity for Gears as a whole should also be a concern, rather than just the simplicity of each gear. I believe a DOM based approach would be a *big* winner here, because the common model reduces variability. Inevitably too, there will be requirements for gears to work with each other, and again I think the common model is exactly what is needed. That’s not to say that the DOM will be able to meet all inter-gear requirements, but I think what’s there is pretty general. Extending the DOM itself is an option in that case too.

  7. i tried to get Gears, to have a number like ‘800K’ to counteract Dion’s “small little components” claim. i have a feeling its like a megabyte of stuff isnt it?

    it says Opera isnt supported, then in Firefox it says im on 64bit and i need 32bit.

    so gears is fail already, quite literally. but yeah, it basically dangles a few carrots to devs in a couple ways it works around things that browsers are fixing the right way, that is built-in, via WHATWG/OpenWeb/W3C/etc APIs

    as for your data. the way id do it is a GET http://geolocatesomehwere.net/searchstring Accept: application/json;text/html and getCurrentLocation() would wrap this GET. no fancy libs needed. i dont know which geolocate services understand webarch, or dont require an annoying API key though. google cut me off after liek 500 geolocates last i tried, which was a couple years ago before they had an API and i was using perl..

    as for the storage, i guess Microformats or RDFa makes too much sense. caching it locally in storage corresponding to the URI of the resource. yeah go crazy with your weird gears shit!

Add your comment now