[fpc-pascal] Creating FPC enabled websites

Prince Riley wmarketing3 at gmail.com
Tue Mar 3 23:17:31 CET 2009


Reading the responses on this discussion thread, it appears the 'religious
war' you mentioned in your prior post was unavoidable.

Not to add any fuel to the warring opinions I'd like answer  a comment you
made in response to my response.

The recent push to make web applications (not simply web browsing) perform
more like desktop  applications has been the primary driver behind the Web
2.0 and the improved Javascript engines by Google and the Mozilla people.
They have their own commercial motivations for those improvements, the
primary driver has been the software application developers who want web
apps to perform like desktop ones.

While several traditional "desktop" application scenarios do still exists
that will likely always run directly on the O/S without a web client front
end, the direction of most major software application development efforts
I've witnessed in the past three years have all targeted migrating the
desktop GUI over to a web browser. Others in the discussion thread have
referenced several reasons for this shift already, but the trends continue
to follow the idea of pushing as much of the presentation and processing
layers onto the remote web browser.

Finally, respectfully I must disagree with your comments that the
applications deployment approach " is only true for small
applets used by a broad public. " ignores the TOC and other economies of
scale afforded by portable web applications. Scott Trade and TD Ameritrade
are just two of several examples where sophisticated trading desk and
customer centric web-based applications are running on 100,000s of web
browsers. Just a few years ago these same applications were shipped  to
clients and had to be installed and run on their desktop PCs.

On Tue, Mar 3, 2009 at 2:44 PM, Joost van der Sluis <joost at cnoc.nl> wrote:

> Op dinsdag 03-03-2009 om 12:30 uur [tijdzone -0600], schreef Prince
> Riley:
> > Primarily the reason why is -- especially for DB web applications --
> > is efficiency, maintainability, and scalability. The recent major
> > efforts by Mozilla, Google, and others to improve the performance of
> > browser Javascript engines is due to their experience designing,
> > writing and running CGI based web applications. There is quite a bit
> > of literature and discussion on the web explaining why they are using
> > REST versus CGI (Request/Response)  which you might find helpful in
> > making your design choices.
> All those parties have a interest in trying to get as much as people
> using web-aplications.
> But the key point in this is that people forget that javascript-programs
> are not meant to replace a full-blown desktopapplication.
> What they say, in fact, is that building web-applications on the server
> side isn't a good idea. (They promoted it for years, and finally they
> have come to the insight that it doesn't work) So now they suggest to
> build a client-side web-application.
> But the question they forget is: why would you want a web-application in
> that case anyway?!?!
> Use a db-server and a desktop-application and all your problems are
> gone...
> It's all so narrow-minded. If you have as a rule "thou shall develop
> web-based" all these things become important.
> Web-based applications are usefull when you have users who only use your
> website now and then. In that case it does't matter much if one session
> takes some time on the server - unless you are google, offcourse. (But
> also large community-sites now are releasing desktop-clients)
> If users use the application constantly, don't use a web-application.
> So the things explained in this document from IBM is usefull for very
> large systems which a lot of users (Like Amazon, but they also don't
> like the idea of a full-blown javascript application) or some idiots who
> do things in a web-application while they shoudn't.
> Joost.
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20090303/3fe7d5f7/attachment.html>

More information about the fpc-pascal mailing list