Re: Application using PostgreSQL as a back end (experienced programmers

Bill Dika wrote:
> Furthermore, I think that if it did use a web interface, it would not be
> nearly as responsive as it is. That is why I was thinking of not using a
> browser. I use SQL-Ledger for my own bookkeeping. It is written in Perl,
> uses PostgreSQL as a backend and a browser for a front end. While I like
> the program very much and enjoy the freedom of using it as compared to
> something like say, Quickbooks, there is a noticeable delay when loading
> a form. This delay seems to be much less in stand alone programs that do
> not use a browser. Or am I wrong about this? In any case your

Basically, the issue with web-based is more of a perception/workflow
problem than performance. Everything is submit->server does
stuff->return results. While you can sprinkle a little Javascript to
make the UI more responsive, using too much Javascript tends to make
your programs hard to maintain.

At least that is how it was before. Now with AJAX, you can background
submit data the moment your user clicks/types something and while
they're still doing their data entry, the server is already processing
their work to either return results faster or update the screen realtime.

A good example of this is comparing Mapquest to Google maps. Mapquest
uses the old paradigm. You click on a map, the mapquest server
resizes/zooms/whatever and creates a new gif for you to download. Google
maps on the otherhand is constantly generating new data while you
navigate allowing what appears a "windows-like" interface.

You definitely have to do much better planning to write AJAX web apps
though. I'm still learning the nuances myself -- trying to figure out
where's the best place to use it in my web apps. I.e. don't go overboard
immediately and try to implement it everywhere. Just use it where the
user perceives UI delays.

Of course, there's the idea of not bothering with AJAX and just living
with the perceived delays. It ends up not being a big deal because (1)
users expect such delays on the web and (2) users get used to such
delays on the web. It was a bit of a concern when we developed our
insurance app as 100% web-based -- users accustomed to switching to
different pages of info instantaneously going to 1 second just for the
browser/submit/return latency. But it ended up being not an issue. Users
adapt, especially if you take advantage of what web apps can do. For
example, use linking so users can go from a page of info/form entry to
multiple ones to either lookup reference info or fill out data needed
beforehand. Users appreciate slower single-click functionality versus an
extremely responsive UI that requires multiple clicks to get into
different areas and back.