This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

Wednesday, September 16, 2009

Open Web Developer Network IRC Meeting for September 16th, 2009 Summary

We had another IRC meeting for the Open Web Developer Network ( today. Here's a short summary for those that missed it:

This was a work meeting, with people working on while in IRC. Initial focus for 0.1 will be Doctype (reference section); View Source (demos + cookbook section); and State of the Open Web (initially an aggregator section). Chris Messina is working on mockups of the home page, Doctype, and View Source. One tension in terms of design is that Mediawiki is ugly and difficult to skin; once we have a design Brad has volunteered to do the actual coding. The Mediawiki Foundation was going to host our wiki, but there is concern on their part in terms of the customization we want to do and hosting third-party code within their cluster. Brad will continue to investigate commercial Mediawiki options and might set up an instance on his web host and point to it for now. Brad will also begin to create sample content for View Source to understand what is needed there. Next meetup will be a few weeks after the SVG Open conference which is in two weeks and which will keep Brad occupied for the next two weeks. Scheduling for the next meeting will happen after SVG Open (beginning of October).

Full IRC log at

Current proposal:

Labels: ,

Monday, November 17, 2008

Fixing the Web, Part I

We've made major progress on the web since 2005 and the rise of Ajax. JavaScript toolkits like JQuery, Dojo, and YUI have expanded what we can do with web browsers and increased our productivity, while dynamic high-profile web sites have legitimized using DHTML and Ajax. The rise of web browsers like Firefox, Safari, and Chrome have done a huge amount to help revive the web and web applications. Developers such as all of us in the Ajax community have shown that it's possible to do things with the web cross-browser that no one expected, including Comet, cross-browser vector graphics, and more.

However, even with all of the amazing work the last few years, the web has some very serious foundational issues that we need to solve or else it's game over. In the next year or two we will begin to hit the limit of what we can achieve with clever JavaScript tricks (I've literally made a career out of this browser black magic). As an industry we've put off having to solve some very serious issues. Unfortunately the bill is going to come due soon, and if we don't take action, solve these issues, and push the web in a new direction some other possibly much less open technology will take over the bulk of new development.

We need to do something about this. This blog post is part of a new, semi-regular series called Fixing the Web. The goal is to highlight these issues, identify potential solutions, and have a dialogue. I don't claim to have the answers for the situation we are in. However, I do know this -- if there is any community that potentially has what it takes to solve these issues I believe it's the Ajax and JavaScript communities, which is why this is a perfect place to have these discussions.

To start, I see four areas that are broken that must be fixed:

1) Make developing for the web much easier and more powerful. There are gaping holes in the web that need to be fixed. Examples include:

2) Solve the standards problem. The web standards process is broken. There is a real disconnect between developers needs and the W3C's standard setting process, creating a dangerous power and leadership vacuum. We need to come up with better mechanisms for creating standards, as well as organizations that can help manage them.

3) Solve the distribution problem. Both Gears and Yahoo BrowserPlus are attempting to address this area. There is just a sheer mass of inertia on the web. It doesn't matter if you have the most amazing standards, developer tools, etc. if they aren't in enough places to do anything. This problem can also be re-framed as 'Solve the Internet Explorer problem', because the other browsers are pretty damned good at getting things out there -- IE is the mass that blocks any positive forward web progress. IE 8 is a start, but at the end of the day it's not doing enough. This is also linked to how hard it is to do web development, since you have to be a wizard to know the potholes or do crazy workarounds.

4) Solve the innovation problem -- There is a saying in politics that you create ideas so that you can draw on them when there is a crises, such as we are seeing now. Much of the innovation on the web has surprisingly happened by Flash, with some by Silverlight lately -- when we get excited about being able to do video on the web, which is great, that's a pretty sad indictment of the open web 'owning' the future. We've got to have better mechanisms for stamping out potential futures and innovation that can then compete, the successful ones turning into standards. Mozilla has done a good job of this with the web "concept cars" type work they've been doing.

What do you see as the major areas we need to address? Expect to see the issues above, and others, discussed in future blog posts in this series.

[Disclaimer: I work for Google. However, this opinion piece is my own and does not represent an official stand of Googles]

Labels: , ,

How Flash Can Integrate With The Open Web

[Big giant usual disclaimer: These are my own thoughts and opinions and not those of my employer]

Dion just put up a great post on how Adobe can join the Open Web by open sourcing Flash. I agree with him, and just wanted to add to the conversation a bit.

I've actually been turning this idea around in my head as well. It might surprise you since I'm an Open Web Advocate, but I like Flash. I've always tried to be non-ideological in my work. Flash has done good things and created a great deal of innovation. Adobe (and Macromedia before it) has always been good about evolving Flash forward, including making ActionScript more like JavaScript, embracing markup language development, open sourcing Flex, and more. I'd like to see Flash continue to evolve into being a core part of the Open Web. This would be good for Flash and good for the Open Web.

As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen.

Here are some suggested ways to make Flash & Flex more a part of the Open Web -- these are just suggestions. The important point is to integrate Flash and Flex more deeply into how the Open Web works:
  1. Cross-Platform Standards
  2. No Vendor Lock-in
  3. Anyone Can Innovate
  4. Powerful, Universal Clients
  5. Open Source Implementations
  6. Mashable, Searchable, and Integrated
Some possible ways to achieve this; I acknowledge these won't necessarily be the easiest for Adobe to do, but it would be extremely powerful if they did:

Directly push Flex and ActionScript to the browser and Embrace View Source

Right now Flex and Flash work by compiling everything you do down into a small, binary SWF file. This has some obvious advantages, mainly that it allows the Flash player to be simpler and not have a full interpreter in it (for example, ActionScript doesn't support eval because there's no way to dynamically execute script at runtime). Back when bandwidth was more constrained it also had the advantage of smaller file sizes and less latency when fetching multiple files.

These were good reasons for their time. However, things have changed. We now have much higher broadband penetration, and the Flash player doesn't have as strong size constraints (though I do agree you want to make sure the size stays small in general -- I've always liked the size constraint Adobe has around their player versus Sun with the Java VM).

At this point, Flash should start working like the web itself: Flex should be pushed right down to the browser and rendered there, with the ActionScript fetched just like SCRIPT tags. In addition, View Source should be on automatically and hooked into the browser's View Source. If I browse to an MXML page and do View Source, I'll see the MXML Flex markup for it. I could also then see the mx:Script tags and view their source as well.

Why this is good:
Integrate With Bookmarking and History

Flash should implement the HTML 5 History interface and should deeply integrate with the browser's bookmarking and history. I know there were some earlier efforts to have Flash have bookmarking machinery, but its buggy, no one uses it, and it doesn't work very well.

Don't Be Afraid of the Browser

AIR is really cool when you want to build desktop applications using web technologies. However, the browser doesn't need to be routed around as if it were a source of damage, which is what AIR essentially does. Personally I'd rather see Flash deeply embrace the browser itself and expand what can be done there, similar to Gears -- I want the web to grow into the desktop, not have the desktop grow into the web. Flash developers generally see the strengths of the browser as weaknesses, when they shouldn't:
Essentially I'm arguing that Flash should grow outwards from the browser keeping the above characteristics, and that AIR should go away. Sorry about that -- I know AIR is cool and nifty engineering, but I personally don't see it within the trajectory of the web. Let's expand what web sites and web applications can do, not try to turn every web site into a downloadable application. I bet the number of web sites you visit is at least an order of magnitude larger than the number of applications you have on your desktop.

Hyperlinks Are Your Friend

Hyperlinks are essential to the web, navigation, and searching -- it's the Hypertext in HyperText Markup Language (HTML) after all. Flash should embrace linking into the resources that are internally present (such as targeting particular parts of an MXML document). I'm not saying XLink is the way to do this, but perhaps one could mix in an attribute onto an MXML element (or the equivalent of a div and span in some inline text in an MXML element) that makes the element a targetable anchor. Or even better, just automatically make everything targetable: Text)

The line above would simply find the first occurrence of 'Some Text'. If there are multiple occurrences you can simply choose which one, starting at 1 rather than 0; for example, to target the second occurrence of 'Some Text', you would do the following: Text)[2]

This is good for search engines, for SEO, and for users. Again, this is just like View Source -- make things linkable by default.

Embrace REST and Readable Remoting Protocols

The Flash remoting protocols are interesting and a nifty piece of engineering. You've got AMF which is essentially a binary RPC protocol, and then you have things like RTMP which lie above this and which can efficiently intermix multiple streams of multimedia to ensure that no channel get's 'starved' if you are doing multiple collaboration or mixing streams together -- nice work. Again, however, this is a case where local efficiency is the enemy of broad adoption. Binary protocols make sense in some cases, but its much better to sacrifice the efficiency of binary protocols for the integration possibilities of textual protocols.

Flash should embrace REST (and if it must have RPC, just do XML-RPC) and layer higher-level protocols above these as HTTP-based protocols. Yes, you're going to sacrifice some efficiency, but it's just much easier for someone to throw up a PHP or Rails based backend that can setup things through REST, spit out some XML-RPC, or do multimedia through something like Jabber.

Embrace SVG

Yes, I know you are creating your own vector-graphics markup language, and I know you just published a long editorial on why SVG wasn't perfect for your needs. I hear what you're saying, but reading through the list it seems like minor errata rather than really good reasons. It seems more like the developer really wanted to make their own thing -- I understand that, it's always more fun to roll your own thing.

SVG's not perfect -- standards never are (and neither was TCP/IP or SMTP versus the competition, BTW). But SVG is actually pretty damn good, and the baseline of support has gotten strong the last year across Firefox, Safari, Chrome and Opera. In the next two years I think we'll start to see SVG emerge as a real tool in most web developers toolkits -- Flash should embrace this. Go ahead and add what you need to it (innovation is okay), but support the core standard itself. It's going to be a little different than the other MXML it's mixed in with, one of the issues you raise, but global systems like the web tend to sacrifice some internal consistency in support of evolvability.

Bonus point: Support the Canvas tag as well, including Web fonts (TrueType, not EOT).

Integrate with HTML and CSS

Yes, HTML has been sitting on its butt for awhile, but things like HTML 5 are starting to make things exciting again, and the work Safari and Firefox have been doing around CSS Effects are really powerful (and really easy for developers to use).

This can be a two-way integration. MXML has some cool ideas around layout, for example, that would be nice to push into HTML, while it would be pretty nifty to start being able to mix HTML and MXML together in some way and styling MXML using CSS. This might also include having one of the open source browsers integrate MXML and aspects of Flash into the layout engine itself. More thought needs to happen around the best way for these particular technologies to integrate.

Make Friends with HTML 5 Video

It would be pretty cool to simply open source and patent-unencumber the FLV format into HTML 5 as the default codec for the HTML 5 Video tag. I might be dreaming (and a bit off about FLV -- I don't know it's technical details deeply), but it never hurts to dream...

Support Both Documents and Applications

The web is good at documents (and with the addition of Ajax relatively okay at applications), while Flash is okay with applications, and not good at documents. The interesting thing about the web is it's actually a spectrum:

Documents <------- Hybrids -------> Applications

What we really need is a technology that can easily adapt along this continuum, creating documents, hybrids like Facebook and MySpace, all the web to full-blown appliations like Gmail and Buzzword, perhaps merging the best ideas of Flash and the HTML web stack. Mark this one as a research area.

Start Working with the W3C and IETF (and/or the Open Web Foundation)

Yeah, I know, working with standards bodies can be a pain. However, it would be pretty cool to have alot of the work happening in Flash flowing into the W3C and IETF (which I know has been happening around Adobe's ActionScript work, but not other aspects). If you want a lighter weight process, you should check out the Open Web Foundation's way of working, which is based on things like OpenID, OAuth, etc. which are a bit more pragmatic than the standards bodies we have today.


At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.

The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).

How do you see this happening?

Labels: , ,

Thursday, July 31, 2008

Open Web Definition (Version 0.4)

[Update: did a slight update of the definition]

Here's another stab at a (short) Open Web definition. I put out a call for folks to help craft a one or two sentence concise definition of the Open Web awhile back. I'm not quite sure if we are there yet, but here is one based on boiling down alot of the feedback from many people. In the comments below give this a +1 or a -1 with a rewrite to make it better (and hopefully shorter). Expect to see more rewrites until we get this tight and have general agreement.

Open Web Definition:
"The Open Web is an interoperable, ubiquitous, and searchable network where everyone can share information, integrate, and innovate without having to ask for permission, accessible through powerful and universal clients."

Here is a litmus test definition we can apply when wondering whether something is part of the Open Web and actions to take.

Open Web Litmus Test

Does it have:
+1 or -1 on this litmus test? If you give it a -1, try to not have the bullet points expand; we want this to be a concise list out of which other things can fall out, not a laundry list.

The goal is to get something as tight as the Open Source definition and work of the Open Source Initiative. We also want to have a short litmus test of characteristics that can help to determine both whether something is part of the Open Web as well as to guide actions and results to make it a reality.

Thanks to everyone who helped either by directly answering or by blogging about what the Open Web is in general:

Jeff Bailey, Jeff Fisher, Kevin Marks, Dion Almaer, DeWitt Clinton, Anthony LaForge, Jason Chen, Jason Robbins, Christopher Keene, Jeffrey S Miller, W3C, Jeff Scudder, Justin Mattson, Talin, Logan Hanks, Tim O'Reilly, Rod Chavez, Anthony LaForge, Glen Lipka, Ray Cromwell, Chris Dent, Joseph, booch, Tom Trenka, Keif, Alex Russell, polterguy, mojave, ialexi, Joe Walker, David Eaves, Mark Pilgrim, Kevin Mullins, Simon Willison, Sumit Chandel, and many more.

As an aside, I liked Jeff Fisher's tongue-in-cheek definition of the Open Web:

Jeff Fisher: "The open web is the great mystery at the heart of all of us"

Labels: ,

Monday, July 21, 2008

What the Heck is the Open Web?

Do you toss the term Open Web around? Ever wonder what the heck it means? Me too.

I'm looking for a definition of the Open Web that:
I've got my own opinions on these but I'm interested in hearing what you think. Basically, what's the elevator pitch for the Open Web? Its easy to talk to the Converted (tm), but what about when talking to other folks that might not care as much yet?

You get bonus points if you can answer the following:
We toss around the term Open Web a bunch, but I've never seen it succinctly defined. What is it, and why do we support it? I believe its important and worth supporting but it's all a bit fuzzy right now.

Post your thoughts and answers to these questions on this blog post.


Friday, April 18, 2008

Wordpress Vs. Facebook

Wow, take a look at this graph showing unique visitors to both Facebook and Wordpress sites:

This graph is important: the traffic to decentralized Wordpress oriented sites are almost as numerous as the traffic to centralized Facebook!

I had thought that the trend the last two years was away from decentralized blogging and communication tools like Wordpress and towards centralized systems like Facebook, but it looks like both are happening at the same time. The deeper trend is towards personal communication platforms, whether these are centralized or decentralized.

This is important, because it means that decentralized platforms stand a chance in the marketplace today, which is important both to me and the open web. Now here's the deeper question: can we make decentralized systems like Wordpress even easier, so that the traffic to those can go beyond centralized systems like Facebook? Maybe it will be a strange fusion of the two: maybe we can create a one-click system that will install Wordpress on Google App Engine, for example, so you can get started very quickly without having to provision storage. What do you think? How can we make decentralized systems as easy to use as more centralized ones so that we get the usability benefit of centralization with the freedom of decentralization (a theme you can see in the work I've been involved in over and over with things like coworking, Paper Airplane, and more.)

[Thanks to A VC for highlighting this graph and the fact that Wordpress Vs. Facebook is doing pretty well]


Thursday, April 10, 2008

Dojo SQL Ported to New Environments + Russell Leggett's Fight for the Open Web Work

Two new bits of news today.

First, Jean-Baptiste Boisseau has done some great work porting Dojo SQL to work not only on Gears, but in a Java and AIR environment (and HTML 5 when that appears). His work is in alpha and can be seen here, including a demo here. He has setup a blog as well to track his progress. Just in case you don't know Dojo SQL is an easy-to-use SQL layer for JavaScript. Under the covers it uses Gears to do the actual storage, and now Java if available thanks to Jean-Baptiste Boisseau.

Second, Russell Leggett was inspired by all the talk around the Open Web and Gears. Russell likes the Open Web, but wants to see JavaScript, HTML, CSS, etc. not just evolved but replaced by better layers that can help with web applications; he just wants to see these new layers remain open, just like HTML. I told him that Gears could potentially act as a way to deploy some of his ideas, and challenged him to write up his ideas and create a blog. Russell accepted the challenge and setup a new weblog, named, as well as a Google Group here. Join the group and join the discussion!

Some excerpts from Russ's first few blog posts:

"I believe there is an alternative solution [to Flash/Silverlight/AIR/etc]. I believe it is possible to fight fire with fire. If Flex/Silverlight/JavaFX threaten the open web, is there a way to compete on the same playing field? If the w3c technologies can't compete, can we take a different route? I propose that one very real solution to the problem would be to create an open source plugin technology to compete. It would allow a few things. First of all, it could ignore backwards compatibility because there would be nothing to be compatible to. Secondly, the cross browser issue would be resolved by being a plugin instead of a single browser implementation."

"I recently had a conversation with Brad Neuberg about the concept of using a plugin to have an Open Web competitor. Brad suggested that this was precisely what Google Gears was trying to do (sort of). In a recent post of his (which has since sparked a conversation across the blogosphere), Brad discussed the definition of the term Open Web and its importance, but also how Gears can help to push the web forward. In our conversation, he asked, "If you were to add functionality to Gears that doesn't enhance the web's existing technologies, but rather creates new ones that live in the browser through Gears what would these look like?" The following was my response:"

Russ wants better data-binding primitives and a refactoring of CSS to include variables, better layout management, and hooking into some kind of new component model for the web.

Russ also isn't gung-ho about JavaScript 2:

"I'm in the group of people that isn't totally gung ho about JS2. I understand the motivation, but its looking like a bit of a kitchen sink language. I think JS needs some improvements, but I'm actually looking at Erlang for inspiration instead of Java and Python. In my vision of a future JavaScript, I see a few things. First of all, I think there are some functional language features that would be good to add considering JavaScript is already a very functional language. I would like to add overloaded functions that use matching and guards for differentiation. I would also like to steal some aspects of the big Erlang feature of concurrent processes. Here, I think, is a perfect convergence with Gears. The Gears worker pools are a lot like Erlang processes (which I'm guessing you knew). No shared state, separate process, and no access to the dom. As I'm sure you know, this can be extremely helpful when trying to stay secure doing mashups, offload intensive operations from the main thread, and communicate with the server. Additionally, I think that there needs to be a little more in the way of modularizing code, allowing private data members, and facilitating better code reuse. I think prototypal inheritance and mixins are definitely better than classes for the language, and I'd like to add some more syntax to encourage them."

As they say in open source, code rules, so I told Russ to grab the Gears source and build it. We can have lots of discussions about how the web should be, but nothing speaks like actually getting a Gears module out that rolls some of the ideas above, at least in prototype form.

Download the Gears source yourself and build it yourself as well.

Labels: , ,

Tuesday, April 01, 2008

What Is the Open Web and Why Is It Important?

What is the Open Web?

Folks toss the term "Open Web" around a bunch, but what exactly is it? Is the Open Web HTTP, HTML, JavaScript, etc., or is it something deeper? Rather than a laundry list of technologies the Open Web is a set of philosophies. These philosophies include: Notice something very important; at no time above did I bind the Open Web to a particular set of technologies. Today the above philosophy is instantiated using a particular set of technologies, including URLs, HTTP, HTML, CSS, JavaScript, etc. However, if we define the Open Web in terms of these technologies, then we risk losing sight of what makes the web special and being able to have the intellectual nimbleness to evolve the infrastructure of the web. For example, we can and should evolve better layout languages than CSS, better document formats than HTML, etc., especially if we want the web to survive as a long-term social institution and public good, similar to the electricity grid, public-water systems, etc. We will be fighting yesterdays battle while allowing new, proprietary technologies to take over if we focus on technologies rather than philosophy. If we take the long term view, how can we give the web an open enough infrastructure to evolve over time and meet each generations needs, while maintaining its structure enough to actually mean something and stay true to its promise, similar to the U.S. Constitution?

Why does the Open Web matter?

The Open Web is like something from an Arthur C. Clarke science fiction story: its a globe spanning, hypertext network containing billions of documents, conversations, and applications, used by a huge cross section of society. Who would have thought it ever would have been successful or stayed as open as it has? It's not controlled by any one government or company. Our historical closeness to the web creates a kind of myopia, where we can't see how amazing it is. It's a billion Library of Alexandria's dropped into our laps.

Douglas Engelbart, father of much of what we have in the computer industry, including the mouse, hypertext, and groupware, thought that computers would become as fundamental to humanity as the development of writing and language have been. Language is probably only about forty-thousand years old, while writing is only about eight-thousand years old. If you pull back and take the larger view, the web and computers are part of a grand development playing out over decades around new tools for communication. Writing and language have fundamentally changed our sense of self, with positive and negative ramifications; computers and the web hold the same promise, though it will take decades for this to play out.

If the web and computers hold this promise, its important to keep the resulting system as open and accessible as possible. Do we want a system that devolves into something like Ancient Egypt, with an authoritarian force controlling and centralizing the water supply? Many archaeologists believe that deep control of access to water, literally something required for life, lead to the longest known authoritarian civilization in history, lasting for thousands of un-broken years. For example, what if the pencil and paper had never escaped the grasp of the Church? If we can keep the open web nimble and open, it can set the stage to fuel further innovations and inventions, just as writing and language gave rise to books, social polities, etc.

How Can We Support the Open Web?

If we agree that the Open Web is important, how do we create a way to update the web and keep it relevant? The U.S. Constitution, for example, includes special provisions to evolve itself and stay relevant. Even with its warts, the U.S. is now the world's oldest and continuous republic.

The web's existing update mechanisms just don't work. It takes years for new features to go from proposal to show up across enough browsers to be used consistently; this is a recipe for fail if we want the web to exist as a long-term entity, rather than a one-hit wonder.

I joined Google to help with a project known as Gears. 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.

I want to look back five years from now and say that I worked with the community to build an open source update mechanism for the web. Why can't we rev the base infrastructure of the web much quicker, plus create more robust, open extension points along the entire web stack, ala Greasemonkey? Is Gears the answer to this? I'm not sure, but its the best answer we have today. Gears is a great way to get the conversation started, plus get HTML 5 out to today's browsers.

On a more prosaic level, Gears gets the following features into today's browsers without waiting years, ready to use by web devs right now:
[Disclosure: I work with the Gears team]

Labels: , ,

Thursday, March 27, 2008

An Update Mechanism for the Web, or N + 1

Alex Russell recently had a great post called "Progress is N+1". An excerpt:

So as webdevs, we must be canny enough to find a way to [do] "better" which doesn't put all of our eggs in any particular basket. Every browser that we depend on either needs an open development process or it needs to have a public plan for N+1. The goal is to ensure that the market knows that there is momentum and a vehicle+timeline for progress. When that's not possible or available, it becomes incumbent on us to support alternate schemes to rev the web faster. Google Gears is our best hope for this right now, and at the same time as we’re encouraging browser venders to do the right thing, we should also be championing the small, brave Open Source team that is bringing us a viable Plan B. Every webdev should be building Gear-specific features into their app today, not because Gears is the only way to get something in an app, but because in lieu of a real roadmap from Microsoft, Gears is our best chance at getting great things into the fabric of the web faster. If the IE team doesn't produce a roadmap, we'll be staring down a long flush-out cycle to replace it with other browsers. The genius of Gears is that it can augment existing browsers instead of replacing them wholesale. Gears targets the platform/product split and gives us a platform story even when we're neglected by the browser vendors.

Gears has an open product development process, an auto-upgrade plan, and a plan for N+1.
I posted a comment there that I want to replicate:

Alex, great post. This is why I joined Google and the Gears team. I believe in the open web and see Gears as a very clever solution to help get us out of the impasse we are all in as web devs. I'd like to look back five years from now and see how we, as a community, constructed an open source update mechanism for the web that cuts cross-browser and cross-platform, giving us leverage to move the web forward and rev it much faster than we have now. Gears is the closest to this we have today. As we say in open source, code rules, so drop on by Gears and contribute Gears modules that make this happen ( Want to see better 2D vector graphics show up cross browser that you can use today? Bake one into 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.

I would add to the comment above and say that Gears, if we can get it embraced by the web dev community itself, means we can finally be in charge of our own destiny! Lets get an update channel into the web itself, vetted by the users and developers of the web itself.

Labels: ,

This page is powered by Blogger. Isn't yours?

Subscribe to Posts [Atom]