techno.blog("Dion")

I am so excited for the Ares team at Palm today as we launch Project Ares a web based IDE for the mobile web.

The full experience packs a lot into the browser: visual designer, code editor, visual debugger, log viewer, source code integration, drag and drop file upload, built-in app preview, and the ability to run your app directly in the emulator or even the device!

I talked more about the details on Ajaxian and the Ares site has more.

I am so jazzed to see this out there. At Mozilla we saw the Ares team building this great product that uses Bespin right now for the code editor, some of the server side, source control and debugger (the first sighting of Bespin debugger!)

The team has worked incredibly hard since then to build what you see now in public beta form.

This also shows how awesome the web platform it is. Because webOS builds on the web we are able to have features like the “preview” feature that shows you how your app will look without even having to go to the emulator or device.

The performance of the app says a lot too. It is incredibly responsive for me, especially since there are a lot of features packed in there. The layout system is really well thought out too and is a dream when you compare to CSS fun. I can’t wait to see what the community has to say about Ares, and I want to hear features that they would like. After using this, I want to be able to build all kinds of web apps from it ;)

I also want to say thanks to my Bespin team mates and community as well as the new friends I have made at Palm. Matt, Scott, Steve, Frankie…. you guys are awesome and it is amazing to see what you have done in short order!

“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.

The Chrome Extensions team had a press event tonight to go over their extensions beta launch that I unfortunately couldn’t make at the last minute. I wanted to be there to see old friends and the good work they have been doing, and support them.

Aaron, Erik, and the team have done a pretty great job with their extension model. They wanted to allow Web developers to develop extensions. Who better to do that than folks who are a) Web developers and b) have written extensions (e.g. Aaron is an old time JS hacker, author of Greasemonkey, and much more since then [Gears etc]).

Of course, over at Mozilla the same idea had been hatched with Jetpack and other equally talented folk are working on that (Aza and Atul and more).

Some of our best Web engineers are on the case, which is great.

Before these new age extension models the world of extensions was tough. On IE you would be mainly a C++ hacker to do anything. Mozilla really raised the bar with its original Add-Ons but even though you could do a lot in JavaScript, there was still a lot of XPCOM and a huge API set since you basically were given the entire Mozilla platform to work with. This was great from a “you can do whatever the crap you want to do” perspective, but it was awfully hard to dive in and get productive.

Thus, most Web developers stayed inside the browser window. We develop applications in our area, and others do the extension thing.

That has changed and we are now breaking out of the browser sandbox in many ways. This is one of them. When we think about delivering experiences to our users we can think of out of the window. What would our users like to be able to do when not on our web site? How can we package our value adds in a way that they can do their thing at any point? How do we interact with the runtime? What can we do if we have more permissions to do interesting things?

We have only just seen the beginning with Jetpack and Chrome Extensions. They are many more APIs to write and for us to then consume. I personally think that Chrome is too restrictive on what you can do in the browser chrome for example. I would love to play around and have my browser morph in interesting ways. If I am on a particular site, new features and functionality could appear if I want them too.

It feels like we are touching the surface on what the Web platform and runtime is versus what a “browser” is as we have envisioned it until now.

2010 will be an exciting year for Web developers as they add extensions to their toolbox in a nice clean way.

I spent a lot of time advocating Gears. I loved the engineers (folks like Aaron Boodman who is doing great stuff with Chrome Extensions, and Chris Prince who now works on the fantastic Google Voice, and many many more…. many of whom are working on Chrome in some fashion).

Today the press is picking up the fact that Gears is dead, even though Google moved its efforts awhile ago (keeping life support turned on) and Linus talks about the focus on HTML5 and Chrome:

“We’re very focused on moving HTML 5 forward, and that’s where we’re putting all of our energy,” Upson said. “When we started the Gears project, three years ago, maybe three and a half years ago now, we did it because we couldn’t get the browser vendors interested in building offline applications. And so, so we said, okay, we’ll build a plugin that could do it. And lo and behold, once we shipped Gears, suddenly the browser vendors got very interested in adding capabilities to build offline applications.

“And so, I think Gears has accomplished its mission very well, in getting these capabilities into HTML 5,” Upson added. “In fact, the team that designed Gears was also instrumental in designing the HTML 5 versions of those APIs. You can almost think of what’s in HTML 5, with app cache, and database, and those things, as essentially Gears 2, and that’s how we view it.”

Many people are happy to wave good bye to Gears and look to the future of HTML5. I feel that too, but I do have a pang of “what coulda been”. The Gears team was incredibly pragmatic. How can we get Gmail Offline? What about other Google properties? This practical experience delivered Gears and the push for support of real APIs that developers need to deliver compelling experiences through the Web platform.

Although it is true that Google can push the cause through their own browser, their properties still need to deal with other browsers. ChromeFrame is one answer there, the new “Google Plugin”. The browser vendors are kicking into gear nicely now. Mozilla, Google, Apple, Opera, and even IE teams are working hard on new features and HTML5 support. When Gears started we (the Web developers) were in the dark ages of browser development. The IE team had moved on to WPF and Silverlight. The other browsers were fighting the fight against a huge IE6 dominant entry with lots of ActiveX keeping it in style.

Does this mean there isn’t a place for a Gears like solution? Yahoo! has BrowserPlus which has the additional benefit of allowing developers to write services. This was one of the issues with Gears. You got APIs that Google gave you. You had no way to extend the experience. Browser Plus allows that and I hope that Lloyd and team have a good 2010.

There is also JetPack (and Chrome Extensions) that allow you to extend the experience in a different way. If I had my way, Gears and Y!BP and JetPack would all have joined forces. That world would then look like:

• Gears/Y!BP allow functionality to work cross browser and offer a services framework to allow you to write new components that also work cross browser. This is fairly low level work, with some nice sugar for certain APIs.
• JetPack would give you access to low level APIs in a nice high level JavaScript API. Since it would run in Gears/Y!BP it would run cross browser too.

My wish for Santa? Have JetPack and Y!BP pickup and work together. Give developers a platform to create new services on the Web and have them work cross browser. We shouldn’t have to wait for browser vendors to implement APIs. We should be allowed to experiment more. Gears started its job with the zipper running higher, but there is always more room to run. If we worked out a way to get more people playing with the platform we could get so much more done. We saw what came out of “how could we do Gmail Offline” what about your application needs?

I will raise a glass to Gears and the new HTML5 overlord, but I will miss the vehicle for cross browser experimentation and what coulda been.

Aaron gave a humane look at how to hire a programmer. It was less about programmers than it was about hiring, and how to judge people. Some have jumped on how this doesn’t scale to BigCorps, and others don’t think it tests the programming side of things at all.

First, the scaling. If you take a look at how big companies recruit their often have legions of sourcers scouring linkedin and the Web, and recruiters on top of them. The law of averages has them weeding out people based on some kind of “bar” which is inperfect but they feel like they need something. Of course, the main problem is that there is a huge amount of nuance in judging someone from their resume. If you can get past the fact that a resume can only tell some part of the tale, you also know that you, the seasoned programmer, can instantly make some kind of judgement on one. “Erm, this guy lists XHTML, HTML, SGML wtf?” Many sourcers will not be able to tell the crap from the truffle. Once you get these people through there are phone screens and the like, and then in person interviews, and suddenly engineers are spending a lot of time in the process. Rather than having them ask how many eggs fit in a mini, maybe there is something more productive.

This directly relates to school exams. We all know the kid that always did well in tests. And we all know the kid that was incredibly bright but never seemed to do as well as he should. Exams and tests are pretty crap depending on what you are going to Be When You Grow Up. If you are a flight traffic control chap, then the fast on the spot thinking will help. If you are an artist? Maybe not.

I am far more interested in seeing a portfolio of education than an exam grade. When Sam and Josh are older I want to talk to them about what they learned, and what they have produced…. not their score out of 10.

I think the same goes for programming. Show me what you have done and let’s talk about it. It is important to understand the scope of that persons role on the project, who they worked with, how long it took, and many other factors, but this can come across with conversation.

Another part of showing me what you have done is doing it with you. The best interviews I have done have been where you get some code out and you hack on it together. This is after all how things will be like in the team, so let’s practice what you will actually be doing. It isn’t about getting every line of code right, or getting the correct big O notation answer to a question.

Ideally of course you would be able to do much more than a quick hack session before you pull the trigger on a hire, and vice versa. So wait, aren’t we just doing this entirely wrong!

Doesn’t it feel like we are jumping into bed before we have rounded the other bases? What I really hope for is that we change the way employment happens. Imagine a world like this:

• A company has need for someone to come hack on a project
• A person has the interest and potentially has the skills
• Person and company come together and start working on the project
• Over time if things are going well, the person and company do more projects together
• Much later, if the companies want to make a joint commitment to each other, the person weds the company

If only we had the tools to do this. Oh wait, we do! We can contract/consult right now. There is no rush to bed at all. The only issues seem to be social and perception.

People often want to jump into bed with a company as they want security (which includes items like healthcare in the US which is INSANELY tied to companies, but that is another matter) and upside (e.g. “get me in now so I can get stock and kick off vesting!”).

Companies often want to jump into bed with a person as they want to “lock them in”. There are many legitimate reasons here such as investing in people, getting domain knowledge (including secret knowledge!), and the like.

Some companies and cultures have the notion of “probation”, but that seems rare and feels much different: “company: Just in case you suck I have an easy way out!” vs. “let’s both check each other out and see how this progresses”.

I have some consultants on my team now who are great. I hope it progresses. I wish that culturally it becomes more common to go this route. It is socially acceptable for permanent bed hoppers (consultants) even if they often have a stigma.

Oh, and with Employment 2.0 we will have micro-employment too. Oh wait, we already do.

Insert Google Anecdote

People love to talk about Google hiring. This is one of my favourite anecdotes. It is hard to get into Google (rightly so!) and you get rated out of 4. When you go through “perf” (the review cycle) you also get rated. I remember being in a meeting where someone ran the numbers to see how the hiring ranking matches the end of first year (and beyond) ranking. There was no correlation at all. The higher the hiring rating didn’t mean anything for 1 year performance.

Insert Hiring Anecdote

We are hiring at Palm. My team is looking for developer advocates and the like, and the company is looking for a whole slew of great people, especially engineers!

• Think the native apps on webOS are cool? They are just HTML/JS/CSS. Help us make more!
• Think that a Web based device platform could be better? Help us on the framework or beyond!
• Low level Linux hacker? Got spots there too. Bring it on!

I love your work and respect you, @ppk, but you just wrote a very naïve post. Guessing @dalmaer slipped you a mickey, so I’ll forgive you.

I did see PPK with a drink, but I didn’t drop anything in it, I promise! :)

What are we talking about here? PPK has written a post commenting on the interesting “Apple’s mistake” essay by Paul Graham.

I love PPK and he is doing great work, but I have to respectfully point out a few things here, especially as some folks thought I put him up to it. For those who are jumping on him in entirety, here does have some things right too! Don’t just get mad at the fact that he called developers arrogant and stupid ;)

There are fantastic web applications on the iPhone. I use Gmail and Google Reader as a Web app, for example. The browser is good, but I have written many times (before being a Palm employee! These are my thoughts… blah blah) about how I wished that Apple let me go the extra mile and access more from the Web side of things.

Although you can do great apps like Gmail, the user experience available to Web developers isn’t anywhere as close to that of the iPhone SDK.

• APIs: You are unable to access the rich APIs on the device. Sure you can get local storage and appcache, but you can’t get to the compass and the [insert tons of APIs here]. Your app may not need it, but they may be able to greatly benefit from them… let alone the enhanced graphics and performance.
• Discoverability: There are two worlds. The Web and the App Store. How does a user find out about your Web app? Sure they could use the power of Google etc…. but if they are trained not to do that anymore? Fortunately we have PhoneGap and Titanium and … stepping up here

So, the feeling of “come on iPhone devs, don’t be stupid and just develop a web app!” is going a tad too far. There are very valid reasons to use native. With PhoneGap et al, there are growing reasons to cover various bases.

At Palm I am excited to push the Web stack further by having it as the SDK, not as an option in the browser. I believe that the Web can be the unifying platform across the multitudes of devices that users will have in the future. This world is going to cause a large number of changes to how we develop experiences, and I am excited by the challenge and working with the Web community (companies and individuals) to meet the challenge.

There is so much to be done on both the technology side (html5 on devices, apis, services, gpu, etc) and on the delivery side (future of app stores, richer discoverability, etc). You can also create fantastic applications for many platforms using Web technology TODAY!

Update

Faruk Ateş has written a detailed post on this topic too that discusses similar issues to my post above, but also goes beyond with more details on $, and the SDK experience.

“Just what the world needs—another sucky JavaScript library,” he said. When I asked him what made it ‘sucky’, he elaborated. “It’s a JavaScript library written by Java developers who clearly don’t get JavaScript.”

This quote is by Kevin Yank, talking to Dmitry Baranovskiy, author of the fantastic Raphaël graphics abstraction library. He writes up more on the issues they see with Closure. This is the few of one side of the community towards the open source release of Google Closure and its tools.

It was bound to happen. When I started at Google I quickly wanted to learn about how Gmail, Google Maps, and all the revolutionary front ends that helped make Ajax happen. Closure was the heart of it, and I quickly wanted to see a way to get the knowledge out there. This was years ago now, but the same reasons permeate through. Even at the time there were a ton of great JavaScript libraries. It wasn’t that I wanted Google to come down the mountain like Moses and bless the world “thou shalt use Closure!” However, some smart people had worked for some time refining their use of the browser runtime and Closure was the art and science of that ongoing experiment. Having the world able to at least see the experiment would be a good thing. Other libraries could learn from it.

No one from Google has said that you should, or must use Closure!

I realize that we live in a world of heros or zeroes. There isn’t room for much in between. You are either going to be a X killer, or you are killed by X. There is no time to tell the longer arching tale. Closure came to us late in the game, where folks are often perceived to be in their camps. I love JavaScript because it allows a diverse group of libraries to do what they do best. Developers and designers can find what suits both their personalities and their particular project.

If someone asks me (and they often do) “Which Ajax library should I use?” there isn’t a simple answer. It is nuanced. It is complicated. It is frustrating! How many of you have even changed libraries in a project? It is embarrassing to go back in time and see what happened with Bespin. At various times we had MooTools, Prototype, Dojo, and SproutCore. Is that productive? Obviously no.

You build many things on the Web. A web site isn’t a web application, and then blend together so you often can’t tell when you go from one to the other (and it doesn’t of course matter at all). jQuery has made a living starting out as a fantastic DSL for sprinkling behaviour onto web sites and going from there. SproutCore and Cappuccino are the other extreme, and Dojo was the kitchen sink of JS development a long time ago. Speaking of Dojo, I really wish that Dojo and Closure had collided a long time ago. I think that it would have benefitted both sides, even though I know that it would have added some overhead for both too. When you are on an internal framework it is built for your needs. If you take a look at the Closure components they feel very Googley out of the box. At the end of the day though, Dojo and Closure are so similar in many ways, that having them joint at the hip a few years back would have been really exciting. C’est la vie.

One tricky thing about Closure is that you can’t look at all of the widgets and packages equally (same for most libraries to be fair). Some are battled hardened to the hilt as they are on important production systems acting as core functionality. The keyboard handling and localization support is top draw. Others may be cool but placed in via an interesting 20% project that isn’t as mission critical and hence battle hardened. Not all code is equal. In fact, I find the line by line code criticism tiring. It is so easy to take someones code and find fault with it (at least perceived fault). I am sure there is bad code in Closure. That is true for all code. It is much harder to be a creator though. Don’t get me wrong, it is good to point out potential issues, but there is a big difference between:

“I noticed that code X does Y. I think there is a bug there that would affect ….”

and

“Code X SUCKS. Mwhahahahahah. SUCKS!”

My new years resolution for 2010: “Say *sucks* less”.

The criticism that made me laugh hardest was the assertion that the Closure engineers were Java folks who wanted JS to be Java. They are far from it. They are old school JS engineers who have done amazing things on the Web and have just learned a few things along the way as they build huge scale JS systems.

Google is of course a big place with engineers with opinions :) When you have the creators of various languages and platforms under one roof that is always going to be the case (From Python to C++ to Java to Go, and then Closure, GWT, etc on the JS side… even jQuery ;). Many of the frontend engineers aren’t fans of Closure (as in: doesn’t fit them) but they do understand where some of the strengths are. Some of the engineers have even weighed in:

NOTE: The following quotes were taken from a Facebook comment stream. There is context missing (for example, Joel talks below about how he didn’t use the term ‘natives’ for example

Joel Webber, GWT guru: “I’m unfortunately not too surprised to see self-appointed “Javascript natives” pissing all over Closure, because it tells them something they don’t want to hear — namely, that you can’t get enough optimization leverage on large applications without some constraints on your code’s structure. The kind of stuff that you see in many Javascript libraries (e.g. lots of dynamic tests to figure out what to do in a function) pretty much guarantees that you’ll have an unoptimizeable mess.”

Gavin Doughtie, Dojo and Google Photos: “As one of the Javascript natives, I must say after three years of using Closure that it gives you a nice split between development-time dynamism and deployment-time optimization. I have found few Javscript idioms unavailable to me when coding, yet still benefit from static checking and optimizations once I’m ready to ship.”

I am more of a JavaScript native than anything else. I am not going to be rushing to use Closure on a project any time soon. It doesn’t fit many of the projects I work on to be honest, and it doesn’t fit me as well as some of the other libraries.

That being said, I am thankful to Google for putting this code in the commons (and the fantastic tools around it!) so we can all check it out (and some of us use it). I hope that the hard part of open sourcing a project kicks in and we see a community form around it, including taking in contributions. I still also harbor the hope that Dojo and Closure joined forces, but that is hard to do (a lot of people using both code bases!)

When it comes to getting closure, I hope that you don’t jump to the extreme and ignore and abuse it, and I also hope that you also don’t think that you SHOULD use it without checking it out and understanding the tradeoffs.

For example, this is crazy:

“I hate to admit but I “might” have switched from jQuery to Closure strictly because of the Google brand.”

Roundup on Closure

• Erik Arvidsson, founder of Closure, awesome JS hackers, on the history
• Alex Russell, founder of Dojo and Chrome Frame
• Dimitry presentation on JavaScript libraries
• Google Closure: how not to write JavaScript
• Learning Closure with goog.net
• Inheritance Patterns in JavaScript

When you think of a Web application, you think of going to an HTML page that then loads scripts and resources to display functionality. Applications in general do not always fit that model. If you launch an “application” like Growl on the Mac, a window doesn’t launch. It merrily kicks off a service in the background.

The same is possible in the world of webOS and browser extension systems. One of the user experiences that I enjoy on webOS is the notification system. Non-modal, and any application can tie into it. There are various levels of notifications:

• Banners: Thin bottom line one liner that appears quickly
• Icons: Notifications are grouped together in time
• Dashboards: Larger areas. A DOM window so you can put controls in there. For example, the media dashboard lets you play, pause, etc.
• Popups: Even richer larger actionable areas

More on these notifications in another post. If you have an application that wants to tie into the notification system you can do so even if a window isn’t open.

I wanted to find out how to do this, and luckily Mitch Allen has a simple example of this in his RSS News application that he builds in his book on Palm webOS.

I hope to offer a simpler API specialized for this, but it is quite trivial to do thanks to the Power service. The timeout service is located via palm://com.palm.power/timeout and there are various properties that you can pass in to do the real work when you are woken up. What application should be opened? What task should be run when opened? That is all tied in via the application manager service (e.g. see the palm://com.palm.applicationManager/open service below).

The wakeup code in the news application is defined in the setWakeup method in the main application assistant (NOTE: assistants help with the controller part of MVC in Mojo):

// setWakeup - called to setup the wakeup alarm for background feed updates
//   if preferences are not set for a manual update (value of "00:00:00")
AppAssistant.prototype.setWakeup = function() {    
    if (News.feedUpdateInterval !== "00:00:00") {
        this.wakeupRequest = new Mojo.Service.Request("palm://com.palm.power/timeout", {
            method: "set",
            parameters: {
                "key": "com.palm.app.news.update",
                "in": News.feedUpdateInterval,
                "wakeup": News.feedUpdateBackgroundEnable,
                "uri": "palm://com.palm.applicationManager/open",
                "params": {
                    "id": "com.palm.app.news",
                    "params": {"action": "feedUpdate"}
                }
            },
            onSuccess: function(response) {
                Mojo.Log.info("Alarm Set Success", response.returnValue);
                News.wakeupTaskId = Object.toJSON(response.taskId);
            },
            onFailure: function(response) {
                Mojo.Log.info("Alarm Set Failure",
                    response.returnValue, response.errorText);
            }
        });
        Mojo.Log.info("Set Update Timeout");
    }
};

Mojo applications have a certain lifecycle and your application will get callbacks for setting up, shutting down, activation (when you come back to a scene), deactivation, etc.

Thus, you will see that setWakeup is called in the main AppAssistant.prototype.setup and when the application is launched AppAssistant.prototype.handleLaunch.

Anyway, suffice to say, having a lot of fun digging into webOS.

I am really jazzed to see the work of the Mozilla Messaging team (Andy Chung, Bryan Clark, Dan Mosedale, David Ascher, Mark Hammond, and James Burke) out there.

Raindrop was so exciting to me, as it allows me to take ownership of how I handle communications.

Gmail is fantastic in that I have been able to extend my experience via Greasemonkey and the Labs tweaks, but it isn’t really open to me.

With Raindrop, you not only get to scrape out some flexibility in the client, but you get to do it the entire stack down. You can write code that changes BOTH frontend and backend. Have you ever wanted to do more than simple filters? Write handlers for particular content in an email? Help you mashup your email in any way? Raindrop will give you that.

It is early days of course. Mozilla is known for getting something out there early so the community can influence it, so jump in.

I am also excited to see that you can hack on things right int he client via an embedded Bespin. Awesome, I can’t wait to see what happens next guys!

There are a slew of interesting videos to check out too:

• UX Design and Demo
• Raindrop software architecture and components
• Automatically Organize / Identify Messages by Type
• Keyboard navigation
• Backend extensions
• Raindrop schema model
• Introduction to CouchDB
• Integrated community support
• First design iteration
• Second design iteration

I have been watching the work of Aaron and the Chrome Extensions team for awhile. I love that with that effort and Jetpack we are going to see extension creation made simpler and more approachable for Web developers.

I realized that I hadn’t written a Chrome extension, so I wanted to try it on for size. I thus created an incredibly simple extension that tells you the size of the window on the fly: Chrome Win Size.

In an ideal world this extension would be as easy as:

• Create a bit of HTML for the tooltip
• Attach an onresize handler to the window that changes the HTML

Unfortunately, it wasn’t quite that easy…. but it was pretty close. The only difference involves the fact that you can’t easily get the window object to resize.

Here is the entire extension to show how simple it is:

Web page for the tool strip

For now, I wanted to put the windows size information in the toolstrip. This isn’t ideal, especially if you don’t have other extensions that turn on the toolstrip. It could be nicer to either: have a subtle grey width/height in the background of the URL bar itself; show the info only when a certain keystroke is pressed. That is all for version 0.2 :)

As you will see below, the extension is just a Web page, and the toolstrip is just a div. You could use class="toolstrip-button" but for now a click doesn’t do anything, so I didn’t use that. Instead I have a title attribute that uses plain English to explain the info.

Once you have the HTML itself, you also have some JavaScript to do the work. The init kicks things off the first time, but the interesting code is the chrome.extension.onConnect.addListener piece that sets up the extension so that a content script can talk to it via postMessage.

<html>
<head>
<script>
 
// Query the current window (anyone will do) and set the window size in the toolstrip
function showDimensions() {
    chrome.windows.getCurrent(function(w) {
        var el = document.getElementById("windowsize");
    	el.innerHTML = w.width + " x " + w.height;
    	el.setAttribute("title", "width: " + w.width + "px, height: " + w.height + "px");
    });
}
 
// Listen to the content script and when told there is a change, query again
chrome.extension.onConnect.addListener(function(port, name) {    
  console.assert(name == "resize");
  port.onMessage.addListener(function() {
      showDimensions();
  });
});
 
</script>
</head>
<body onload="showDimensions()">
  <div id="windowsize"></div>
</body>
</html>

Content Script

Why do we need a content script? Ideally, we would be able to grab a window in the extension and add a resize listener to it and be done. That isn’t the case right now though. In the code above, the window object that we get in w from chrome.windows.getCurrent(function(w) {... isn’t a DOM Window, but just something with a few properties (width, height, etc).

To get an actual DOM window, we need to inject a content script and have that talk to the extension. The code is as simple as below… which does the postMessage() back to the listener that we setup in the extension:

// When the window resizes send a quick message to the extension
window.addEventListener("resize", function() {
	chrome.extension.connect({name: "resize"}).postMessage();
}, false);

Manifest

Now we need to put it all together and that is where the manifest comes in. It is here that we tell Chrome where the files are for the toolstrip and content script, and what permissions they have (e.g. give it the tabs permission), as well as metadata:

{
  "name": "Window Size", 
  "version": "0.1",
  "description": "Displays the size of the main window",
/*  "icons": { "128": "gmail-128x128.png" }, */
  "permissions": [
    "tabs"
  ],
  "toolstrips": [
    "winsize.html"
  ],
  "content_scripts": [
    {
      "matches": ["http://*/*", "https://*/*"],
      "js": ["contentscript.js"]
    }
  ]
}

Caveats

Even with the content script hack, it is pretty easy to do this kind of thing. It would be nice to do more with the window object as the hack has limitations beyond the extra code. For one, if you are on a page such as chrome://extensions/ nothing kicks in (due to the matching). Rather than matching on pages for content scripts to embed, it would be much better to declare that you care about windows themselves.

The toolstrips themselves are a little bulky and ugly, at least on Chrome for Mac (which is very much in beta) and as mentioned earlier…. unless you are using a bunch of extensions, it feels very unChrome-like to use that space.

FYI: To package an extension on Mac/Linux use this handy script as the built-in functionality isn’t there yet.

All in all a decent experience already. Really nice to just work on an HTML document to kick out the functionality. The idealist in me would love to see Jetpack and Chrome Extensions coming together so Web devs had One Way to extend the platform…… The Web is in a fortunate position to have folks like Aaron Boodman, Aza Raskin, Atul Varma and many others on the case of Web extensions.