Links

pmuellr is Patrick Mueller

other pmuellr thangs: home page, twitter, flickr, github

Friday, November 14, 2008

javascript service frameworks

In my "brainwashed" post, I managed to get a diss in for Yahoo!'s BrowserPlus™, calling it a band-aid. However, I carefully, pro-actively covered my arse with an earlier Twitter message "Y! BrowserPlus™ looks interesting; maybe the service framework moreso than the function provided".

The existing services provided by BrowserPlus™ seem like eye-candy. Not sure I really need an IRC client in my web apps, nor text to speech. And I'm worried about the kill switch. Mainly because the implication is that I'm somehow always tethered in an uncacheable way to Yahoo!. shiver

But I do like the service framework stuff. At this point, don't really care how useful it is, glad to see people playing in the space. Why?

The level of functionality we have today, provided by the browsers, for components/modularity of javascript code is <script src="">. Basically, all the power, flexibility, and functionality of the C preprocessor's #include statement (good and bad). But I'm looking at my calendar to see what year this is again. Doh!

The big JavaScript frameworks build their component stories on top of this, and the whole thing just gives me the willies looking at it. While I often wonder if JavaScript actually needs real structuring capabilities in the language, like a class statement, et al., I'm happy to try living without it, and try playing with some other mechanisms.

Java likewise has a crap component/modularity capabilities out of the box. Jar files and class loaders. OSGi plugs that hole. JavaScript likewise needs it's hole filled (that link is sfw, I swear).

So let's start experimenting! Go, go Yahoo! BrowserPlus™!

Could we do this with Google Gears WorkerPools?

In my "fun with WorkerPools" blog post from a while back, I wondered about building a service framework on top of the WorkerPool bits from Google Gears. Seems like building something similar to what BrowserPlus™ provides is pretty do-able.

The great thing about the WorkerPool stuff is that it brings another dimension to the JavaScript story - separate environments / contexts / spaces. The ability to have a bunch of code running, separated into protected object spaces, with very explicit communication channels open between these spaces. The best you can do with <script src=""> is namespacing via fixed name objects. Ugly and unsafe. I assume BrowserPlus™ is doing the multi-context thing as well, but I haven't looked close enough.

The other neat thing about Google Gears is that something like it has leaked into the WHATWG work, via a draft recommendation called Web Workers. Meaning we may be able to do this in a browser-independent way sometime around 2022. Or, our Chrome Overlords will render it moot, since Chrome already ships Google Gears. Or all the browsers will start shipping Gears. Whatever. Workers FTW!

So let's start experimenting! Go, go Google Gears WorkerPool-based service frameworks!

No comments: