Out of the page and into the runtime; Extensions move the Web development model further Project Ares: An awesome mobile web IDE built on the web
Dec 16

Chrome Extensions and webOS Applications look quite similar

Tech, webOS with tags: Add comments

appsandextensions

“If you squint, Chrome Extensions and webOS applications look similar” — a wise friend

Having now written webOS applications and Chrome Extensions I have been struck by how similar they are, and could be.

It may seem weird to see similarity in a browser extension mechanism and a mobile application runtime, but when you look at it, there is plenty to share at a high level:

Breaking out of the sandbox

Both worlds need to break out of the web browser sandbox. Extensions can’t be restricted to the same limitations and Chrome Extensions have various API that relate to UI elements in the browser, as well as getting access to more.

On webOS we have exactly the same issue. When building native applications on webOS you can’t have the same restrictions and thus new APIs, UI widgets, and services.

This issue goes beyond even these too worlds, and is one of the big challenges for Web runtimes in the near future. I expect my runtime to be able to do a lot more and to get access to my data not just through third party server side services, but locally too. This all brings us to…

Permissions

The Web needs a permissioning model. The sandbox doesn’t give us enough, and although people quickly talk about security (which is critical) we forget what happens if the user can’t do something through the Web. They often will download an .exe to their local computer and will just run it, not knowing anything about what it does.

A big challenge for us is to come up with a model that doesn’t Do A Vista and drive our users nuts. We have to balance the desire to not ask the user for something all the time, while making sure the user knows what is happening. For power users at least, I favour the idea of showing me what is going on. Even if I grant an application a lot of power, if I could see when and what it was doing it would help. Of course, being able to restrict access to APIs is fantastic, especially when you get to layer social trust on top of the technical security. The Mozilla team talked a lot about just this and I look forward to more of their ideas and implementation.

(You can see an example of how Chrome does permissions with Cross site XHR.)

Application Bundle Info

The permissions and other metadata need to live somewhere. We have a appinfo.json file that has you declare info on your app. Chrome has a manifest.json.

On the Web we don’t really have this. You hit a URL and you bootstrap from there. The HTML5 manifest does tell the browser which files are in scope for caching and the like, but that is about it. Applications and extensions can tell the system much more. You have ids, versions, pointers to update, icons, main launching points or not…

Headless Chickens

You don’t often think of a headless web app. You can think of headless applications and extensions though. How many services are running on your computer now that have no UI? On webOS you can noWindow away and still provide value through the various services that we offer, the obvious being the rich and varied notification styles. Background apps are nicely supported.

Chrome Extensions have the notion of a background page as a way to manage a long lived lifecycle. Your background page is a singleton:

In a typical extension with a background page, the UI — for example, the browser action or page action and any options page — is implemented by dumb views. When the view needs some state, it requests the state from the background page. When the background page notices a state change, the background page tells the views to update.

In webOS and the Mojo framework we have a rich MVC system with a detailed lifecycle as well as the simple ability to define models, views and controllers.

And on

The more I look at these worlds, and others like them (e.g. Jetpack) the more I hope we come together. There are similar needs, and when you look from Chrome Extensions to Chrome OS, you can see a potential progression if done right.

3 Responses to “Chrome Extensions and webOS Applications look quite similar”

  1. Michael Lee Says:

    Indeed. Hopefully the “progression” will be a blending of the pros each offer rather than the domination of one for any other reason. It’s definitely an exciting area that’s just heating up!

  2. Jani Hartikainen Says:

    I think it would be very cool to see a standard emerge for this kind of stuff. I’ve worked with Nokia WRT widgets, WebOS apps and Opera Mobile widgets which all provide different APIs for same tasks. Imagine the possibilities with standard APIs…

  3. Steve Says:

    IMO, the sandbox is the only sanity we have left. You comment on ‘they will just install an executable’. That isn’t so trivial. We can teach users not to say ok to the Vista popup (you say that’s bad, I don’t think that’s so bad), but the idea that you could click on some link in a webpage and have access to the user’s data… I don’t really like that concept whatsoever.

    Silverlight is attempting this in Silverlight 4.0, where authorization will give you access to a users ‘MyDocuments’ – if run as an ‘out of browser’ (offline) application.

    Ok, that said… how do we do what we need too ? First, I think we look at what I’d consider to be the ‘prototype’, ie. let’s say Google Docs. Alternatively, I’d consider some form of partitioning of local drive space – similiar again to what Silverlight provides with it’s storage.

    Tread lightly on the idea of accessing a users file system – the developers think that is cool… but users I know that aren’t that technical will be in a world of hurt.

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: What is the number before 3? (just put in the digit)