David Notik

From a reader: I think the case for HTML5 is being a bit overstated. Even if it is widely adopted (which I think it will be) I am not sure how dramatically different the experience will be.. It removes the need for plug-in RIA's like Flash and Silverlight, but that is tantamount to standardization of technology that has more or less been around for years.

From one angle, the whole point is indeed that the experience will be the same. So from a typical end-user's perspective, it doesn't matter a hoot.

It does matter for some end-users from a marketing perspective -- just yesterday I met with a prospective client and they wanted to move their (uneditable, unsearchable, unmanageable) site from Flash to HTML. They'd heard for themselves that HTML itself could do any of the cool stuff like animations, while potentially solving the usual pitfalls of Flash because HTML is more a part of the web -- and they're novice. There's been a perception that if you wanted a cool, "flashy", interactive site (especially for entertainment, fashion, arts) you wanted to go with Flash. That's now going out the door, thanks to fodder from Google and Apple and the broader community, and I welcome that. I would have to explain to clients that they didn't need Flash just because they wanted a rotating feature spot or fading graphics on their website!

And it of course does matter from a developer's perspective and a broader development-of-the-web perspective. The case for HTML5 is largely a developers rallying cry, pushing the community to adopt it and pushing tool-makers to support the standard. Why? A web based on standards makes for a better web -- no more plug-in issues (how many businesses refuse to allow Flash) = less dependencies to worry about, deep integration with every other aspect of the client-side stack = a richer experience, lighter-weight and tightly-coupled to the core standard = easier to deploy and support on all kinds of devices on our fragile web, open versus binary = searchable and editable the web way, standard versus proprietary = legally and forever a part of the open web owned by no one, and so on and so on. Further, it bridges a gap amongst the web development community which is important from a broader industry standpoint.

So the case for HTML5 is a case because that's how evolution and adoption goes. It's as simple as that.

Some HTML5 fun:

Apple's HTML5 examples: http://www.apple.com/html5/
Chrome Experiments: http://www.chromeexperiments.com/
Full-on Quake game w/ HTML5 (must be a geek to compile): http://code.google.com/p/quake2-gwt-port/

If you want to try the Apple stuff on Chrome, change your user-agent to trick the site into thinking you're running Safari with this extension: https://chrome.google.com/extensions/detail/aafciojnlamllgpkpdkbamkfgbof...

In response to a discussion about Facebook privacy concerns and what some kids are doing about it with the Diaspora project, I repeated what is a common mantra with me: P2P is the future.

It's just a matter of time. I keep saying it. It needs to happen and it will happen. It will address our issues with giving all of our data to any one big company, with capacity, with privacy, with reliability. Of course, for this to happen complex network infrastructure needs to be open sourced and some things need to be invented. But luckily, the software is what's most important. For us to get there, there need to be major market forces and other incentives at play. One such force is the backlash over privacy we're seeing -- and we'll continue to see a lot more until efforts start being channeled towards open source, decentralized and distributed alternatives. Eventually, they'll be just as good as centrally served experiences, and eventually they'll be better and the current client-server model will be but a memory.

When asked how that fits in with the idea of the cloud, I offered the following explanation.

The cloud is simply a term to describe the idea that the complex infrastructure that serves your applications and your data (i.e. your computing experience) resides "out there in the cloud". It's a marketable term that helps avoid unnecessary talk about servers and datacenters and colocation and content delivery networks. All of the messy stuff from expensive hardware to expensive security processes and more is handled by one or more companies, and you just consume using thin clients (i.e. anything with a web browser and a local cache). It helps us into the future, as people start to understand and accept the idea of software as a service.

P2P describes how some of that messy network stuff can work. The idea is that the network is the computer. Everything -- all the code and data -- that makes up our experience is distributed over the countless nodes that are yours and my and everyone's computers. The processing of all that stuff is handled by the commodity processors in all the nodes (our computers, kiosks, anything sufficiently internet connected). There may be companies and governments that offer supernodes which help bring more resources to the grid. All of this stuff is encrypted and distributed and your stuff is only accessible by you.

And in fact that's how much of this stuff is working right now. Google's cloud is really a private distributed P2P infrastructure. They have commodity servers with certain hardware and software specs and these are geographically distributed as well. They just plug in a new node (server) and it starts talking to the other nodes and it's ready to go. There's no dependency on any one node -- if one node dies, traffic avoids it and a new one is plugged right in. Data is distributed redundantly across the entire global network. You log in from anywhere and you've got access to all your stuff.

Imagine if Google released their P2P network to the world (I'm hopeful) and we all worked on one of those nodes. Well, that's true P2P. We are all contributing and receiving (more or less depending on your node's constraints) on this P2P network. It's a commons of sorts, owned by no one.

Gone is the issue of Google having all our data -- because it's everywhere and nowhere on a distributed, encrypted network. Gone the Facebook privacy concerns -- because you own your information and you decide how you want it to interact with other services. Gone is the issue of capacity -- as the network grows the more nodes are on it. Gone the ability for the government to subpoena all your search queries from Yahoo or Google -- because your stuff's flowing through no one company. And it would severely hamper the ability of a government like China or Iran to shut down services -- because you can no longer tie a particular service to a particular isolated range of IPs.

Of course, there are so many new challenges... but such is the nature of our evolving world order.

These folks with the project called Diaspora -- I think they get it. I don't care if their project is all smoke and mirrors and nothing ultimately comes of it. As far as I'm concerned they're bringing a necessary and oft-ignored discussion to the forefront. I welcome that.

There's been a lot of banter about Apple's refusal to support Adobe's Flash on its iWhatevers. Adobe weighed in unofficially and now Apple's Steve Jobs penned a letter.

Mr. Jobs gave the expected reasons for Apple's refusal to support Flash, and all were well articulated. I personally appreciate Apple's stance because I think Flash has to go, but simply find it ironic that Apple is pushing for an open web in this case. Mr. Jobs, although you skim over apps in your diatribe, we know the full story. Proprietary apps that only work on your devices do their fair share to stifle the open web. But I do understand that going this route allows you to offer a clean experience that's tightly coupled with the device right now, and I'd like to have faith that you will one day evolve this situation along with evolving web standards, and eventually abandon device-centric apps in favor of the open web. How and how quickly you do this will tell me a lot about your true interest and relevance in the open web you claim to espouse.

Many (including Adobe) would argue that Apple is unnecessarily being picky about the way things are built for their platform. Flash, they say, is a framework and language that has great tools and a great following so why not support it?

Well, for one, if you think Apple should simply give you choice with little other consideration, you're asking them not to be Apple. Apple is defined by their walled garden approach (see my previous post), making the experience better through thoughtful restrictions. Whether it's limiting their OS to their own hardware or deciding which apps you can run on your device, this approach arguably makes their products better and more accessible for many. Jobs articulated several reasons why Flash will impair the experience, both for the end-user and, they believe, for their developers. If we don't like it (I happen to agree), we can only hope for or create other choices. (And we have other choices with Android, thanks to Google.)

I think it's mostly a happy byproduct that Apple finds itself appearing to protect and support the open web, but they're right to "believe that all standards pertaining to the web should be open", and that is the most interesting part of this discussion. So what if Flash has great tools and a following? That alone does not determine what should be an accepted web standard. Microsoft also happened to have great tools and a following -- but ActiveX was a nightmare that nobody respectable would argue should be a web standard. Web standards are critical to the evolution of the web.

Open web standards are evolving (with HTML5 and beyond) to include native video, animation and 3D and it's imperative that this happens. Apple may have beef with Adobe and their own inane or justified reasons for not supporting Flash in the meantime, but they're in a better position to do this because the web development community knows that Flash must go in favor of web standards and so any uproar is therefore muted because Apple slyly appears to be working on their behalf by not supporting Flash.

Flash, in its current form, will go and must go. I agree with Steve Jobs (woa) that Adobe should focus on evolving their great tools to support web developers and designers who are creating video, animation and 3D for a web that is based on open standards.

The argument continues: but what if someone likes Ruby, Python, or C#? Apple is shooting themselves in the foot by being picky about the way things are built for their platform.

Well, then you'd have to say that the open web is shooting itself in the foot by being picky about the way things are built for its open platform. And that would be ridiculous. If you don't think there need to be web standards, you're on the wrong side.

Do you see what's going on here? Jobs has cleverly shifted the discussion about how open Apple should be to a discussion about the open web and what open really is. In other words, if the open web favors and adopts certain languages and methods in the pursuit of creating a "standard", how can you fault Apple for favoring and adopting certain languages and methods to maintain its standard?

Flash offers client-side web based features and functionality by way of its proprietary, ubiquitous plug-in. Really, the only thing similar is Java, specifically the Java plug-in (not the programming language), and iWhatevers and other devices don't support that either!

Sure, you can create an application in Ruby or Python or C#, heck you can create a desktop application in VB or C that connects to the internet, or an iPhone app in Objective-C that pulls in web content. But these are all outside of the web browser, and they are not web applications by accepted definition. There is nothing even remotely ubiquitous that allows for Ruby to run on the client (i.e. in the web browser), and the same is true of Python and others. The same is *not* true of Java or Flash -- both are unique in that the plug-ins (the runtimes) that allow for them to function on the client side (in a web browser) have been popularized and are ubiquitous. This fact means developers can in fact consider relying on Java or Flash (Flash being a far easier call than Java) for certain client-side features of a web application, and this is *not* true of Ruby or Python or C or Objective-C or others.

Sure, there's an obscure effort to allow for Ruby in the browser (which isn't really so as it relies on JavaScript and Flash given their ubiquity). And there are obscure efforts to force other languages in. But this demonstrates why we need web standards! If everyone tried shoving their language or framework in by way of some plug-in, then we have a very broken web! (How many "I don't have the plug-in" complaints do we see?) To see the web properly, we need web browsers that are all showing us (interpreting) the web in more or less the same way. And so to assuage the issue of one web browser not being able to see the same stuff as another browser, we have web standards guided by committee and community. (There are of course many more reasons.)

The web standard with respect to client-side functionality is centered around JavaScript, interacting with the DOM (Document Object Model, or the hooks into various elements of the page) and standards based features of the web browser (like scrollbars or browser size or LocalCache in HTML5).

Flash is not a web standard. Java is not a web standard. Web standards are necessarily evolving to incorporate what those plug-ins offer, natively. And that means we are choosing to move away from selective dependencies on external plug-ins in support of an integrated, native experience that every web browser can incorporate simply by following relatively light-weight web standards. We are agreeing on an open platform we can all implement and rely on, with no necessary dependency on proprietary or isolated components. With respect to where a web application must interact with external components, say the hard-ware specific accelerometer on an iPhone, there is a standards based way of approaching this where you can detect what capabilities exist on the client and write special conditions to handle that (the same way you'd detect resolution, or detect if you're on a mobile device, or detect if the browser has Google Gears installed for offline functionality).

Still the argument goes on: but allowing other languages and frameworks on your platform is a way to win over those developers and get new apps. Saying no to other great languages and runtimes is bad.

Well, is it bad for the web? I think not. In the world of the web, an open platform owned by no one company, the dynamics are totally different. There are standards for the client side part of the equation. What you do on the server side (or on the development side, i.e. which tools you use to produce the client-side code) is up to you because that's isolated to your environment and the world wide web doesn't need to care so long as you send over the stuff it needs to see and interact with.

Web standards exist to manage the client-side experience. Anybody, anywhere, on any device should be able to have a similar experience. And it's all working over a global network. Given the complex, delicate nature of this open platform, there must be web standards. If web standards did not exist, none of the implementors of the client-side experience (web browser makers, device makers) would know what to support, some technologies wouldn't play well with others, some may be too intensive given network and device constraints, developers wouldn't know how to spend their time, people would be seeing different versions of the web given different client-side implementations, and the whole damn thing would be broke! In this way, there is no comparison to pre-web platforms like Windows.

Now, while Apple can point to the open web to help justify Apple's refusal to support Flash, the correlation is limited.

For one, web standards are thankfully determined in a pretty practical way. Sure, there's the W3C which is comprised of anybody that wants to be a part, and there are community discussions and decisions, but there are also simple market forces at play -- i.e. if HTML5 catches on and there is widespread acceptance among the development community of it as a standard, then implementors (i.e. web browsers) can support it, even before it's ratified as a standard. When there's enough support, developers can leverage these features in the client-side experiences they're building. And the web moves forward.

And web standards, in fact, do have a standard way to support non-standard components -- via a plug-in architecture and things like the object tag. The iWhatevers, on the other hand, do not. But Apple can refuse those non-standard components and still claim it's supporting an open web. As for *why* it would eschew Flash or other languages and frameworks at potentially great expense (e.g. sites don't work and not as many developers are attracted), refer back to the many other reasons Jobs described including the unsaid one that defines Apple: walled gardens make for better experiences in their estimation.

I welcome greater adoption of HTML5 and web standards, from Apple or whomever. I want Flash to go. But Mr. Jobs, if you are rallying behind the open web and expect us to forgive Apple's closed nature and forced restrictions because of it, get out from behind the veil and get fully on board. You may not be able to open up everything right away because of important factors like experience, and I respect that, but when legitimate ways to open up further present themselves (for example web standards evolve to match the speed and device integration of native iWhatever apps), make the right moves. I believe your company's future depends on it.

To an open web.