Web App + Offline = Crappy Client App
on 04.21.08, 06:00am in software • share on facebook • comments (7)
[Venture Beat] It’s a little counterintuitive, but one of the most important frontiers in web development is getting offline — taking applications that have been built online and allowing them to run even when people aren’t connected to the Internet.
Q: What do you get when you cross a browser application with the ability to go offline?
A: A client application without any the goodness that the platform (be it Windows or OS X) has to offer.
Really? Do people really want this?
Don’t get me wrong, I get the convenience of having access to your data from whatever machine your on, but wouldn’t a better model be to store the data in the cloud and provide a good abstraction on top of it so that it could be accessed from either a really well done rich client and a web application?
Point in case: I find it interesting that most of the twitter feeds that I read are created by client applications accessing the twitter API.
Perhaps there’s been so much blah blah blah about web 2.0, social networks, etc., or that folks have just gotten so lazy that they’ve forgotten how to write client applications. It’s sad really.
Mike Moore (April 21, 2008 @ 8:18 am)
Realistically, web apps should provide both cloud storage and local storage. I’ve built offline apps that synchronized with a server (using web services event) when connected to the network, and it isn’t easy or fun. You have to make sure your web services are designed appropriately for the task, and then you have to deal with data conflicts.
But, how much easier would it be if you didn’t have to create a separate app to do that? Don’t you see how it would be simpler to just use the browser for that? Yes, you still have to design your app appropriately, but you don’t need to implement the app twice. You can build a client app for offline use, but you don’t _have_ to.
Twitter is on the other end of the spectrum. Its a great service that many like to consume with 3rd party apps. But it isn’t an offline app, so I don’t think the inclusion in a discussion about offline capabilities of the browser adds much.
smakofs (April 21, 2008 @ 9:39 am)
Easier? Sure. But does that make a great client app? No, not in my opinion.
Perhaps I’m a dinosaur, but I’d rather have a *real* application that uses the rich resources and features of the operating system I’m on, including it’s native controls, rather than having it shoehorned into a browser, just because the developer is too lazy.
Twitter - yeah, you’re probably right, just was an example of a defacto Web 2.0 site, where client usage is high.
l.m.orchard (April 21, 2008 @ 10:11 am)
“folks have just gotten so lazy that they’ve forgotten how to write client applications”
I think this is pretty close to it - although I wouldn’t say “lazy”. I’d say that many (most?) people using these new offline-web kits to build desktop apps have never learned how to build a native app. And suddenly they don’t have to, now that all the stuff they’ve learned within a browser window “just works” on the desktop.
But “just works” is thhis Uncanny GUI Valley that I’d hoped would die with Java apps on the desktop - all these UI controls and conventions that are almost, but not quite, totally unlike anything anywhere else in the host OS. Ugh.
Mike Moore (April 21, 2008 @ 10:47 am)
@smakofs I don’t think its laziness. I think there is some synergy to providing an offline experience of your online web app, all within the same app within the same browser. You don’t always need the full power of a desktop UI to have a great app. If you do, then you probably aren’t an existing web app.
@l.m.orchard And I don’t think its ignorance. I would be hesitant to construe the desire to get web apps working while offline with a lack of understanding on how to build a native client app. Do you have any evidence to support that position?
Ryan Kennedy (April 21, 2008 @ 5:08 pm)
Of course, to leverage all of that OS goodness you generally have to program in the local dialect (.NET, Objective-C), which makes it really unlikely that you’re going to have cross platform code anymore. You’re certainly unlikely to get much/any code reuse out of the browser-based version of your application. That generally offends most web-based developers so they jump into the arms of Adobe AIR or Mozilla XUL, giving them a cross platform play at the desktop by lowering themselves to whatever lowest common denominator was implemented by their platform of choice. At that point, they’re wondering why they ever decided to leave the browser since that, at least, provides a compelling (zero download) application distribution story.
The Twitter case you cite is interesting because they built a platform and a passable web app on top of it to get users hooked. After that, the community took over and wrote most/all of the client apps.
Maybe that’s the answer: make a great platform and an application that shows the power of the platform without doing everything and let the community fill in the gaps and find new uses for the platform.
smakofs (April 22, 2008 @ 5:45 am)
Ryan - I’m a believer that you need to write client apps in their native dialect. You’re already reusing your data access and storage layer, since it’s hosted in the cloud someplace - who cares if its a client application, web application, embedded device, etc. that uses it, as long as it’s abstracted properly.
Trying to shoehorn a browser application as a great client application, just because its less code to write, doesnt make it any better of an experience for users.
Mike Moore (April 22, 2008 @ 8:17 am)
Ohhhh, I see where you are going. Too bad you didn’t say that in your original post. You want a “great” client application! Well I don’t think anyone is claiming that adding offline capabilities to the web browser will turn web apps into “great” client applications. I think they are instead claiming it can allow for a great web app to be available offline. Those are two very different things. I suspect your expectations have been set too high.