On The Webbyness of an Installable Web App
I’ve heard some talk lately, primarily from Henri Sivonen, regarding whether Google’s notion of an Installable Web App is “webby”.
I am not sure exactly what webby means, but if I had to guess, it would involve the kinds of qualities that Mitchell Baker and Mark Surman believe make the web better: more transparent, participatory, decentralized, and hackable.
Though I’m not fully sold on these newfangled apps, I can think of three ways that they could make the web better.
The Usability of Files
At first glance, one might say that putting some web pages and scripts into a ZIP file marginally reduces transparency, as one now has to unpack it to see the original code.
However, this simple mechanism addresses a significant barrier to web development that isn’t often captured by web standards: casual developers intuitively understand files because—for better or for worse—they’re something that’s an integral part of the way one interacts with their computer from day to day. The notion of creating some files on one’s computer and making them available to the rest of the internet is reasonably simple and profoundly powerful. The operative metaphor of a ZIP file—putting a bunch of files into a little box that can be delivered as a single file and unpacked later—isn’t hard to understand once one knows what a file is. While it’s a bit of a hassle to put things into the box and unpack them, most operating systems already offer tools to make this easier for ordinary users.
Introduce the notion of HTTP Response Headers, however, and barriers start to appear: this is a completely different concept from files, requires an understanding of the Hypertext Transfer Protocol to not be completely mysterious, and requires learning the particularities of tools that one may not even be aware that they’re using.
Dump some files onto a server and you don’t even need to care whether that server uses Apache, Microsoft Internet Information Services, Lighttpd, or something else. Add a requirement to a Web standard that an arbitrary file be served with a special MIME type via an HTTP header, however, and suddenly a casual Web developer has to become aware of an entirely new layer of technology that they were previously blissfully unaware of.
The reason I mention this is because there are at least two different web standard proposals I know of that involve the use of ZIP files to make it easier for casual developers to participate in the web and make it better. One of them is Alexander Limi’s Resource Packages specification, and the other is Google’s proposal for Installable Web Apps. Both of them involve taking things that are currently arcane—configuring a web server to automatically serve files with compression over a keepalive connection and serving an offline web application with a cache manifest of type text/cache-manifest, respectively—and make them easy and understandable for non-professionals.
With some browsers already capable of introspecting into ZIP files, the effectiveness of View Source—the enabler of transparency and hackability—need not be reduced. In fact, it could even be increased: if putting JavaScript into a compressed ZIP file reduces its size enough to make minification less of a necessity when it comes to delivering Web content quickly, then more web content will be delivered in way that others can learn from and remix.
Untethered Applications
Google’s proposal for Web Apps actually makes the internet a more decentralized place, because it contains provisions for creating and sharing entirely serverless, untethered applications. Using the terminology of Jonathan Zittrain, this makes it easier for control to be transferred to the endpoint that users are (hopefully) in control of. That said, there are other proposals that could technically enable similar use cases, such as Brandon Sterne’s excellent Content Security Policy.
Webs of Trust, Not Heirarchies
Another area in which Installable Web Apps could decentralize the internet has to do with the field of trust. It’s currently very difficult to actually prove that a piece of Web content or functionality I created came from me, and wasn’t altered at some point by someone else. The only viable way to do this is via Secure HTTP, which requires asking an authority for permission to issue you a certificate. That this frequently involves paying them money and that the system is susceptible to corruption are besides the point. As Mark Surman mentions in a draft of Drumbeat’s mission statement:
Ultimately, our goal is a strong, safe open internet: an internet built and backed by a massive global community committed to the idea that everyone should all be able to freely create, innovate and express ideas online without asking permission from others. (Emphasis mine)
It should be possible to prove to other people that something came from you without having to ask permission from someone else, and in this respect, even though this mechanism is part of the Web, I would argue that it is profoundly un-webby. Google’s proposal for Installable Web Applications associates an application’s identity with a public key that doesn’t require a blessing from any kind of authority; all versions of the application are self-signed by the key, which makes it far easier to establish trust between a user and an application. The trust model is also more granular and secure, because it creates a trust relationship between the user and the particular application they’re using, rather than the server they’re connecting to—which often isn’t even under a web developer’s full control. It’s because of this that we’re using a similar mechanism in Jetpack; extending it to the entire Web would be very webby, not coincidentally because it establishes a foundation for what could eventually become a web of trust.
Conclusion
While I’m still on the fence regarding whether Google’s proposal for Installable Web Apps are the best solution for a better Web, I do think that they’re a step in the right direction. In particular, they address social issues and usability concerns that, if resolved, will make computing life more transparent, participatory, decentralized, and hackable for everyone.
May 26th, 2010 at 12:11 pm
WRT minification of JS. Is that ever necessary now?
Most browsers support Accept-Encoding: compress,gzip these days.
And it doesn’t even have to be done on the fly, the webserver can and do keep use local zipped copies, mapping a request for /foo.js to /foo.js.gz or /cache/foo.js.gz or whatever.
May 26th, 2010 at 12:22 pm
Google Web Apps will be decentralized? Well, in comparison to what we have now, they will, but if they are indeed the future, I can’t see many ways of it not becoming the beginning of a completely decentralized (albeit in a different way) web app “market”.
For one, it needs to be free. It’s not conceivable that web apps have licenses. It’s bad enough already with paid forum engines and whatnot. If people want to use those, great, but keep them out of this.
For two, it needs to be independent. And as trustful of Google as anyone may be, it’s not healthy that the web app “market” is controlled by anyone with economical interests in all this. Not only because that would inevitably lead to multiple “markets” from different sides, but also because it would become a YouTube for web apps, sooner rather than later.
For three, it needs to be extremely quality focused. In a world like ours, having something like, I don’t know, deviantART, where anyone can upload anything, and public exposure is controlled by public acceptance, and public acceptance is controlled by public exposure, it’s just not good enough. I mean, it would work, but it would be a pain in the ass. If you’re gonna do it, do it right, I think. Otherwise it will barely be an improvement from the “oh! here’s a code that does what I want!” that we see today, that leads to many (professional!) websites having complex javascript code (that doesn’t degrade gracefully) for stuff like hover effects (OMG!) and drop down menus… Which leads me to…
For four… no, not the Smart car… For four, it has to be a school as well as a market. It has to be somewhere developers go to share knowledge, tips, learn the stardards, something that has a wiki, that has tutorials, that has videos, that has demos, that has code and forums and FAQs.
An utopia? Who cares?! As long as H264 doesn’t win the video war and we get a new Firefox version every quarter, I’m happy!
May 26th, 2010 at 12:27 pm
@nemo: Exactly, but the moment webservers need to be specially configured to do anything, casual developers are out of the loop, because it’s no longer “just about files”, but about configuring a web-server to do something special–which could involve talking to a hosting company or a system administrator, consulting the documentation for their web server, editing server-side configuration files, and/or other things, all of which are far more complicated than just throwing things in a ZIP file and uploading it.
I also found when writing my memory profiler that, unfortunately, the vast majority of code “in the wild” that I looked at was minified, which also made it really hard to do meaningful JS memory profiling with.
I’d add, though, that the option to not have to use ZIP files should always be available too: when developing, for instance, a user shouldn’t have to re-package their content every time they want to see what a change might look like.
May 26th, 2010 at 12:36 pm
@Tiago: As far as I can tell, Google’s attempt to standardize Installable Web Apps (see the WHATWG mailing list thread) is entirely decoupled from notions of monetization or licensing—and while I have thoughts on the notion of a “store” for Web Apps, I intentionally didn’t focus on any of those issues in my blog post because I’d like to address them in a separate post.
May 26th, 2010 at 8:35 pm
“With some browsers already capable of introspecting into ZIP files”
Yeah, like Firefox which keeps this capability well-hidden! Firefox should offer itself as a ZIP/JAR/APK file viewer (https://bugzilla.mozilla.org/show_bug.cgi?id=502528 , please confirm it), and put jar files on the web so I can browse them jar:http://download.mozilla.com/firefox/latest/toolkit.jar!/
May 26th, 2010 at 10:44 pm
Pretty much my thoughts exactly and some interesting extras to boot.
I have a few concerns about installable web apps: 1) Installations should be rare, but what will prevent every (major) website asking the user to install it? and 2) How does the user experience port from one computer to another or one browser to another?
At the moment, “installing” a website on a new computer is as simple as entering a username and password…
May 27th, 2010 at 11:35 am
[...] has written a very nice piece that dives deep into the core issues: I am not sure exactly what webby means, but if I had to guess, it would involve the kinds of [...]
June 4th, 2010 at 3:41 am
I tried to articulate what I meant in the WHATWG post. I did not mean the app being transparent, participatory or hackable.
Web apps don’t need to have a participatory component to be Web apps. A single-player game could be a Web app even if the player didn’t participate with anyone.
While you can Greasemonkey the client side of Web apps and View Source, the server side of Web apps can be completely opaque and non-hackable. You don’t get to inspect and hack the server-side part of GMail or Flickr Organizr, for example.
I wrote in the WHATWG post: “I think an essential part of an app being a *Web* app is that you navigate in your Web browser to a URL pointing to somewhere out there *on the Web* and the application UI loads into your browser from out there.”
Consider Web documents: A Web document lives somewhere out there on the Web and when you navigate to its URL in a browser, you can view it. Even if the document gets cached locally, conceptually, the file lives at its URL that points to a server out there in the cloud. If you have an HTML file locally on your computer and you can’t navigate to it using a browser on another Internet-connected computer, it’s just a document in a Web-oriented file format but it’s not really a Web document.
June 8th, 2010 at 2:19 pm
@voracity: Great questions, and I’m not sure what the answers are myself. I think something like Mozilla Sync could be useful here if it turned into a standard.
@Henri: I understand what you mean about the prerequisites for something being part of the Web, in that it needs to be *on* the Web in order to be part of it. Yet this then begs the question of what exactly these things are. Many of my web projects, in fact, such as Parchment, my Bugzilla Dashboard, my about:mozilla redesign, and Mozilla: The Big Picture, fit into this category in that they don’t need a server that I provide, and instead are essentially “client-side apps” whose URLs are only needed to access and use them, but nothing more. Their primary value to users is not that they are located at toolness.com: it’s the actual functionality that the apps provide them. The users would be even more in-control of their online lives if the apps were just on their local computer as a collection of files that they could freely copy and modify, rather than hosted by a domain I own, which could go away or change at any moment.
In other words, I don’t understand why it’s a requirement that every standard browsers use be part of “the web” and available “out there”. Both Web Apps (in Google’s terms) and browser extensions are clearly things of value to users, and could benefit from standardization.