Blog on JavaDB sparks debate over thin clients, AJAX, and synch

Blog on JavaDB sparks debate over thin clients, AJAX, and synch

Summary: Yesterday's posting regarding JavaDB (see JavaDB: An idea whose time has finally come) has sparked a glass-half-empty vs. glass-half-full debate between ZDNet reader Justin James and Sun's Francois Orsini that drags the idea of thin clients and AJAX-programming through the mud a bit.

TOPICS: Open Source

Yesterday's posting regarding JavaDB (see JavaDB: An idea whose time has finally come) has sparked a glass-half-empty vs. glass-half-full debate between ZDNet reader Justin James and Sun's Francois Orsini that drags the idea of thin clients and AJAX-programming through the mud a bit. Whereas  James sees little or no merit to AJAX style programming, thin clients and JavaDB, Orsini argues that different use cases call for different models and that AJAX and JavaDB have something to offer in certain scenarios.  Wrote James:

[The people who disagree with me] fell off the same rocker you did too when [David Berlind] drank the AJAX Kool Aid. Have you ever tried writing a piece of AJAX? It is extremely difficult for even the [best] coder to write anything that is even moderately complex. There are browser incompatabilities all over the place; blame whoever you want (browser maker of your choice), that does not change the basic fact. More importantly, the problem with JavaScript isn't just the language itself (although it is extremely weak, even as far as scripting language go), but the interpreters! I don't care if you have Donald Bloody Knuth himself writing the code, it doesn't change the fact that JavaScript interpreters are slower than molasses. Try iterating through a few thousand objects in JavaScript, which is exactly what your little JavaDB scenario will want to do. It will take literally tens, hundreds, or even THOUSANDS of times as long to execute as comparable code outside of the browser. I know. I have done it....Even James Gosling says that AJAX development is incredibly difficult.

Responded Orisini (edited for punctuation):

I don't have to iterate through thousands of records via Javascript - JavaDB supports Java procedures so if I get into some performance issues, I can move the iteration part at the Java engine level and not the Javascript one...Javascript is weak as a scripting language? I guess you are *not* talking about the Rhino engine, are you? Weak in which aspects if I may ask? ....Ajax is a web development methodology - nothing else - It serves a very specific purpose and by looking at how it is being adopted by many popular applications, I fail to see how it would be useless and a possible failure.  Is there room for improvement? Sure there is plenty.  [I] completely agree with this. But Ajax [allows developers] to enhance a lot of Web applications out there as well as creating some next generation ones, and this fairly rapidly.  As far as its complexity [is concerned], well it's everyone's opinion here.  I don't find it complex myself.  But I agree there is room for improvement, Yes.

There are plenty of other tit-for-tat points made by both men and I've invited both to go verbal on the debate with a podcast that I'd host.  Additionally, Sun's chief open source officer Simon Phipps chimed in via his SunMink blog where he sums up my offline-enabler sentiments regarding JavaDB with two words: Local AJAX.  Exactly.  Call it a thin client.  Call it a rich client.  Call it an off-line client.  I don't care.  Imagine if AJAX-based apps could work off the data they need to (or create data) whether there's an Internet connection or not.  JavaDB can serve as a facilitator of Local AJAX when the resources across the Internet that AJAX apps normally connect to are inaccessible for whatever reasons.  Then when the connetivity returns, the local JavaDB-based cache can be synchronized with on-line data.  Via email, Phipps took an even bigger picture view that was more interesting:

I think this is finally the true usage of Java applets emerging, as helper classes for AJAX apps. François calls this "Local AJAX" but I even think it has applications when connected, and not just for resyncing offline stuff. Imagine adding encryption classes. Or a tiny Jabber server than can then use your IM as a UI for your app..

Helper classes for online apps?  Oy.  Hadn't thought of that.  Of course, for JavaDB to serve as such a platform (where the sky's the only limit on innovation), glass-half-full developers who like to push the envelope have to give it a shot and some might not be ready for that yet. Why? Well, as evidenced by JavaDB alternatives that also tackle local persistence, I'll bet that many are interested in the "L" word (local). For example, RedMonk's Stephen O'Grady joined the JavaDB conversation with a pointers to Dojo.Storage -- a technology that leverages Flash's persistence mechanism.  This in turn raises the thin (or rich) client architecture question. If a de facto standard for the basic utility of such a client emerged (utility that all developers could count on being there), what would that utility be? A browser with Java support?  A browser with Flash support? USB (to facilitate the key-fob computer)? Support for all three and maybe others? Standardizing on too many plug-ins or leaving the plug-in architecture of a supposedly thin or rich client completely open for dynamically loadable "helper classes" (perhaps from a USB key) eventually gets us right back to where we started (and to the one thing we're trying to avoid in the name of cost and complexity): a fat client (in which case, developers can count on pretty much everything being available).

O'Grady also hits me up on the synch issue: something I didn't adequately cover in my JavaDB post.  Writes O'Grady:

The problem as I see it in this case isn't the persistence itself; that's easy. Whether it's a file system approach or some sort of database - hierarchical, object oriented, or relational - to me is not the question. The problem, as far as I can see, is syncing: it's difficult enough with rather regimented schemas such as contact databases. For something like a spreadsheet or text document, the problem would seem to be considerably more complicated.

Synching is a point that I addressed in a subsquent post (see More wag the dog: Mobile databases not exactly free).  Judging by the amount of synchronizing that's taking place out there in IT-land, there is huge value to synchronization.  The problem is that there's virtually no standard way to do it (compounded by the multitude of dissimilar data formats at the end points).  In the majority of places where synch is taking place, it's invariably governed by expensively developed and hard to maintain custom code or by a canned solution from a vendor that specializes in synch. 

In either case, there isn't a lot of flexibility and generally speaking, where there's IT rigidity, there's usually opportunity.  Opportunity for standards.  Opportunity for innovation.  Opportunity for open source (to remove the proprietary binds that are in the way). For example, in the same way that some open source project could open up synchronization between Microsoft's handheld version of  its SQL database and a centralized MySQL Server, it could also build a bridge between Local AJAX-driven (L-AJAX) Web authoring (using JavaDB, Dojo.Storage, or whatever) and the MetaWeblog API that services many of blogging systems out there today.  There must be some commonalities to these and other synchronization problems that are fodder for an innovative standard.  Dating back to his days working on Lotus Notes, and then Groove  (both of which can credit their success to synch), and now at Microsoft,  Ray Ozzie -- the king of synch -- must think about this stuff in his sleep. Under his watch, perhaps Microsoft's Creative Commons-released Simple Sharing Extension to RSS is a starting point for addressing some of those commonalities.  Today, I'm aware of several innovations in the works where SSE is being used in an AJAX-driven context to synchronize data across multiple domains.  Why can't your USB key be one of them?

I'm with Orsini on this.  The glass is very much half full. 

Topic: Open Source

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Client-side scripting

    "Local AJAX" is a SPECIFIC form of client-side scripting. I'm with Orisini on this too - using client-side methods enable web technologies to fly! But I'm also with James - Javascript is pathetic and non-standard across browsers.

    We NEED to embed a BETTER scripting language into browsers! If we are talking about using a thin-client with JUST a single app (browser), then wouldn't you want as "rich" a programming environment as possible? JS is an afterthought - the COBOL of web scripting. It works, its everywhere, and it sucks.

    If ANY OTHER SCRIPT LANGUAGE was available, JS would NEVER be used! Think about that one. I can see that trying to choose just one script language would be like eating one Lays potato chip. But too many choices would make it hard for universality. I propose (in the spirit of PAPPL) that Ruby be made the default scripting language of all browsers.

    Yes, I can hear the disagreements now. But I would choose Ruby because there is already the Ruby on Rails work done, and Ruby is compact and Object Oriented. I would make it a straight up choice - Ruby or Javascript - and "enforce" it by getting Konqueror, FireFox and Opera on board . . .
    Roger Ramjet
  • Support nightmare

    As someone who has had to support this type of application (not written in "local AJAX", but a client/server app that provided DB syncing for mobile users), I can tell you that this apoplication model is outright horrid, especially on the support end. It is difficult enough to support the application itself, but when you are sitting on the phone trying to figure out if the problem is the server, the application, the Internet connection, the user, the relevant Nostradamues prediction or the pollen count, you quickly yearn for "the good old days." Another major problem is when someone offline has the ability to make a major data change but that change does not get into the database until much later. Would you feel comfortable in a plane if the radar systems at the airport did not always use real time data?

    Justin James
    • The Pollen Count

      Good one. Next time I'm on the phone with my IT support guy, I'll ask him if my open windows that let the pollen may have had something to do with my problem. I get the drift though. It's complex stuff. Hard to maintain. Anything can go wrong and tough to diagnose. Nevertheless, people are doing it.
  • is here, now, and works across 95% of Internet

    Here's whats great about it's works right now, across 95% of the installed Internet base; no waiting for some futuristic technology or depending on JVMs which are unreliable when scripted from JavaScript. works across Safari, Firefox, and Internet Explorer, and uses features that are found in Flash 6 forward. Flash has more of an installed base than IE: Flash has 97% installed base, while IE 95%. enables offline access as well, and is a generic, pluggable storage system that could even accomodate a Java backend (a Java Storage Provider is planned). Check it out at
    Disclosure: I am the author of
  • JavaScript is good enough

    JavaScript is the c++ of the scripting world: ugly, but with massive installed base. People complain about it and want to replace it with other languages, but I'm more interested in getting work done using the existing installed base than creating something new that will take 5 to 8 years to diseminate across the installed base (which is the traditional amount of time a new web technology can take to reach broad enough of an installed base). What you can do with JavaScript is amazing, and not well known. It is in fact an object oriented language, with functional language support such as closures and first class function objects; plus, it has perl 5 regular expressions. It's performance can also be very good if you know when to use it and how; for example, don't transform a huge amount of data with JavaScript; use XSLT on the client side with XML, for example, which is much faster.
    • Question on naming conventions

      Didn't Javascript have it's name changed to EcmaScript?
      • Other way around, I beleive

        It is my understanding that "JavaScript" was Netscape's name for their implementation of ECMAScript. I am also pretty sure that Netscape did not actually originally do ECMAScript, but were the first to use it in a product. But this was a long, long time ago and my memory is a touch fuzzy on it.

        Justin James
  • Synch is the difficult problem

    Having written an offline AJAX prototype (TiwyWiki), I can attest that the synchronization is most of the pain. Somewhat usable error handling of all the scenarios would come second.
    That's not to say that improvements in client-side storage wouldn't matter though: I'd love to see a richer API than getValue and setValue ;-)

    More info at

    Why not start a offline AJAX discussion group or mailing list?
  • It would be better to use Java

    If you are going to start persisting data on the client and install JavaDB, you might as well go to a full Java solution using applets or better yet, Web Start. Java is like the Rodney Dangerfield of the rich client world - it doesn't get any respect - even though it is a much more robust, peformant and maintainable solution than AJAX and most other languages. Admitedly, it would be better to have a JRE distro that was trimmed down to a bare minimum to speed downloads (just supply the most used 80% of the functionality with the rest a short download away). With broadband access becoming ubiquitous, distributing the JVM is not the huge problem it used to be - but it could be streamlined even more. I'd like to see a little more discussion about Java versus AJAX instead of this crazy AJAX religion that is spreading based on hype and not functionality.
  • Disconnected data

    Would we not use SDO disconnected datagraphs?
    Staged locally and updated on reconnection to some universal store (such as a DHT)?