Hot or Not: The Web as an SDK
Remember back when the iPhone first came out and Steve Jobs proudly announced that the SDK for it was “the web”? Apparently history really does repeat itself because now Google is trying the exact same thing with Chrome OS:
The software architecture is simple — Google Chrome running within a new windowing system on top of a Linux kernel. For application developers, the web is the platform. All web-based applications will automatically work and new applications can be written using your favorite web technologies.
The decision was extremely unpopular with the iPhone but no doubt it will be extremely popular with Google because it matches people’s expectations. Interestingly, the most common reason people give for the iPhone’s success is now the App Store. I guess we’ll get a chance to see if they’re right or not. I don’t see the web as the only API working even though it would work very well for a large percentage of computer usage. Twitter would be a particularly good example of why – you can use Twitter via the web and certainly some people do, but the standalone clients are by far and away the best way to use it. The same generally applies to instant messaging as well.
July 9th, 2009 at 1:10 am
What characteristics of the standalone clients for twitter make them “far and away the best way” to use Twitter?
July 9th, 2009 at 1:14 am
I think the same applies to most apps, and I think its purely a UI thing. Desktop clients tend to have better UIs. The web is in a constant state of UI evolution, but is still very primitive compared to what is possible via desktop apps. The web is getting better – both UI and general capabilities – and, well, if you add things like Java to the mix there isn’t a whole lot you can’t do inside the browser.
For at least a decade we’ve been seeing a prominent shift in focus from desktop to web as the preferred platform for software development. It’s kinda crazy that we’re at the point where people are experimenting with ditching the desktop, untethering ourselves from it, and presenting just the web as the entire experience.
From here, I think we’ll see the evolution of the browser. Without the desktop, the browser still has some niches to fill. Some will be filled via the web itself (Facebook looks like a windows start menu and task bar these days), but the browser can fill in some other parts, too.
I wonder how it will all pan out in the next few years. Definitely some interesting times ahead. We’re questioning and changing the very paradigms of our core interface with our computers. Well, I guess the web has been doing that for a while… but I can see some things really being flipped upside down soon. You can see Google’s been itching to reinvent the OS for a while now.
July 9th, 2009 at 9:51 am
There are a lot of things that can in theory be done with web apps but are nowhere near as seamless as with desktop apps. Window management would be a major part of it for something like twitter or instant messenger. You don’t want an app like that hidden in some tab and taking up the full screen size, so it should appear as a separate window. So do you leave it to the user to drag the browser tab out and resize it or do you pop up a new window at a suitable size automatically? Do you then close the main window? I can’t see how that’s going to make a smooth launch experience.
Then how do you bring your twitter client back to the front to use it? It’s just one of a whole bunch of different browser windows but a standalone app would have it’s own icon in the dock, or it’s own group in the Windows start bar.
You can build solutions to all of these but suddenly instead of developing a web app you’re building a desktop app with a bunch of HTML and JavaScript along and proprietary or at least OS specific extensions to integrate it with the desktop environment properly. Do we really want to develop everything in HTML and JavaScript? If we’re going to spend all this effort making web pages work like desktop apps, why not work to make desktop apps deploy like web apps instead?
July 9th, 2009 at 9:34 pm
Well, there’s the two approaches. Try to give desktop apps the advantages of web apps, and vice versa. For whatever reason, the industry seems more interested in improving web apps.
I think the problems you’re raising with browser tabs will be solved either by the browser, or by portal systems behaving like desktop shells.
July 10th, 2009 at 12:29 am
> proprietary or at least OS specific extensions to integrate it with the desktop environment properly
Well, if the browser is the OS, then perhaps there is no desktop. Web apps in a browser can be seen as an alternative to the “desktop” metaphor. That’s what I’m talking about with changing the fundamental paradigms of interacting. But, yeah, the desktop is useful and the browser or web apps either give a alternative, or use certain extensions to integrate with a desktop.
> why not work to make desktop apps deploy like web apps instead?
Yeah, I’ve often wondered that, too – deployment one of the web’s greatest strengths over desktop software. Of course there’s Java Web Start… but it still uses the web, and Sun just couldn’t polish it and get enough support for it. App Store is another… and it works because Apple are Apple ’nuff said. There are a bunch in the enterprise desktop management space… I used to work with one called ManageSoft that let admins push apps to client desktops in an AD network. And, I’m sure VMWare have an answer to this, too.
But they all suffer from an intrinsic flaw – they attempt to make it easier to deploy an app to the desktop for the user to run. With the web, it’s “just there”. It’s like going Start -> Run -> “word” and having MS-word just pop up without installing it. That’s the level of competition these solutions have with web apps.
By offloading to the server, the client is so thin that it can be deployed on-demand in a very, very short time. Desktop apps can still take advantage of this advantage of client-server to reduce the client app’s footprint, but with the web, the infrastructure’s already there. There’s a nice service locator (browser + address bar + search engine) and the client-server infrastructure is solid and available.
The document metaphor also smashes the entry barrier to create web software. Making a document is simple… from there you can add more software-y bits. This is far simpler than writing and compiling software.
I guess, given these things, it’s seen as simpler to improve the UI of browsers and web apps, than to improve the ease of development and deployment of desktop apps.