Blinking WebKit

  • Speed. When Alex Russell talks about greater speed [1], I take it fractally. At micro level, it means actual day-to-day web development and debugging is faster; and at macro level, it means browsers and web standards move faster. Google works the same way; it is a company which cares deeply about speed; at macro level, that means pushing Kurzweil’s broader interpretation of Moore’s Law to its limit, and at micro level, it means great victory for every nanosecond that can be shaved off a search query.

  • Inevitable. The writing has been on the wall for years. Chrom{e/ium} has been heavily driving WebKit and it’s only natural they should want to lead the project. Cutting-edge WebKit is already there on desktop and mobile; in the future, it will need to be there in more contexts, i.e. Android webviews, Google TV or what becomes of it, Glass, cars, etc.

  • Dart. I can’t get a grip on how much Dart is growing, I’m too out of the loop. But if it is indeed growing to the point that it gets to survive and be blessed internally, it will be part of Blink. No question.

  • Safari. I’ve read some people say to the effect “you’re doing it wrong if not already testing on Safari as they’re already different”. Well yeah if you’re writing a mission-critical trading app. But let’s be honest; this business about testing on all browsers comes with a big wink and a sizeable nudge. Most of us can and do get by testing only occasionally on Safari. Even more so for Windows developers who don’t even have access to a modern Safari. I don’t see Apple adopting Blink anytime soon, I’m not even sure the importance of this fork will filter up to Apple’s seniors for some time. And this is a good old fashioned fork; WebKit and Blink will be significantly different. So the net effect for developers is more testing on Safari. And compensated by less testing on …

  • …Opera. My heart sank a little for Opera on reading this news; so it’s good to know Opera was in on the secret. If not when they made the decision to adopt WebKit, then at least some point before the Blink news dropped. Blink will certainly be stronger for Opera’s contributions.

  • Samsung. Samsung has to be considered a major part of today’s browser ecosystem. They get to pick the browser that goes into most smartphones after all, and it’s no secret they are on a collision path with Google. Last night’s news of a major collaboration with Mozilla (on Servo) is more evidence of that. Should Samsung start shipping Firefox as the default browser, the web really will have four major mobile engines (including IE here). It feels like battle lines have been drawn, but that’s probably more about the coincidence of timing. Also worth mentioning Amazon as a similar company with potential to grow into a major influence on the web ecosystem, via Silk. One can assume they will adopt Blink.

  1. http://infrequently.org/2013/04/probably-wrong/

Chrome Installation Links

Some web apps on the store are promoting their web app to users visiting from Chrome, in the same way we sometimes see “Try our mobile app!” links. Why would you do this, when the user has already visited the app from a regular website? Mostly because if a user installs the app, they’re likely to keep coming back, given that it’s easily accessible from the New Tab Page. In addition, installed apps have extra powers: in-app payments (coming soon), background apps, and – in the case of packaged apps – extension capabilities. It will also help the app’s landing page on the store if happy users are leaving positive reviews.

I see all this as progressive enhancement. Each app platform has its own capabilities, some are not (yet) standard, but still expected by users. So make a normal web page that rocks, then make it rock harder for specific platforms. And let people know about it.

One size fits all? Nup. Here’s a little gallery of four sites I know who are doing this, all in different ways?

Marvel goes all-out with lightbox on entry:

HuffPo has a “Try Newsglide” message above its header:

Picnik has an “Install Picnik into Chrome” alongside Twitter and Facebook buttons:

CricInfo has an infobar on top of the page:

Apps, Bookmarks, and the Chrome Web Store

A question we get a lot about the Chrome Web Store is the distinction between apps and sites, or “aren’t these just bookmarks”? Here is my take on the topic. It’s not necessarily the official view, just my personal opinion to help you explore the concept further.

Most apps on the store are are indeed a link to an existing page on the web somewhere; what matters is the content on that page. A successful app will be visually rich, “full-screen”, task-focused, and easy to start using. For example, a link to Amazon.com wouldn’t work as an app, but Amazon Window Shop does.

The fine print:

  • I suggest thinking of the store as a place where you can discover great web apps. Need a photo editor? Search for it on the store and you’ll not only find a list of apps, but also reviews, comments, and screenshots for those apps. That preview info is much more useful than just links, when you consider that each app takes time to learn and in some cases require sign-up and payment.
  • In some cases, apps already exist and are then submitted to the web store. That’s totally fine, the important thing is if it’s a good app or not. Mapnificent was an existing website, it works on multiple browsers, but was submitted to the store and has been popular with users.
  • Some apps can gain from the publicity of launching on the store at the same time as launching as a regular website, but that’s a side issue. Also, apps like GMail – which were well known prior to the store launching – seem to attract more “but it’s just a bookmark” reactions. I think that’s just an initial reaction and will go away as users get familiar with the web store concept.
  • In other cases, apps are developed just for the store. e.g. I think (but don’t have the back story), this was the case with WeatherBug’s Weather Window, one of my favourite examples of a well-focused, personalised, rich app on the store.
  • Many modern websites fall somewhere between the richness of a Mapnificent and the traditional stature of a Wikipedia (for example). These modern sites are often good candidates for apps, but just need a little UI tweaking. So the app’s manifest should point to a slightly different endpoint, which uses a different set of stylesheets, for example, which remove most of the branding and auxiliary site info (which are gratuitous since the user has already “installed” the app). It’s also good practice for these sites to support single-sign on by implementing and checking for Open ID.
  • This being the Chrome Web Store, you can assume the platform has all the latest features of HTML5 that ship with Chrome. It’s great if your app also works in other browsers too, but it’s not a requirement. If you’re using a feature which only Chrome supports, chances are it will eventually work when other browsers introduce the feature too. The important thing is you’re at liberty not to target legacy browsers (though, again, for the right kind of app, it’s certainly still worth considering web standards and degrading gracefully; but when it comes to games, for example, not gonna happen).
  • In fact, there are actually some differences between apps on the store and apps accessed as regular websites. Firstly, I’ve been talking about hosted apps here, but there are also packaged apps, which are a hybrid of an extension and an app, and they can do more powerful things like injecting content on web pages. e.g. Fiabee lets you drag images into a special “Drop Images Here” region it embeds into the page at the appropriate time. Secondly, with the recent introduction of the background feature, hosted apps also get some additional permissions.

All this helps to answer a related question: How long will it take to build an app? The quick response might be the ever-faithful “How long is a piece of string?”, but that old pearl ducks the question, so let me make it more concrete:

  • If your product is already “Thinking In Web Apps”, stick it in the store today. (You might like to add Open ID support if login’s required and Open ID isn’t supported already.) A simple way to put it in the store is Paul’s AppMator. Typical Effort: 60-120 minutes, including time to make a quality landing page.
  • If your website is already using modern features, has modern look-and-feel, etc., you will probably need to customise the UI a bit and maybe revamp some features. You might also consider making it work offline with Application Cache, but that’s not critical at this stage. Then submit your customised app to the store. Typical Effort: 3-7 days.
  • If your website is a traditional “static” website, with minimal JavaScript and so on, and you’ve decided you want presence in the store, you’ll probably want to create a brand new app from scratch. Or maybe more than one, since there doesn’t have to be a 1:1 relationship between apps and sites. It’s actually many:many; an app can mash up multiple sites, and a site could power multiple apps (e.g. an e-commerce site could yield a product browser, a shopping cart manager, a new deals monitor, etc.; each of these is a bite-sized, task-focused app,; the best kind of app!) Typical Effort: How long is a piece of string?!! Well, it depends a lot on your existing infrastucture, e.g. do you have an easy-to-use API for your services. So depending on that, and the nature of the app, it could be anywhere from a few days to a month or more.

Interview on HTML5 Game Development

Here’s an interview on HTML5 gaming and the Chrome Web Store which took place at Casual Connect, Kiev, last October. Excerpt:

HTML5 speaks to what games are very well – and the opportunities Canvass presents means good things for gamers. That combined with the new avenues to purchase new apps and content through PCs and mobile, when you combine that delivery with the development environment for the industry there is a real opportunity.

Startups Share Chrome Web Store Experiences

Part of my role in developer relations is to work with startups who are using Google’s platforms, and for me, that mostly means people doing interesting things with HTML5 and the Chrome Web Store. Here are some early reports from developers of great apps which were present – and in many cases, featured – on the web store. It’s early days, but the reports here suggest there are benefits in terms of discoverability and usage.

1. Todo.ly

Todo.ly indicates how being featured can impact on the stats of a young product:

Thanks to the store, our user base has increased by 780%, achieving the goals we planned for the next 1/1.5 years within the first 3 weeks. Traffic of Todo.ly has increased even more – by almost 1000.

2. SlideRocket

SlideRocket lists their experiences, including installation stats:

#1 Results – The SlideRocket app on the Chrome Web Store received over 50,000 installs in the first 10 days of availability and the volume hasn’t yet dropped off. As much as 60% of SlideRocket’s daily lead flow now comes from the Chrome Web Store.

#10 The revenue share is only 5% – With all of the benefits in points 1-9 we feel like sharing 5% of our revenue with Google is a small price to pay. Compared to the other marketplaces and apps stores which usually charge between 20% and 25%, this is kind of a bargain.

3. LucidChart

LucidChart emphasises that it’s not all about being featured:

First, thanks to the almost 30,000 users who have installed LucidChart to date, we are one of the top paid apps and also one of the highest rated apps in the Web Store.

Google rotates the applications that are featured in the Web Store, so LucidChart has been both featured and not featured in the store. While featured status definitely brings a significant bump in overall exposure and traffic, we have found that the store still brings an important volume of users even when unfeatured. So the Web Store can be an important driver of traffic and user growth for any web app.

They also comment on the nature of users on the store. I think this is an overlooked-point – we often hear X store has X number of users, but the nature of the users and the way they reached the store should also be a factor.

Second and perhaps just as significantly, we’ve found that the Chrome Web Store brings really well qualified traffic to LucidChart. Our user signup rate for visitors via the Chrome Web Store is about 75% higher than traffic from other sources. So the store not only brings significant numbers of new visitors to our site, but it has an even larger impact on the number of new users we’re registering. In fact, it turns out that a visitor to our listing on the Chrome Web Store is almost as good as a visitor directly to our own site.

4. Streamie

This is of personal interest to me, as I know the developer Malte (who now works for Google), and I had a hand in kicking off its Web Store presence. I wanted to scratch my own itch, so I took 15 minutes out to make a Streamie app, which is a lightweight wrapper of the app at streamie.com. Malte has subsequently incorporated the web store presence into the core Streamie code base, which is nice as an open source example of listing on the store, and he’s submitted it to the store. I was pleasantly surprised (given it’s a “beta” app developed in Malte’s spare time) to see Streamie subsequently featured on the front page of the store. He recently wrote about the front-page experience:

I’m personally somewhat surprised with the overall traffic that Streamie is receiving. It is nice that people like it. The Chrome webstore definitely helped pushing the traffic to a new level, though, which, of course, triggered a lot of blog posts and tweets and then more traffic :)

Discussion: Great Apps Get Featured

These days, there are many significant platforms for an HTML5-powered app, beyond just running in web browsers, and I think developers who can leverage them will do well. Chrome Web Store is one of those platforms; others include the Android Market, Apple’s iTunes, and so on. But wait, aren’t those “just mobile” platforms? No – aside from the fact that “mobile” means all manner of tablet, phone, and PDA form factors – Android apps also run on TVs, for example, and HTML5 can be the user-interface driver behind that 10-foot experience. And pure speculation, but I’m fully expecting HTML5 (or “open web standards” if you prefer) to power apps running on watches, cars, kitchen appliances, assorted furniture.

It’s going to be perfectly possible to sell a single app on all of those platforms, where the majority – or even all – of the code is reused across the platforms. Beyond app platforms, you can also be featured in other ways, e.g. by using certain (non-app) platforms or APIs. To take a random – and very cool – API, meet Withings, a smart French outfit with wifi scales that upload your stats to a server. Here’s a page where they list apps using their API. Do you think it’s in Withings’ interests to promote these apps?

Now, I do indeed work for a company with app platforms, so take this advice how you will. My main aim here is to highlight the benefits of working with platforms and to be aware that each of these platforms have developer relations people you may be able to work with, under certain conditions. Why would companies who run app platforms provide free to support developers, especially developers who are already committed to building apps for that platform? The reason is it helps ensure developers are building the best possible apps – the platform people see a lot of apps and know what works and what doesn’t. This leads to (a) great apps for users; (b) “role model” apps for other developers. I recommend you bear these goals in mind when you aim to be featured in the store, because they are important considerations when it comes to being featured. A further reason for developer relations is to listen to developers, and feed bugs and requests back to the platform’s engineers.

In terms of the Chrome Web Store, apps that have done well are typically those which are following good UX principles and making the most of the platform at hand. In the case of an HTML5 app on the Chrome Web Store, making the most of the platform could mean apps using application cache, local storage, HTML5 notifications, CSS3 styling, etc. And for packaged apps, suitably leverage extension behaviours, since those are available to packaged apps. Finally, landing page matters, and fortunately for many developers, there is plenty of low-hanging fruit on their landing pages.

Async Talk on Chrome Extensions and Chrome Web Store

I gave a talk last night at Async, a fortnightly meetup for Brighton’s ever-thriving JavaScript community, organised by the talented Prem Rose. The talk was on Chrome Extensions and the Chrome Web Store, and was a mashup of our separate GDD talks on those topics (GitHub), some live coding, and some new stuff now that the Web Store is live…though the main focus was Chrome extensions.

Slide Deck: Chrome Extensions and the Chrome Web Store

A fun part of the talk was live coding. I haven’t done it before, but I felt it went well and was definitely worthwhile. The project was an extension to show the latest blog posts on the Async website, in a toolbar button (aka browser action). Chrome extensions are a lot easier to write than most people imagine, so it was an effective demo to start with a new directory and make it happen. For the record, here’s the extension we hacked up in 15 minutes or so: async.crx. (Styling was not the main focus of this exercise :) ).

I also did something I’ve been meaning to do for a while: A Venn diagram to illustrate the relationship between extensions, packaged apps, and hosted apps:

Finally, I had a good question about detecting if you’re website is running as an installed app. I couldn’t remember the details, but they are here:

javascript
< view plain text >
  1. if (window.chrome && chrome.app && chrome.app.isInstalled)

(Updated the snippet following Johan’s suggestion in the comments.)

HTML5: The Platform Apps Have Been Waiting For

I just finished my FOWA talk, explaining the technologies of HTML5 that are making it possible to develop rich web apps. There are three things I should mention:

  • London in a tube strike is not pretty, until you realise you’re in 28 Days Later, and suddenly it’s ace.
  • I am posting my slides below. They are based on a slide framework that I trend to stitch and mend with each presentation. So they are still very alpha! But getting to be awesome for authoring. Also, I tend to use the biggest-size images available, so download may be slow.
  • Thanks to Carsonified for doing an amazing job making sure everything was taken care of, and the crowd for their energy, and for actually making it in to the venue on this challenging day of travel.

HTML5: The Platform Apps Have Been Waiting For (full-page version)

–>

In terms of questions, we had time for three – one was about which payment solutions are possible on the Web Store (any – it’s open – but the web store provides solutions which should help developers); one was about making native apps (Web Store doesn’t support native apps as such; but tools like PhoneGap let people create native apps targeting iPhone/Android/etc); and one was about whether Application Cache (and, I assume, other features under discussion in the presentation) are HTML5-specific versus Google-specific etc. I mentioned that I want to avoid the HTML5 debate in this talk and I’ll define it here as the spec and everything else going on around it. It’s a good point though to be clear that Application Cache and the other general technologies I discussed are based on open standards.

Twitter Feedback (via List Of Tweets:

  • Amazing Google Chrome experiment site using #html5 goodness http://bit.ly/cRV3WQ #fowa Mon Oct 04 09:07:34 +0000 2010 from Jas
  • Chrome Experiments http://bit.ly/HDM7w <-- #html5 Not your mother's Javascript! #fowa Mon Oct 04 09:10:22 +0000 2010 from Jas
  • Chrome App Store looks kinda cool. #fowa #google Mon Oct 04 09:18:13 +0000 2010 from jacksonj04
  • payments for web apps – according to #google #fowa chrome app store is the solution http://bit.ly/a7rBot Mon Oct 04 09:21:54 +0000 2010 from timanderson
  • Whoa! Proper geek exodus to Michael Mahemoff’s HTML5 talk at #Fowa Mon Oct 04 08:46:54 +0000 2010 from Jas
  • Huge welcome from a packed room at #FOWA for @mahemoff Mon Oct 04 08:48:47 +0000 2010 from sammachin
  • apps are not applications say Michael Mahemoff #google #fowa Mon Oct 04 08:49:05 +0000 2010 from timanderson
  • HTML 5 talk by @mahemoff from Google #fowa #yam Mon Oct 04 08:50:25 +0000 2010 from WebAndTech
  • Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security Mon Oct 04 08:54:19 +0000 2010 from codepo8
  • RT @codepo8: Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security Mon Oct 04 08:55:03 +0000 2010 from mheap
  • #fowa @mahemoff pumping on stage – good talk http://twitpic.com/2uk56j Mon Oct 04 08:55:32 +0000 2010 from codepo8
  • RT @codepo8: #fowa @mahemoff pumping on stage – good talk http://twitpic.com/2uk56j Mon Oct 04 08:56:44 +0000 2010 from Paul_Kinlan
  • Christian Heilmann: Good talk so far at #fowa by @mahemoff about concepts of building apps with HTML5. #ux #security: http://bit.ly/aRzGgm Mon Oct 04 08:56:59 +0000 2010 from __UBI__
  • #Fowa #Mahemoff “the proof is in the pudding” what does that mean? Mon Oct 04 08:57:11 +0000 2010 from llaisdy
  • Suffering catastrophic sense of humour failure as it looks like I’ll miss @mahemoff’s session at #fowa. £#^$ you, London transport. Mon Oct 04 08:58:38 +0000 2010 from philhawksworth
  • HTML5: The Platform Apps Have Been Waiting For – Michael Mahemoff – Google. http://twitpic.com/2uk62j Mon Oct 04 09:00:43 +0000 2010 from lewisking
  • Michael Mahemoff (Google) HTML5 web apps: #NewTwitter, Gmail on iPad, and lots of new games and now even video. Even fonts. #FOWA Mon Oct 04 09:00:57 +0000 2010 from Hagoleshet
  • Michael Mahemoff giving his talk on html5 using http://www.html5rocks.com/ at #FOWA Mon Oct 04 09:04:38 +0000 2010 from kaosbeat
  • The Wilderness Downtown explained… Getting great ideas from @mahemoff http://ow.ly/2NV7N #FOWA #yam Mon Oct 04 09:06:49 +0000 2010 from WebAndTech
  • @mahemoff recommends studying local storage API for prototyping so you don’t need to work with servers when doing quick hacks #fowa #easy Mon Oct 04 09:13:45 +0000 2010 from kaosbeat
  • Props to @mahemoff for being the first to skirt around the definition of #html5 at #fowa. Let’s #focus Mon Oct 04 09:18:14 +0000 2010 from codepo8
  • 4 things web apps need according to #google #fowa: local storage, application cache ,locally installable, payments Mon Oct 04 09:13:40 +0000 2010 from timanderson

Thinking in Web Apps

Thinking In Web Apps is a short list of design principles for Chrome Web apps, published a couple of weeks ago by several of us in Chrome Developer Relations.

Many people think Developer Relations means blogging and speaking. That’s part of it, but it’s also important to be spending time with developers and understanding the challenges they face, as well as supporting them. In the case of Chrome Web Store, I’ve been working with several partners who are building apps in time for the store’s launch. Explaining how certain technologies work and taking questions back to the core Chrome development team. One of the things I’ve discovered in Developer Relations is the way patterns/principles emerge:

  • A new capability is announced, e.g. a new programming language, an upgrade to a hosting service, a new API. In this case, it’s the Chrome Web Store and the concept of installable web apps.
  • We make some guesses about how to use it and share them with developers. You have to see it as educated guesses; it’s the law of unanticipated consequences that says you can never be sure how people will use a capability, even if you’re the one who designed it.
  • Developers start to build use the new capability.
  • By aggregating across all of the pioneering developers, and talking to other developer relations people working with other pioneering developers, we gain a new appreciation of what works and what doesn’t.
  • We have more general info to share with partners. Wash, rinse, repeat.

The important thing is to be documenting what we’re learning as we go along, hence you can expect to see more articles like Thinking in Web Apps. Whether you want to call them patterns, principles, or whatever.

See also Task-Artifact Cycle.

Web Tablets: The Tipping Point is Nigh

It’s been said that the world hasn’t been this excited about a tablet since Moses came down the mountain. January 27, 2010, is the day Apple is slated to finally put us out of our misery and tell us what it’s all about. But imagine Steve Job moseys onto the stage, launches a forceful history of Apple’s portable record, and then announces Apple’s launching some new ipod speakers. (It happened a few years ago.) No “one more thing”. No tablet. Not even an iPhone OS 4.0.

Even if this happened (it won’t), Apple will have added huge value by sparking a conversation about the future of computing. While some say all the speculation is a waste of time, in this case, I’ve actually found some of the discourse rather fascinating. In particular, Gizmodo’s invocation of Jef Raskin and the “information appliance” dream, and John Gruber’s analysis.

I think Gruber nails it. Steve Jobs, in what many consider will be his final act at Apple, is attempting no less than the next generation of computing UI. Many people are already finding they can get by with just their iPhone for many tasks. Myself, I actually prefer to read blogs on iPhone NetNewsWire and Instapaper on iPhone Instapaper. I can read these away from the distraction of the big machine, whether at home, commuting, or in a shopping line. I’ve been trying to read stuff on mobile devices since the Palm Pilot, and now it’s truly practical. If people are finding their phone does some things better than the computer, imagine what will happen when you have a big touch-screen, let alone any secret-sauce innovations like tactile feedback or live docking into desktop equipment. I think we will find it’s more than adequate for many casual users and a valued extra device for power users.

But this is about much more than Apple. I think we can take it for granted that the medium-term future will be all about touch-screen tablets. We’ll struggle our way through questions about how to stand them up and challenges like their never-satisfying battery life. And what happens when they fall on the floor? Oh, and there will be patent wars galore. But the category will grow fast, as many people start to reap the benefits of a double whammy: better interaction, more convenient form factor.

The really interesting question is how will the UI on these tablets work? The Gizmodo and Daring Fireball articles point in the right direction – it will be more like the new “super phone” mobile generation and less like the traditional PC. Lots of sandboxing, lots of highly-customised idiosyncratic interfaces (but with common idioms), and lots of abstraction (==liberation) from the file system, lots of app stores and repositories.

Now one model for all this is iPhoneOS, the custom-built operating system Apple put together or its own phone. Is there another model?

Of course. The web.

And we can do it today. Apple won’t, others will. We have the makings of an operating system that does all that. Lots of sandboxing? Yep, the whole security model of the web assumes domains don’t trust each other, unlike traditional desktop applications. Lots of customised interfaces? Yep, with Canvas and CSS3 and SVG and WebGL and audio and video and screamingly-fast browsers and a million brilliant libraries and toolkits, yes. Lots of abstraction? Yep, the web never did like file systems, and with offline storage, it doesn’t have to. App stores? Yep, a simple system of URIs and standard HTTP security techniques can do it easily.

Most developers would rather code in technology they already know, that’s open, and has a diverse community contributing a wealth of “how-to” knowledge.

It’s all happening now. Google has ChromeOS. Palm has WebOS. Nokia and others have the W3C web widget standard. Stick these things on tablets, and a whole new generation of UI will flourish.

For Browser Extensions, Grease is the Word

Chrome now has Greasemonkey support. The Chromium patch came from Aaron Boodman, who is at once a Google employee and the brains behind the original Firefox Greasemonkey extension.

It makes me wonder if this is the plan for Chrome add-ons. Forget about anything like Firefox’s add-on mechanism and just rely on Greasemonkey. With the right APIs, it’s all you need.

For a long time, I have been confused and disturbed by the disparity between Greasemonkey and Firefox extensions. Creating a Greasemonkey extension is dead simple for any Ajax developer; creating a bona fide Firefox extension is more complicated, and involves writing the kind of meta-descriptions and JARs that most Ajax folk avoid. (The kind of simplicity mantra that has made JQuery king of the hill for now.)

You might recall I automagically ported the domain teleporter Greasemonkey script to a Firefox extension a while back. That this was possible, and easy, demonstrates that the Firefox extension mechanism could be made a lot simpler. I thought there was talk of doing it for FF3, but it didn’t happen.

What do Firefox extensions do that Greasemonkey can’t? Nothing Greasemonkey can’t get around.

  • Extended access – manipulating the Browser Object Model, accessing local file system, etc. All of this could be possible from a Greasemonkey script with the right APIs available. There are security implications, of course, but as long as users are aware of who can do what, it’s no different from what we have now. It may be even better, due to Greasemonkey’s built-in wildcard-based URL filtering, so that certain apps might only be limited to certain domains.
  • Metadata – certain metadata is present in an extension. This could just as easily be part of Greasemonkey’s metadata.

It’s my hope that Google’s vision for Chrome plugins is Greasemonkey on Steroids, and that this unleashes a whole new ecosystem of powerful add-ons that have until now required too much effort to build.