Slashdot Mirror

← Back to Stories (view on slashdot.org)

AJAX Buzzword Reinvigorates Javascript

Posted by CmdrTaco on from the scripting-is-cool-again-now dept.

samuel4242 writes "Javascript may have been with us since the beginning of the browser, but it's going through a renaissance as companies like Google create Javascript-enabled tools like Google Maps . There's even a nice, newly coined acronym , AJAX for "Asynchronous Javascript and XML". A nice survey article from Infoworld interviews Javascript creator, Brendan Eich, who says that this is what he and Marc Andreessen planned from the beginning. Perhaps AJAX will finally deliver what Java promised. Perhaps it will really provide a solid way to distribute software seamlessly."

83 of 541 comments (clear)

  1. AJAX also good for... by Anonymous Coward · · Score: 5, Funny

    cleaning tub
    cleaning toilet
    getting first post

    1. Re:AJAX also good for... by nahdude812 · · Score: 5, Informative

      Oh, and getting all the Slashdot pundits on their soap boxes, preaching about technologies they don't really understand, and making dire predictions about the unworthiness of the tech.

      Seriously, being someone who actually has quite a bit of *real* experience with Ajax (though we were doing it before the term was coined) across multiple browsers, I can say that the ratio of comments which demonstrate the author understands the full implications of Ajax to those who are just spouting nonsense is about 1:75. I've never read an article on Slashdot before where so many comments missed the target, and I feel like I've been around Slashdot for a little while.

      The idea behind Ajax *does* revolutionize the web paradigm. All this nonsense about cross browser compatability issues is just that: nonsense; it works in Mozilla, Firefox, IE, Opera, and Konqueror each on their respective available platforms. I've actually heard people talking about "Ajax enabled advertisements instead of Flash." Other gems like "Ajax doesn't do anything that a well programmed web application can't do," and "It's just needlessly complex web pages" only point to users who fail to grasp the fundamental concept.

      Let me tell you: Ajax is FAST. You don't realize how unresponsive web pages are until you get to play with a web app that is always waiting on you, no the other way around. When I submit information, why do I need to wait for that information to get to the server before I can begin to perform another operation if that operation isn't dependant on the previous? Click Add To Cart then *immediately* start searching for the next item. Stuff like that.

      The amount of data being exchanged is far less (if you do it RIGHT, you people who are talking about using the XMLHttpRequest.responseText property, this does NOT include you). Rather than reload an entire page with all the framework, you're loading only the portion of the page that changed.

      Aside from piecemeal page loading, you also get to load only the relevant data. For example, rather than load a form, and all the form formatting to make the text fields line up correctly, and all the validation code to validate that form, you load a series of XML tags that contain only the basic information needed to tell the client how to lay out the form. The client takes care of generating the HTML for the form, and your form data looks more like this:
      <input name="username" label="User Name" required="yes" minlength="5" maxlength="10"/>
      versus
      <tr class="lightRow"><td class="labelColumn"><label for="username">User Name:</label></td><td class="inputColumn"><input id="username" name="username" maxlength="10"></td></tr>
      , then later form validation code.

      Often times your data fits inside a single TCP packet.

      I'll make this concession: yes, this is stuff that could be done before the Ajax philosophy using Flash or Java Applets. But both require a plugin, and one of them is even proprietary. Both have potential firewall issues, and neither will run on a vanilla Fedora Core build. Both require higher resource consumption for the user, and both lend to a feeling of sluggishness on the site for the user.

      That's not to say that it's not without its dangers. Like all web apps, you can't trust the data from the client. Here the client gets a bit lower level access to the data. You still have to make sure that you're protecting yourself well against data poisoning attacks.

      The thing I like most about this model though is this: It's truly a MVC (Model View Controller) framework.

      The model is of course your server side logic scripts. The View is the browser (the server side logic scripts send back generically formatted data, the browser does all the display). The Controller is the combination of XMLHttpRequest object, and the processing management script on the server. It's very conceivable that you could write a new front end for your application by simply

      --
      Slay a dragon... over lunch!
    2. Re:AJAX also good for... by drew · · Score: 2, Interesting

      nice to see that there are at least a few people around here who know what they're talking about on this subject. kind of hard to find a sane voice around here once somebody mentions javascript.

      what i don't understand is how many people act like they've never seen or heard of this before, and how it's some amazing new paradigm. IE 6.0 is 4 years old. all of the major mechanisms that are commonly used to perform asynchronous IO in webpages have been around more or less unchanged since before then. so why this big burst of interest now? what caused the web development world at large to suddenly wake up to this now? was it really gmail? sure it was probably the most popular use of 'ajax' technology, but it was hardly the first or the most impressive.

      --
      If I don't put anything here, will anyone recognize me anymore?
    3. Re:AJAX also good for... by Anonymous Coward · · Score: 3, Interesting

      The idea behind Ajax *does* revolutionize the web paradigm.

      Don't be silly. It's a nice optimisation. It's very useful, and I use it a lot, but it's not revolutionary.

      For example, rather than load a form, and all the form formatting to make the text fields line up correctly, and all the validation code to validate that form, you load a series of XML tags that contain only the basic information needed to tell the client how to lay out the form.

      Huh? An external stylesheet and generic script loaded from cache means the only thing you need in your HTML are the form controls and a couple of regexps to drive the script. You want to replace that with dynamically loading XML? That's over-engineering that reduces quality.

      The client takes care of generating the HTML for the form

      Sounds like you've just made your application dependent upon Javascript. That's not good practice, and law requires an accessible alternative in many places, so you either don't do this, or have to code the functionality twice, once with Javascript, once without.

      Those who have used good Ajax sites (google maps, gmail) should understand the power behind it, and these sites only break the tip of the ice berg.

      Have you actually looked at the gmail code? It's hideously bad.

    4. Re:AJAX also good for... by tiptone · · Score: 2, Insightful

      to quote you:

      "The amount of data being exchanged is far less (if you do it RIGHT, you people who are talking about using the XMLHttpRequest.responseText property, this does NOT include you)."

      Are you implying that accessing the data being returned using req.responseText is incorrect? How else should it be done, using req.responseXML? Who has a client-side XML parser?

      Also, no data from the client should EVER be trusted, not even a little. So pushing the validation code down to the client is a waste, you're just going to have to do it again on the server side. I'm really not trying to blast you or your comment, it just raised some questions with me.

      --
      Please don't read my sig.
    5. Re:AJAX also good for... by NutscrapeSucks · · Score: 2, Insightful

      The big burst of interest is because Firefox, Opera, and Safari now support XmlHttpRequest, so you can deploy a public web application which uses it. And yes, gmail showed people how.

      Microsoft devs have known about this techinque for a while, but it was catgorized as one of those "Evil IE-Only ActiveX" things that you could only get away with in single platform intranet apps. I also think that most people coming from a non-MS webdev background don't really know anything about proprietary IE APIs other than you shouldn't use them.

      --
      Whenever I hear the word 'Innovation', I reach for my pistol.
    6. Re:AJAX also good for... by elbobo · · Score: 2, Informative

      Sounds like you've just made your application dependent upon Javascript. That's not good practice

      Don't be ridiculous. Web Applications must depend upon a client side programming language. Web pages need not depend on a client side programming language. Applications have specific target platforms and requirements. Pages however are expected to be at least viewable on a much broader range of browser platforms.

      Me thinks you're out of your depth.

    7. Re:AJAX also good for... by nahdude812 · · Score: 2, Informative

      I wish I had one, perhaps I should actually *write* one. We figured out most of the Ajax methodology ourselves, as I mentioned we were doing this stuff before Gmail & the term "Ajax" came along.

      The basic overview is that you have various 's on your page with ID attributes. You create a wrapper function (eg, ajax(function,arguments,onReturn)) which makes a call with the XMLHttpRequest object back to your server, passing the function and arguments. On the server, the function does its processing (you need to make SURE that only functions you expect to be called directly by users can be called through this script). The server side function gets its results ready and hands them back to the server side Ajax script, which formats it as XML and sends it back. Back on the client end, the onReturn code executes across the result data, creating HTML out of the XML being sent, and putting this HTML into the appropriate on the page.

      Only the portion of the page that needs to change actually changes, the user never reloads anything else. Because this happens asynchronously, multiple operations can happen in parallel and the user can continue to interact with the rest of the page while their operation performs in the background.

      Imagine looking at a product listing on an ecommerce site. You can click "Add To Cart" next to each item on the page in rapid succession. You don't have to wait for each adding to successfully register, you click "Add" and it immediately appears in the shopping cart, with perhaps an indicator that the add is still taking place (italicise the text of the product name, for example, and unitalicize it when the add is done).

      The reason why it's a paradigm shift is that this makes the web page behave much more like a desktop application, but it can be more responsive than some desktop apps I've seen which are not capable of parallel operations like this (while processing an action, no further actions can happen). The web developer works only with individual page parts, and they don't have to worry about what else should be displayed on the page. You've already sent data to the client about the user's personal information (login name, view preferences, and such), there's no need to re-send this the next time the user clicks on a link. You get to preserve the state of previous page hits.

      There's no longer a model of pages, it's a functional model. Individual layouts happen as a page hit, everything else is a function call. That function returns raw data and the client lays it out. All formatting is client side, and this combined with the fact that you're only building the portions of pages that changed leads to greatly reduced server loads.

      But most importantly of all, the user never ever waits on the server to respond unless they either need confirmation that the operation has happened, or they are depending on the results of that response for their next operation (eg, when you do a search for a given product, you have to wait for the server to give you that product listing before you can add it to your cart).

      --
      Slay a dragon... over lunch!
    8. Re:AJAX also good for... by elbobo · · Score: 2, Informative

      I also have been writing web applications for five or more years. Client side scripting is more and more an integral part. The lack of it makes them just web pages with some "application" application, like Slashdot for example.

      When you talk about "the web" being the platform, you're not talking about applications, you're talking about web pages with application-like usage patterns.

      Only a fraction of applications built with the browser as the platform require that the most absolute cross-platform "everyone" be able to use them without out of the box.

  2. Rewriting history? by Anonymous Coward · · Score: 5, Informative

    Javascript may have been with us since the beginning of the browser...

    Huh? I don't seem to remember seeing it until about '96 or '97. That's just a wee bit later than the beginning of the browser...

    1. Re:Rewriting history? by KillerDeathRobot · · Score: 3, Informative

      If I recall it was created for Netscape 3. So definitely not the beginning of the browser.

      --
      Thinkin' Lincoln - a web comic of presidential proportions
    2. Re:Rewriting history? by bhirsch · · Score: 2, Informative

      Nope. It made its debut in Netscape 2, along with Java applets. The big hype was the ability for the two to interact, but it never really seemed to happen.

    3. Re:Rewriting history? by Anonymous Coward · · Score: 2, Informative

      Actually it appears JavaScript debuted in Netscape 2.0. (Link via this.)

    4. Re:Rewriting history? by brundlefly · · Score: 4, Informative

      JavaScript first arrived in Netscape 2. In that browser most of the core language was in place, making it one of the first ever prototype-based OO languages to go from concept to reality.

      But in Netscape 2, there were not very many hooks from JavaScript back into the HTML. You had a document object and a window object of course, but beyond that about the only "DHTML" you could do was mostly restricted to manipulating form values and popping open new windows. Useful, to be sure, but that was about it.

      In Netscape 3 they added the document.images array, and that began the whole image-swapping madness that got everyone hooked on JavaScript, for better or worse.

      And then in NS4/MSIE4 they added the competing, incompatible DOMs that got us into the hell years of DHTML. DHTML as a term arrived with the version 4 browsers.

      Give JavaScript some credit for surviving its own history... the language has been through some very rough years, only to now finally get some credit for being a powerful web tool.

  3. Correct me if i'm wrong but... by 0kComputer · · Score: 3, Insightful

    Isn't part of this due to Microsoft's non-complient browser API?

    Go ahead and mod me as flamebait.

    --
    Top 10 Reasons To Procrastinate
    10.
    1. Re:Correct me if i'm wrong but... by costas · · Score: 3, Informative

      Hm, Ajax as these guys mean it, is centered around XmlHttpRequest which IE (6, I think) introduced first (meaning it was a non-standard API). Mozilla actually copied MS, which then made XmlHttpRequest "cool" and we now have this Ajax buzzword business. Never mind that there have been libraries that have been enabling asynchronous DOMServer communication for much longer than Google Maps or GMail...

    2. Re:Correct me if i'm wrong but... by Vraylle · · Score: 2, Informative

      The current iteration of our AJAX library handles IE, Moz, and Opera. While there are browser checks, they're not overly cumbersome.

      It works beautifully in all three.

      --
      Mutant Freaks of Nature: "Frighteningly Addictive"
    3. Re:Correct me if i'm wrong but... by FidelCatsro · · Score: 2, Interesting

      I probably should have said "Did" , ive been checking out ajax and ruby on rails for a few things and I am impressed with both . It will be good to have client side browser scripting which dosn't require 17 hours(slight hyperbole) of testing on various browsers.

      --
      The only things certain in war are Propaganda and Death. You can never be sure which is which though
    4. Re:Correct me if i'm wrong but... by ad0gg · · Score: 4, Informative

      Its been out since IE 5.0 which was released in 2001. I've seen intranet apps use it all the time. Hell quick search, revealed old articles on the subject. I don't get how a 4 year old technology becomes new by simply giving it a stupid name. I even love how the article fails to mention that its been around for 4 years. And i love how the grand parent gets modded flamebait by merely pointing out that it was a Microsoft invention.

      --

      Have you ever been to a turkish prison?

  4. Re:Choosing language by Karma+Farmer · · Score: 2, Insightful

    You're smoking crack. Client-Side scripting has always been in JavaScript or languages that look exactly like JavaScript.

  5. Re:thanks, slashdot by Anonymous Coward · · Score: 2, Funny

    By the way, am I the only one that uses the web with JavaScript turned off for almost every site?

    Yes. Here's your tin foil hat now go sit in the corner.

  6. Ruby on Rails and AJAX by mortonda · · Score: 2, Informative

    Ruby on Rails has been working on this for some time, at least since the 0.11 release back in March. This is a wonderful technique for speeding up web applications. Browse around the web site, or hang out in IRC, and you will quickly see what all the excitement is all about.

    1. Re:Ruby on Rails and AJAX by PerlDudeXL · · Score: 2, Informative

      Correct me if I'm wrong, but Ruby on Rails is server based and AJAX is browser based and I see no way to compare those concepts!?

    2. Re:Ruby on Rails and AJAX by mortonda · · Score: 4, Informative

      True, RoR is server based, but AJAX requires an interaction between both client and server. RoR includes a javascript component called Prototype, which helps handle the client side of things. In addition, RoR includes many helper functions that help you write the appropriate javascript functions, without needing to know much javascript.

  7. widget set by oever · · Score: 2, Insightful

    What we need now (and Google has shown that it's feasable) is a Javascript based GUI.

    Gnome and KDE can conquer all desktops once they are ported to this AJAX framework.

    Where's the first javascript based window manager? Personalized Google is the first step in that direction.

    --
    DNA is the ultimate spaghetti code.
    1. Re:widget set by los+furtive · · Score: 3, Informative

      Try domapi, it has a very polished set of JavaScript widgets and version 4 is currently in beta.

      --

      I'm a writer, a poet, a genius, I know it. I don't buy software, I grow it.

    2. Re:widget set by mmkkbb · · Score: 3, Insightful

      Well, that answers the age-old question: what do end-users need 4 GHz processors for?

      --
      -mkb
    3. Re:widget set by xiphoris · · Score: 2, Insightful

      It exists and it's called XUL, used on the Mozilla platform.

  8. AJAX Won't Deliver... by NardofDoom · · Score: 4, Insightful
    ... until every browser does things the same. A lot of the current applications for Google Maps (like this one) don't work in Safari.

    Unless standards are complied with fully there can never be "one programming language" for web scripting. Anyone who's had to debug Javascript in IE that works in Firefox knows this.

    --
    You have two hands and one brain, so always code twice as much as you think!
    1. Re:AJAX Won't Deliver... by md17 · · Score: 3, Informative

      This is why people are building component frameworks around AJAX. Component frameworks hide the messy browser specific details. This gives a developer who uses these components "one programming language" that works universally and provides a RIA experience.

      AJAX's fate does not rest on all browsers being in full compliance to the standards, it rests more on the implementation of AJAX components. You can read more about my view on this on my blog.

    2. Re:AJAX Won't Deliver... by neoform · · Score: 2, Interesting

      yeah, well i'm developping a web forum using all JS..

      http://www.cslacker.com/

      works fine in IE, Firefox and Safari.. but IE's retarded CSS handling makes things dicey..

      --
      MABASPLOOM!
    3. Re:AJAX Won't Deliver... by Jeff+Hornby · · Score: 2, Insightful

      why bother with IE?

      Are you kidding? Are you out of your mind? Are you trying to lose money?

      These are the things that my clients would say to me if I even asked: why bother with IE? IE still has ~90% of the browser market. If you decide to ignore IE, 90% of the world will ignore you, and you therefore reduce your revenues by 90%.

      You'd be better off ignoring all other browsers and focusing solely on IE than not supporting IE.

      --
      Why doesn't Slashdot ever get slashdotted?
    4. Re:AJAX Won't Deliver... by MightyMartian · · Score: 2, Insightful

      Well hopefully 4.x browsers are going to be in a rather sharp minority nowadays. I don't do a lot of fancy Javascript, mainly just form validation and the like, and I actually haven't had a compatibility issue in two or three years now. I don't even think about the older browsers. If someone is still running IE 5 or Netscape 4, then that's tough for them.

      --
      The world's burning. Moped Jesus spotted on I50. Details at 11.
    5. Re:AJAX Won't Deliver... by rnd() · · Score: 2, Interesting

      I'm sorry but your comment is so off base it deserves a rebuttal.

      IE was around for a long time and the FF developers explicitly decided not to support nonstandard features that not just IE but tens of thousands of websites were using.

      The standards jihad has held back the Mozilla project big time. Why not just display a "non compliant code" icon on the status bar somewhere... even display a security risk popup.

      There was "one programming language" for web scripting back when MS had 95+% of the browser market share, and FF and Moz decided to go on a jihad instead of realizing that the specifics of the standard aren't that important and a de-facto standard is good enough for most people.

      --

      Amazing magic tricks

    6. Re:AJAX Won't Deliver... by FrangoAssado · · Score: 2, Interesting
      IE was around for a long time and the FF developers explicitly decided not to support nonstandard features that not just IE but tens of thousands of websites were using.

      IE's nonstandard features are mostly hacks, and IE has only brain damaged support for CSS. If you ever try to build an actual application in javascript, you can't fail to notice this. Mozilla's decision of supporting whe W3C standards was done in order to have a truly powerful tool for web developers (i.e., people who want to build real *applications* in the web, not just homepages -- for these, i.e. is mostly OK). That, and the fact that it enables the applications themselves (Mozilla, Firefox, Thunderbitd, etc.) to be built in the same platform -- XUL, XBL, javascript and CSS.

      The standards jihad has held back the Mozilla project big time. Why not just display a "non compliant code" icon on the status bar somewhere... even display a security risk popup.

      Mozilla has adopted some nonstandard features from IE, the most used ones are XMLHttpRequest and innerHTML. They are adopted when they are useful and make sense. There are discussions about adopting others, like document.all, but this can't be done easily, because many sites assume that if one nonstandard feature is present, then all of IE's quirks can be counted on: I can't tell you how many times I have seen this:

      if (document.all) { /* IE stuff */ }
      else if (document.getElementById) { /* Mozilla stuff... */ }
      else { /* tell the user it won't work... */ }

      The fact is, Mozilla trying to copy IE's quirky behaviour would most likely fail, because Microsoft would be free to make IE a moving target (the same way they have done countless times before) as soon as they felt threatened (which seems to be happening now -- witness the next "revolutionary" release of IE 7).

    7. Re:AJAX Won't Deliver... by drew · · Score: 2, Insightful

      There was "one programming language" for web scripting back when MS had 95+% of the browser market share, and FF and Moz decided to go on a jihad instead of realizing that the specifics of the standard aren't that important and a de-facto standard is good enough for most people.

      ahhh... right. so should they have followed the de facto standard as implemented in IE 5.0, IE 5.5 or IE 6.0? And how do they verify that they are compatible with whichever defacto standard they chose without visiting every site that uses the de facto standard in some way?

      --
      If I don't put anything here, will anyone recognize me anymore?
  9. So what's the big deal? by Anonymous Coward · · Score: 2, Insightful

    This has been possible for years. I've personally been using this type of scripting in web applications since 2001. Why the big fuss all of a sudden? Is it just because of the new XhtmlhttpRequest object (or whatever the hell its called)? You can do the same thing with an iFrame. Sure, its not as elegant, but it gets the job done. And it registers in your browser history.

    1. Re:So what's the big deal? by Anonymous Coward · · Score: 2, Interesting

      XhtmlhttpRequest isn't new, its been around since 2000 and IE 5.0. What is new is that another browser supports it(firefox) and is no longer and IE only feature.

    2. Re:So what's the big deal? by blakespot · · Score: 3, Interesting
      I've been using XMLHttpRequest to wonderful effect in developing Dashboard widgets for Mac OS X. Seamless, behind-the-scenes data grabs - nothing akin to a page refresh.

      Here's a demo in a proper web page:

      http://www.blakespot.com/xml.html

      Good stuff.



      blakespot

      --
      -- Heisenberg may have slept here.
      iPod Hacks.com
  10. this is good, and here's more material by yagu · · Score: 5, Informative

    For me, the crux of the usefulness and eventual adoption and finally complete embracing of AJAX lies in the article's paragraph:

    Some of the buzz surrounding AJAX has been generated by Web designers as well as programmers. AJAX?s flexibility is invigorating for Web designers because JavaScript can control any aspect of any images or type on a page. Fonts can grow or shrink. Tables can add or lose lines. Colors can change. Although none of these capabilities are new to programmers accustomed to building client applications -- or, for that matter, Java applets -- they are novelties to Web designers who would otherwise be forced to rely on Macromedia (Profile, Products, Articles) Flash.

    I've seen what Google has done with AJAX (e.g., Google suggest), and it's stuff I never imagined could be so repsonsive in a web context. For me it starts to make programming fun again, and web programming an acceptable form of application development.

    When browsers and web first emerged I could see the writing on the wall, but I wasn't happy about it. Browser application writing from the programming perspective was probably the single most giant leap backwards in technology for me (not including technologies introduced by Microsoft)....: you mean, all the years I've spent honing skills writing applications no longer apply? You mean I no longer have "state" as a tool for maintaining sanity in my application???? Hwaahhh??? I have to do what to change the web page???

    While there have been some technologies (ASP, JSP, etc) to help with these issues, none have addressed the responsiveness issue with the web page round trip message loop. AJAX comes close. Now all I have to do is learn it.

    For a great example of the responsive nature of this (I've referenced this before), go to Google Personal Home, set up your own home page, and play... Configure your modules by dragging them around... open and close your g-mail previews. This all starts looking alot like programs actually running locally on your own machine. (I'm assuming all are familiar with and have played similarly with Google Maps.)

    Additionally, here are some very good resources to learn more about AJAX:

    That's it, I'm done.

  11. goodbye javascript! by asr_man · · Score: 2, Funny

    Processing threads running in the background preloads page content..

    Browsers load AJAX applications automatically. Customers are often reluctant to install custom applications, but most people can be convinced to visit a Web site.

    Finally, the reason I was looking for to disable Javascript is here.

  12. Re:DAMNIT Java != Javascript by Anonymous Coward · · Score: 2, Informative

    Nobody here said it did! They said it might be able to deliver what Java promised. NO MENTION of Java and Javascript being the same there. If I say I might be able to deliver what Jane promised, I'm not saying I'm Jane, am I? They're refering to run-anywhere.

  13. Re:thanks, slashdot by Anonymous Coward · · Score: 2, Funny

    Oh yes, I have JavaScript turned off. Also, I browse with a monochrome monitor, my speakers shut off, and my tinfoil hat firmly in place.

    Damn you technology!

    (get over JS)

  14. Re:Slower than Java by natrius · · Score: 4, Insightful

    Having to go back to the server again and again and again to get tiny amounts of data doesn't sound too nice to me.

    That's what you do each time you click on a link to go to a different web page within a site. With AJAX, you only get the data you need. It's not slow. Have you used Google Maps? GMail? That's what's going on behind the scenes, and it makes the experience far better.

  15. Re:Slower than Java by Anonymous Coward · · Score: 2, Informative

    You don't have to do that. Just add a little more data in the initial page load and make the browser do all the work. Once you reach a milestone, then post back to the server. You have to add some server-side validation to keep the script-kiddies at bay, but the performance cost of that is negligible. Also, if you do have to trip back to the server for data, its a lot quicker to just return the data that you need rather than refreshing the whole page.

  16. Java by HRbnjR · · Score: 4, Insightful

    People keep talking like Java has failed and is now dead and gone.

    I have been programming primarily in Java since 97, and if you ask me, it's just *starting* to pick up steam.

    The language itself is just becoming mature - with big strides (generics, etc) in Java 1.5. And only now are we seeing alternate implementations to Suns, with GNU Classpath approaching a million lines of code, and GCJ compiled applications shipping in Fedora Core 4. Java applications such as Eclipse are also just starting to become popular, and Java API's for things like GNOME are just appearing on the horizon.

    So quit calling Java dead :)

    1. Re:Java by poot_rootbeer · · Score: 2, Informative

      So quit calling Java dead :)

      Okay, fine.

      Java applets embedded in webpages are dead.

      But on the other hand, J2EE is heading towards becoming the de facto standard language for server-side web development, as is J2ME for handheld development.

      On the whole, Java is alive and well.

    2. Re:Java by Espectr0 · · Score: 2, Insightful

      The language itself is just becoming mature - with big strides (generics, etc) in Java 1.5

      Big strides? How is a broken design and implementation of a feature become a big stride? Generics in Java 2 version 5.0 version 1.5 suck big time. The implementation does NOT guarantee type-safety. It DOESN'T eliminate casts, they are still being done, with a processing cost, it's just syntactic sugar.

      To try to somewhat fix this horrible implementation, they did autoboxing, a.k.a the worst feature in C#. You would think that adding the int value "8" to a list would make the list a list of ints. But no, they are a list of objects, and old-fashion conversions are done, very slowly.

      The correct implementation would let using primitives types directly, just like C#. It is sad when a virtual clone of Java is better than Java itself, and sad also because Microsoft did it.

      Back on topic, people think another language like javascript is going to succeed? It won't. Javascript works differently in all browsers. At least Java is "mostly" compatible between all vendors.

      --
      Open Source Java Web Forum with LDAP authentication
  17. Gah by American+AC+in+Paris · · Score: 2, Insightful
    Perhaps AJAX will finally deliver what Java promised. Perhaps it will really provide a solid way to distribute software seamlessly.

    All "AJAX" is going to do is sell a bunch more four-color glossies to those IT types with more stars in their eyes than substance in their heads. It's just another vaguely-defined acronym with a catchy ring to it.

    For anybody who actually writes code, things like Google Maps are simply a happy marriage of time-honored techniques and modern browser tricks. They're cool, they're novel, they're useful, they're quite well-written, and they're letting us do things in the browser that used to require plugins--but there's nothing terribly eye-popping about the techniques themselves.

    --

    Obliteracy: Words with explosions

  18. Open up AJAX by iamthesamurai · · Score: 5, Insightful

    There is a need to standardize (as much as possible) the way that AJAX will work in the browser. There are a lot of code-writers and code-copy-n-pasters out there. When you visit one of these sites, you know because the browser may act funny due to poor programming/hacking of Javascript interacting with the server. AJAX is much bigger than just XML messaging, it's an opportunity to bring a more traditional application model to the browser via Event handling and dispatching. Notice that if you have an engine or framework that is well built, it's quite simple to add event handlers like key presses or mouse clicks or even drag-n-drop. If one was to script each element on a page, that gets heavy and can slow the browser. Which - btw, is why AJAX hadn't caught on until recently: computing resources were not sufficient in many cases.

    That being said, everyone should look at http://www.sourcelabs.com/ajb/AJAX Mistakes. There's also a nice list being compiled at http://www.openajax.net/OpenAJAX .net. This combination of technologies has been around for a while, however, as people find them more useful and interesting, there is a need for good information and a solid foundation for folks to work off of.

  19. WANTED - AJAX DEVELOPER by BillsPetMonkey · · Score: 5, Funny

    * Bluechip client
    * Excellent Package
    * London, Engliand Offices

    Requirements -

    * 5 years of writing AJAX apps for enterprise clients
    * 5-10 years .NET Experience on Linux
    * At least 15 years Linux experience

    Call now or apply online by clicking here!

    --
    "It's not your information. It's information about you" - John Ford, Vice President, Equifax
  20. I've been seing this pop up on job postings by hey! · · Score: 2, Insightful

    Of course, most people developing web applications have a little experience in the main technologies in AJAX, particularly DHTML and DOM, which are the critical ones. Only now we have a buzzword that HR an latch onto.

    On the other hand, if they're looking at people who can architect something like Google maps, well, they're going to have to wait until the frameworks catch up. I've got my eye on Echo.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  21. Ajax and Java deliver the same promise by davide+marney · · Score: 3, Insightful

    Perhaps AJAX will finally deliver what Java promised. Perhaps it will really provide a solid way to distribute software seamlessly... (emphasis mine)

    The "promise" of Java (write once, run anywhere) is exactly the same as Ajax. A big implmentation difference is in the runtime. Ajax's runtime is native to the browser; Java's runtime is not.

    If what you need to do can be done with Ajax, then Ajax delivers on the promise, today. Java? Sure, it delivers big-time, if you can live with Web Start and deploying the runtime to every desktop.

    Ajax should be welcomed by Java advocates everywhere. The marketplace are finally "getting it" regarding write once, run anywhere. The limitations of Ajax are substantial, so it won't be long before people need more muscle.

    --
    "We receive as friendly that which agrees with, we resist with dislike that which opposes us" - Faraday
  22. Re:widget set - Try Konfabulator by spookymonster · · Score: 2, Interesting

    Try www.konfabulator.com. It's free to use (nagware, actually) and versions are available for Windows and Mac.

    With Konfabulator, you can build cross-platform (no Linux yet) desktop widgets (similar to OSX Dashboard widgets, but more functional), using XML and Javascript. You can define the different components of your widget in XML, and then write the event handlers in Javascript. Optionally, you can have Javascript dynamcially create the components in the onLoad event handler. It uses the Spidermonkey Javascript engine, also found in Mozilla/Firefox.

    If you give it a try, Check out my widget, ClipDrop (a clipboard manager), in the Gallery.

    --
    - Despite popular opinion, I am not perfect.
  23. Re:Choosing language by Jeff+Hornby · · Score: 3, Funny

    Great idea.

    I've got an .EXE on my site that does some really cool things including encrypting your hard drive. But that's OK, you can pay me $200 and I'll send you the decryption key.

    --
    Why doesn't Slashdot ever get slashdotted?
  24. Re:Slower than Java by ciroknight · · Score: 3, Insightful

    I'd rather go back to the server every time for a small, 2k object than go back to the server for 14k of HTML, and 160k of images/flash/multimedia/etc. For most application's, it's even a smaller object than that. Just look at Google Maps vs Mapquest. Every time you change zoom, Mapquest has to refresh the entire page, whereas G Maps, it's entirely seemless, and doesn't even seem like it's going to the server at all.

    It's got some other potential uses I've been investigating as well. Brings back the whole HTML-based video game idea, now that you don't have to refresh the entire page to change one variable to something useful...

    --
    "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
  25. Re:Choosing language by pthisis · · Score: 2, Interesting

    Client-Side scripting has always been in JavaScript or languages that look exactly like JavaScript

    Or Java.

    And a few niche browsers had alternatives (e.g. http://grail.sourceforge.net/ allowed client-side Python scripts), but none of them ever got anything approaching critical mass.

    --
    rage, rage against the dying of the light
  26. Are we sure it's the buzzword? by twifosp · · Score: 4, Insightful
    I find it hard to believe that the buzzword itself breathed life back into Javascript like the title implies.

    I think maybe the slick apps like google maps is finally showing what good code CAN do, instead of the bloated bug ridden javascripting of yesterday.

    Or maybe I'm just not transcending expectations by thinking outside of the box, and therefore my toolset isn't capable of brigding the information gap causing a chasm with my ability to think forwardly.

    I'm struggling to identify which is worse: The day when we report that a buzzword has made progress, or the day a buzzword actually creates progress.

  27. AJAX + JSON = Powerful combination by MarkEst1973 · · Score: 4, Interesting
    AJAX is great, but parsing XML always sucks. The XmlHttpRequest object also has a property called ".text", which returns the text value of the data.

    Set your content type to "text/javascript" and you can send data over the network and have it be perfectly legal and ready to use. NO XML PARSING!

    JSON (JSON.org) just happens to be legal Python syntax... which makes me think...

    hmmm.... Google has a huge server farm and is renowed for using Python... Google Maps talks client/server using Javascript, not xml... Python and Javascript shared JSON sytax for serializing objects... hmmm...

    It is a very efficient combo: Python, Javascript, JSON, mod_python.

  28. Ajax Q&A... the real one by grangerg · · Score: 4, Funny
    Q.Did Adaptive Path invent Ajax? Did Google? Did Adaptive Path help build Google's Ajax applications? A.Yes. We wanted to call it HTTP, but that was already taken. Q. Is Adaptive Path selling Ajax components or trademarking the name? Where can I download it? A. Oops. Sorry; fooled you. It's not a product; cool acronym though, right? Q. Is Ajax just another name for XMLHttpRequest? A. Damn you kids are smart. Wait! I meant "No". We put "CSS" in there too, and "XML". Yeah; XML changes everything. Q. Why did you feel the need to give this a name? A. Two words: Midlife Crisis. Q. Techniques for asynchronous server communication have been around for years. What makes Ajax a "new" approach? A. Because I said so; I'm Jack Bauer! Q. Is Ajax a technology platform or is it an architectural style? A. Is using the BLINK tag a platform or is it an architectural style? Snatch the pebble from my hand, Grasshopper. Q. What kinds of applications is Ajax best suited for? A. Hmmm... That's a tough one. How about "web pages"? Does that sound nice? Q. Does this mean Adaptive Path is anti-Flash? A. Yes. If we liked Flash, why would we pull our hair out attempting something this complex in Javascript? Q. Does Ajax have significant accessibility or browser compatibility limitations? Blah blah blah... A. My sources say "Yes". ...but if you shake the magic 8 ball again, who knows? Q. Some of the Google examples you cite don't use XML at all. Do I have to use XML and/or XSLT in an Ajax application? A. Yes. We put "XML" in the acronym! Of course you have to! Why? ...because ...because SHUT UP! Q. Are Ajax applications easier to develop than traditional web applications? A. Duh. Are you stupid? Of course they are. We called it "AJAX"; isn't that teh ish? Q. Do Ajax applications always deliver a better experience than traditional web applications? A. Only if we make them. Everyone else sucks.

    And on a serious note: Who was the moron who made the onreadystatechange event handler? Why couldn't you just pass in a reference to the XmlHttpRequest object so people wouldn't be forced to use global variables to store the reference? Is that so hard?

    1. Re:Ajax Q&A... the real one by wootest · · Score: 4, Informative

      I do believe Microsoft was the moron that made the onreadystatechange event handler, along with the rest of the XMLHTTPRequest object.

  29. ...why? by ciroknight · · Score: 3, Interesting

    The thing that's different about an AJAX application is that the application has no file system hooks. About the only things it could read datawise are cookies, and if you're that afraid of webobjects, you've probably already got them disabled and you probably have a hard time with even the simplest websites (read: slashdot).

    Note, this doesn't stop the annoyance factor. Those stupid flash ads will eventually become those stupid AJAX ads, as SVG matures into something usable, and people code more SVG-AJAX apps. But we've still got some time.

    Besides, AJAX could do some good. I could think of it as possible to build a quick and dirty AJAX application to check if the packages on a system are out of date (yes, re-inventing the wheel is bad, but if you're changing the whole framework, sometimes you have to). Or any of the other millions of applications Dashboard widgets are already doing today.

    --
    "Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is." G.W.Bush
  30. Ajax mistakes by afd8856 · · Score: 4, Informative

    Just today I was looking at this page It's a list of ten easy to do mistakes in Ajax apps. Some of them are not that easy to avoid...

    --
    I'll do the stupid thing first and then you shy people follow...
  31. Yeah, But... by Greyfox · · Score: 4, Insightful
    You're still programming in a brain damaged environment. The browser provides a tiny fraction of what the entire system is capable of and a tiny fraction of the refinement of the programming interfaces that have been around since the '70's. The only way that programmers will be able to cope with these shortcomings will be to increase the scope of the browser until it pretty much becomes the OS. At which point we will have gone full circle.

    That being said, this does look like the least annoying of a lot of really annoying hacks to attempt to shoehorn stateful programming into an inherently stateless paradigm. Personally I think we should be rethinking the underlying infrastructure before we build too much on top of it.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

    1. Re:Yeah, But... by drix · · Score: 3, Insightful

      You're missing the point: you don't need that complexity any more. Google Maps basically gives me the ability to use a $300 thin client to accomplish (some of the) tasks I do at work using a $5000 Xeon machine with $10000 worth of ESRI software to do at work. What's more, if Google comes up with some way to make Google Maps better, like, say, add satellite images, they implement that functionality overnight and have millions of users using it the next day. Compare with the release-patch-rerelease paradigm of old. I don't consider JavaScript and the browser and it to be a brain-damaged programming environment--you just have to remember that you are no longer expected to do any heavy lifting on the client side, and the majority of the GUI tasks are already handled for you by the browser itself. Most of the "refinment[s] in programming interfaces that have been around since the 70s" were to simplify those very chores. In that sense, the limited functionality provided by JS is really quite elegant.

      Also, emulating stateful-ness over the web is being handled at a much lower level than the browser these days, and to good effect. See Tapestry.

      --

      I think there is a world market for maybe five personal web logs.
  32. Re:Javascript? by telbij · · Score: 5, Informative

    Quite honestly javascript is a very poor language.

    Actually, Javascript is surprisingly robust. Probably you're referring the platform inconsistencies, which have long been a showstopper. But with recent versions of browsers supporting the javascript standard (ie. ECMAScript) increasingly well, a lot of the major wholes are closing, and you really can write cross-platform javascript with a minimal compatibility layer.

    Javascript is not meant to be a large-scale programming language... it doesn't have strong-typing or other features that you want when developing million-line applications. However, it is still an extremely powerful language providing things like full object-orientation (everything is secretly descended from the window object), comprehensive hooks to HTML, functions as data, regular expressions, flexible data access (eg. objects as hashes), and robust event handling.

    I used to think of javascript as a toy language, but when you get to down to it, it does what it needs to do very cleanly and efficiently without imposing unnecessary overhead on the programmer.

  33. Reinvigorates? by Schnapple · · Score: 2, Funny

    I guess AJAX reinvigorates Javascript. It's a perfectly cromulent term. It sure did embiggen Google Maps

    --

    Schnapple

  34. Re:MOD PARENT UP by Surye · · Score: 2, Insightful

    Is all of slashdot completely retarded this morning? No one confused Java and Javascript as the same thing. They mearly compared the big picture of AJAX and Java, which is portable clientside applications.

    Oh, and "There is one thing for sure though... nothing will finally deliver what Java promised. It's dead Jim. JavaSCRIPT on the other hand..." So, you're saying Javascript on the other hand... may fill that promise? Like the summary says? =D Stop coming to Slashdot please.

  35. Mozilla, XUL and Javascript is better than AJAX by tvlinux · · Score: 2, Interesting

    Mozilla/Firefox browser uses a XML interface that is better than HTML called XUL. All the extensions for Firefox use XUL and Javascript. But signed XUL&Javascript Apps can be server over the web also. Why not use a better interface language than HTML? Yes it is not compatible with IE, but for better specialized applications it would be work.

  36. AJAX is not the end all... by eno2001 · · Score: 4, Funny

    ...and be all of client side scripting. There is another...

    BLEACH (Bloatware + Leanware + Emacs + (x86) Assembly + C + Heroine) has been working wonders for my development. I usually start the day by shooting up in my office, then I start up all of the Office apps (bloatware) on my co-worker's PC to slwo him down. After that, I load up ACIDWARP.EXE (leanware. No DLLs, libs, nothing, jst one EXE and it's small for what it does) on my boss' PC which stuns him for a few hours so he can't keep track of what's going on in the office (usually play Purple Haze in the background). I then open up Emacs on my box and set to work redesigning everything (Screw WYSIWYG. It's overrated.) I also write a lot of my CGI in assembly language to keep the resource usage low and the code tight. C, when it's needed, which is almost never because of how well I can do things in assembly. And finally, another serving of heroine to keep the Jedi Mind tricks fresh. So far, this plan has worked so well, that I've been shuffled through about 70 different companies this year alone. My talents are in demand!

    --
    -"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
  37. Standardization: Flash, Java, AJAX by arete · · Score: 3, Informative

    It's quite possible to build powerful crossplatform applications for the web now - in Flash, Java or AJAX.

    One way is AJAX. To make it work well, you essentially have to write a version of the page for each major browser - which is a lot of work. Of course, there are development tools that make this substantially easier. It is by far the most seamlessly integrated with the BROWSING experience, but is less suited than Flash or Java for real applications - like a game or any other datadriven mouse-interactive thing. I don't believe there is no OOP Javascript in a browser.

    Another way is Java applets. Java has the advantage that lots of programmers learn it to do nonapplet Java work. The big disadvantage is that a big part of the installed userbase has broken M$ Java engines, and it's generally impossible to install a Java engine without computer-admin privs (as opposed to "browser admin" privs)

    The final way is Flash MX 2004 or Flex. Like Java applets, it is a fully featured OOP programming language (Actionscript) It expects to deal with server information, and can innately request data from mostly-arbitrary SOAP Web Services. It also works innately on OSX, Windows and i386 Linux in most all browsers and on a variety of small devices. It doesn't work on more obscure platforms, however, and it's not OSS so it can't be ported by just anybody.

    Summary: If you want to a supercharged browser experience, use AJAX. If you want an application that "just happens" to be projected over the web, use Flash.

    --
    Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
  38. It's still a kludge by Anonymous Coward · · Score: 2, Insightful

    Even with AJAX, web-based applications are still giant kludges. HTML forms is a kludge put together quickly to make web pages interactive. It's still missing basic elements like combo boxes and modal dialogs. Javascript is the same thing, a kludge that some people try too hard to make into a real programming language while keeping it backwards compatible.

    If you want to make real applications using browsers, you need to come up with native support for many more GUI elements, and you need to come up with a scripting language that is robust and geared towards programmers, i.e. totally unlike javascript. Create these two parts with no concern for backward compatibility, stop asking web "designers" to implement interactive applications, and you will have the start of real web-based applications.

  39. Anyterm by krabbe · · Score: 2, Interesting

    Very cool demonstration of what AJAX can do for interactive web applications: Anyterm - an ssh-like web-based terminal that doesn't rely on a java applet. Needs apache2 to run, though. Also, have a look at "livepage," which is part of the asynchronous python web development framework called nevow.

  40. Re:Choosing language by Jeff+Hornby · · Score: 2, Insightful

    The problem with the Graceful Degradation principle is that it makes the same assumption that the designers of HTML made: the only thing people are going to want to do on the web is publish books.

    When you're trying to create a full-fledged application on the web, base HTML just doesn't cut it. Hell, even for most websites, Basic HTML doesn't cut it.

    The problem is that HTML was never really thought through. Creating sites in HTML (or any derivatives like XHTML) just doesn't work. HTML is a good model for the Gutenberg project but a bad model for everything else.

    What we really need is a new language that has nothing to do with HTML that can create complex interactions. Unfortunately that doesn't seem to be happening. Even movements in that direction like XAML borrow too much from HTML.

    --
    Why doesn't Slashdot ever get slashdotted?
  41. No Refreshes! by N8F8 · · Score: 2, Interesting

    THe "big deal" for a lot of web developers is that you can avoid annoying refreshes to update content. Using XMLHTTP you can retrieve your information in the background and use the XML DOM/DHTML to update only what needs to be updated - instead of redownloading an entire page (and flickering). I wrote a chat app a few year ago that worked this way and it was amazingly responsive.

    --
    "God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
  42. Forget AJAX, here's JAH by epeus · · Score: 3, Interesting

    The XML part of XmlHttpRequest is a bit misleading - you don't have to use XML and parse it in the client. If you use a server process that generates an HTML fragment, you can replace the innerHTML of a target id easily.
    I made a JAH example to show how easy this is.
    JAH stands for Just Async HTML

  43. The Interview by lullabud · · Score: 3, Funny

    Interviewer: "I'm here with Brendan Eich, the creator of Javascript. So, Brendan, it looks like some companies are doing some pretty awesome stuff with Javascript these days! Word has it this was what you envisioned for Javascript from the beginning."

    Brendan: "Yeah... um, this is exactly what we envisioned! Awesome tools like what Google is doing with the maps thing, and the... uh... craigslist + Google maps thing! Yeah.. these companies are finally doing exactly what we had originally planned, so... just wait until they come up with--I mean finally catch on to our big picture and we'll let you know what else we had envisioned! You'll just have to wait and see what we take credit fo--I mean, the other ideas of ours they catch on to!"

  44. AJAX will also kick your ass by argoff · · Score: 2, Insightful

    I don't know about you, but between all the nuances in the javascript, and all the newances in the DOM, and trying to figure out where one starts and the other begins, and have you ever tried to figure out which functions/properties work correctly for which object, and have you ever tried to figure out which DOM to use and how to make DOM's of different browsers compatable, or even simply trying to figure out which objects are really on your web page, and then trying to deal with things like XML parsing on top of that, and then now asynchronous communication, not to mention new things in the pipe like XUL, and franlky ....

    Forget the toilets, AJAX is kicking my ASS and I can't imagine that other people who want to do more than copy cutie javascript tidbits aren't having the same problem. What am I missing here?

    1. Re:AJAX will also kick your ass by Jellybob · · Score: 4, Informative

      The thing your missing is Prototype - a Javascript library which attempts (most successfully) to provide cross-platform objects to access common issues.

      It's worth the price just for the $() function, which does a document.getElementById() on the argument ;)

    2. Re:AJAX will also kick your ass by AstroDrabb · · Score: 2, Informative
      Huh? Why don't you look for a real DOM ref? That one is not standards compliant. So if you only care about crappy IE, you are OK, otherwise, you will get a bunch of crap.

      For example, click on the first link in your example. It takes you to "DHTML Collections". It lists "all" as a collection. "all" is not a DOM collection. It is MS specific crap that break compatibility between browsers and makes your web app only work in IE.

      Here is a _real_ DOM reference. This one is standards compliant and will work with the major browsers out there.

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    3. Re:AJAX will also kick your ass by rjshields · · Score: 2, Interesting
      It's worth the price just for the $() function, which does a document.getElementById() on the argument ;)
      $ = function() {
      return document.getElementById(arguments[0]);
      }
      --
      In this world nothing is certain but death, taxes and flawed car analogies.
  45. Re:widget set - Try Konfabulator by snorklewacker · · Score: 2, Informative

    The Konfabulator site needs more categorization. If I took out all the clocks, countdown timers, single-purpose RSS readers, and webcams, there'd be like six widgets left. I've never seen so much useless junk in my life. Well I suppose I have actually, but not in this particular fashion.

    --
    I am no longer wasting my time with slashdot
  46. Re:thanks, slashdot by masklinn · · Score: 2, Insightful
    I don't think giving it a cool name made it popular. I couldn't give a shit what you called it.
    That's still what happened.
    That and (much more importantly) google using it in live webapps with GMail, Google Maps and Google Suggests.

    Everyone was pretty much ready, the web was ready, we needed someone to actually make the jump.
    The CoolGuys© at google did it, people now know it works (aka it isn't yet another crappy useless technology) and are therefore willing to use it.

    Google was the First Factor
    The AJAX buzzword was the second one, because let's face it executives love buzzword, and without a l33t buzzword to go with it a technology just doesn't exist as far as they're concerned (Asynchroneous Javascript + xmlHttpRequest + DOM doesn't quite sound as sexy as AJAX, now does it?), and if an executive doesn't know your technology he won't allow you to use it in a professionnal environment.
    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler