This is not another XMLHttpRequest article

2 March 2005

34 comments

A Blue Perspective: This is not another XMLHttpRequest article

You're probably sick of articles expounding the virtues of XMLHttpRequest by now, well this isn't one of them.

While I am suitably impressed with the uses that have brought dynamic retrieval of data via JavaScript into the spotlight of late (Google Maps ... ummmm ... Google Suggest ... ummmm ...) I am yet to be persuaded that it will (or should) have a ground breaking effect upon the Web at large.

Although it has been around for a while, in terms of its usage JavaScript data retrieval is still a very immature technology. The uses which I have seen are either for manipulation of form data (Google Suggest), or complete web applications (Google Maps, GMail, map.search.ch). The reason that there is no inbetween is because, as with all JavaScript solutions, JavaScript data retrieval has an Achilles heel: you can never rely on a client to have it or allow it. All forms still have to be validated server side, all dropdown menus still have to have links to root pages, all widgEditors still have to be textareas.

This has lead to a tradition of using JavaScript just for "the extras". So, if you've got JavaScript turned on you'll be rewarded with plenty of time saving widgets, helpful hints and cute effects, but if you don't you'll still have access to "essential services".

Google Maps, to use the current iconic example, blows this idea out of the water. No JavaScript, no maps. Granted, the service is still in beta (isn't everything at Google?) so they may be introducing a non-JavaScript version in the future, but this case demonstrates the overhead required by all JavaScript-driven services – the need to code for redundancy. Depending upon the complexity and type of your service, this can add significant amounts of development time (and therefore money) to a project.

This need, however, is technical, not necessarily practical. It would be nice if Google Maps were accessible by non-JavaScript enabled user agents, but in practice this must be weighed up against market forces – is an acceptable proportion of your target market likely to have JavaScript enabled, or is your service so useful that people will go out of their way to acquire JavaScript capabilities to use it?

In Google Maps' case it is debatable whether their target market would have JavaScript enabled, that's something that's very subjective and reliant upon internal metrics. But if you didn't have JavaScript capabilities (and you were actually using Google Maps to find out where you were going, not to just check out how cool it is) you would probably go to another map provider to get the information. GMail is a different proposition altogether; undoubtedly many people have switched browsers for it.

Market forces aside, from an accessible Internet perpective Google Maps perhaps lies on the border between acceptable JavaScript exclusion and unacceptable. On one side of this border I like to place archetypal, everyday web pages – non-interactive (in a data sense), essentially text, linkable, crawlable, holders of public information. On the other side we have web applications – interactive, self-contained systems, used to complete a task.

Ever since the Internet began these lines have grown increasingly blurred. Forms allow data to be exchanged between the user and the server, logins allow users to save their data, cookies allow sites to be tailored to a users' preferences. But I still see web applications as essentially different from web pages. Much like intranets, they don't have to play nice with other sites or standards (of the non-XHTML kind), because they are closed systems. Their aim is to complete a set task, not to hold linkable, publicly accessible information. When you send an e-mail, do you want its confirmation screen to be recorded in history for public posterity?

I think the essential characteristic defining the divide between an application and a web page is probably this public linkability. If the essence of your project is static information that should be available to a wider community (be it five friends or five continents), then it is most suited to a web page. This is one of the major failings of Flash sans HTML. In the all Flash model, each website is treated as a singular entity – similar to an application – and does not allow arbitrary access to parts of that website. This makes it extremely difficult to access information without following a pre-determined path.

Should finding your way on a map be a web page or an application? Probably an application. Should sharing a location on a map be a web page or an application? Probably a web page. Google Maps fails as a web page because although they provide a static link to your current location, to view this link the service requires that you have JavaScript.

What does this mean? It doesn't mean that Google Maps is junk, or a failure. Far from it. It is merely a perfect example of why JavaScript is brilliant for presenting content in web applications, but inadvisable for presenting content on web pages. It'll still let you do cool things – really useful things – but it shouldn't change the way that websites are built or used, because 99% of the Internet is not an application.

Categories

, , ,

Comments

  1. 1/34

    Brandon Keepers commented on 2 March 2005 @ 01:04

    I think you're right in theory.  I try to subscribe to the practice of only using JavaScript for nice-to-haves, and avoid using it if it breaks the functionality.

    Even though there are browsers out there that don't support JavaScript, and there are people that have it disabled, the reality is that the web is full of JavaScript.  Who seriously uses lynx for their day-to-day web browsing?  I haven't used a browser that didn't have JavaScript support since 1998. Even though there are browsers like Konqueror, Safari, and even Opera whose implementation is less than complete, I think lack of browser support is no longer a valid arguement.

  2. 2/34

    Ryan Brooks commented on 2 March 2005 @ 01:40

    There is a long way to go in the web development community to get rid of the stigma of javascript. In fact, today I was defending it from one who said:

    'using client-dependent (and INCOMPATIBLE) technologies is fucking stupid (javascript vs. jscript vs. neither)' or 'Javascript is teh sux :)'

    It's very easy to say 'yeah, just use a server side solution' but there ARE cases where it IS useful.

    But I'm with Brandon. Javascript should only be a nice-to-have.

  3. 3/34

    Ruy commented on 2 March 2005 @ 08:14

    I think what will need to happen regarding this problem is to streamline the way one develops web apps client side AND server-side concurrently.

    Projects such as JSPAN will probably help this along a great deal.

    I deffinatly think that it is possible to develop something like gmail or google maps and still have a server-side no-js alternative without that much overhead (some overhead will always be there - but it should be managable).

    The only time you have a real excuse for failing to gracefully degrade your site/app is when you are working in a tightly controlled setting - for instance, an intranet (and at that point why mess-about with javascript? Just use actual Java or Flex or make a .NET standalone app etc. ).

    Of course that is not to say you can't just "forget" about no-js users - after all, having a cool js-only web app is still better then no cool web app at all. For now, the business case for making backwards compatible js pages is very weak.

    Hopefully in the future the cost of building such applications will go down as new tools are developed to help the process along.

  4. 4/34

    Mike D. commented on 2 March 2005 @ 14:36

    Agreed on most accounts here. However, 99% of the web is not an application only if you consider 99% to mean:

    1. Right now.

    2. Raw number of "locations" on the web.

    Right now, most "locations" are documents and rightfully so. They probably always will be.

    But if you instead consider what that 99% number would be in terms of either a) total amount of time people spend on the web, or b) total amount of labor put into development of said locations, I feel it goes way down... and will continue to do so.

    For instance, if you spend half your time online using Gmail, you are all of a sudden spending 50% in a web application... not on web pages. This addresses the consumer side of the equation but not the producer side. To address the producer side, assume that the amount of time required to "develop" static content (not writing articles, but actually coding pages) will keep decreasing, and the amount and complexity of web applications will keep increasing. Then the collective amount of time web developers spend producing web applications rises a great deal... and hence the coming dramatic effect of the XML-HTTPRequest.

    As a side note though, I do find it funny that people view this as a novel technology when we've all been using Flash to handle asynchronous non-refreshing data requests for years and years. That ability has been available since Flash 4. It's great that you can do it without Flash now, but Flash is still arguably a lot better at this sort of thing than XML/HTTP is in a lot of circumstances.

  5. 5/34

    The Man in Blue commented on 2 March 2005 @ 16:07

    Mike: Granted, the usage of web applications will increase, and "content" decrease, but there is a cut-off point. The Web will not be consumed by applications, as people still require the basic information.

    ... Or perhaps a web application will be built that totally re-defines the content on the Web, sort of creating an improved SubNet (similar to Flash) ... But then you'd just release a new browser.

    I didn't want to get to deeply into a Flash comparison in the entry, but yes, I was struck by how much these new web applications are similar to Flash applications, though very much rougher.

    What advantages are there to using XML/HTTP versus Flash when the content is no longer transparent?

  6. 6/34

    mattymcg commented on 2 March 2005 @ 19:30

    Great article Cam, I had to laugh at your ever so subtle plug for widgEdit! I am thinking of using XHR on my next (personal) project, not because I need to but to teach myself a bit about it and see what is possible. I agree that I don't think the technology will ever give us a rich application, but it's those grey areas between an app and a page that do seem like an interesting area right now.

  7. 7/34

    Mike D. commented on 3 March 2005 @ 00:45

    Cameron: Yep, it's certainly debatable how many advantages XMLHttp has over Flash. I'd say it definitely has *some* advantages, but overall Flash has more. The Flash programming environment, although not perfect, is a lot more mature than the standard XML/HTTP/HTML environment at this point.

    Flash 4 started it, but sucked. Flash 5 improved it syntactically but not operationally. Flash 6 made it much more robust. Flash 7 made it faster and more object-oriented. And now Flash 8 is about to make it EXTREMELY quick and lean.

    My only point here is that Macromedia, as a company, has the focus and drive to rapidly improve their plug-in whereas browser development tends to move quite a bit slower. Each new version of Flash reaches 80-90% penetration about 14 months after it is released, and browser uptake is nowhere even remotely close to this.

    However, working against Macromedia is the fact that a lot of hard core developers simply feel safer and more responsible if they develop their apps in a more open environment. Yes, the .swf file format is technically open, but unless it's 100% open and W3C backed, some developers will always shy away.

  8. 8/34

    Steve commented on 3 March 2005 @ 01:54

    Interesting article, but...

    You mention, "user that have JavaScript turned off"... unless I'm missing something, *these* users, are morons, and you wouldn't want them on your site.

    JavaScript, is safe, and used almost everywhere... your Browser would suck, without it.

    The only reason I can see people turning JavaScript off, is if they are stuck on a crappy browser, like IE, that can't separate JavaScript, from JScript and VBScript, which can, and often has, been harmful.

    If you make a site/web app today... you have to expect the user to be on the latest major version of the browser, and have JavaScript enabled.

    If you're users, are afraid to do that, then they need to install Firefox right away, because the Web is a lonely place, with IE, and no JavaScript.

    No banking, no pizza, no online shopping, no google maps... nada..

    Get Firefox!

  9. 9/34

    Morgan Roderick commented on 3 March 2005 @ 09:47

    Just like with any other technologies applied to information (web pages) today, we need to find the best practices for JavaScript, or more to the point: asynchronous background  communicaiton of information.

    There should be a clear distinction between whatever griefs one may have with what Google does (or M$ for that matter) with the technologies, and what the rest of us do with it.

    Google have created some new and exciting things, true, and congratulations to them for inspiring so many... but it is still up to the rest of us to find the best practices.

    Allowing linking to content is still "a good thing[tm]" ... but so is allowing a user to add something to a shopping cart without reloading their semantic, well-formed and nicely styled documents all the time, is also a good thing, when done right.

    If you maintain your content as content, and keep your sites wonderful functionalities simple and to the point, it should not be too hard to create good scripting that improves the user experience instead of detracting from it.

    Creating fall over server side functionality for stupid/simple clients is also not that hard.

  10. 10/34

    Patrick Hall commented on 3 March 2005 @ 13:10

    Hi Man in Blue,

    I'm a big fan of your work, WidgEdit is great.

    From my point of view, the main thing that all this Ajax stuff offers is that I can start using it right now. The same can't be said of Flash. I think vector graphics is great, and I hope that it opens up some more -- the possiblities that Flickr points at are quite cool.

    But as an independent developer who uses Linux, Flash is pretty much unreachable to me.

    It would be interesting to know the ratio of people who have Flash installed to the proportion of people who have Javascript turned on. I suspect the ratio tends toward the latter.

    And then there's the fact that Flash apps just feel a little off, somehow. How many Flash sites like this have you seen where the text is... not really text? That kind of stuff drives me bonkers -- the Ajax approach on the other hand ends up with apps that look and feel just like HTML, they're just an order of magnitude faster.  

  11. 11/34

    MH commented on 3 March 2005 @ 13:12

    Steve wrote: "You mention, "user that have JavaScript turned off"... unless I'm missing something, *these* users, are morons, and you wouldn't want them on your site."

    ...or perhaps they're visually impaired, and their screen reader doesn't support javascript.

  12. 12/34

    webfoo commented on 4 March 2005 @ 08:02

    People turn javascipt off due to ads, and what not remember how ads popped up everywhere on screens. And also there was an issue a while back(download.ject) that left most people running scared.

    They are not morons, but they are not as advanced as yourself let alone go and install firefox.

    There would always be users that have javascript turned off.

    Go to most sites that use javascript to validate forms, if you turn off javascript you can wreck those sites instantly.

    Having said that developers should always consider a serverside option that does the equivalent, time consuming but it's worth the effort.

    I personally use to rename my macromed folder in the system32 folder / send all requests to macromedia to 127.0.0.1 so as not to see any Flash ads.

    It's the world we live in the Good, the BAd, and the UGLY.

  13. 13/34

    Cody Lindley commented on 5 March 2005 @ 01:50

    I think Mike D. is on the right track. However when browsers support the same specification (ECMA V.4/Javascript 2) that actionscript does the playing field between AJAX and Flash will even out.

  14. 14/34

    Dean Edwards commented on 8 March 2005 @ 16:45

    The advantage of JavaScript/XML over Flash is that it is not proprietary technology. Without Ajax (OK we'll call it that!) data transfer on the web would be in the hands of a corporation. We don't want that.

    Regarding JavaScript disablement:
    on the IE platform users that disable JavaScript tend to also disable ActiveX. Which in turn disables Flash (which uses ActiveX). So they can't do sexy web apps either way...

  15. 15/34

    monooso commented on 8 March 2005 @ 19:28

    Steve wrote:
    "The only reason I can see people turning JavaScript off, is if they are stuck on a crappy browser, like IE...

    "...you have to expect the user to be on the latest major version of the browser, and have JavaScript enabled."


    I can't say I agree with either of these points, Steve.  There are plenty of reasons why JavaScript would be turned off, including visual impairment, and company policy.

    And with regard to abusing people for using IE, that's just plain stupid.  Sure, developing for it makes my life a living hell but it doesn't mean that I don't recognise that the majority of people still use it (either by choice or because, again, it's company policy)... are you saying that you would want to actively exclude 80% of the online population from a commercial website that you developed?

    And finally, with regard to the point that everybody should have the latest browser version (and there's no excuse not to) - Jesus, have you ever even looked at your server stats?

    Oh yes, I almost forgot - interesting article MiB, thanks ;)

  16. 16/34

    Terry commented on 8 March 2005 @ 21:41

    XMLHttpRequest is javascript and people can learn from viewing the source code. Flash may be light years ahead, maybe not, but I'm not about to decompile a binary just to see if I can learn how someone did what they did.  It's the biggest flaw to Flash as far as I'm concerned. Within a day or two, many people had already un-obfuscated the Google Maps app client-side code - and its downright genius, I might add. We can learn from it and adapt certain pieces of the logic to our own projects if we choose.

    Both technologies still have their place though. And if it's only eye candy and the "wow factor" that's the goal, then Flash might be more appropriate in many cases.

  17. 17/34

    Tommi commented on 8 March 2005 @ 23:32

    I think Ajax apps (Asyncronous Javascript + xml (meaning xmlhttp)) has it's place and incomparison to Flash, I find it even more usefull for web apps. As it was allready meantioned, javascript is not proprietary and you don't need a xxx$ IDE to develop an "ajax" web app.

    Flash also has an achilles heel: flash apps are basically completely non-search-engine friendly. Sure, you can program a million metatags into your html page hosting the flash, but still ..

    Also a lot of developers are allready accustomed to programming javascript on their sites, so for them the learning curve is not too steep to start using "ajax" style to create web apps, getting same feel (almost) as you would from Flash apps (I'm referring to the responsivness of the web app).

    And yes - I also agree ajax is not a silver bullet to be used for everything. I personally would only use when it's needed: with data-centric web apps that need to fetch snippets of data/material from a backend.

  18. 18/34

    The Man in Blue commented on 8 March 2005 @ 23:49

    Yes, Flash applications aren't search engine friendly (though there are reports that Google et al can actually index Flash content), but the same applies to Ajax applications (at least in the form of Google Maps).

    Any method that doesn't have page refreshes will suffer the same fate. They are not web pages, and can't be indexed as such.

  19. 19/34

    Rion D"luz commented on 9 March 2005 @ 09:06

    Your argument:
    Pages - no js, mostly static content
    Apps - js laden and more narrowly focused
    audience

    is fine but shallow. Personally, I love going
    to a website that contains little or no
    markup in a static html document.  As long
    as all i want is the one piece of info it contains. (ex: http://www.lcdf.org/gifsicle )
    To me its analgous to broadcasting info.
    Get more complicated, layer on nav tools,
    menus, useful widgets to make drilling for
    info easier: voila, more scripting or more
    server calls.
    Make the site (or docs) more interactive with forms and such: voila more scripting.
    My point is the more robust and functional
    the site is the heavier the dependency on client UA capabilities, including scripting.
    Was the UA designed to do this, maybe not. But as it moves more toward a sgml-like env scripting is going to become more pervasive, not less.

  20. 20/34

    stylo~ commented on 9 March 2005 @ 13:31

    >>Ajax apps (Asyncronous Javascript + xml (meaning xmlhttp))

    Why are people such sheep in the blog world? It's always been called javascript, or more specifically "remote scripting" if you want, not "Ajax."

    First of all, it doesn't have to be asynchronous, so there goes the "A", and, secondly, it doesn't need xml data as put forth in the "Ajax" article - in fact you're far better off speedwise not using xml -, so there goes the "x". (You can also fetch data with dynamic scripts and don't need xmlhttprequest, so again no "x".)

    So if you need a another name, call it "Ja", and pronounce with a German inflection, nodding as you say it. -Of course then you can't charge $150/hr and have sheep link to you, but what the heck.

  21. 21/34

    Michael commented on 11 March 2005 @ 04:35

    stylo~

    wow, bitter?

    I used to be an extremely proficient javascript professional. Then I delved into server side scripting, and javascript/dhtml went by the way side. Ajax, or whatever you want to call it makes me interested in javacript again. If nothing else, that's why it's cool.

  22. 22/34

    ismael commented on 12 March 2005 @ 00:34

    I think one advantage of "Ajax" (I just learned the term) over Flash is that the output is still HTML so you can attach CSS to it, thus making the design way more maintainable.
    PS: "Ajax" sounds like a Viking warrior or something. Where the heck have I seen that name before? In a movie?

  23. 23/34

    Ismael commented on 12 March 2005 @ 00:36

    Oh, I think it's a character in Homer's The Odyssey, isn't it?

  24. 24/34

    Ali Khalili commented on 16 March 2005 @ 07:21

    Hello dear.

    You have a very usefull website with beautifull name!

    speed of your website is very high! Do you use Ajax method to reload page of your site?!!

  25. 25/34

    Houser commented on 17 March 2005 @ 09:41

    Hrm... Your article is thought provoking, but I think it may border on zealotry. Most browsers these days employ Javascript and users must have a certain comfort with technology in order to disable it (my Mom couldn't do it, for example). To extrapolate on your dissertation, are we to infer that sites that have 'content' and need to degrade gracefully should not only provide for exclusion of Javascript, but also maintain compliance with 4.x browsers? What about some of the 3.x browsers?

    At some point, developers have to feel enabled to move forward. Done with enough concert and the masses will be forced to follow. This is not necessarily a negative idea.

  26. 26/34

    The Man in Blue commented on 17 March 2005 @ 10:42

    Re: Houser (25)

    Sure, if you don't want your content to be accessible at all, code for just JavaScript enabled browsers. I'm pretty sure that screen readers would have a hell of a time accessing your content, as would other non-desktop browsing devices.

    The idea behind Web Standards is to make code that is accessible to all, but uses presentation for those that are presentation-enabled. Therefore, the code is already accessible to 4.x browsers, they just don't get styles.

    The equivalent cannot be said of JavaScript-only applications. We cannot afford to lose the progress we have made with HTML Standards by throwing it out the window with client-side scripting.

  27. 27/34

    Rick commented on 19 March 2005 @ 07:31

    Where have you seen that name before? It's cleaning fluid.

    <script src="chrome://greasemonkey/content/scripts/1102161148673"><script><script src="chrome://greasemonkey/content/scripts/1102237157909"><script>
  28. 28/34

    setmajer commented on 25 March 2005 @ 22:26

    Ismael: Yes, Ajax was a greek hero and regarded as the second most adept warrior after Achilles. He carried the body of the fallen Achilles back from the field of battle during the Trojan war, and was eventually driven mad by Athena.

    And yes, Rick, it's also a brand of cleaning fluid in the U.S.

    MIB: "I'm pretty sure that screen readers would have a hell of a time accessing your content..."

    Depends on how the UI is written. Screen readers are typically add-ons, not browsers themselves (this is true of the 800-pound gorilla of the market -- JAWS). That means they support whatever the underlying browser supports (usually IE -- it's even more dominant among the vision-impaired than among 'ordinary' users). What can be difficult is if they require an onclick to fire; if you also set them up to respond to onkeypress, or use the (shudder) javascript: pseudo-protocol scripts can operate with screen readers (of course, with the onkeypress you have to filter out tabs if you want the end user to ever be able to move to another link...).

    Note too that it isn't just screen readers that may have problems with poorly-implemented scripts: users who can't use a mouse may have trouble as well.

    MIB: "What advantages are there to using XML/HTTP versus Flash when the content is no longer transparent?

    Well, accessibility for disabled users is problematic for both technologies, so not (much) difference there.

    The development environment for Flash is what, US$500 or so? Maybe $50-100 for the non-MM Flash apps (but then, my impresson of them is that they're not very good for the complex stuff anyway...)? For JS it's free -- including some very good editors (JEdit, Text Wrangler, HTMLKit), a pretty good debugger (Venkman) and even some WYSIWYG tools (Nvu, Bluefish).

    Flash isn't 'open' in the sense that ECMAScript is open, nor even in the sense that XUL is open. MM currently allows people to implement the format for free, but that's not *quite* the same thing.

    Ajax-style JS builds on a developers' existing JS/CSS/DOM/HTML chops. With the exception of the ECMAScript-compliant syntax (which doesn't help as much as one might expect as the API is radically different), Flash dev skills are orthoganal to other web dev skills.

    Flash has a much flatter learning curve (meaning it takes longer to get up to a given level of expertise) for existing devs. Even if they're not already familiar with markup and stylesheets, the timeline model is something rarely encountered outside audio/video/multimedia apps. The lack of a 'view source' equivalent for Flash mentioned above also hurts in this area.

    Flash is more difficult to integrate into a web page; making it 'talk' to JS is a black art, and getting it to interact with HTML elements any other way isn't possible short of server round-trips.

    Flash plugin version trouble is quite real. I've fought it repeatedly with the few Flash widgets we've deployed; 80-90% penetration of a given version isn't nearly good enough for marketing stuff, for example. And one can bet on one's clients having older versions lurking in their company that'll surface when the new site goes live. That adds a wildcard into the already complicated browser debacle.

    JS+HTML+CSS can be written on-the-fly with PHP, Python, Perl, ASP.Net, Ruby, etc. I expect it's probably *possible* to write swf files even without MM's server-side widgets, but it's a non-trivial task. And MM's server-side widgets are beaucoup bucks.

    Managing and maintaining complex Flash projects appears to have been improved in v7, but from what I know (not all that much, truth be told) it doesn't seem like it fits as well with a typical subversion/CVS/VSS setup.

    None of which is to say that Flash is inferior to JS in any absolute sense; just that both technologies have their place.

  29. 29/34

    Dan Ferreira commented on 31 March 2005 @ 04:26

    Here's the reason why I think Ajax is definitely the next step in the web experience.

    You just have to look at the history of online multiplayer games in the past decade or so.

    Back in the days when Quake was starting the whole online multiplayer phenomenon, the gaming experience was only truly enjoyable for the lucky few who had broadband or were playing in LAN parties.

    So John Carmack developed QuakeWorld: the next step in the asynchronous client-server model where the client would participate more actively in the gaming experience. By using a kind of "client-side prediction", the client would run a simulation of the game world (that was actually happening only on the server-side), so players would have the illusion of actions like shooting, jumping, picking up items, etc. taking place immediately even though they weren't, due to network communication's intrinsic latency.

    QuakeWorld also pioneered things like network compression and on-demand downloading of resources. That was only possible because client and server were both able to cooperate inteligently, sharing the costs of data processing and saving on time and bandwidth.

    Overall, this model pioneered by QuakeWorld became the standard for every major action-oriented multiplayer game released since then.

    It's only natural that the client should participate more in the whole user experience, it's dumb not to. It became the norm with games because the benefits were obvious. I predict it will become the norm for the web too.

    You may not be fond of JavaScript, it may have its drawbacks, but people are definitely going to make the switch when they experience the benefits of Ajax, when they see a web page interact and respond actively without reloading itself all the time. Also, this distinction between web page and web application will become totally irrelevant, even laughable.

    It was the same with QuakeWorld. At the time it was launched, many people criticized it. Today, the huge success games like Counter-strike or Half-Life 2 would be unimaginable without a "smarter" client.

    Some people may argue that, unlike action games, surfing the web doesn't require twitchy reflexes and instant feedback, but the common ground in this whole analogy is that humans don't like to wait. No matter what we're waiting for, we tend to get annoyed by it. Waiting is always detrimental to usability.

    In the end, usability speaks louder.

  30. 30/34

    Zachary Kessin commented on 3 April 2005 @ 23:24

    You should always do at least some server side validation, if nothing else it will prevent all sorts of attacks on your site.  In an AJAX type application you are exposing a web service to the world, there is no reason someone can't look at your source code and write a script (in perl maybe) to send data to it outside of your nice javascript interface. In some cases that  might even be a useful thing.

    I have been working on a new project, the XAB toolkit, to help develop Ajax applications with Firefox, SOAP, and PHP, you can download it from my website
    http://www.kessin.com/XAB/

    One thing we are realzing is that Ajax is a new thing, and we are still learning how to work with it.

  31. 31/34

    The Man in Blue commented on 3 April 2005 @ 23:34

    AJAX isn't a new thing. The acronym is, but the ideas aren't.

    And as for server side validation, it's nothing that you wouldn't normally do with any public web script. Of course you have to put in measures against people trying to hack it.

  32. 32/34

    Zach commented on 28 April 2005 @ 02:36

    Quoting this from above - "That ability has been available since Flash 4. It's great that you can do it without Flash now, but Flash is still arguably a lot better at this sort of thing than XML/HTTP is in a lot of circumstances."

    Its been available in JS for years, above and beyond the xml/http variety - and with no security issues.

    http://sportsforum.ws/ - chat room on top (only registered can use it) - is live, js only, the method works cross browser (at least Moz and IE, dont care one way or another about opera until it supports some other basic stuff I use) - -- and is light weight enough to be on top of a forum, on every page, with out causing any problems.

    I made that chat room 2 years ago - so to say any of this stuff is new, is a joke

    (Note - Moz hates me, its a personal thing I am sure - anyway - the method works in Moz, in this use, the other code around it I could not, for whatever reason get to work in Moz,and I am slightly way behind on what I am doing and have not had the time to pretend to figure out what the heck is different in Moz than IE that I just dont instinctively grasp - long story short - the method works in Moz, to see this use, you have to use IE)

     

  33. 33/34

    Ryan commented on 10 May 2005 @ 12:38

    Dismassing "Ajax" is pointless.  It's a great framework for buildilng better web apps.

    In my opinion, it's supperior to flash as it:
    a) doesn't require the user to install anything
    b) doesn't require any vector graphics experience to create a site
    c) leaves valid XHTML/CSS pages in it's wake

    However, in terms of degrading etc and accessibility I think the correct way to build an "Ajax" style app would be to first build it the traditional way, with the server functionality sufficiently abstracted that you can then insert an "Ajax" layer in the middle.

    This should in theory provide a degraded version that works the traditional way for browsers without javascript.

    I haven't tried this yet, but in principle it's the same technique we use on the front end to make sure the XHTML/CSS degrades nicely in older browsers.

  34. 34/34

    Treehouse Cityguide commented on 3 September 2005 @ 05:22

    As more and more people use Javascript (thanks to google's trailblazing), things like the thread model will get more features and more standards, and it will become a useful programming language.

  35. Leave your own comment

    Comments have been turned off on this entry to foil the demons from the lower pits of Spamzalot.

    If you've got some vitriol that just has to be spat, then contact me.

Follow me on Twitter

To hear smaller but more regular stuff from me, follow @themaninblue.

Monthly Archives

Popular Entries

My Book: Simply JavaScript

Simply JavaScript

Simply JavaScript is an enjoyable and easy-to-follow guide for beginners as they begin their journey into JavaScript. Separated into 9 logical chapters, it will take you all the way from the basics of the JavaScript language through to DOM manipulation and Ajax.

Step-by-step examples, rich illustrations and humourous commentary will teach you the right way to code JavaScript in both an unobtrusive and an accessible manner.

RSS feed