Why do people prefer Ajax apps over Java applets?

Discussion in 'Javascript' started by jason.m.ho@gmail.com, Sep 21, 2006.

  1. Guest

    >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
    , Sep 21, 2006
    #1
    1. Advertising

  2. Ivan Marsh Guest

    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.
    Ivan Marsh, Sep 21, 2006
    #2
    1. Advertising

  3. VK Guest

    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 <object> on 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?
    VK, Sep 21, 2006
    #3
  4. weston Guest

    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. :)
    weston, Sep 22, 2006
    #4
  5. 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.
    Richard Cornford, Sep 22, 2006
    #5
  6. VK Guest

    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 <object> tag
    (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.
    VK, Sep 26, 2006
    #6
  7. VK Guest

    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>...</script> blocks 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.
    VK, Sep 29, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    6
    Views:
    767
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=
    Sep 24, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    1,756
    Smokey Grindel
    Dec 2, 2006
  3. Replies:
    54
    Views:
    1,320
    D'Arcy J.M. Cain
    Apr 3, 2008
  4. Hendrik van Rooyen

    Re: Why prefer != over <> for Python 3.0?

    Hendrik van Rooyen, Apr 2, 2008, in forum: Python
    Replies:
    2
    Views:
    276
    Paul Rubin
    Apr 3, 2008
  5. Andrew
    Replies:
    1
    Views:
    1,009
    Joe Kesselman
    Dec 22, 2010
Loading...

Share This Page