Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Advanced Requests and Responses in Ajax 209

Posted by ScuttleMonkey from the cleaner-code-not-just-a-cleaner dept.
An anonymous reader writes "The Web is no longer a place where simple applications are tolerated; 'users have become more advanced, customers expect robustness and advanced error reporting, and managers are fired because an application goes down 1 percent of the time. It's your job then, to go beyond a simple Ajax application that requires a more thorough understanding of XMLHttpRequest.' This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly."
This discussion has been archived. No new comments can be posted.

Advanced Requests and Responses in Ajax More

Advanced Requests and Responses in Ajax

Comments Filter:

  • CS101 (Score:4, Insightful)

    by slackaddict ( 950042 ) <rmorgan@NoSPaM.openaddict.com> on Wednesday February 15, 2006 @01:31PM (#14725551) Homepage Journal
    "...to build a solid foundation in which an application handles errors and problems smoothly."

    Um, aren't these concepts something we learned in college??? This is just basic stuff... although I think it highlights how RAD languages can teach you sloppy coding habits if you don't take the time do do things correctly.

    • Unfortunately... (Score:5, Interesting)

      by everphilski ( 877346 ) on Wednesday February 15, 2006 @01:40PM (#14725638) Journal
      In this day and age a lot of us are asked to program who are not by nature computer programmers. In a perfect world all the programmers would be CS majors. For example, I am an Aerospace Engineer, however I spend 6 hours a day writing code in c++. It isn't pretty but it works. Why? The company I work for could either:

      (a) Hire engineers who know engineering and are crappy programmers, and make them learn programming, or
      (b) Hire CS majors who don't know engineering, and spend 4 years to teach them engineering

      (a) makes more sense to me. A lot of my code looks like crap, and I know my CS friends could do better quicker, but they don't know the engineering principles I do. Long story short, I didn't have CS101, CS102, etc. There are a lot of us out here who are asked to code, who weren't brought up to be coders, who have to be taught some principles that aren't immediately apparent :P

      • Re:Unfortunately... (Score:5, Insightful)

        by AuMatar ( 183847 ) on Wednesday February 15, 2006 @01:52PM (#14725738)
        The correct answer is c

        c)Have the people who understand the engineering write pseudocode algorithms and work hand in hand with real programmers.

        The advantages you get from this- code that doesn't look like shit and have major architectural short commings, and much easier/cheaper maintenance. While I'm sure an Aero can learn to do basic programming in a month or so, it does take a few years to write good, well designed code. Whereas an experienced programmer can write equivalent functionality in 1/10 the time. By working together, you end up with higher quality software for much cheaper. This is the same way you see EEs and MechEs working with programmers in the embedded world.

        • Re:Unfortunately... (Score:3, Insightful)

          by Quarters ( 18322 )
          Except that c) doubles the costs (at least) the company will incur. While it is the right answer from a technical standpoint, from a business standpoint it isn't optimal.

          • Re:Unfortunately... (Score:5, Insightful)

            by Radres ( 776901 ) on Wednesday February 15, 2006 @02:06PM (#14725835)
            But c) will also half the maintenance costs of your crappy code.

          • Re:Unfortunately... (Score:5, Insightful)

            by AuMatar ( 183847 ) on Wednesday February 15, 2006 @02:26PM (#14725995)
            Not in the medium to long term. The improved maintainability (and very likely, quicker turn around time) of the programmer's code will very quickly make up the cost and more. If a good programmer can turn an algorithm from an aero to code in 1/4 the time (which is not, by any means, an unreasonable assumption) you end up saving money very quickly- you can hire 4 aero engineers to code, or you can hir 1 programmer and 1 aero engineer. And the aero might have free bandwidth to do more aero based stuff as well.
        • What Quarters said, plus you have problems with verification and validation. You need the engineers to do the actual verification and validation of the codes with the algorithms, how can they do that if they didn't write and are not compotent with the code? I think the better compromise is to hire engineers with some level of programming experiance and tolerate the fact that they will spend a few hours a week educating themselves.
          • Umm, and who do you think is more qualified to verify and validate a software program- an aero or a CS major? Again, the aero will have to work with the testing/QA team, but instead of spending all of his time writing crappy code that will have huge maintenance costs over time, he spends a small amount of his time working with other team, then spends most of his time doing the aero based stuff like engine design (or whatever his real job is).

            Like I said, this is what is normally done in the embedded indus
            • By validating, we aren't validating the application as a whole. We are talking about validating the algorithms

              (1) as implemented in the code
              (2) as they interact with the rest of the system (other algorithms)

              You can't ask someone who doesn't understand the physics behind the problem (IE: a CS) to do that. You need the AE to do that. And you can't ask the AE to do that if he doesn't know the language well enough to jump in and mess around with it. I'm not saying throwing a CS or two in the mix is unwise,
              • ANd thats what software testing and QA are all about. I've written scanner firmware before, do you think I have a PHD in physics and understand optics? I've written motor control code before, but I'm not a mechE either. Thats what testing is all about. Aero isn't any different. You do black box testing to ensure that for whatever inputs you have, the algorithm outputs the expected value(s). I'd be one hell of a lot more scared to use software tested by the aero's to be honest- no aero will have any u
                • I've written scanner firmware before, do you think I have a PHD in physics and understand optics?

                  Motor feedback circuits are easy. Lego's Robotic Invention System 2.0 contains enough parts to build a rudiamentary scanner, many grade school and high school kids have built scanners with them (google it). Not trying to belittle your accomplishment.

                  I disagree with your opinions but I can't really go into more detail on the public forum. Sorry. Bio may clue you in as to why.
              • Doesn't understand the physics? What kind of CS's are you dealing with? I had to take plenty of physics and math and I'm sure I could handle anything you have to.

                I'm happy your friend gets a good chuckle. Hopefully he's a passenger on one of the craft you programmed for.
          • All engineers and scientists, regardless of field, speak math. If you hire a CS person with a background in mathematical methods, he will be able to translate your equations into computer language.
        • Or even d)Have your engineers know how to develop good programs. I remember when my mother taught typing to high school students just ten to fifteen years ago - now everyone is expected to know how to use a keyboard, whether you do it "properly" or not.

          I don't think it's too much of a stretch to think that in the near future, everyone in technical fields will have to know how to build good software, not just know how to make a "hello world". It may not be the best software, and there will still be plenty
          • Except that it isn't practical, for several reasons

            1)Not everyone has the mindset to be a good programmer. I'm not saying that the average engineer can't learn basic programming- they probably can. But I know some damn good engineers, and even some good math majors, who failed all their programming classes. They had no interest, and really didn't have the ability to break down problems the right way.

            2)Time. An engineer already has a shitload to learn. Even bachelor degrees are inching twoards 5 years
            • 1 and 2- if i had an engineer working with / for me that couldn't learn to be a passable programmer, i'd not want them to work with / for me. programming (at the level most engineers would be doing it- we're not talking huge codes here (typically)) mostly involves relatively simple math and control structures that any vaguely competant engineer should be able to pick up quickly. 3- engineering time is typically cheaper than (good) programmers' time. not to mention the engineer would still have to spend t
        • pffffftttt... i'm actually an AE that does a lot of coding as well, and we've tried it that way. you need to write *ridiculously* detailed specs on everything for a non-engineer to understand the problem your trying to solve and get it right. it's quicker, easier, and cheaper to do it ourselves.
          • Yeah, requirements.....those are a real bumber. Imagine that...you have to have a consistent process to develop something very complicated.

            Most people with a CS degree should have more than enough understanding of Physics and Mathematics that they should be able to interpret what you're doing. Couple that with the fact that once they've been in your system a bit and understand the lingo and systems, they can really start to flow.

            It's quicker right now....maybe. It's easier right now...maybe. It's cheape

        • Re:Unfortunately... (Score:3, Insightful)

          by Tooky ( 15656 )
          Have the people who understand the engineering write pseudocode algorithms and work hand in hand with real programmers.

          Even better, get them to pair-program. I heard a talk at XPDay London recently by a guy from a company who build gear boxes. They had similar problems where either developers didn't understand the engineering well enough or the engineers produced poor code.

          They began to implement XP (which we don't need to go into) and had developers and engineers pair-program on the tasks. This was a huge
      • a) Hire engineers who know engineering and are crappy programmers, and make them learn programming

        I disagree that this is preferable. It takes more than that same "4 years to teach them engineering" to get an untrained programmer writing code to the same standard of the hypothetical trained and experienced CS major.

        This may be acceptable for some applications, esp. small, useful mathematical tools. The more sophisticated the project scope starts at (or grows to), the greater the benefit in having folks ar

      • Re:Unfortunately... (Score:3, Interesting)

        by khendron ( 225184 )
        I also graduated with a Masters in Aerodynamics, and I worked for an engineering company that required us to program. They adopted choice (a), and I will tell you (a) just doesn't work.

        Our code was crap and our applications extremely fragile. Nothing we produced was scalable or easily transferable from one client to another. Oh, everything worked after a fashion, but the architecture was comparable to a house of cards.

        I agree that our engineering background was essential, but what they should have done i
      • however I spend 6 hours a day writing code in c++. It isn't pretty but it works.
        I fail to see how Javascript will help you with this, or even teach you "some principles that aren't immediately apparent" ?
      • I seriously hope you don't write any software that could affect a humans life. Not to mention you could potentially be writing code that projects rather expensive (and heavy for that matter) things into space...and since you're not an expert in software design, practices or memory management for that matter, this could pose a problem.

        Software is not to be taken lightly. The fact they have you programming in C++ scares me a bit. C++, as you probably know, is a rather low level programming languages with l
      • I bet cheap companies spend a lot of wasted time learning things they should already know. You get what you pay for, but in some cases you get a lot more by doing a google/wikipedia search or reading a book. All I know is I would run things differently. But then I tend to disagree with most styles of business management these days.
      • Thank you! I am about as far from an Aerospace Engineer as you can get, but even those of us in mundane jobs like banking ended up doing some coding when we never had that in our job description. In fact, I think a large percentage of on-site development is done this way. If I were the boss, I, too, would take the engineer I already have who can write me some module that solves our problem and does what he needs rather than bring in Waldo the Visual Basic Wonder Boy at $15/hr to hose the whole system for a

    • Re:CS101 (Score:2, Insightful)

      by Anonymous Coward
      Isn't that a contradiction? The whole point of RAD is the "R"... you know, rapid. As in, NOT taking time?

      Oh sure, *I* agree with your point about doing things the right way, but the average acronym loving project manager sees "RAD" and (aside from the "party-on dude" connotations), assumes it means he doesn't have to spend time developing. One of the many reasons I hate that term and encourage others not to use it. It convinves people not to think in a relative perspective... "Rapid" means "faster than doin

    • Re:CS101 (Score:3, Interesting)

      by firewrought ( 36952 )
      Um, aren't these concepts something we learned in college?u

      Error handling wasn't taught well at my college [gatech.edu]. Yeah, you might fail one of Greenlee's assignments if you if you didn't check the return status of a system call, but that's not the same thing as knowing how to handle an error when you get one.

      It wouldn't be difficult to add an error-handling module to an intermediate-level programming class. There are only a few basic response to any error situation: ignore it, propagate it, retry it, ask the u

    • Gotta disagree with you. RAD neither help nor hinder good coding habits. It generally just makes the tedious stuff easier. Actually if the RAD is in the form of a good code generator, and the programmer follows the pattern the RAD generator outputs, it could actually lead to better organized code. Either way, RAD doesnt really effect sloppy coding habits.

      However, SCRIPTING does. Growing up a C/C++ programmer, switching over to python ( which I love sofar ), I notice I have to work especially hard to
      • I've heard this line of thought more times than I care to remember, and the standard response is that it's possible to write good or bad code in any language.

        I've seen (in school) C++ programs where the "programmer" had named all of their variables after fruits (strawberry, kiwi...), and all of their methods after greek letters (theta, alpha...). Style is style is style. You can't put a bad programmer in front of a c++ compiler and expect their code to be any better than it would have been in perl or python
        • I agree with your points, except you missed one major difference of compiled languages vs scripting ones- typing. Most compiled languages are typed, most scripting languages are not. This allows some bugs and performance issues to be found at compile time for compiled languages, rather than at run time. This can be both bugs (oops, this function only works on integer input) and performance issues (I had a python program take 12 hours on my box vs 2 on a coworkers. Turns out, he had twice the ram and wa

    • Re:CS101 (Score:4, Insightful)

      by hey! ( 33014 ) on Wednesday February 15, 2006 @03:03PM (#14726241) Homepage Journal
      What the issue at hand boils down to this: knowing how to program in an asynchronous enviornment. If you've done it before, you can skim the article in under five minutes, because it's just a small and managemeable set of conventions that sets dealing with the XMLHttpRequest that would be new to you. The strategy is just common sense, if you've done this sort of thing.

      CS101 certainly touches on aspects of asynchronous programming, such as threads, but I suspect the student's first serious exposure is more likley to come in second or third year OS class. But in any case you have to expect a CS program to fill the student's heads with more knowledge than skills. I've even hired engineers with masters degrees who, while they had the basic theoretical knowledge needed to do this kind of work, don't have a decent feel for it.

      The reason is that while they learned the theory, in practice details have always been taken care of by some framework or another. For example some ajax frameworks work by callback functions; clearly they're doing just this stuff under the covers.

      I'm not saying this is rocket science; quite the contrary. Very, very little in CS is. Most practical skills in CS amount to this: attention to detail and taking care with making assumptions you make -- particularly knowing when an assumption can be trusted to hold and when it cannot. I've often reflected that doggedness and fastidiousness (well, mental fastidiousness at least) are equally important with intelligence in making a good programmer.

      The problem is that programmers always have too many details to manage. Succeeding is what differentiates the good ones from the bad, and experience is very helpful. As in many things, an ounce of prevention is worth a pound of cure. It's all to easy to be careless or inattentive in the wrong places. Believing you know when to do this is what converts garden variety laziness into the hubris. Getting this stuff right isn't hard, but getting it wrong isn't hard either, in which case you end up with hard to debug problems or systems that are unresponsive.
    • It's amazing how we keep going back and forth between fat server and fat client.

      First, you had to sit in front of the computer to use it. Then they invented terminals so you could sit far away and use it remotely. Then they invented portable/personal computers so you could take it with you and have it right in front of you again. Then they invented the web so you could use a program running on a computer far away. Now you just download the AJAX program and run it on your own computer again.

      Of course each

      • It's amazing how we keep going back and forth between fat server and fat client.

        The web is more than just another iteration. You can write a web application that transparently serves smart web browsers with a whole drag and drop interface, text-only browsers and dumb scripts.

        Okay, so lots of developers are dumb and end up writing one or the other, but the idea is that you build the basic stuff, and add all the fancy Javascript and CSS on top. That way it works for both smart clients and dumb clie

        • It's a decent enough object-oriented scripting language. Most of the criticism of it comes from people who've only been exposed to dumb popup window scripts and rollovers. UI scripting is only one application, you can write server-side code, admin scripts and all sorts with it.

          Do you think the script writers would squeal too loudly if we added stuff like namespaces, strong typing and libraries to it? Having try/catch is respectable though.

          And it's delivered as source code, not exactly efficient. It's onl

    • Bunk! (Score:2)

      by jabber ( 13196 )
      If this line of reasoning, there would be no need for medical malpractice insurance either, because doctors would learn to do things exactly right each and every time early in medical school.

      Fact is, the world is a complicated place. Not only do people, even highly trained professionals, make mistakes from time to time - situations change, often unpredictably, and even the most reasonable and appropriate strategies suddenly become grossly inadequate.

      Software solutions are developed with budgets and schedule

  • Ironically (Score:4, Funny)

    by RealProgrammer ( 723725 ) on Wednesday February 15, 2006 @01:32PM (#14725560) Homepage Journal
    When I tried to download the code [ibm.com] from the article, and clicked through the license, it said:
    404 Not Found

    Not Found
    The requested URL /ibmdl/pub/software/dw/web/ wa-ajaxintro3_ajax-xhr_adv.zip was not found on this server.

    Perhaps someone should write an article on how to write robust AJAX code. Oh, wait...

  • nothing too new (Score:2, Insightful)

    by nuttzy ( 877548 )

    I think the article covers some things that are missing in a lot of ajax classes available, but really is nothing new. My own ajax class is far, far superior (trying to get the okay from work to OSS it).

    Too many classes are using a global httprequest object. This is not good if you are doing many requests (though I suppose uses less memory). There's also no timeout for graceful handling of a slow server. I've done quite a bit in the way of error handling.

    At least this one doesn't make you learn a da

    • We've also written applications with concurrent requests. The callback function takes an index into a request array, but the array is still global. Still, the limitation to concurrent XMLHttpRequests is the number of persistant connections the client's browser allows to a single server. If this is 2 (default in Firefox, supposed default in IE) then subsequent requests block until one of the first two finishes.

  • Good for Them (Score:3, Insightful)

    by trongey ( 21550 ) on Wednesday February 15, 2006 @01:37PM (#14725605) Homepage
    ...This DevWorks article tries to help developers use Ajax to build a solid foundation in which an application handles errors and problems smoothly.

    That's good, because none of the commercial "enterprise class" software that I have to work with handles errors and problems smoothly. They just crash or send an error message that has no relation ot the actual problem.
    • That's good, because none of the commercial "enterprise class" software that I have to work with handles errors and problems smoothly. They just crash or send an error message that has no relation ot the actual problem.

      Yeah, all the "enterprise class" software I code just throw some odd "NullPointerExceptions" when things go wrong. Ajax could really help me with that.

  • Users.. (Score:5, Insightful)

    by onion2k ( 203094 ) on Wednesday February 15, 2006 @01:39PM (#14725624) Homepage
    users have become more advanced

    They really haven't actually. They've stopped being mostly geeks and academics and now the internet is open to all. Users are much, much less advanced today than they were ten years ago. What has changed in more recent times is that the users now they're think more advanced. They're presented with interesting social networks (FlickR, Blogger, deli.co.us, etc), and they're capable of using these straightforward interfaces with lots of handholding (rebranding categories as tags for example) and they get the impression that they're learning something. Does that mean they know, or care, what an XMLHTTPRequest is? Nope.

    The same goes for customers. Yes, they want advanced reporting and robust apps .. do they care how those are achieved? Generally, nope.

    As for managers being fired for an application being unavailable 1% of the time .. the article talks about AJAX .. AJAX relies on JavaScript. Between 7% and 10% of web users have JavaScript turned off either implicitly or due to their IE security level. Surely if you're creating an AJAX application then you must realise the application is already unavailable to 7% of users even when your server is up and running? If high availability is key then you'd better not be using anything beyond HTML.

    • Re:Users.. (Score:2, Informative)

      by nuttzy ( 877548 )

      If high availability is key then you'd better not be using anything beyond HTML.

      Uh... how about having an app degrade nicely? In most cases it's not that tough. So for the large majority that can take advantage of your whiz bang web app, go ahead and use AJAX (where it makes sense) and just be sure to have it degrade nicely for browsers that are not ajax aware and then also for browsers that are not handling javascript.

      • be sure to have it degrade nicely for browsers that are not ajax aware and then also for browsers that are not handling javascript.

        I am a big proponent of this way of thinking, and I design *all* my apps to degrade gracefully. Nobody has ever asked me to code this way and nobody seems to care that I do it, but for me it is a point of personal pride.

        And you know what, it really isn't all that hard to do this. For starters, you check your input params on the server. Many people think they don't have to do

    • Re:Users.. (Score:3, Interesting)

      by spyrral ( 162842 )
      My company uses a very popular ad system that relies on javascript to function. If the user doesn't have javascript turned on, then they can't see our ads. If they can't see our ads, then ... we really don't care if the site doesn't work for them.

      For all of you who've got adblockers on and javascript and flash turned off, welcome to the beginning of the end. I hope you enjoy cruising the crusty bowels of the Internet while the rest of us enjoy Flickr and the rest of the really tasty web 2.0 apps that are co
      • funny, all the hot internet sites I use work very well without any of that crap turned on - eBay, google, yahoo, amazno, various news sites, even slashdot. Maybe your company might see the beginning of the end as more and more people become security conscious.

      • Re:Users.. (Score:4, Interesting)

        by just_another_sean ( 919159 ) on Wednesday February 15, 2006 @02:02PM (#14725802) Journal
        For all of you who've got ad blockers on and JavaScript and flash turned off, welcome to the beginning of the end.

        Oh the delicious irony of seeing this post immediately after a sensible poster [slashdot.org] mentions graceful degradation.

        See, I actually see things differently then you do. I do run with JavaScript disabled for the most part and AdBlock turned on. And you know what? I don't really have that many issues with websites. And if I do run into issues? Well, I really don't care if my browser doesn't work for them.

        I think perhaps just because you have "They're not seeing our ads? Well F them then!" attitude towards customers does not a) mean all companies do and more importantly b) not all developers do. Standards are generally designed to implement some backward compatibility. I don't think, despite your gloomy predictions, that this is likely to change anytime soon. The majority of (useful, interesting) sites will continue to keep this in mind in order to take advantage of as many eyeballs as possible.

        So I think I'll continue to use ad block, watch all my TV on DVR and skip the commercials, avoid tracking tools, like toolbars that integrate with my browser and in general keep myself as ad free as possible.

        Meanwhile you and the rest of the mass marketing industry can try the RIAA route and whine to the government about it. Maybe they'll make my DVR and ad blockers illegal. Then, I guess you win.
        • How the hell are you a customer if you refuse to view the ads? We're supposed to spend time and money to makes sure that self-important leeches like you can see our content? For what? Where is the benefit to us?

          Let me clarify that we don't actively block our content from people who can't view the ads. That would be a waste of time and money. But to go out of our way so "just_another_sean" who's so frickin l33t that he's got his Firefox adblockers and flash and js disablers installed and is gleefully laughi
          • Good for you. Great to see you waving the losing flag with so much conviction.
            • Please explain to me how not expending time and money on users who do not bring in revenue is a losing strategy for a company.
              • OK, since the original poster didn't bite, I will.

                If you make your site unusable without Javascript, Flash, Java and whatever else you want to impose, you *do* end up missing some customers. Making your site gracefully degrade means that people won't think that you are a failure as a programmer. See, when people go to a site and get broken links, partial page loads and other things like that, they think it is the sites fault, not their configuration (your Nemesis in the parent posts notwithstanding).

                That ma
          • Hmmm... I am probably risking some fingers by feeding the troll here but I guess I started it so here goes...

            How the hell are you a customer if you refuse to view the ads?
            Ok, first what are you selling? Just because I don't see your ads does not mean I'm not a customer. Tigerdirect sends me flyers (at home and work) and email all the time that go in the garbage the minute I get them. But guess who I buy 90% of my and my company's computers from? All the Dell, Newegg and IBM popups in the world don't change

      • Re:Users.. (Score:3, Interesting)

        by cruachan ( 113813 )
        Ho Ho Ho. Why would anyone want to turn Adblockers off? Personally I keep javascript on (why should I disable an extremely useful browser extension because some advertising scum abuse it?) but run the Adblocking at the highest level I can. I rarely see any adverts and it seems to me that the adblockers are winning the arms race - we can have our web 2.0 applications just fine without the dregs of humanity that are advertiser messing things up for us.

      • Ha! Meet the Firefox extension: noscript.

        https://addons.mozilla.org/extensions/moreinfo.php ?id=722&application=firefox [mozilla.org]

        I can selectively enable javascript and every other web plugin for websites. If I need to see a site with javascript that I don't trust enough to add to my "always allow" list, I just temporarily grant access for the browser session.

        Combining that with adblock I enjoy (and pay to subscribe to) flickr and other sites, overly hyped web 2.0 apps, and such with no crappy javascript/flash ad
      • Funny- I think being able to avoid sites like Flickr and ad based monstrosities like your site are a bonus, not a negative.

    • Re:Users.. (Score:3, Insightful)

      by mpcooke3 ( 306161 )
      The problem is that for various well known reasons "we" (the technical community) have decided that most applications will be deployed over the web these days. As new users come onto the internet for the first time they access these applications and they quite naturally expect them to behave like other applications. Whether an application was accessed via the "Blue E" or by the start button they expect them to behave in similar ways. Internet users in the old days used to be looking at research papers and t
    • Between 7% and 10% of web users have JavaScript turned off either implicitly or due to their IE security level. Surely if you're creating an AJAX application then you must realise the application is already unavailable to 7% of users even when your server is up and running?

      Those users aren't cool enough to count. Not for AJAX man!
    • AJAX relies on JavaScript. Between 7% and 10% of web users have JavaScript turned off either implicitly or due to their IE security level

      That's got to be the most made-up stat I've seen in a long while. The actual number is much closer to .0001%

  • Pretty sparse (Score:4, Informative)

    by Gopal.V ( 532678 ) on Wednesday February 15, 2006 @01:45PM (#14725674) Homepage Journal
    The document is pretty much ranks in the category of 30 second ajax tutorials [rajshekhar.net]. It would have been better if the document has explained how you were supposed to handle concurrent XmlHttpRequests - a problem I am faced with. Yesterday, I noticed the new Y! libs released had - transaction ids [yahoo.net] for Ajax requests. I've been using closures in javascript to maintain the context info, but this way sounds much better.

    Any decent webdev entering the field should know about http status codes, HEAD requests and all that. Also it should be noted that article didn't even mention how many times state 3 is hit for a particular request - I got caught by that one once.

    • Hmmm... I wonder. You could probably just create a JavaScript object to store information about each request, and use a method reference as the onreadystatechange callback function, though I'm not sure how portable/reliable that is.

  • frameworks reduce need for low level details (Score:3, Interesting)

    by DeveloperAdvantage ( 923539 ) on Wednesday February 15, 2006 @01:59PM (#14725788) Homepage
    Every Ajax application uses the XMLHttpRequest object, so you'll want to be intimately familiar with it to make your Ajax applications perform and perform well.

    I think this is true right now, at least to some extent, but as frameworks solidify and become proven, there will be less benefit to being "intimately familiar" with the XMLHttpRequest object. Of course, knowing more about the underlying technology can't hurt, and you will need to know them if you are the one writing a framework.

    For a very good source on frameworks, take a look at http://ajaxpatterns.org/Ajax_Frameworks [ajaxpatterns.org]

  • the web IS such a place! (Score:3, Insightful)

    by tjr ( 908724 ) on Wednesday February 15, 2006 @02:01PM (#14725800) Homepage
    The Web is no longer a place where simple applications are tolerated;

    Sure it is. Most web applications that I use, whether if they make use of AJAX or not, could certainly be plenty usable and valuable without AJAX.

    AJAX makes some things possible that aren't possible using plain HTML, but it doesn't make ALL plain HTML so much better that it would be impossible to imagine the site without it.

  • simple != intolerable (Score:5, Insightful)

    by blue_adept ( 40915 ) on Wednesday February 15, 2006 @02:06PM (#14725841)
    The Web is no longer a place where simple applications are tolerated

    Not so. Simple = GOOD, just look at the success of google; no fancy front end required. AJAX, like good special effects in a movie, can enhance the end-user experience when applied selectively and intelligently. They are NOT an end in themselves.

    The truth is, the web is a place were only USEFUL applications are tolerated, whether or not they use AJAX.

    • I agree with you. Content and usefulness matter. And Simple = BEAUTIFUL.

      Yet, Simple != Easy to create. And Simple != Low Tech. Simple = Nothing excessive.

      And as far as AJAX helps to save some mouse clicks and page reloads, it may be used to weave really simple web.

  • The Web is no longer a place for information exchange. It is a place to invest your money, to hire more and more coders/artists/testers/managers, to maintain all this eye-candy. There is a reason: It looks just like a real application inside your web browser!

    We don't have anything special to say. But now instead of looking for a `Back' button, you may drag-n-drop our whole corporate site directly to your Recycled Bin!

    • You know, this comment is not just funny, I find it rather ironic. Why do we try and force a "real application" through a web browser? The way we are treating browsers these days, it seems like they are less about information presentation/sharing and more about actual application-type functionality. I thought that was what all the GUI libraries that come with your OS were meant for!

      Rather than taking an incremental approach and altering the core purpose of "web browsing", why don't we get all of the majo
      • Why do we try and force a "real application" through a web browser? The way we are treating browsers these days, it seems like they are less about information presentation/sharing and more about actual application-type functionality.
        Web applications have a number of good qualities, from the user's perspective. They allow ubiquitous access, work on essentially any modern computer (Firefox will run apps on Windows, Mac, and Linux with no problem), and can be kept updated automatically. I don't know where yo
        • I thought that was what all the GUI libraries that come with your OS were meant for!
          GUI libraries pre-date the Internet. I think that today, they're mostly there for legacy purposes. From a developer's perspective, a single code base that runs everywhere is much more appealing.

          While I will agree that SOME GUI libraries predate the net.. I feel like many GUI libraries had so much of the functionality that we are trying to emulate now with AJAX in the browser, that it's kind of silly that we can't use na
          • You're right about not having native widgets exposed in the web browser. Sorry about that. When I wrote my earlier response, I didn't quite understand the point you were getting at.

            Perhaps what we need is as simple as exposing these additional controls through HTML's <input> element or XForms.

            I think very few people truly understood the potential of what the web could become...Sir Berners-Lee certainly didn't. One of the few who did might have been Microsoft. In an ironic way, Microsoft's sudden a
  • Comment removed based on user account deletion

  • I would prefer the JSON way (Score:4, Informative)

    by moria ( 829831 ) on Wednesday February 15, 2006 @02:35PM (#14726055)
    Using JSON [json.org], JavaScript can load data from any address, when XMLHttpRequest requires you to stay in the same domain. Besides, JSON is JavaScript native and is therefore much easier to consume, for example, using MochiKit [mochikit.com]. As for the generator, it is trivial to convert native data to JSON data in a wide range of programming languages, including all the major server side scripting languages, like Python [red-bean.com] and Java [json.org]. Yahoo has released a lot of their APIs on JSON [yahoo.net] and some excellent Python WebApp Framework [turbogears.org] has built-in support to speak to the client scripts in JSON.
    • There's always Anthem.Net [sourceforge.net] for those that like C# as well... ;) I think JSON is much lighter for data than using xml... since the syntax can be *much* lighter with json, especially for somewhat complex relationships, and data.
  • You know, a downtime of 1 percent is almost 4 whole days a year. That is a lot of "sorry we're closed" (or "building is gone") if you are supposed to have a 24/7 business. I don't think it's unreasonable to have slightly higher demands than that.

  • No longer tolerating what?? (Score:3, Interesting)

    by ben_1432 ( 871549 ) on Wednesday February 15, 2006 @02:52PM (#14726170)
    Where's the ajax on slashdot? Are we supposed to be rebelling because it uses the traditional get/post methods instead of the (new name, old technology) "ajax" version?

    Where's the ajax on msn & yahoo .com's? Or on mainstream news sites?

    Ajax is a "web two point oh" buzzword, and 99% of "web two point oh" services/systems aren't going to be a success just because they utilize it.

    I'm not disputing it can be useful and add something to an application, but the hype outweighs the benefit.

    One thing I fear about ajax is the poor standards many developers work to - how long before we see phpbb/phpnuke/et al tearing servers apart because each visitor is suddenly making an extra 10 database queries a minute while previously they'd alt-tab back and hit refresh every few minutes?

  • Echo2 (Score:2)

    by Mock ( 29603 )
    http://www.nextapp.com/platform/echo2/echo/ [nextapp.com]

    If you want a proper application that handles user and error conditions gracefully, it helps to use a tool that aids good design.

    Echo2 lets you build AJAX applications as if you were writing a swing app.
    No messy html/javascript. You don't even need to know that XMLHttpRequest exists.

    I'm currently in the process of building an AJAX app for a large financial institution and all I can say is thank god I don't have to mess about in javascript to make a nice applicatio
  • At times like these, it's nice to know that Ruby on Rails' AJAX helper functions already handle neat things like scripting actions on errors or sending errors to a different DOM element.
  • Nothing that was ever worth anything to anybody was ever covered with every single stinking article about it starting off: "The web is no longer a place..." | "Programmers no longer have to..." | "Computer applications used to..." | "In the old days of the web, applications..." | "The old way of managing interactive content..." | "Now there's a new way to..." | "Is everything we know about web programming about to become..." | "Computer scientists the world over have voluntarily turned themselves in for dea

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close