Thanks for taking the time to reply. As you well know, I don’t blame IE for everything. When I talk about a roadmap, what I’m suggesting here is that the IE team not having a release date or deployment plan is both understandable and highly problematic. As I outlined in the post, the idea of waiting on omnibus browser releases to “fix the web” leaves the broader community of web developers in the lurch for years at a time. Of course we have to wait on new renderers for CSS and HTML rendering bugs to get fixed…but why are we waiting on IE 8 (or Firefox 3, etc.) for JScript fixes and enhacements? Or for DOM fixes? Or for offline support? The concept of the omnibus browser is truly useful, but it’s also limiting in ways that are bad for the web so long as we need to assume that we must replace an application on everyone’s desktop to get a better platform to build applications *within* that chrome upon. Gears breaks us of that dependence without also throwing the basic model of the web under the bus (which both Silverlight and Flex are more than happy to do).

What I am trying to figure out is how we can get to a place where we get a better web faster. Looking at the current landscape and the history of the browser wars, I think it’s pretty safe to say that all browsers getting auto-update is a huge deal…but it’s fundamentally also too slow. This isn’t about any one particular feature, it’s about the overall rate of change. I have hope that renewed browser competition will do more than Gears or Ajax frameworks ever could to ensure a high rate of improvement to the platform, but there seems to be a gap still. The uptake of IE 7 hasn’t been nearly good enough and there was an (as yet) unexplained year lag from release to being pushed to auto-update. In a faster evolving web, that kind of lag is a problem. Fundamentally, making users choose a *platform* based on an *application* is kinda backwards, and Gears go some way toward leveling out the collateral damage from the extant asymmetric information problem. None of the browser vendors have stepped up to really separate chrome for renderer and the platform suffers as a result. Auto-update only matters to getting a better *platform* when we’re not also waiting on the next searchbox enhancement to emerge.

Gears is therefore different in ways which I think you (as someone working on a browser engine) may find to be either “lesser” or at least not fully adequate to the tasks at hand. It’s true that there are things which Gears can’t do as well as if they were implemented natively, but *those things will never be implemented natively on IE 7 and IE 6*. Those browser still need a hot-patch, and MSFT isn’t providing it (and the planned patch, IE 8, has no release date/plan AFAICT). Here’s where Gears has regular browser evolution “beat”:

1.) gears does not require that users upgrade their browser or that they upgrade their OS. If their version of IE can handle the plugin, Gears can provide many capabilities which that old/slow/broken browser may never have been able to approach on its own. Note that this is the *exact same argument* being implicitly made by the Silverlight team, except that this team the plugin is *playing for our team*.

2.) while you mentioned the awesome responsibility of needing to provide something that is in front of half a billion people every day, if the open web doesn’t grow new capabilities, those half billion people will just chose different types of platforms. Gears is our bootstrap into that future. You (and the IE team) can stabilize, standardize, and solidify technology and techniques for app development embodied both by the Ajax toolkits and also (now) by Gears. The different between them (JS and Gears) is that while it’s much harder to provide capability v ia Gears, it’s a much more complete and (once deployed) “less expensive” way of emulating a missing feature. That said, there are some thing thst Gears fundamentally cannot provide without replacing the renderer, and that hasn’t been it’s focus thus far (and I’m conflicted about whether or not it should).

3.) Gears is on auto-update and is independent of the browser release cycles. We can get new stuff faster and in a less omnibus fashion. Having to wait until all the old browsers flush out of circulation is going to leave me an old, grey man before I the web evolves very far. Gears gets us the future sooner, albeit with the bootstrap problem to solve. The Google Docs announcement is the first step on the road to getting that done, and I expect we’ll see more.

Lastly, Gears is an open project under a liberal OSS license. There aren’t issues of transparency or single vendor control. Anyone who wants to can get involved and help improve the state of the web for every browser. That’s really, really different.

Regards

I haven’t seen your post till now, not exactly because I was not looking, but a vacation aligned with a spring break can get in a way of work…
I very much sympathize with your desire to see a solid path to the web as a whole moving towards something substantially different. I also have a number of desires towards the future which I wish I could have a clear roadmap for, such as when Americans will actually leave Iraq (I have no intention to make any kind of a political statement with this one, or any kind of parallels. I just really, sincerely want to know).
I am not sure what the example of Gears will teach us. It is great to see people make commitments and stand by them. We (IE) do make commitments and stand by them. It takes some planning to make a commitment that can affect a billion people or so. Even if we know that we can absolutely, no doubt, ship software on a particular date (it does happen), we have to take any other variable out of the way before we tell anyone. So sorry, you’ll have to be patient. You know we are on your side, but changing the world can be somewhat slow…
Meanwhile, consider all that computers that will never get updated. Then, consider the computers that actually do run other browsers (based on a standard that doesn’t exist). Suppose every IE becomes IE8… Will you get a web where you can really author once? What will your next problem be?
You know, I am fine with people blaming IE for web development being difficult. We’ve contributed our share. Think a step or two ahead – if IE did everything you want it to, is it enough to make the world better? (I am assuming at this point that IE is still not the only browser in universe, and I don’t know that either…)
Ahh, I love being a browser developer. Everybody readily appreciates my hard work (which I totally pretend to do, mostly writing emails sitting at an exotic beach…
–Alex

I’m counting on you being wrong on this one. Google has reach, and the virtuous cycle of self-perpetuating gears-based features/installs doesn’t need much of a kickstart once Google products really start to use it.

The fact that Gears doesn’t present an entirely different programming model/environment is it’s biggest strength and the reason I think its uptake will be both swift and (relatively) silent. Silverlight needs a bit splash to sell itself…Gears just needs email and document editing offline. I’m betting there’s more pent-up demand for the latter than the former.

I’ll buy you a case of your favorite beer if gears isn’t on 50% of desktops in a year.

Regards

I’m not sure it does make sense for MS (on a selfish, short-term basis) and I don’t know that any browser vendor will seriously consider it. That said, it *would* be good for the world if MS distributed Gears and got involved in the (open) Gears development process. Same is true for Yahoo building Gears features and supporting the project (which they probably won’t until it’s too late) or Sun shipping it alongside the JRE (which they won’t do until it’s waaaaaaaay too late).

Most of those organizations have a vested interest in seeing the Open Web improve (as does some faction inside of MSFT), but in all cases they cannot or will not move to preserve this investment; either because of a desire to exploit the opportunity of Open Web stagnation for product gain, or because their browser-based efforts would be threatened insofar as shipping gears would be tacit acknowledgment that their browsers aren’t good enough.

Luckily, Google may be large enough on its own to pull it off, but I fear that without engagement by other parties who SHOULD be at the table, Gears will continue to be a Google-only effort (with predictable and negative long-term results).

It would be good for MSFT on a rational, medium-term basis to get involved in the Gears development effort and to ship to older IE installs in an effort to stave off other browsers, but I don’t see that level of foresight being able to overcome the “but we have an answer in Silverlight…” arguments which would be immediately brought to bear. For the other tech giants, it’s just a “rinse, repeat” situation WRT their own investments.

Regards

Microsoft could do the world a favor and start distributing Gears as part of the Silverlight installer. Clearly the fact that it’s a plugin can’t be an a-priori strategic disadvantage or else Silverlight and Flash would be similarly un-viable. Gears has the advantage, though, that it doesn’t burden you with changing your entire development process to take advantage of it. As Brad mentions, installed base shouldn’t be an issue once people realize how important Gears is to the future of a healthy web.

I’ve been saying for a while that Silverlight has better evolutionary characteristics than Flash, but Gears trumps them both by piggybacking on HTML itself and not requiring a new markup system.

Gears FTW!

Regards

Brad Neuberg
Gears

Best,
Brad Neuberg
Gears

Just in case you don’t know about Gears or what it has today here’s some more info:

Gears is an open source plug-in that teaches current web browsers new tricks. Gears is a clever way to raise the bar cross-browser and cross-platform, today, running inside of Firefox and Internet Explorer on Windows, Mac OS X, and Linux. No more waiting years for features to show up across all browsers and platforms. APIs include: A real embedded relational database (SQLite) for web sites; client-side full text search; threads for JavaScript; offline web applications; secure and fast cross-domain mashups; desktop shortcuts; mobile devices; and more.