AJAX, why not Applets

[Dilton McGowan II]

Why is AJAX getting such attention, why not just use Applets and have
extreme programming flexibility? Is it so bad if people must download a
single plug-in?

 

[Chris Smith]

Why is AJAX getting such attention, why not just use Applets and have
extreme programming flexibility? Is it so bad if people must download a
single plug-in?

For one thing, yes it is quite a deterrent that running applets requires
downloading and installing a plugin. That's a very large plugin for
someone (part of slightly under half the U.S. population, and a far
larger percentage in many other parts of the world) still working with a
standard phone line.

The bigger deal, though, is that it's a bother to go to the web site,
agree to the EULA, download something, then find and run it, and click
through all the install screens. That stuff isn't impossible -- and may
even be worth it for an application that sees use on at least a weekly
basis -- but it definitely causes more problems and just makes things
look less magical than if it all just works.

The even bigger deal yet, though, is that applets were designed to be
self-contained, and it shows. Even the little box on the page where the
applet is confined to reside demonstrates how little an applet is
actually a part of the web page, and how much it is its own little thing
that happens to reside in a web page. Matching the look and feel of the
applet with a surrounding page is fragile and will never look quite
right. There isn't anything remotely like HTML/CSS where the server can
generate and transmit on-the-fly a huge variety of content and
presentation choices; it's all got to just be there in code, meaning the
client gets thicker and has to load more stuff up-front. That makes it
feel kludgy to use the page.

In short, there are more problems that I can mention in a reasonable
time-frame. JavaScript has its own issues, of course, but use of
JavaScript to communicate directly with the server really is an exciting
and useful idea as a way that applets never approached.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dag Sunde]

For one thing, yes it is quite a deterrent that running applets requires
downloading and installing a plugin. That's a very large plugin for
someone (part of slightly under half the U.S. population, and a far
larger percentage in many other parts of the world) still working with a
standard phone line.

The bigger deal, though, is that it's a bother to go to the web site,
agree to the EULA, download something, then find and run it, and click
through all the install screens. That stuff isn't impossible -- and may
even be worth it for an application that sees use on at least a weekly
basis -- but it definitely causes more problems and just makes things
look less magical than if it all just works.

The even bigger deal yet, though, is that applets were designed to be
self-contained, and it shows. Even the little box on the page where the
applet is confined to reside demonstrates how little an applet is
actually a part of the web page, and how much it is its own little thing
that happens to reside in a web page. Matching the look and feel of the
applet with a surrounding page is fragile and will never look quite
right. There isn't anything remotely like HTML/CSS where the server can
generate and transmit on-the-fly a huge variety of content and
presentation choices; it's all got to just be there in code, meaning the
client gets thicker and has to load more stuff up-front. That makes it
feel kludgy to use the page.

In short, there are more problems that I can mention in a reasonable
time-frame. JavaScript has its own issues, of course, but use of
JavaScript to communicate directly with the server really is an exciting
and useful idea as a way that applets never approached.

Agree with Mr. Smith here, but...

In certain cases Applets are *really* usefull. In controlled situations
where you need i.e. a "grid" gui, access to the users clipboard, printer,
et.c. You can use a signed applet, and extend the usefullness of the
browser as a application-container.

I have used that approach for a couple of customers where the users are
a select group of their vendors or customers, and are so far very happy
with it (for 3 years now).

 

[Andrew Thompson]

That is a very good point Chris, and it seems
lost on most Applet developers. I can select
"Font Zoom - 150%' in the browser menus and a
web page (and it's text and links) will instantly
scale to my needs. An applet (the fonts and such)
won't.

If the author uses styles that do not provide
enough contrast, I can override those styles with
my own (not in IE, but most others). That does
not work for applets either. There is no easy
way for the end user to tweak an applet's PLAF.

I agree, that is part of the problem. So few applet
developers really understand the rigors of web development,
they do not appreciate what the *text* of an actual
web page goes through before it gets presented to the user,
and just how much applets get in the way of that.

I am not saying it would *not* be possible to make an
applet that can gain those advantages (back), But that
would probably require a significant amount of JS, probably
more than it would take to have created the page, and done
basic validation on form fields and such, in a DHTML page.

What? I must admit I have not tried it, but what
is the problem with an applet connecting to any
number of servlets or other documents/resources
on the site from which it originates?

Did I miss something here?

In certain cases Applets are *really* usefull. In controlled situations
where you need i.e. a "grid" gui,

- HTML table

..access to the users clipboard,

- snippet of JS

.. printer,

- 'alt f | p', or 'ctrl p' ..in my browser.

et.c. You can use a signed applet, and extend the usefullness of the
browser as a application-container.

You need to add those things to a (signed) applet
specifically, whereas they come free with a little
well designed HTML and some snippets of JS.

Perhaps you think I am going a little off topic,
but I am also thinking of another thread where the
(D)HTML/Applet divide was being discussed.
<http://groups.google.com.au/group/comp.lang.java.programmer/msg/7f4320f3a5860ce7>

Again in this thread, I find myself wondering if
there is anything in the applet that could not
be done (usually, better, faster and cleaner)
in appropriate HTML/CSS supported by well
written JS.

 

[Dag Sunde]

- HTML table


- snippet of JS


- 'alt f | p', or 'ctrl p' ..in my browser.

An html-table implementing a spreadsheet-like gui, with
multiple selection, cut/copy/paste, formatted print,
save, arrow-key cell-navigation, etc. etc.?

I have thought about trying to implement such a beast in
HTML/CSS/JS several times, but always given up before I've started.

You need to add those things to a (signed) applet
specifically, whereas they come free with a little
well designed HTML and some snippets of JS.

Of course you have to add them, but the complex functionality
I described above (should have been more specific the first time),
does certainly *not* come for free "with a little well designed..."

Perhaps you think I am going a little off topic,
but I am also thinking of another thread where the
(D)HTML/Applet divide was being discussed.
<http://groups.google.com.au/group/comp.lang.java.programmer/msg/7f4320f3a5860ce7>

Again in this thread, I find myself wondering if
there is anything in the applet that could not
be done (usually, better, faster and cleaner)
in appropriate HTML/CSS supported by well
written JS.

The scenario I described above is one of the main reasons I
turn to Applets once in a while. (My customers are brokers,
and live & breathe Excel). So if you have any suggestions on
better, faster and cleaner, implemented in HTML/CSS/JS, I will
be eternally grateful.

 

[Andrew Thompson]

...
An html-table implementing a spreadsheet-like gui, ..

[snip]

Well (harumph) that is a lot more specific than "grid",
and yes, I agree you have already gone beyond what I
would recommend for DHTML. The JS could probably do it,
but the complexities of x-browser support would probably
make the end JS significantly larger than the (compressed)
applet.

 

[James Yong]

Why is AJAX getting such attention, why not just use Applets and have
extreme programming flexibility? Is it so bad if people must download a
single plug-in?

Hi,

Just to add on. I am not sure why people wanted to use Ajax at all.

For form validation, it is safer to have it done at server side rather than
client side validation. Because the user may turn off javascript support of
the browser.

Shouldn't this consideration be taken that it is better not to have Ajax
because it is dependent on javascript.

BTW, I never used Ajax before.

Regards,
James

 

[Andrew Thompson]

....
Just to add on. I am not sure why people wanted to use Ajax at all.

For form validation, it is safer to have it done at server side rather than
client side validation.

In what situations are you recommending the server
does not *also* do validation?

..Because the user may turn off javascript support of
the browser.

Yes, of course they might.

Then again, I dealt with a project where the D/B
programmers wanted to do all validation at the
front door of the D/B, as seemed to make perfect
sense to me (ultimately, the D/B has to look after
itself, first).

As opposed to the GUI people who were arguing that
they wanted to do all validation in the GUI and
'just trust us'.

Since the project had only enough budget to do
one or the other, the managers chose 'client side'
and as a result, chaos reigned as D/B and GUI people
read specs. in different ways, and no end of crappy
data was corrupting the D/B.

If you have to choose '1 or the other', keep the
validation on the server or D/B that is supposed
to be *acting* on the information.

 

[James Yong]

In what situations are you recommending the server
does not *also* do validation?

Hi Andrew,

I think you have gone on to reply the question that you have asked me above
;-)

For form validation, I prefer doing it in the serverside because by doing it
in java
(i don't use XML for validation), I can make the overall code less and also
ensures that the web application works regards of the browser that the
client is using.

Right now, I am looking for some worthwhile reasons to use AJAX.

Regards,
James

 

[Chris Smith]

Just to add on. I am not sure why people wanted to use Ajax at all.

For form validation, it is safer to have it done at server side rather than
client side validation. Because the user may turn off javascript support of
the browser.

Shouldn't this consideration be taken that it is better not to have Ajax
because it is dependent on javascript.

Communication between JavaScript and the server (what's being called
AJAX here) is not incredibly useful for form validation.

The opportunities it presents are exactly in the various interactions
that occur outside of form validation, though. Your post was actually
illustrative of exactly how limited web development generally is.
JavaScript talking to the server is exciting to a lot of people
precisely because it opens up a lot of possibilities besides just
validating forms. For example, it might tell you how many results to
expect as you're typing in a query, so that you can narrow things down
appropriately without a "submit and revise" cycle.

Its most important applications so far come from scanning quickly
through large amounts of data that is loaded on demand... the sort of
thing that was previously possible only with applets or other more
isolated client-side code, but without the disadvantages I described in
my earlier post to this thread. Using JavaScript for this stuff in the
past has been either painful or just plain inappropriate, because of the
time required to reload a page.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Dag Sunde]

Hi Andrew,

I think you have gone on to reply the question that you have asked me
above
;-)

For form validation, I prefer doing it in the serverside because by doing
it
in java
(i don't use XML for validation), I can make the overall code less and
also
ensures that the web application works regards of the browser that the
client is using.

Right now, I am looking for some worthwhile reasons to use AJAX.

A couple of the items at this page is good (althoug trivial):
https://bpcatalog.dev.java.net/nonav/ajax/index.html

One place I've used it is in a situation where the users
(Power plant operators) sends in production plans to the
central grid operator. These production plans are converted
to EDI messages on the server, and processed asynchronously
by an external system (This can take up to 10 minutes).

My client GUI have a small status frame, listing the status
of the different messages the user have sendt. I use AJAX to
poll the server regularly to check the status of the message,
and to update the status-gui accordingly (ie. colored leds)
(Dim Blue: message sendt, Bright blue: message received
Red: message read by EDI and rejected.
Green: message read and accepted)

Large "Treeview" hierarcies, where you only load the top-level
nodes, and load the content of the child-nodes on demand...

 

[Dilton McGowan II]

For one thing, yes it is quite a deterrent that running applets requires
downloading and installing a plugin. That's a very large plugin for
someone (part of slightly under half the U.S. population, and a far
larger percentage in many other parts of the world) still working with a
standard phone line.

For those on a modem connection, I agree, a 16 meg download is a lot. Though
i'm not sure why with so many homes having access to cable that it is such a
high number of people using modems. The sizes of a lot of the files I come
across these days would seem to suggest to me that there are more people on
high speed Internet than not.

The bigger deal, though, is that it's a bother to go to the web site,
agree to the EULA, download something, then find and run it, and click
through all the install screens. That stuff isn't impossible -- and may
even be worth it for an application that sees use on at least a weekly
basis -- but it definitely causes more problems and just makes things
look less magical than if it all just works.

Yup that is ugly, younger tech savy users are more likely to not be deterred
by this I think.

The even bigger deal yet, though, is that applets were designed to be
self-contained, and it shows. Even the little box on the page where the
applet is confined to reside demonstrates how little an applet is
actually a part of the web page, and how much it is its own little thing
that happens to reside in a web page. Matching the look and feel of the
applet with a surrounding page is fragile and will never look quite
right. There isn't anything remotely like HTML/CSS where the server can
generate and transmit on-the-fly a huge variety of content and
presentation choices; it's all got to just be there in code, meaning the
client gets thicker and has to load more stuff up-front. That makes it
feel kludgy to use the page.

Is it possible to write a JavaScript library that maps browser events to the
applet(s) running on that page? Then the applet can consume the whole page
and be responsive like a regular web page.

 

[The Magpie]

Why is AJAX getting such attention, why not just use Applets and have
extreme programming flexibility? Is it so bad if people must download a
single plug-in?

For one thing, yes it is quite a deterrent that running applets requires
downloading and installing a plugin. [snip]

For those on a modem connection, I agree, a 16 meg download is a lot. Though
i'm not sure why with so many homes having access [snip]

The reason is simple - it takes time, even on broadband, and time equals
bandwidth. The less bandwidth you use, the better the responsiveness of
your web application. Add to that the zero-install client requirements
and Ajax gives you all the points with none of the pressure.

The even bigger deal yet, though, is that applets were designed to be
self-contained, and it shows. [snip]

Is it possible to write a JavaScript library that maps browser events to the
applet(s) running on that page? [snip]

It is, and you will find one such example - perhaps the single best
implementation of Ajax that I have ever seen - in the OpenLaszlo
Project. If you want to see what Ajax can do (and how you can use the
installed Javascript library) you can do no better than to pop over to
www.openlaszlo.org and take a look at their example applications and
system details.

Most importantly, they also are well aware that there may be server
issues as well as client issues with the use of applets or even
server-side CGI, PHP, Javascript etc. So much so that Laszlo comes in
two forms - the SOLO one where there is a standard web server such as
Apache with nothing added or one where you can use server-side functions
for added features.

 

[Daniel Dyer]

It is, and you will find one such example - perhaps the single best
implementation of Ajax that I have ever seen - in the OpenLaszlo
Project. If you want to see what Ajax can do (and how you can use the
installed Javascript library) you can do no better than to pop over to
www.openlaszlo.org and take a look at their example applications and
system details.

Most importantly, they also are well aware that there may be server
issues as well as client issues with the use of applets or even
server-side CGI, PHP, Javascript etc. So much so that Laszlo comes in
two forms - the SOLO one where there is a standard web server such as
Apache with nothing added or one where you can use server-side functions
for added features.

Laszlo is not AJAX, it uses Flash
(http://www.openlaszlo.org/about/architecture.html), which means you do
require a client-side plug-in to use it, albeit a smaller and more widely
deployed one.

Dan.

 

[Tim Tyler]

Why is AJAX getting such attention, why not just use Applets and have
extreme programming flexibility? Is it so bad if people must download a
single plug-in?

IMO, Google maps screams out for a proper programming language.

Google opted for a Windows-only desktop application in that case - with
Google Earth: http://earth.google.com/

I /think/ they are using 3D graphics cards, for some of their imaging -
and that's not one of the strong points of Java applets.

Check out http://www.mgmaps.com/ for MIDP Google maps.

 

[The Magpie]

Laszlo is not AJAX, it uses Flash
(http://www.openlaszlo.org/about/architecture.html), which means you do
require a client-side plug-in to use it, albeit a smaller and more
widely deployed one.

That is true, Dan - but its all written in Javascript, XML and the odd
extra media item if you want it. As far as building it is concerned, its
AJAX even though it does compile down to Flash. Personally, I think it
offers the best of all worlds... but I'm greedy for the class finish it
gives.

 

[Raymond DeCampo]

That is true, Dan - but its all written in Javascript, XML and the odd
extra media item if you want it. As far as building it is concerned, its
AJAX even though it does compile down to Flash. Personally, I think it
offers the best of all worlds... but I'm greedy for the class finish it
gives.

It's not AJAX. I've heard this from the horse's mouth.

It is probably architecturally similar to AJAX, in that Flash has
capabilities like and beyond JavaScript's XmlHttpRequest.

Ray