Why do people prefer Ajax apps over Java applets?

[jason.m.ho]

>From the common user perspective (like my grandma), why would they care
if its a java applet or an ajax application? Say I want to make a chat
system on my website...If i'm doing really involved Comet push-style
data communication, and rendering everything using DHTML, why would
users prefer that over a java applet?

Moreover, say I use a java applet to transfer data through a socket
connection, then use DHTML to display the data, so that basically the
front end is the same, but the backend is differs, why would a user
prefer the comet-style programming over applet?

I'm asking because I wrote an Ajax chat system through polling, and I
want to switch to a Comet push-style system because polling just isn't
responsive enough. I want to know if I can avoid Comet (since it is
alot of overhead for the server) and just use an applet in the
background to transfer data through socket connections, then use DHTML
to render the chat boxes.

- Jason

[Ivan Marsh]

On Thu, 21 Sep 2006 13:33:44 -0700, jason.m.ho wrote:

From the common user perspective (like my grandma), why would they care
if its a java applet or an ajax application?

Ajax doesn't require anything on the client side outside of the browser...
I don't have the JRE installed on my machine, therefore no java.

[VK]

ja********@gmail.com wrote:

From the common user perspective (like my grandma), why would they care
if its a java applet or an ajax application?

>From the common user perspective they don't give a damn if it's AJAX,

SOAP, Java or Foobar :-) *But* only as long as they just come on your
page and use it. They will care if prompted first to go to some other
site, download a bounch of megs of unknown stuff, install it, and only
then come back. Many may decide do not go throu that.
And unfortunately from a common user you cannot expect a JVM installed.
Right the opposite, it will be most probably Windows XP, IE6 a not a
sign of any Java plugin.

That is really disfortunate, because Java is much better fits to the
spelled task. Whatever it does natively, with JavaScript/DOM can be
done only by rather ugly hacks and workarounds. Maybe there is some
lightweight socket listener to be used as <objecton the page? You may
look around. Overall if we can insert and script Flash, media players
and other stuff: maybe there is a way to insert AIM-like object?

[weston]

VK wrote:

>They will care if prompted first to go to some other
site, download a bounch of megs of unknown stuff, install it, and only
then come back. Many may decide do not go throu that.
And unfortunately from a common user you cannot expect a JVM installed.
Right the opposite, it will be most probably Windows XP, IE6 a not a
sign of any Java plugin.

I've been led to believe Java still has a fairly wide browser
penetration -- something like 90% of visitors to my employer's website,
anyway, according to our web analytics guy.
Of course, (a) this is narrower than Javascript and Flash (both in the
95-99% range), (b) excluding or discouraging 5% of visitors is
generally not a good idea, (c) I'm not really sure how he did the
measurements and if there could be problems with that, and (d) there
may be stats out there which tell a different story. But if it's 90%,
Java certainly remains a servicable option. Asynchronous Javascript
simply has more buzz at the moment. Applets are sooo 1997. :)

[Richard Cornford]

weston wrote:

VK wrote:

<snip>

I've been led to believe Java still has a fairly wide
browser penetration

By the optimistic promoters or Java?

-- something like 90% of visitors to my employer's
website, anyway, according to our web analytics guy.

Unless the web site is of purely general internees (very unlikely) the
sample is no representative, and unless it never uses Java any Java
related statistics derived from its logs will be self-biasing. Remember
that a visitor to a site that needs Java who does not have Java finds a
site that does not work and so goes away and never returns to a site
that just doesn't work for them. While individuals with Java available
find a site that works, browse around it and clock up the hits, and may
even return in the future. This self-biasing effect applies to all sites
that depend upon any particular technology (flash, javascript, Microsoft
only features, etc.).

Of course, (a) this is narrower than Javascript and Flash
(both in the 95-99% range),

See above.

(b) excluding or discouraging 5% of visitors is
generally not a good idea,

Especially if the point of the site is to facilitate (possibly
indirectly) taking money from those visitors. And even more so if the 5%
is the self-biased result of a dependency on a technology and the real
impact in terms of visitors turned away is 20-25%.

(c) I'm not really sure how he did the measurements
and if there could be problems with that,

Using HTTP is enough to make accurate statistics gathering impossible.
If your " web analytics guy" is not making that clear then he probably
is not sure what he is doing either.

and (d) there may be stats out there which tell a
different story.

You can find statistics that will tell you anything at all. The numbers
themselves are always meaningless unless you know a great deal about
what is being measured and how it is being measured.

But if it's 90%, Java certainly remains a servicable
option.

That "if" and "remains" implies that you don't know anything about Java
use as it stands.

Asynchronous Javascript simply has more buzz at the
moment. Applets are sooo 1997. :)

It is possible to make a web site that is just as unusable for someone
with XML HTTP request support unavailable/disabled as it is to make a
web site that is unusable for someone with Java support
unavailable/disabled, that doesn't make either a good idea.

Richard.

[drclue]

ja********@gmail.com wrote:

>>From the common user perspective (like my grandma), why would they care

if its a java applet or an ajax application? Say I want to make a chat
system on my website...If i'm doing really involved Comet push-style
data communication, and rendering everything using DHTML, why would
users prefer that over a java applet?

Moreover, say I use a java applet to transfer data through a socket
connection, then use DHTML to display the data, so that basically the
front end is the same, but the backend is differs, why would a user
prefer the comet-style programming over applet?

I'm asking because I wrote an Ajax chat system through polling, and I
want to switch to a Comet push-style system because polling just isn't
responsive enough. I want to know if I can avoid Comet (since it is
alot of overhead for the server) and just use an applet in the
background to transfer data through socket connections, then use DHTML
to render the chat boxes.

Well, there are a few issues with JAVA vs Javascript.

I thing the most annoying one relates to the fact that many
browsers treat an applet as a plug-in of sorts, and typically
the UI in an applet is a bit detached from the browser, making "granny"
and the rest of us adapt to the typically differing interface.
Probably a close second is that delay while it loads.

As far as latency in javascript chat , this typically has more to
do with the phrasing of the back-end than anything else.
my context servers can even on a $150 computer pump out over
30 fat transactions a second. Far more if all they are doing is those
tiny chat lines

[VK]

drclue wrote:

I thing the most annoying one relates to the fact that many
browsers treat an applet as a plug-in of sorts

Taking into account that NN4 is gone way ago and Microsoft JVM joined
it too, that is the only situation you can expect on a wide run with
Java used on a web-page: just another plugin injected over <objecttag
(leaving out server-side Java like .jsp)
I'd like to avoid a la comp.lang.java.advocacy discussion here, but the
question was posed from the point of view of the most basic regular
user "like my grandma" ;-)

As far as latency in javascript chat , this typically has more to
do with the phrasing of the back-end than anything else.
my context servers can even on a $150 computer pump out over
30 fat transactions a second. Far more if all they are doing is those
tiny chat lines.

The killer with the "Comet" hack is not the per-connection load - it is
negligible. The problem is with the number of simultaneously open
connections. With a more-or-less intensive use and especially with a
sub-optimal server-side processor you'll easily get an analog of DOS
attack on your server - initiated by yourself.

As a reminder: "Comet" hack is based on the age old client spoofing
trick once used for server-side driven image animations on the page.
The core principle is to make the client think that it's downloading
some extremely large file so it would keep the channel open; you also
have to keep some minimum activity over the channel so do not let UA to
"loose the patience" with the "Connection timed out" error. That is
really all wisdom of "Comet". At the pre-historic era one used false
(enormously huge) file size reported for .gif file with server-data
overriding the same scanlines on the picture. With "comet" it is either
an artificially created "border line slow" downstream for say frame or
iframe; or the rather recent miltipart/override MIME in the ajaxoid
response.

Personally I consider all of this *now* as a manually implanted server
virus, but I may be missing the progress curb in this aspect.

In application to web-chats I see nothing wrong with an ol'good ajaxoid
making HEAD request every say second and making GET/POST request as
soon as server reports new data available. That is times more resource
saving, and with all workarounds involved for "Comet" the delay will be
nearly shorter.

Again: maybe I'm just missing the progress here.

[drclue]

VK wrote:

drclue wrote:

>I thing the most annoying one relates to the fact that many
browsers treat an applet as a plug-in of sorts

Taking into account that NN4 is gone way ago and Microsoft JVM joined
it too, that is the only situation you can expect on a wide run with
Java used on a web-page: just another plugin injected over <objecttag
(leaving out server-side Java like .jsp)
I'd like to avoid a la comp.lang.java.advocacy discussion here, but the
question was posed from the point of view of the most basic regular
user "like my grandma" ;-)

>As far as latency in javascript chat , this typically has more to
do with the phrasing of the back-end than anything else.
my context servers can even on a $150 computer pump out over
30 fat transactions a second. Far more if all they are doing is those
tiny chat lines.

The killer with the "Comet" hack is not the per-connection load -

<snip>

I don't uses the "comet" (Content-Type: multipart/mixed;) in my CHAT
servers.

In application to web-chats I see nothing wrong with an ol'good ajaxoid
making HEAD request every say second and making GET/POST request as
soon as server reports new data available. That is times more resource
saving, and with all workarounds involved for "Comet" the delay will be
nearly shorter.

Again: maybe I'm just missing the progress here.

Well, I don't uses AJAX in my chat client javascript code either,
just plain old DOM.

[VK]

drclue wrote:

I don't uses the "comet" (Content-Type: multipart/mixed;) in my CHAT
servers.
I don't uses AJAX in my chat client javascript code either,
just plain old DOM.

So let me guess from one attempt: "slow frame", right? (with
<script>...</scriptblocks coming). I used it once, it can be very
elegant, actually - yet I still prefer one real port listener over any
comets and meteors. But it's IMHO and doesn't matter.