It'd be nice if we could use the correct terms for these things. I know that I'm probably picking nits, but there's a difference between extensions and plugins.
My simplified definition: plugins run native code, extensions run Javascript. Flash if a plugin, Firebug in an extension.
The terms plugin, extension, add-on, widget, drop-in, applet, cram-thru, etc. have all historically been used interchangeably to mean little more than "lack of modular design".
Don't expect actual extensibility from Chromium any time soon. If they can't be bothered to even plan for platform independence (http://dev.chromium.org/developers/browser-bootstrapping) then they don't have the design wherewithall to retrofit a C++ app with a comprehensive extension mechanism.
My hope is that a Google-independent fork will start that extracts the nifty subsystems in Chromium, like process level isolation, and uses them to build a more thoughtfully architected browser/platform.
1) If they had planned for platform independence, they wouldn't have been able to release anything for a long time.
2) Since Chrome relies heavily on process isolation, I would think that a lot of the architecture of the browser is tied to the platform. Even the html rendering pipeline (based on WebKit) runs out-of-band and the rendered bitmap is send to the browser window via IPC. (I don't work on the team but from my understanding of someone's comments, this is how it roughly works)
3) Regarding extensibility, I agree that I doubt Google is going to provide much extensibility of the actual browser chrome. Google's interests are in the web sites themselves and as such, the greasemonkey-like extensions are what they're probably going to promote. They want to hide the browser container as much as possible and move the focus to the web page inside it.
1 & 2) I should hope that a company worth hundreds of millions of dollars and employing a vast army of the greatest programming minds in the world could take the time to wrap their platform specific code in an abstraction layer, a relatively minor task that is now practiced almost universally, or at least use some of the many mature cross-platform libraries available.
3) If Chrome is to be a platform, it's going to need a shell with a rich interface to manage multiple applications and allow them to interact with each other. It's also going to need an ecosystem and the people it needs in that ecosystem use OSX and Linux. Making it inflexible or "hiding" it are the exact wrong things to do.
Firefox Greasemonkey scripts are used by power users to make minor tweaks to specific sites. I don't see how that functionality will further Google's lofty plans for Chrome. This was a quick hack that nominatively fulfilled a very popular feature request.
> If Chrome is to be a platform, it's going to need a shell with a rich interface to manage multiple applications and allow them to interact with each other. It's also going to need an ecosystem and the people it needs in that ecosystem use OSX and Linux. Making it inflexible or "hiding" it are the exact wrong things to do.
I'm certainly not the one in charge of directing Google's vision but it would seem to logical to me that they are not interested in creating a new 'platform' in the sense that xul is a platform.
As far as I can see, the purpose of Chrome is to promote web apps as a reasonable alternative to desktop apps.
If they'd done that, they wouldn't even be in beta yet, let alone out of it. Look at how long Netscape 6, let alone Firefox, took to materialize. Remember that most of the Chrome team are ex-Firefox-luminaries: these are not stupid people, and you probably use their other products all the time.
Still doesn't offer any real extension functionality; it's more a glorified, built-in version of Greasemonkey. This precludes such popular and useful Firefox extensions such as Firebug, Foxmarks, AdBlock, or just about any other extension besides Greasemonkey itself...
A lot of Firefox's bloat comes from the XUL interface. It's their cross-platform GUI which is written in XML and Javascript. It's what allows add-ons to reach in and modify some very deep elements of the browser. For example, I run the Tab Mix Plus extension which radically changes the operation of tabs.
However, XUL and Javascript is a very heavy-weight way of doing things. Chrome and other browsers have a native UI. That is partially what makes Chrome a light-weight browser. It also means that the deep level of cross platform add-on's available for Firefox will not be possible for Chrome in it's current state.
I've read the proposals for expanding Chrome extensions and it sounds like they want to go a similar route to XUL. It probably won't be as low-level because they'll want to keep their native UI code. That will help Chrome to provide some more complex plugins with their own UI but still won't allow for some of the more radical and interesting plugins available for Firefox.
Check out the editor of XBL - for those not familiar, XBL is what XUL is built on top of as well as all the widgets you see in the mozilla platform (ff/tb etc), including all your html controls. I think if google went this route, they are definitely picking up where netscape left off and where moz foundation has limped along with, ie. building a platform around the browser.
I can imagine AdBlock, as well as other plugins that deal mainly with the DOM, as entirely possible. I mean, how much does AdBlock really do? Grabs a list of blacklisted URLs (with wildcards), matches applicable elements in the DOM, and removes them.
AdBlock may prevent these requests from being issued at all, but that isn't to say you can't implement something similar in a Greasemonkey-like environment.
The whole point of AdBlock is that it does block the actualy requests in the first place. Why should I have to download 800k of ads for a 200k webpage, and open myself to adware tracking cookies? Removing them from DOM after they've been downloaded is not a proper solution to me at all...
I disagree. I have an internet plan with 100 gigs of allotted transfer. I don't care if a few kb here and there come down. I understand that your position may be different, but in my opinion most use Adblock the way I do -- to not see advertisements.
Transfer totals has no bearing on bandwidth speed. When I'm on wireless connections, or at work where I am forced to work from a connection shared with 400 other employees, the bandwidth required by ads actually takes up a significant amount of time. I don't even have any caps on my usable bandwidth, in any of the above situations or at home, but the speed can still be greatly affected by the number of ads being loaded that I don't even see. Even my cable internet provider still gives me only a measly 384kilobit upload speed, and that now has to be shared between even more outgoing connections?
To top it all off, from an ad-provider's perspective, why should I be paying for ad impressions that the end user doesn't even get to see? At least with Adblock, my server bandwidth isn't used, and my impression statistics aren't being impacted by users who aren't actually getting the chance to view the content...
I don't think there's anything adblock does that a chromium extension script (or a greasemonkey script) can't do.
You can write a script that just looks for the html fragments that represent ads and nuke them before the page renders, right? - in the same way adblock does
In firefox, the only way to do cross domain xhr was to access a javascript object outside of the browser sandbox, make the call, then send the data back. I'd be pretty confident that google chrome's version would have the same security limitations.
Chrome is WebKit, WebKit has an amazing inspector/Firebug clone. In using both, I actually prefer the WebKit inspector. I haven't used Chrome yet, so I'm not sure what magical incantation is required to activate the inspector (in Safari it's part of the "Develop" menu"), but it should be there.
I'm not sure what your point is, but Chrome doesn't use WebKit for JS, it uses Google's internally developed V8 engine, so don't expect JS to always run identically in Safari and Chrome.
well the cool thing about greasemonkey was that you could do a little more than just inject javascript code... for example, you could make cross domain xhr calls as well, and it did so by jumping out of the security sandbox to do this. I'm not so sure if it will be possible in chrome...
When complete, the ID is going to be a hash of the extension's public key, and extension content will be signed with the key. So there won't be conflicts (unless you share your private key).
My simplified definition: plugins run native code, extensions run Javascript. Flash if a plugin, Firebug in an extension.