Fabrizio Giudici's Blog

Provocation: with Google Gears, is it still a web app?

Google Gears is a new piece of technology from Google which, in few words, extends your browser with a local database (SQLite) and a JavaScript API that allows applications to keep a persistent state in the client. With this enhancement, e.g. Google Mail can keep a local cache of mail items that can be accessed when you are disconnected. A replication technology would be able to keep local data in sync with the server.

Reasoning with architectural blocks, this sounds very good to me. Indeed I'm a big fan of applications that can work in disconnected mode and replicate the state among different nodes (for now I won't go in further details about the fact that I largely prefer applications where master data is on the user's hardware and the server has just a replication, which is different than the Google Gears model AFAIU). Indeed the capability of working in disconnected mode is the main reason I've been criticizing the idea, pushed by many, that one day the whole world would be a web application. In my mind, applications with local state are RIA, Rich Internet Applications, not web applications. So I see Google's move as a way to admit that the pure web app paradigm won't catch (all) the world.

[The following paragraph has been edited to fix some ambiguous or incorrect use of the terminology, as pointed out by the first comment below; further small edits are in square brackets]

Now let me clarify. A RIA is a kind of web app. My point is that the webapp advantage arises from the concept of "thin client", as it was e.g. used by Sun around ten years ago, at the age of the (soon died) JavaStation:

• Since data are not stored in the client, you can access all of them everywhere you have just a browser, e.g. in a pub or a restaurant.
• If the client hardware breaks down, you don't lose data.
• So, you're not responsible for backups, the service provides is in charge for them.
• You don't have to install and maintain software in the client platform.

This is not just a matter of words: my point is that every time I've been requested to design a system with a web/thin client, it was related to some or all the above points being part of the requirements.

Now, having a stateful client, which - yes - is a local cache but it can hold for some time data that aren't elsewhere (i.e. between two replications), disrupts at least partially some of the points above. In the period between two replications you can't access those data elsewhere, you have to take care of backups, if you break your PC your data are gone, etc... This sounds just as a ["desktop"] RIA to me [, moving things off the original concept of thin, web apps].

But if it [behaves as] a ["desktop"] RIA, which is the advantage of using the web paradigm - and Google Gear? I'd rather say that - and I'm giving up advocating my favourite technology - anything in the set: Java, C#, Objective C, Flex, JavaFX, SilverLight with a local database is probably a better choice. Because they are technologies which have been designed with rich clients in mind, unlike JavaScript, furthermore running in a tweaked browser.

Of course, I'm thinking by extreme and I'd like to provoke some thoughts here - I admit that in the real world there are many shades of gray. Also, I've strong feelings about this, but not a final opinion. What do you think?

PS There's still the "zero admin stuff". But in a world where any fat client can be more or less easily upgraded (today everything and its dog has an update center), do webapps still have a strong advantage? Keep in mind that the local database will make that "zero" a bit heavier...

[For correctness, I'm including the original paragraph that I've edited above. Please don't consider it for the discussion, as terminology was not correctly used]

Of course, please don't focus on words but on beef. Looking at WikiPedia's definition, "... a Web application or webapp is an application that is accessed with a Web browser over a network such as the Internet or an intranet.". This still holds true for Google Gears. But the next sentence is "Web applications are popular due to the ubiquity of the browser as a client, sometimes called a thin client.". Of course, we could even discuss about the meaning of "thin client". To me, the original meaning is what Sun spoke about around ten years ago, at the age of the (soon died) JavaStation: a thin client is mostly a stateless client, with the following properties: ...

Comments

• Web apps can be RIAs. So, I assume, when you say RIA, you referring to deskop RIA applications since you are comparing RIAs to web apps.
  With Google Gears, since the data is stored locally in a database, as you mentioned you would lose data if a drive crashes and the web apps data hasn't been synched to the server yet, which is also the case with a desktop application.

  Although there is a database that is installed etc, the total foot print of Google Gears for Firefox is less than 800 K and since it is a plugin to the browser it is a one time thing and not per webapp, so it is really nice in that perspective.

  If Google Gears is not installed webapps will still behave the same way, zero foot print, no backups needed, you can access the data from anywhere etc, and I think Google Gears will compliment webapps and gives the users even better experience for eg, the user does not need to stop working when there is network connectivity problems, and it is much more convenient and reliable. The apps can be made to synch itself silently in the background after the user comes online.
  One thing though, with this, the users need to made aware that if an app chooses automatic synching (that is with out user interaction unlike the way Google Reader offline mode is currently implemented), and the user made changes to the local database when offline, they cannot expect the changes to be there from a different place (different machine) unless the previous offline changes were synched to the server. The users can think, oh why are my changes not showing here!

  
  There was also the demo on this from Google developer day yesterday on YouTube and the concept of WorkerPool was really interesting.

  Posted by: ksenji on June 01, 2007 at 10:27 AM

• "So, I assume, when you say RIA, you referring to desktop RIA applications"

  Yes, thank you for pointing it out, there's some confusion with terminology in my post and I apologize for it. Hopefully next readers will read this clarification before commenting; in any case I see you got my point.

  I'll comment your other points later, when maybe other readers have added their contributions.
  

  Posted by: fabriziogiudici on June 01, 2007 at 10:52 AM

• Hmm... I've tried to edit the original post to remove the ambiuguity pointed out by ksenji, but it looks like it didn't worked...

  Posted by: fabriziogiudici on June 01, 2007 at 11:04 AM

• Ok, the edit is visible now.

  Posted by: fabriziogiudici on June 01, 2007 at 11:05 AM

• Sometimes it helps to remember that user's don't care for technology in general. As long as a technology does the job, they give a * whether it's a browser app, a RIA or a yet-to-be-invented technology.

  Posted by: christian_schlichtherle on June 04, 2007 at 08:07 AM

• @christian_schlichtherle Absolutely true. My question is from the architect's perspective.

  Posted by: fabriziogiudici on June 04, 2007 at 01:17 PM

• I think you're making an interesting point.

  Now with some of the productivity tools in Netbeans like Matisse and JAX-WS support, it would be fairly easy to slap together a reasonable looking UI running 'natively' down on the desktop, and just hand whole Java objects back to the Web Services running on the server for it to persist them.

  And with JPA you can have a local cache which is really similar to the one deployed on the back end (from the point of view of the coding interfaces). You can reuse the same entity classes for instance.

  So if the local repository is just a pre-cache for the network operations, your concern about the first three point is taken care of and you get the best of both worlds.

  However, that brings us to the fourth point which you mention which I will refer to just as 'deployment'.

  I still think the ultimate deployment mechanism for an application is an executable jar. And the ultimate deployment mechanism for a library is a normal jar. Web start is an interesting idea that never seems to work properly.

  Java Web start, Flash, Flex, Silverlight and the rest all suffer from the same thing - making sure that the client is using the 'correct' version of the runtime.

  The ultimate deployment mechanism for a web app / RIA... I don't think we've seen it yet.

  Posted by: rickcarson on June 04, 2007 at 05:24 PM

• Yes, that's true. And we know that probably Java is a little behind others for smoothness of installation, but things could change with the new JRE in a few months.

  @ksenji: I don't think that a very small footprint (800k) is a very important feature today. I mean, I think people can live with some megabytes to download once and for all, considering that a typical scenario application such as Google Mail would transfer much more than that in a single day (at least that's what happen to me). I'd prefer a bigger runtime if it offers more.
  

  Posted by: fabriziogiudici on June 05, 2007 at 01:18 AM

• 
  But if it [behaves as] a ["desktop"] RIA, which is the advantage of using the web paradigm - and Google Gear? I'd rather say that - and I'm giving up advocating my favourite technology - anything in the set: Java, C#, Objective C, Flex, JavaFX, SilverLight with a local database is probably a better choice. Because they are technologies which have been designed with rich clients in mind, unlike JavaScript, furthermore running in a tweaked browser.

  
  I think you will be very interested to learn about Dekoh.

  Dekoh is desktop platform for applications that deliver integrated experience of web and desktop. You can deploy RIA Java Web applications that use JPA and deploy them on Dekoh platform. Btw, installation is a breeze.

  Posted by: cprashantreddy on June 05, 2007 at 02:06 AM

This work is licensed under a Creative Commons License.