Re: Application using PostgreSQL as a back end (experien - Mailing list pgsql-novice

I've been doing web apps for about 8 years now and just to add to some of
what William said.

One of the key benefits of a web app is that as long as you stick with W3
compliance, your web app will work on any browser/OS.

Also you can't beat the ease of maintenance with a web app.  When you need
to make fundamental changes to your app, you don't need to push out an
install to the user, you only need to worry about the server.  Which is just
an immense savings in terms of user maintenance.

On another note.  AJAX has made the responsiveness of the web interface more
comperable with a desktop app. There is a point of overdoing AJAX though
where you need to be careful.  For example there is a lot you can do with
plain old javascript and DHTML (e.g. writing tables on the screen, drag and
drop which don't require a trip back to the server to get data).  If your
dataset is for example small - it would be pointless to query back to the
server for every keystroke.  A simple javascript autofill drop down list
will do.  In those cases you would just use javascript and DHTML.

Generation of web apps has also become much simpler than it was way back
when I started.  A lot of toolkits exist out there that do all the messy
javascript, AJAX stuff for you.  For example PHP has PHPSmarty with built in
validators, html boxes etc. , SAJAX which compartmentalizes a lot of the
wizardry of these technologies for very common repetitive tasks.  ASP.NET
has AJAX.net, atlas, tons of commercial and free controls etc.





-----Original Message-----
From: William Yu [mailto:wyu@talisys.com]
Sent: Wednesday, November 16, 2005 11:03 AM
To: pgsql-novice@postgresql.org
Subject: Re: [NOVICE] 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.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster