This is a repost of a comment I originally made on Paul Kinlan’s blog. Since it appears that moves to adopt Web Intents in Chrome and other browsers are progressing quickly, I felt that I should reiterate my reservations here.
I’m excited about the prospect of an intent mechanism for the Web to parallel that provided by the Android framework. The Intent has demonstrated itself to be an extremely useful abstraction that broadens the range of applications that it is possible to write; it facilitates the creation of smaller applications that, as a consequence, have greater scope for reuse.
Bringing these benefits to the Web is something I’ve given some thought to (on and off) over an extended period of time, so when I read this post I had already formed a conception of how intents might work on the Web, which it turns out has many similarities and some key differences.
Firstly, I think there is some basic semantic confusion in the API as I understand it. Intents in the Android system can be formulated by one application but handled by another on the basis of its registered IntentFilters. In the web intents API, this distinction appears to have been elided; the <intent> element does not encapsulate an intent, but an intent filter, so is misnamed in my opinion. The <intent> element is also less expressive than the equivalent IntentFilter construct in Android which:
Each of these have important use cases on the Web:
CATEGORY_GADGET) to indicate that it supports this.Personally, I think it’s questionable to embed tags directly into the HTML to record this information. The cost of repeatedly downloading and parsing these tags (which could be numerous) seems out of proportion with the frequency with which the information would be acted upon by a user. In my opinion, a <link> tag to an XML document containing intent information is more in keeping with established patterns (eg. linking to stylesheets or RSS feeds) and provides for greater efficiency since the linked document can be cached by the browser.
And I think that assigning the responsibility of intent selection to the user-agent is a poor choice too (assuming I’ve understood this correctly - the post refers to intents being recorded by “the system” so it’s not clear). My reasoning is partly based on the history of browser plugins, which has been one of progressive deprecation and irrelevance, and originates (I suspect) in the inertia of users: who wants the near-immediate satisfaction of a web page interrupted by the demand to install a plugin? Web Intents could suffer a similar rejection if users are frequently called on to find/choose matching web applications to perform simple actions.
But I think there is another factor that accelerated the descent of plugins: users have gradually become conditioned to expect uniform behaviour of web applications across any browsers. Installing a plugin into one browser would probably have been tolerated better had users not begun to access the Web from such a multitude of devices. It simply isn’t satisfactory for users to go around configuring each system they use to browse the Web.
When I sign-in to Gmail —from any browser— absolutely everything I have customized about the functioning of that application is remembered and it simply works in the manner I’m accustomed to. Were Gmail to adopt Web Intents it would be jarring (and simply inferior) if, when accessing it from someone else’s browser, I was subjected to their intent handling preferences; I would expect my own. It would be better if the intents I had registered, and my preferences for them had been stored in ‘the cloud’.
This leads on to an important question. Android Intents work as well as they do because a privileged system process acts as a broker between applications. The Intent data transferred between applications is stored and transmitted to solely to the system process, resulting in a robust and secure basis on which complex application interactions can be built. The question is, what should that broker be on the Web? I can only see two main candidates: the browser and the cloud. The conception of web intents appears to lean heavily on the former. I can see limitations in both, but my gut (and it’s nothing more than that) tells me that the cloud (if its feasible) is a better fit.
There’s been lots of commentary about Apple’s unveiling of iCloud at the WWDC. I haven’t had any time to contribute my own views, but I have read a number of posts about iCloud (they’ve been difficult to avoid). One thing that has really jumped out at me is the apparent confusion that permeates the discussion of native applications as contrasted to web applications.
For the purpose of this post, I define a web application to be an application composed of HTML pages running in a browser and define a native application as any application implemented otherwise. The “native/web” distinction seems to be poorly understood, here’s my take.
A web application that does not use local storage/caching will probably be rendered inaccessible by a total network failure. A native application that doesn’t use web storage will probably be rendered unusable by a disk failure that corrupts the user’s data partition. The first is more likely, the second is more catastrophic.
Advancing this scenario to reflect more modern implementations, the web application can use local storage to mitigate network failure, and the native application can use web storage to mitigate disk failure. For modern web applications running in modern browsers, the differentiator has little to do with network availability.
Whether it’s true or not, the perception that native applications are inherently more tolerant of network problems than web applications may come to be seen as mostly irrelevant; it may not always be the case that computing devices frequently lose Internet connectivity. And even if reliable connectivity remains elusive, the list of characteristics that are uniquely associated with native applications, including the ability to run offline, can be expected to shorten significantly: Offline availability, Local storage, Geolocation, Media capture Multitouch, Background processes, 3D are all coming (or have come) to HTML, and the list could go on.
I think the issue that will remain least adequately addressed by web applications is that of performance, particularly performance on mobile devices. Putting aside the use of Canvas for producing graphics, animations and games, application UIs that are both responsive and complex remain beyond the comfortable reach of the processors in mobile devices. And unless a revolution in battery technology occurs this is likely to remain the case.
Even accounting for the recent performance improvements in browsers on all platforms (JS in particular has seen spectacular gains), performance lags native applications. This can be masked by more powerful computers, and often by clever application design, but the gap is real and readily detected by users.
In my opinion, there are two essential benefits to web applications over native applications.
Linking
The URL/URI is an incredibly powerful tool. It allows any web resource(*) to reference any other web resource. This is an advantage that native applications lack, almost entirely. Android does expose Intents but these lack a persistent serialized form (and in any case serve a different purpose), nothing else comes close, except perhaps sharing a URL at which the native application’s executable can be downloaded, but this is a weak simulacrum(†).
Anyone can discover a web application, share it’s URL, and in principle invite everyone else in the world with a browser and a connection to the Internet to use it too. No native application is shared in the same way.
Graceful degradation
Though the Web is cross platform, it’s well appreciated that supporting the huge number of browsers that users can throw at a website comes at a marked price in its development; the time spent adapting perfectly good HTML and JS to accommodate bugs in browsers can be colossal. This may precede attempts to progressively refine the web application to take advantage of new browser technologies which could be available.
For extremely complex web applications which are also required to serve very large numbers of users, I don’t think it’s at all certain that the cost of developing a good web-based UI is necessarily less than that of writing a multitude of native applications that could span the same number of users. But where Web development wins incontestably is that the user experience is elastic and though it may be that only a small proportion of users have the best experience, every user can have some experience assuming their device has a browser. Native applications on the other hand lead to a situation where some people simply can’t access the application and never will unless a suitable native application is developed.
And that’s it — there’s no answer to be drawn from all this, certainly no simple answer. The choice one faces between developing a native application and a web application is deeply nuanced. Personally, I love developing both.
(*) More specifically any resource that is complex enough to embed an ASCII character sequence.
(†) Though I do have ideas about how some classes of native application could be seamless linked in this way.
Yesterday I read a blog post which was wholly negative about the !# syntax that’s becoming increasingly popular in the URLs of modern AJAX websites. There are good reasons to be concerned by the broad adoption of hashbangs, since it is a shift away from the well established principle that a URL directly informs the server which resource is being requested (without depending on any interceding Javascript) because it makes serving, bookmarking and indexing more robust.
However, the post was inaccurate about the drawbacks of hashbangs, and I think its author failed to recognize its necessity in some cases. So what, someone is wrong on the internet, which wouldn’t normally bother me, but when I saw the arguments being propagated, I felt it was necessary to post corrections.
First in rebuttal to first the post I read:
Caching, by proxy server or otherwise, is not broken by using AJAX or even a hashbang. The JS/XML fragments served for page content are as elligible for caching as any other content. On the contrary, AJAX often improves cachability, because instead of serving one entire webpage whose content is rendered uncacheable because of small pockets of dynamic content, JS can compose the HTML from separate JS/XML fragments each with their own expiry headers.
It is quite true that only RFC-2396 compliant crawlers will recognize the content. But if you need what hashbangs provide (see below) you are no worse off than if you just used a hash. And if you anticipate that the RFC-2396 standard will see broad adoption (which I do - how many search engines can ignore Facebook and Twitter?) then the concern is diminished.
I don’t see any negative implications for Microformats other than those that were already present in the adoption of AJAX.
The Facebook “Like” widget and other such services already have access (via JS) to the full URL of the page and this includes the fragment. Such services simply need to preserve the fragment in the case that it starts with a !.
Finally, the author dismisses adoption of hashbangs with:
Engineers will mutter something about preserving state within an Ajax application. And frankly, that’s a ridiculous reason for breaking URLs like that.
which is a blasé dismissal of one of the engineer’s core responsibilities, which is to preserve application state in a way that is consistent with the user’s expectations. It boils down to this:
then you must use hashbangs. Occasionally, for reasons of usability/performance, the first condition isn’t an option - and who wouldn’t want the other two?
I’m certainly not advocating that hashbangs are a good thing, or even desirable: I’m a huge fan of progressive refinement (and her sister graceful degradation). But engineers make judgments based on the priorities associated with their website/web-app; though these decisions should be informed by the web’s history, they shouldn’t be bound by them or we’d never have anything new on the web.
One parting comment, which I’ve been intending to make for a very long time…
I’ve been doing lots of Android development, which features a lovely system of Intents which act as entry points into the components of Android applications. These objects capture the information that an application needs to restore a user’s activity within the application; precisely the sort of information that web app developers are attempting to shoehorn into the URL.
So it’s a terrible missed opportunity that Android doesn’t provide either a way of externalizing Intents (as URLs provide for on the web) or alternatively, allow applications to expose their present state as a URL. It would open-up new possibilities, most obviously the ability to bookmark and potentially share one’s location within an application. Think how much more simply Google Analytics would have mapped onto Android had this been considered.
It’s ironic that web developers are trying to fabricate Intents from URLs, while Android developers are stuck doing the opposite.
I’ve been doing my first bit of client side web development in a good while, and thought I would catch up on the latest browser news, which this week happened to be the launch of IE9.
I found an interview with Ryan Gavin, the Senior Director of Internet Explorer, that gave Microsoft’s perspective on what they were looking to achieve with the latest iteration of Internet Explorer.
Two of his comments caught my attention:
We’ve re-architected IE9 to tap into the power of the [whole PC] to really enable experiences that don’t feel like webpages, they almost feel like [native applications].
When did this conversion occur? Perhaps this has been their public position for a while now and I didn’t notice; Microsoft isn’t a company I ever look to to find out what new in web technology.
Evelyn Rusli then asks if Microsoft has any plans to provide IE9 on other platforms. Ryan’s answer is clear enough.
We take a very straightforward point of view, that’s just: the number one experience on Windows - browsing the web. Our job is to make that a fantastic experience, so that’s our focus and that’s what we have here with IE 9.
Elsewhere I’ve read that IE9 will not be supported on Windows XP, only Vista and Windows 7, which together account for around 37% of web requests.
More broadly, the dialog did little more than remind me how far Microsoft have had to come just to reach parity with their competition. Repeatedly stating that they want to ‘support web developers’ to ‘bring their sites to fore’ and ‘re-imagine the web’ will do little to grab the attention of the developers they want to engage. I have never seen any software product come close to raising the levels of bile that Internet Explorer 6 does among web developers; I think Microsoft is still hated for it (a strong word, but I think it’s the right description).
This is how I see it:
It’s 2010, Microsoft have just decided that we need webpages that rival native applications and they’re going to support developers to create these. They’re late, with a browser that will only run on (at maximum) one third of the machines that currently access the web, and they don’t have the goodwill of the web development community at large.
Despite Ryan Gavin’s enthusiasm for what appears to be a good web browser, I don’t think the technical merits of Internet Explorer 9 matter very much at this stage.
