The Current State of Ajax

Dion Hinchcliffe writes "Ajax hasn't even been big a year yet and already open source development tools by the dozen are pouring out. Not to mention big names like TIBCO and Microsoft already have previews on the way of full-fledged IDEs for developing Ajax applications. Ajax may be the biggest software development story of 2005. Dion Hinchcliffe has a detailed article about how Ajax has evolved over the last six months and assesses the current state of tools, libraries, and mindshare. He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services."

Comments

Thin Clients, Fat Pockets

[mfh]

Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services.

I think we've been seeing this shift for a while now, since people went from fat client software towards more streamlined C/S replacements, due mostly to convenience and easier features, server updates etc. Plus you can't argue with the repeat revenue stream generated by services that you can offer your customer, as opposed to a single sale.

When did you move your email handling from a fat client to webmail? My first move was from Eudora to Outlook, then Outlook (yuk) to Pegasus (don't ask) and then to Hotmail and now Gmail. I don't think I'll move away from Gmail, but you never know.

Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes. I look at Ajax as being only a bugfix to the intarweb and nothing else, really. Seriously, why do I want to refresh a whole template when I want to send only a little widget of text in the middle?

Frames were not the way to handle this kind of presentation/data separation, mostly because they could be indexed and that would confuse visitors coming to the center frame and not the whole display. Eventually many people just stopped using frames because they are clunky, and have strange display problems on varrious systems. Ajax remedies this problem, really. Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?

Ajax is definately going to push for more service oriented contracts and eventually I can see products dwindling or becoming wrapped into services and monthly subscriptions instead of out of the box solutions that are popular today.

I will bet that eventually we'll see some very thin looking clients in the near future, thanks to Ajax.

Re:Thin Clients, Fat Pockets

[Anonymous Coward]

Nice comment. But still nicer Slashdot id, or did the new ids max out and wrap around to 0?

Re:Thin Clients, Fat Pockets

[Anonymous Coward]

Let me get this straight. You typed up all that in 1 minute from when the article was posted???

The Current State of Ajax
Posted by samzenpus on Friday August 19, @04:42PM

Thin Clients, Fat Pockets (Score:2, Insightful)
by mfh (56) on Friday August 19, @04:43PM (#13358051)

Re:Thin Clients, Fat Pockets

[bedroll]

Frames also didn't solve all the problems. IFrames came much closer, but still no cigar. One of the problems is that sometimes you just need a round trip to the server to tell script to do something to the page, you can accomplish that with a hidden IFrame or Frame, but that's not really what they were designed for and it requires the browser to interpret the result and attempt to render a page. That slows everything down just enough to be noticable.

p.s. I used Pegasus as my primary mail client some 8-10 years ago. For that time it was pretty good, is it really that bad now that it gets a "don't ask"?

Re:Thin Clients, Fat Pockets

[gregstumph]

Let me get this straight. You typed up all that in 1 minute from when the article was posted???

See: the previous NTP story ;)

Re:Thin Clients, Fat Pockets

[AKAImBatman]

I think you'll find that the idea behind AJAX has been 20 years in the making. It's about time it caught on! ;-)

Re:Thin Clients, Fat Pockets

[AKAImBatman]

One of the problems is that sometimes you just need a round trip to the server to tell script to do something to the page, you can accomplish that with a hidden IFrame or Frame, but that's not really what they were designed for and it requires the browser to interpret the result and attempt to render a page.

If you get an XML response in a hidden IFrame, it's just as good as the XMLHttpRequest. You can assign a listener to the IFrame so that you know when it's done loading. The listener can then walk the XML DOM for the information it needs to modify the HTML document.

Not sure if that's useful at all, but I figured I'd throw it out there. :-)

Re:Thin Clients, Fat Pockets

[C.Batt]

Hypothetically you could set up a site that had a bunch of frames that interacted independantly and achieve a similar result to Ajax, but who would want to have to handle the cross platform and cross browser problems that arrive when you rely on frames?

I can speak as someone who has in fact done just that and would have killed for an XMLHttpRequest object back in 2001.

Today I'm architecting a significant new web project and my first order of business on the UI side was to specify XMLHttpRequest (buzzword catchphrase, yuck.) as the core around which the client would be developed. It's working fantastically. It simplifies just about everything, imho, once the basics are in place.

It is now possible to do highly-reactive monitoring applications in a browser without applets, plug-ins, or frames+script chicanery. Download the core app, then stream in the rest of the bits behind the scenes. Sweet!

The clients love it, we love to develop using it. Win, win situation - a strange place to be on an IT project.

Re:Thin Clients, Fat Pockets

[dotwaffle]

I use Pegasus on my Windows system, and a mix of KMail and mutt on my Linux system. Pegasus is by far the best mailer for me, as I get a lot of junk that needs sifting through quickly (AFTER junk filtration) and in fact I prefer it to any other PIM - the telephone message function is quite handy too.

The only disbenefit is the IMAP functionality - whilst it is getting the IMAP login/folders etc, the systen freezes, annoying when you have 40 folders and it takes ~5 seconds.

Re:Thin Clients, Fat Pockets

[El_Muerte_TDS]

thinner clients?...

I use mutt, irssi, slrn and ELinks. I don't think I want thinner than that.

Re:Thin Clients, Fat Pockets

[AstroDrabb]

Huh? This doesn't sound anything like AJAX. AJAX uses asynchronous/synchronous calls backs to the server and you will usually get just XML as a response. From your link you were talking about sending down heavy Java Applets and PostScript. Not even close to AJAX. The link you posted even pointed out the problems:

You see, when Sun created NeWS they charged a licensing fee to developers for the use of the technology. This wouldn't have been so bad if Adobe didn't also charge a licensing fee for the PostScript technology. Not only that, but PostScript turned out to be a very difficult language for developers to work with due to its Reverse Polish Notation. Combine this with the fact that NeWS was not an open standard, and you end up with a lot of customers who wanted something a bit more open and less expensive.

Hmm, it doesn't even sound close to AJAX IMO. I don't blame developers from passing on a "technology" that they would have to pay Sun _and_ Adobe to use and then be a "difficult language for developers to work with".

Re:Thin Clients, Fat Pockets

[SquadBoy]

Bah. Gmail takes a browser talk about bloat. Mutt now *there* is a thin client.

Re:Thin Clients, Fat Pockets

[vcv]

It WAS available back in 2001. In IE ;)

Re:Thin Clients, Fat Pockets

[jericho4.0]

He bought it on ebay. No joke.

Re:Thin Clients, Fat Pockets

[Bryan Ischo]

No, he probably did what I sometimes do: as a subscriber to Slashdot, I get to see the articles before they're published, presumably so that I can get a "sneak peek" and also so that I can submit bugs about the editorial text before the content is published. Sometimes I see an article I want to comment on, and I know that if I get an early comment it's more likely to be read and (hopefully) modded up. So I type up my post in an emacs buffer, and refresh the Slashdot homepage every couple of minutes until the story goes from red (not posted yet) to green (posted and ready to receive comments). Then it's simple to copy-and-paste the text.

Re:Thin Clients, Fat Pockets

[Anonymous Coward]

Wow... why isn't this spam post modded down to oblivion?

Re:Thin Clients, Fat Pockets

[br0ck]

And doing it in an IFrame can get around one of the biggest disadvantages of XMLHTTPRequest, the broken browser back button. This is the method that Google Maps uses to be able to page back through search results. The Ajax Wikipidia article mentions this and other workarounds.

Re:Thin Clients, Fat Pockets

[yomahz]

I can speak as someone who has in fact done just that and would have killed for an XMLHttpRequest object back in 2001.

MS added XMLHttpRequest to IE4 around 1998-1999. You wouldn't have had to kill anyone.

http://en.wikipedia.org/wiki/AJAX

Re:Thin Clients, Fat Pockets

[bedroll]

And doing it in an IFrame can get around one of the biggest disadvantages of XMLHTTPRequest, the broken browser back button.

Your disadvantage is my advantage. Sometimes you don't want that user to hit the back button to get to the last page, like when that last page was a form that you don't want them to reuse. It's annoying that I've had to develop methods to avoid duplicate submissions just because people hit a button twice or decide that the proper way to correct a mistake is to hit back then submit again.

Re:Thin Clients, Fat Pockets

[bedroll]

Junk filter? IMAP? Yeah, a lot has changed in nearly a decade.

In-browser interfaces are just too good and too convenient for me to pass up right now. I gave up on my pop account and set it to forward everything but definite spam to my Gmail account.

I should check out Pegasus just for nostalgia.

Re:Thin Clients, Fat Pockets

[misleb]

Great, now all we need to do is fix the pitiful state of HTML "widgets" and we will be all set! Seriously, HTML has to be the single worst way to make a "rich" web application. You get like 3 or 4 basic widgets with very little flexibility to make a GUI with, and that is about it. The rest is rather complex CSS. Now, XUL, that is a slick way to make a nice web app. And you can use the very same Ajax technology with it. Too bad it is Mozilla only.

-matthew

Re:Thin Clients, Fat Pockets

[killjoe]

Perhaps you could answer this question for me.

Why couldn't your problem be solved by a more stateful thin client solution? Specifically why couldn't you solve your problem with java web start?

I would think a full blown java application could run rings around a stateless, HTTP based, XML based, PRC protocol no?

Re:Thin Clients, Fat Pockets

[Anonymous Coward]

or decide that the proper way to correct a mistake is to hit back then submit again.

That is the proper way to correct a mistake, it's the way the web works. Don't blame your users because your too lazy to write proper code.

Yes, there are sometimes transactions that can't be undone. In that case you return a page explaining why it can't be undone, and what they can do to correct the problem (e.g. call customer support).

Re:Thin Clients, Fat Pockets

[skrolle2]

When did you move your email handling from a fat client to webmail? My first move was from Eudora to Outlook, then Outlook (yuk) to Pegasus (don't ask) and then to Hotmail and now Gmail. I don't think I'll move away from Gmail, but you never know.
Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes.

Oh, you mean the kind of responsiveness and bandwidth conserving that every IMAP-capable email application can deliver? The kind of application that you don't need to download from a webpage every time you want to use it, but instead is installed locally? The kind that runs natively on your machine, instead of living in a webbrowser?

The emperor is naked.

Re:Thin Clients, Fat Pockets

[SillyNickName4me]

Trying to stop people from using the back button means interfering with their ability to navigate the web. If you believe that is a good idea then you really should start from scratch and try to understand what the web is and why it works.

As others have mentioned, if resubmission of a form is a problem, generate a proper error page that explains this.

Re:Thin Clients, Fat Pockets

[master_p]

Ajax unplugs you because you get the immediate, targeted response from the server that wasn't available before. So refreshing a whole page when I only need to see a small widget change is really what Ajax fixes. I look at Ajax as being only a bugfix to the intarweb and nothing else, really. Seriously, why do I want to refresh a whole template when I want to send only a little widget of text in the middle?

The above really means that html as we know it is flawed and what is needed is a distributed application framework that can be as light or as heavy as the programmer wants.

The X-Window system was an early attempt for a networked GUI, but it forgot to provide the widgets. HTML was also an attempt to provide networked GUI, but it was too static. Java is too bloated and downloading applets takes time./p>

It's clear that a solution which is in between the X-Window system and HTML is needed. Ajax does not cut it for me, because it's based on hacks like Javascript.

Re:Thin Clients, Fat Pockets

[fbjon]

Yes. Damn those users, always pressing unexpected buttons!

No really, if you think about it, the proper way to correct a mistake is to go back, correct it, and then continue. Proper does not mean technically proper, it means intuitive. Also, the back button is just as much a "cancel" or "oops!" button as anything else. Remember that the back/forward buttons are the backbone of surfing. If you break them, you break the nice waves. And if you break the nice surfin' waves, you lose good karma. (in life, not on /.)

And btw, please don't tell me you have a screen that tells the user that "You pressed the button twice, the second press will be disregarded, lohoo-ser.". That's one of the most obscene ways to show total disregard for interface design.

Re:Thin Clients, Fat Pockets

[fbjon]

How about we all agree to shorten it to XHR?

We avoid:

1. Unnecessary length (httprequestblabla)
2. That yucky buzzword XML

Though, if we don't use it with superiors, we might also be avoiding:

3. ???
4. Profit! :-(

Re:Thin Clients, Fat Pockets

[SimHacker]

NeWS was developed a long time before Java, by the same person working for the same company: James Gosling at Sun.

NeWS used PostScript throughout, as the imaging model (like DHTML), the scripting language (like JavaScript) and the data model (like XML). It was like AJAX in that it sent asynchronous messages over the network and used a dynamic scripting language on the client side (called the NeWS server), so it could implement local graphical user input feedback, and efficient application specific network protocols (using a binary encoding for PS data).

NeWS was much more consistent and better designed than AJAX's amalgamation of accidental technologies (DHTML, JavaScript, XML). NeWS also has many other advantages over AJAX, such an excellent imaging model, wysiwyg printer compatibility, shared modules, multithreading, synchronization, a programmable event distribution system, a fully developed Open Look gui toolkit, and graphical interface builder (HyperLook).

Writing NeWS PostScript is a lot like directly programming byte code for the Java or Flash virtual machines, which are both object oriented stack machines a lot like PostScript and Forth. At the time, we were well aware that many people had a hard time programming in PostScript directly (although I love it), so several interesting compilers were developed. Rehmi Post wrote a back-end to the Amsterdam Compiler Kit (CScript: C for yourself, PostScript for NeWS), Arthur van Hoff (who later wrote the Java compiler in Java) wrote PdB (Pretty darn Brilliant), a compiler that translated object oriented C into PostScript , which supported subclassing PostScript NeWS toolkit classes. Dave Singer at Schlumberger wrote LispScript, a Lisp to PostScript compiler, which allowed you to take full advantage of Common Lisp macros to develop PostScript programs!

OpenLaszlo is a high level XML/JavaScript based programming language, which compiles into Flash byte code that runs in the Flash player, and works exactly the same across all platform. The inner loops and hot-spots of Laszlo are hand written in "flasm" (Flash Assembler), as hand optimized alternatives to the compiled JavaScript code. (Laszlo is a JavaScript compiler that currently outputs SWF code, but will support other virtual machines in the future.) Flasm looks a lot like NeWS PostScript code, with all the stack comments. Laszlo is open source, so you can grab a copy of the LPS sources and look at "LaszloView.as" to see what I mean.

-Don

Re:Thin Clients, Fat Pockets

[Bill Dog]

(I would mod that "underrated" if I had points.)
Good point -- when we refer to a browser-based app as a "thin client", we're referring to our own app not needing to be "installed" or having a "footprint" on the client machine, and we lump the web browser into that "thin" definition only because it's almost always already installed, and then forget about its footprint (especially with IE on Windows where it's thought of as part of the OS).

Re:Thin Clients, Fat Pockets

[SquadBoy]

apt-get install sense-of-humour

Re:Thin Clients, Fat Pockets

[plague3106]

I will bet that eventually we'll see some very thin looking clients in the near future, thanks to Ajax.

Sorry, I don't see it. I've been doing web development for 7 years now, and Ajax doesn't fix some of the bigger problems that come with web development. Javascript objects are still limited by the fact that JS is scripting, which is inherently harder to debug / mantain. .Net, with No touch deployment and the upcoming clickonce install removes many of the deployment and installation problems that traditional thick clients pose. Ajax doesn't compare given the rich controls of a traditional application.

Internally I think we'll see a return of thick clients with a proper n-tier architechture. That same architechture will allow outside companies to communicate using SOA.

SOA gives your clients / suppliers the option of using a dumb client with limited features or developing a traditional application that communicates with a SOA.

I think (and hope) that the browsers day's are numbered for providing applications. Applications will come again, they will be more of a distributed nature.

Re:Thin Clients, Fat Pockets

[gregstumph]

And how do you spend your "spare" time?

Re:Thin Clients, Fat Pockets

[C.Batt]

Hey, you're right. No argument from me. But...

many times you end up working on a project that someone else spec'd and that money has already changed hands on and you have to deliver.

And just to clarify something too (re: other comments in response to my original statement). I was aware that IE had this capability, amongst others, way back when... but that was IE. Please refer to the previous paragraph.

(I know that this is a really late response to the original message)

High Performance Back-end Services

[pete-classic]

SERVICE UNAVAILABLE

Re:High Performance Back-end Services

[Anonymous Coward]

ROFL. I thought of exactly the same thing.

Re:High Performance Back-end Services

[Anonymous Coward]

Heh, what did you expect, it's asp.net. ;-)

Re:High Performance Back-end Services

[drgonzo59]

Yeah I love that, that was a good laugh. I can see someone saying, "Hey boss, check out this article about Ajax, we gotta get ourselves some of dat Ajax stuff, its way awesome! Let's click on the link to read more about it - SERVICE UNAVAILABLE - doh!"

Re:High Performance Back-end Services

[Anonymous Coward]

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Agility, Service-Orientation, Enterprise Architecture, and Software Development
State of Ajax: Progress, Challenges, and Implications for SOAs
A lot of bits have been pushed around the blogosphere on the topic of Ajax over the last few months. This includes my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial to Alex Bosworth's list of Ajax Mistakes to the uber-repository of Ajax knowedge, Ajax Matters.

Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API), and then use JavaScript to manipulate what the users sees programmatically via DHTML.

All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?

Figure 1: Ajax: The first compelling new client application model since the modern web browser

Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).

Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."

This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatever they're browsing with. It doesn't require anything more specific than your local browser, is based on standards, and leverages all the services that most organizations have in place in their back office, especially if they have been building service-oriented architectures.

Of course, there are some problems with Ajax, as there inevitably are with any major new approach. One is testing. You not only still have to test your applications, but even more thoroughly. Given that JavaScript, DHTML, XmlHttpRequest, and DOM support all vary slightly between browsers, you need to test your Ajax applications in all supported browser versions and in multiple screen resolutions to make sure you have

Re:High Performance Back-end Services

[Anonymous Coward]

Ahahahahahahah!

That's a good one, OP.

Nothing

[Luigi30]

Nothing for you to see here, please move along. I guess Slashdot hasn't heard of Ajax either.

Wow

[nightsweat]

Slashdotted by the second comment. That's impressive.

Re:Wow

[TopSpin]

Slashdotted by the second comment.

Doubt it. More like they saw the "mysterious future" post themselves and the subscribers hitting their machine before the post appeared before all ./. Some admin with enough wit to handle the situation frobbed the server and saved himself a tough Friday afternoon.

Re:Wow

[nightsweat]

Good Point. Forgot about the 1.21 Gigawatts feature for the subscribers.

By the way, did you get that at Ebay?

If Slashdot supported AJAX

[Anonymous Coward]

You could see the dupes as the editors approved them.

What is it?

[Daniel_Staal]

Ok, the site is down, and I'm ignorant. What is Ajax? Free Karma to the best answer.

Re:What is it?

[Anonymous Coward]

Not sure if its slashdotted or not.

Don't care about karma, so meh.

Re:What is it?

[RingDev]

Active Java Asychronous Transfer (IIRC) it allows you to run xml queries from the client to the server with out posting the page.

Compare maps.google.com to mapquest.com. With Mapquest, when you zoom/move the map, it posts to the server and refreshes the frame. In google maps, there is no post, the map just moves/zooms like it would on a thick client.

-Rick

Re:What is it?

[Metaphorically]

Ajax is a buzz-word for Asynchronous JavaScript and XML. It generally refers to web based applications that feel more responsive than traditional pages because they don't refresh the whole page every time the user does an action. There's plenty more on Wikipedia.

Once you get down to the brass tacks of writing an app, here's a good way to deal with implementation problems people run in to.

Re:What is it?

[Anonymous Coward]

http://en.wikipedia.org/wiki/AJAX

Re:What is it?

[Mr. Underbridge]

Have you been in a coma, a cave, or just high on dope for the past year

Not all of us follow the latest fads. My programming library is kind of like my closet. It's neither worth rebuying your clothes or relearning your skillset annually.

Re:What is it?

[mogalpha]

AJAX is a combination of technologies that allows web app creators to have real-time refreshing of data. This refresh is not only selective (you can choose only to update a portion of the page), but it also won't waste bandwidth when there's nothing to refresh (it just sends a checksum or an id number). I'm currently using it in http://www.mogos.net/. On the front page of the site, you can see the latest word's that people have posted (and through AJAX, it refreshes every 8 seconds). It's a sort of real-time/turn-based word game.

Re:What is it?

[Daniel_Staal]

I don't think you understand the point of my question. The article wasn't avalible, and it was talking about the growth of a tech that was less than a year old, by the blurb. I had never heard of it. I keep moderatly up to date, but I don't have time to follow every new trend. Apparently this one is interesting to people.

So, in the interest of the discussion, I asked what it was. It's not likely to be relevent to anything I do; If it was I'd likely have heard of it. But here's a chance to offer insight into the issue, both to me and other readers. A chance to show the benfits and disadvantages.

Since I can't discuss the article, that's the next best thing. And it might be useful, to me or others.

Re:What is it?

[ch-chuck]

To be really up-to-date and 'with-it', here's a podcast

Re:What is it?

[AKAImBatman]

JavaScript. Please don't confuse Java with JavaScript. It just makes everyone's lives harder. (Especially when managers hire the new "Java" expert.) :-/

Re:What is it?

[Smokin Goat McGruff]

It was actually introduced in IE 5, so it's much more than a year old. It's only recently gained popularity thanks to the terrible acronym AJAX. Seriously, doesn't anyone else thing of Duckman when they hear that?

-nb

Re:What is it?

[Anonymous Coward]

What are you talking about? Everyone knows Ajax is a cleaning product!!

Re:What is it?

[afidel]

Why do people still call it Javascript? The correct term for the modern language is ECMAScript, Javascript was the Netscape version built in colaboration with Sun and revised several times over the years. I doubt that much origional Javascript code would work well in modern browsers.

Re:What is it?

[AstroDrabb]

What is Ajax? Free Karma to the best answer.

Do I win?

William Colgate started a candle and soap making company in New York City in 1806. By 1906, the company was making over 3,000 different soaps, perfumes and other products. For example, Colgate Dental Cream was introduced in 1877. In 1864, Caleb Johnson founded a soap company called B.J. Johnson Soap Co., in Milwaukee. In 1898, this company introduced a soap made of palm and olive oils, called Palmolive. It was so successful that that the B.J. Johnson Soap Co. changed their name to Palmolive in 1917. Another soap making company called the Peet Brothers Co. of Kansas City started in 1872. In 1927, Palmolive merged with them to became Palmolive Peet. In 1928, Palmolive Peet merged with Colgate to form Colgate-Palmolive-Peet. In 1953, the name was shortened to just Colgate-Palmolive. Ajax cleanser was one of their first major brand names introduced in the early 1940s.

Re:What is it?

[sexyrexy]

relearning your skillset annually.

Why should you have to relearn? Appending to your skillset regularly is what separates the 30k/year programmers from the 150k/year ones. Then you don't have to wear the same old ratty clothes!

Re:What is it?

[RingDev]

My bust, That's what I get for not proof reading ;)

-Rick

Re:What is it?

[BitHive]

Yeah, I have the same problem when people talk about Mambo (the PHP-based CMS)

Re:What is it?

[Brad1138]

Wile E. Coyote's secondary source (behind Acme) for questionable quality gizmos, traps, gadgets etc.

Re:What is it?

[Anonymous Coward]

You think that's funny, you fucking stupid asshole-licking son of a bitch. Everybody hates you and your miserable attempt at humour. Die, die,die, bitch!

Re:What is it?

[Mr. Underbridge]

Why should you have to relearn? Appending to your skillset regularly is what separates the 30k/year programmers from the 150k/year ones. Then you don't have to wear the same old ratty clothes!

The problem is that the newest fad language doesn't equate to a marketable skill. I would say the $30K/yr programmer is the kid who can't understand why no one will pay him for his knowledge of an infinite number of scripting languages.

Re:What is it?

[MattFlower]

It was JavaScript long before it was ECMAScript. Even Microsoft called their implementation JScript in deference to the original. JavaScript was already a recognizable name for scores of developers and quite a few users. A standardization body that few care about is going to do little to change that. Even now, if I called it ECMAScript at work, there is no doubt that the people at work would think me a newbie.

Mostly importantly though, AEAX sucks as a name. :)

Re:What is it?

[Bill Dog]

Appending to your skillset regularly is what separates the 30k/year programmers from the 150k/year ones.

Generally agreed, but on the other hand, if I was a 150k/year programmer (don't I wish!), why would I rush to learn something that would put me in competition with 30k/year programmers?

More than a year thanks

[buro9]

"Ajax hasn't even been around a year yet"

Which is strange, because in 1999 I was making web applications that utilised hidden frames to post information to the server and return JavaScript arrays which I would then use to modify the limited parts of the DOM I had access to at that time. It worked in Netscape 3, Netscape 4, and IE 3 and IE 4.

So the techniques in question have been around for ages, and the use of Xml and the XmlHttp objects appeared several years ago with Outlook Web Access.

The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX".

I'm glad other people are picking up on it and using it, it's very powerful, but let's not credit Adaptive Path with creating a technology or method that many people have been using for a long time.

If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.

Re:More than a year thanks

[PIPBoy3000]

Yep. Very true.

We were having performance issues with our Intranet home page. The page was data-driven and requests took too long to execute. People would get impatient, hit refresh, add more items to the queue, and eventually things would melt into a puddle.

I rewrote as much as possible using static javascript includes and cookies, greatly improving performance. There were still a couple things personalized to the individual. Those I threw into a hidden frame which filled in a couple drop-down boxes and populated a line that said "Hello username." (not my idea).

If the database was down or busy, those things wouldn't be available, but 90% of the time the users wanted to click one of the static links.

Re:More than a year thanks

[jdavidb]

If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable and doesn't restrict the developer to asynchronous work only for it to be included in that.

Thank you for the explanation. I've been wondering what in the world AJAX is, and why I should care. I don't know what AJAX is. But I can tell what a Rich Interactive Application is. Isn't it nice how language can be used as a communication tool rather than a way to hide your meaning so you can feel elitist compared to those who do not know the new terms? To date I don't think there's been a single slashdot submission that explained in the summary what AJAX was, even though this submitter clearly agrees that it's something new. You'd think if it were new and something they want to promote they would be explaining it at every opportunity -- unless of course they want to hide the fact that it's not that big of an advancement.

Re:More than a year thanks

[buro9]

AJAX = Asynchronous Javascript And Xml

It's a terrible name because it says nothing about what it is, only what it is made of. Even then it poorly describes what it is made of, as it can be made of other things too.

So from this CBL (Carbon Based Lifeform) to another, I say, "Goodnight".

Re:More than a year thanks

[merreborn]

A startup I worked for, State Software had a full out API developed that did the exact same thing back in 2001 -- used a hidden IFRAME to pass javascript objects to and from a server. It was enterprise ready... But it was proprietary, and while they recieved quite a bit of attention from the biggest names in ECommerce apps, they never did get any real sales/installations.

Re:More than a year thanks

[Anonymous Coward]

Ajax hasn't even been big a year yet

around != big

Re:More than a year thanks

[quamaretto]

Which is strange, because in 1999 I was making web applications that utilised hidden frames to post information to the server and return JavaScript arrays which I would then use to modify the limited parts of the DOM I had access to at that time. It worked in Netscape 3, Netscape 4, and IE 3 and IE 4.

Yup. Our company has a VERY old web application that makes minor use of this sort of thing, to fill dropdowns in a business application. Except, whoever wrote it used a pop-up window instead. Not quite as eleganet.

The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX".

A simple solution would be to believe AJAX stands for "AJAX, Javascript And XmlHttpRequest." (This definition replaces 'asynchronous' with a specific mechanism, XmlHttpRequest, and drops XML.)

Even so, it could be interpreted in the same manner as LAMP. The operating system could be one of Linux, any BSD, Solaris, Darwin, or something else entirely. The web server could be Apache or a great many others. Database? MySQL, Postgres, Firebird, SQLite... Language/Platform? Oh, hell. So, the real representation would be /[LBSDW].[MPFS][PRMLS]/. Use your imagination on these. AJAX is the sameway; it is a mishmash of ideas and technologies, but a few lead the pack and represent what is going on.

But, maybe your RIA idea is better. :)

I have been working on a nice AJAX app for awhile now and the most tiring part of it (apart from cross-browser woes) is trying to explain what AJAX is.

RE:More than a year thanks

[Anonymous Coward]

Yeah, but the X doesn't stand for 'Hidden Frames'.
The topic here is AJAX, not the fact that an (IMO) ugly hack can also make RIA's.

Although I do agree that it has been around for a lot longer than TFA makes out, and that AJAX is a wanky name - everything in the tech world is given an acronym now-a-days and it seems most of the time the words are fitted to the acronym not the other way round. Adds to the coolness for people who don't use the tech and annoys some people who do use the tech (but don't want a stupid name for it).

Re:More than a year thanks

[TigerTale]

If you have to use a name, then RIA (Rich Interactive Applications) is far more suitable

RMS, is that you?

Re:More than a year thanks

[Anonymous Coward]

Don't you mean CarbOn Based Organic Lifeform?

Re:More than a year thanks

[__aajwxe560]

I laughed when I read your post, as I was thinking the same thing.

For years there has been this certain drive to turn the web browser into more of an "application" platform, and most attempts I have seen were a failure in one way or another (poor execution speed, strict browser requirements, buggy interface, random crashing, inconsistent experience with different browsers or even different versions of same browser, etc.). And for the countless billions of web pages out there, and the very limited scope of those that I have seen myself, I have only seen two web-based "applications" that impressed me with a certain wow factor - Outlook Web Access, and Google Maps.

This just seems like something new for the guys who keep pushing the web browser as a viable application platform to grab onto to sell books and libraries until the next acronym comes flying by. Meanwhile, I am still both impressed and amazed at the amount of information available now, compared to 10 years ago, simply by just using my browser as the information tool it was originally intended. In fact, I have no idea how I would have even accomplished my job 10 years ago without it.

Re:More than a year thanks

[Rinzai]

Yeah, amen to that, brother, I was too. Nice how finally people come around to the right way of doing things.

Re:More than a year thanks

[Kamiza Ikioi]

"It's a terrible name because it says nothing about what it is, only what it is made of."

XML = Extensible Markup Language. Not exactly an extremely informative name there, but certainly acceptable. I rather it be AJAX instead of:

UJATDUIXFTDUPWRTWPOLANWP = Using Javascript And Templated Documents Usually In XML Format To Dynamically Update Pages Without Refreshing The Web Page Or Loading A New Web Page.

Re:More than a year thanks

[emlprime]

You could just assume, like I did, that it was a reference to "The wall-like Aias" (Anglified to Ajax) from the Illiad. He was the biggest and the strongest of the Achaians who won the trojan war. I prefer Ajax to RIA because it's easier to remember than another TLA.

Re:More than a year thanks

[Samus]

Personally I think Linux Apache Mysql and Ruby make a nice funny little acronym. I can just imagine a bunch of guys going around saying that they are lamer programmers.

Note this isn't a dig against Ruby or RoR, and I do not intend to start a flamewar.

Re:More than a year thanks

[dbIII]

The ONLY thing that has been around for approx' a year is the utterly stupid name for it, "AJAX"

Another ideal firewall name gone! In the Iliad, a warrior got this as a nickname because he was built like a wall.

Re:More than a year thanks

[misleb]

Oh give me a break. Nobody is trying to hide information from you, moron. Just look it up if you don't understand what it means.

-mathew

Re:More than a year thanks

[statusbar]

It is a bad name because the 'XML' is not even necessary. A few popular sites that are said to use AJAX are really using JSON, not XML. The concept is the same though.

jeff

Microsoft?

[Eightyford]

Microsoft has an AJAX IDE coming out? Isn't AJAX supposed to do away with alot of Windows development , and replace it with browser based apps? I could see Microsofts AJAX IDE crippling Firefox in many 'accidental' ways.

Re:Microsoft?

[Anonymous Coward]

Huh?

Do you even know what an IDE is?

I'm guessing no.

Re:Microsoft?

[Anonymous Coward]

perhaps he means the resulting app will be compiled in such a way that it wont work in firefox?
he's scraping the bottom of the barrel of paranoia though imo

Re:Microsoft?

[Eightyford]

Frontpage is basically in IDE right? Sure you can write standards complient code with it, but the automated stuff spews out all kinds of non-standard crap.

Re:Microsoft?

[Anonymous Coward]

Although I'm a lowly AC, I went to an MSDN event yesterday where they demo'd ASP.net 2.0, scheduled for release in November. One of the features they highlighted was AJAX support. They even showed it working with Firefox. The presenter said "yeah, I know, people don't believe we'd do this, but we're pragmatic...we want you to use our developer tools, and we know there are plenty of non-IE browsers you have to support."

At the end he asked us our favorite things we saw demo'd...I was so tempted to yell out "Firefox!" but I refrained :)

Re:Microsoft?

[Anonymous Coward]

Correct me if I'm wrong. Isn't Microsoft the one who "invented" the XMLHttpRequest method, the core of all AJAX-based apps?

Should've been Google, everyone would know.

Re:Microsoft?

[Anonymous Coward]

Hi, I was wondering if you could provide some video clips or screenshots of the AJAX stuff you saw at the MSDN event where they demo'd ASP.net 2.0 for release in November? Or maybe could you tell us more about some of the AJAX features you saw? Thanks. I'm sure alot of readers would be interested in seeing or hearing more about it the new AJAX stuff.

I think they need to use some Ajax...

[meditation_dude]

...to scrub out their server after that Slashdotting. ;-)

Re:I think they need to use some Ajax...

[Anonymous Coward]

Hmm, if only the cleaner "Ajax" would be known to every human in the great wide world ...

Is it really that popular?

Smoking crater

[Anonymous Coward]

"Ajax requires high-performance service-orie....a@%JA6zzzz1...NO CARRIER

The Current state of ajax?

[Anonymous Coward]

I think you can still find the cleanser at any Wal-Mart, Meijer or Kroger. ;)

Re:The Current state of ajax?

[Radres]

OMG TEH LOLZ!!!

What's next, you can find Java at Starbucks?

Re:The Current state of ajax?

[aminorex]

...Perl in oysters, Ruby in North Carolina, Afghanistan, and Tanzania, CAML in the Zahara and Gobi, Orca in the north Pacific, C in the alphabet, Ada in Babbage's budoir...

I'm working on a script for a Matt Damon movie, "The Bourne Shell".

Re:The Current state of ajax?

[maelstrom]

And the SQL to the Bourne Shell, "Bourne Again".

Re:The Current state of ajax?

[value_added]

I'm working on a script for a Matt Damon movie, "The Bourne Shell".

FLASHBACK - INT. CAR - NIGHT

"Kill zcat," sed ed.
"Awk!" sed perl.
"Make sum nice tee, joe," sed man.

Re:The Current state of ajax?

[DrewCapu]

I still have some students that can't find C# on a piano.

Re:The Current state of ajax?

[Unordained]

I don't get it. The ess-queue-el to the bourne shell? I guess it rhymes, but ...

Re:The Current state of ajax?

[IgLou]

OMG, I'm snickering so loudly at this that the co-op near me must think I'm insane.

Would the script read something like:
ed finger perl man kill ed
perl man split
man grep perl tail

... Nevermind, somehow my brain just went south.

Re:The Current state of ajax?

[cirisme]

The joke is dependent on pronouncing SQL like "Sequel".

Re:The Current state of ajax?

[Anonymous Coward]

I'm working on a script for a Matt Damon movie, "The Bourne Shell".

I'm working under the Bourne Shell to write some code for a new server process, the Matt Daemon.

Re:The Current state of ajax?

[NoOneInParticular]

A joker, a pedant and a fool came into a bar ...

Since it's Slashdotted...

[tcopeland]

...here's an article by Curt Hibbs on Ajax with Rails. He's got an "Ajax in 60 seconds" history lesson at the top of the article...

AJAX and Centrino

[cerelib]

Does anybody think of Intel Centrino when they hear AJAX? They are quite similar in the fact that it is just giving a name to using a combination of technologies. Also, has anybody ever heard a Best Buy computer salesman say "This one has a Centrino processor."?

Re:AJAX and Centrino

[ReverendRyan]

Also, has anybody ever heard a Best Buy computer salesman say "This one has a Centrino processor."?

No, because none of us ever goes INTO Best Buy...

Ruby on Rails settles everything

[duffbeer703]

Ruby on Rails and AJAX makes everything else obsolete. A coworker and I just implemented the J2EE spec in 25 minutes. We're working on the win32 api on monday!

Re:Ruby on Rails settles everything

[TopSpin]

We're working on the win32 api on monday!

Win32? Big deal. Go implement X11 6.8.2 if you want to impress /.

Go ahead, I'll wait...

Re:Ruby on Rails settles everything

[drgonzo59]

Oh yeah, I'll see your X11 and raise by one Emacs editor.

Re:Ruby on Rails settles everything

[Anonymous Coward]

25 minutes? Didn't you see the helper code?

def my_app
J2EE.instance.run
end

I swear, Ruby is being overrun by newbies who insist on doing everything the slow way.

Re:Ruby on Rails settles everything

[Anonymous Coward]

Nobody ever denied that emacs is a great operating system.

But to compete with the likes of Linux or the *BSDs, it needs a decent editor.

Comment removed

[account_deleted]

Comment removed based on user account deletion

You know..

[Anonymous Coward]

He also points out that Ajax will inadvertently end up being a driving force for Service-Oriented Architecture (SOA) for many organizations since it requires high performance back-end XML services.

Advertising programming languages with a pre-com-bust-style-buzzword-overload isn't very useful for gaining the attention of developers.

Re:You know..

[Krimszon]

Even worse, SOA is dutch for a STD. Yes, one of those...

What is it? Its this

[razmaspaz]

http://en.wikipedia.org/wiki/AJAX

Ajax is using Javascript to fetch only part of a web page and then updating the page with DHTML and JavaScript, reducing round trip time and server load and making the application "feel " more native.

Re:What is it? Its this

[Evro]

You'd think the "editors" of this site would at least take the time to CAPITALIZE the acronym AJAX to distinguish it from Ajax, the Greek warrior, or Ajax, the household cleaner...

Re:What is it? Its this

[Anonymous Coward]

Or Ajax the Warriors' warrior.

"I'll shove that bat up your ass and turn you into a popsicle."

Best line ever.

accessability guidelines

[sammy baby]

Does anyone here know of a good reference for balancing the "gee-whiz, nifty" aspects of ajax techniques with designing towards accessibility? I like the thought of, say, livesearch, but dislike the idea of breaking support for text-to-speech readers, assistive devices, et cetera.

In fact, the article in the story might have a terrific section about just this issue. But I wouldn't know, because the server fell over worse than I do after a gin-and-tonic bender.

Re:accessability guidelines

[Metaphorically]

Accessibility takes a back seat to flashiness so far. A lot of "gee-whiz" ajax applications are great eye candy and the surprising responsiveness can make you wonder if it's just a web page or something more. I think that most of what we're seeing now doesn't get past that stage.

I follow Ajaxian, and even though it doesn't cover accessibility directly, I find that the developers they link to do get in to these issues sometimes. It's a new field, so you have to dig deeper to find people doing apps that are more than just experiments.

Degrade gracefully. Include keyboard accelerators. Always use alt text. The same rules, but there's got to be a lot of interpretation still.

Re:accessability guidelines

[MemeRot]

There was an article on slashdot a couple days ago about ibm donating a large section of code to firefox to enhance accessibility in ajax apps.

Re:accessability guidelines

[voodoo_bluesman]

Everything is so new that this hasn't been fully addressed. I am working on a new web app, and have decided to fully redesign it to be non-Ajax specifically for this reason.

My target audience could very well include those with screen readers, or even geeks w/ lynx. Since I'm more interested in reaching the largest audience as possible, Ajax will have to wait for me.

Maybe within the next two years we'll see a different take, but for now I'm sad to say I've got to stay away from it.

qooxdoo

[The Bungi]

http://qooxdoo.sourceforge.net/

Weird name, but very impressive. Though not an "AJAX" framework, with some effort it can be "bound" to an OOB request factory or something similar to have your cake and eat it (rich client-side stuff + backend server). Very cool. And it works with IE and FF, but obviously better with Firefox.

BTW, I love how this "AJAX" thing is just a cute name for a Microsoft technology that was first introduced with IE4. The first "AJAX" app was the Exchange OWA client.

Re:qooxdoo

[MemeRot]

True, but the XML part of this framework isn't really necessary. Why send a lot of xml text back to the browser and then make it load it into memory and walk through it? It's often better to send back a Javascript array - no real overhead for the browser or the internet connection.

BTW, OWA is so much more pleasant to use in Firefox (without all the dynamic crap) than it is in IE. It's sooooo slow in IE when all I want is webmail.

What is this...

[__aaclcg7560]

Postings of articles about AJAX on /. seems to be getting very popular these days. Is AJAX important or just another fad?

Re:What is this...

[Karma Farmer]

Postings of articles about AJAX on /. seems to be getting very popular these days. Is AJAX important or just another fad?

You've probably noticed that Slashdot itself now has a rich AJAX-based comment browser. It's actually very innovative -- you've probably noticed the improvement.

Some people like how it downloads the latest comments without uselessly refreshing the entire page. But, my favorite is when I click on "x comments below your current threshold." The animation as the new content slides into the page is realllly cool.

Of course, I suspect it's also reduced a lot of load on the servers, but that's not really my bag, baby.

Re:What is this...

[jericho4.0]

IMO, very important. The tech, as others have noted, has been around for a while. The label 'AJAX' has allowed people to publish books 'Learn AJAX in 24 hours', and allows one to throw a buzzword at PHBs. And with google and others providing slick examples of what's possible, more is sure to come.

Re:What is this...

[straterpatrick]

You know it's a fad when everyone is talking about it but the only real examples of it being used are the two examples that are attributed to it's initial popularity (Google maps and Gmail). I have yet to see any other practical, useful example of "AJAX" anywhere.

The concept is great but a bunch of people saying "AJAX" a lot does not mean it should be hailed as being important.

Re:What is this...

[mark_lybarger]

it's a fad that's going to eventually come around. there's only two examples because it's not fun stuff to develop. the current tools suck, cross browser issues are abundant, and how about following the specification?

the tech services folks love the internet applications due to the ease of deployment. they can count on nearly every user having a modern browser (mostly IE is sufficient). java and flash just aren't as widespread. on the other hand, internet applications suck. the controls are few in number and horribly limited in functionality. ajax only solves the one problem of a screen event causing the page to submit to the server, and waiting to rebuild the next page based on the response.

when things like toolbars, menuitems, tree views, tab controls, etc, etc, etc are standardized and available from the hyper text markup language, then i'll get excited about web development.

Got in before it went down

[NoTheory]

Dion Hinchcliffe's Blog - Musings and Ruminations on Building Great Systems

Agility, Service-Orientation, Enterprise Architecture, and Software Development

State of Ajax: Progress, Challenges, and Implications for SOAs

A lot of bits have been pushed around the blogosphere on the topic of Ajax over the last few months. This includes my own post back in March, which gave a general overview of what Ajax was and what it does. A lot of exciting stuff has happened since then, and Ajax has rapidy matured into a development of major significance. Coverage has been all over the map and runs the gamut from Rasmus' been-there-done-that 30 second Ajax tutorial to Alex Bosworth's list of Ajax Mistakes to the uber-repository of Ajax knowedge, Ajax Matters.

Many of you already know that Ajax is a web client programming style which eschews traditional HTML web pages, which are only sprinkled lightly with JavaScript and reload pretty much every time they are updated or clicked on. Instead, an Ajax web client receives an Ajax JavaScript library into a hidden frame which provides run-time visuals on the main browser window that look and feel very much like a native application. Ajax web clients, once loaded, communicate with XML services on the back end (via a browser's built-in powerful XMLHttpRequest API), and then use JavaScript to manipulate what the users sees programmatically via DHTML.

All of this allows Ajax to provide a compelling user experience because 1) it doesn't reload the web page, and 2) it runs asynchronously allowing background server-side requests for information to be issued, all while the users clicks, types, and otherwise interacts with the application in the foreground. Google Maps is the pre-eminent example of a modern Ajax application: rich, interactive, easy-to-use, and predictive in that it loads the map tiles that are just offscreen in case you need them. This is all very good for web client client development, but why all the attention across the board?

Figure 1: Ajax: The first compelling new client application model since the modern web browser

Because Ajax is a sincerely compelling synthesis of the ubiquitous features found in the most popular Internet browsers is why. Practitioners of Ajax get high-intensity user interaction (end-user productivity), asynchronicity (efficient backround processing), web browser access to web services (web service access, reuse, and interoperability, as well as SOA integration), platform neutrality (browser and operating system agnosticity), and the Ajax feature set can be delivered as a framework you don't have to create yourself (developer productivity).

Individually, these items are very nice, but taken as a whole, working solution and you have something extremely special. While many folks thought the web browser story had stopped around the year 2000, Ajax takes us to a whole new place. Slashdot recently highlighted a notable new article in Wired that claims that the industry, mostly on the basis of Ajax, "has affirmed the viability of the web as a standalone software development platform."

This is no small thing, and has the potential to repave the modern application development landscape. Why? Because Ajax creates a rich and fertile new space for developing software solutions that can reach almost anyone, anywhere whatev

Re:Got in before it went down

[14erCleaner]

Slashdotting: the arrow in the Achille's heel of the thin-client model. :)

Ajax hasn't even been around a year yet?!

[Flinx_ca]

Ajax has been around for 50 years...

Re:Ajax hasn't even been around a year yet?!

[Anonymous Coward]

a few millenia, actually http://www.infoplease.com/ce6/ent/A0802924.html

No Kidding

[Tony]

I started in about 2000 with hidden frames, Javascript, and DOM. I got the idea from someone else on the web; I thought it was brilliant at the time. I was able to auto-update forms without clearing the form, etc. All the stuff that AJAX is doing now.

It's nothing new. Other folks just think it is.

Re:No Kidding

[temojen]

I did it in 1998 in NN & IE. Just make a frame that loads dynamic web pages that contain javascript to make the changes to the main document, with no borgers & the same background colour as the main frame. Worked like a charm.

i stopped reading here:

[circletimessquare]

"Ajax hasn't even been around a year yet"

excuse me?

ajax the functionality has been around for 6 years or more

the buzzword "ajax" and the google maps implementation that skyrocketed the word to buzzword status has only been around for less than a year

i'm usually not one to champion geek snobbery

but when geek snobbery is pitted against cattle herds of phbs spouting buzzwords with little understanding of the buzzword itself, geek snobbery is more appealing

Re:i stopped reading here:

[camarojoe]

Ajax (tm) has been around for about 24 years, and Comet (tm) works better Anyway, the article says "Service Unavailable". :P

Re:i stopped reading here:

[Anonymous Coward]

perhaps you never started to read, since it actually says:

"Ajax hasn't even been big a year yet"

there is a big difference there.

Mmm, yeah, ok

[Anonymous Coward]

Dion Hinchcliffe writes...

'Dion Hinchcliffe has a detailed article about how Ajax has evolved'

It is never a good sign when someone talks about themselves in the 3rd person.

You gotta love those consultants, always after some free ad space in search of the dollar...

Re:Mmm, yeah, ok

[Anonymous Coward]

Anonymous Coward writes...

'Anonymous Coward has a detailed comment on how this self-promotion feeding frenzy around what is basically just a HTTP GET on a worker thread first done in 1999 is getting beyond a joke'

You insensitive clod, I *am* the 3rd person!

Annoyed

[defile]

You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.

Sigh.

I realize there's worry about cross site scripting attacks, and in the end it's not a big deal, it just means moving the request to a server side proxy. It's just added complexity that wouldn't exist if someone didn't impose something "for our own good".

Re:Annoyed

[Anonymous Coward]

That security "feature" exists when you are using IE. You can "AJAX" other domains.
At least I did it from localhost to one of my works web sites.

Re:Annoyed

[BobBonobobo]

That is annoying.

Flash provides a server-side policy file that allows servers to opt-in to provide data to scripts from other domains.

This allows Flash to default to the same security model as the browser, but also work more effectively when the data-provider knows what they're doing.

See http://www.macromedia.com/cfusion/knowledgebase/in dex.cfm?id=tn_14213

Re:Annoyed

[eieken]

Maybe you've never heard of Greasemonkey. Even though it is primarily client-side plugins being added in at the users request, it has cross-site AJAX capabilities built into it.

Old AJAX in New Buzzwords

[Doc Ruby]

The "name" AJAX hasn't been around long, but client JavaScript loading XML from servers for dynamic page rendering, inrteractive with client GUI events, has beeen around as long as JavaScript and XML. Before XML, it was data in proprietary or app-specific formats. Along the way it was FRAMES. The technique has always been the wizardry of the most aggressive web developers.

But now the marketers have a buzzword for it. It's good to have them back. They got so spun out as the Bubble popped that we haven't been able to get them to get anyone to buy stuff for years. Now it's time for them get back to work, marketing the tech that the rest of us have been producing for the past 5 years. It's good to have you back on the team - now show us the money.

No.

[mnemonic_]

I did not think "Centrino" when I heard "AJAX." It's not like giving a single name to multiple technologies is rare, see; object oriented programming, linux, fuel cell, sensor fusion, quiet supersonic platform (QSP), etc. I don't see why you think AJAX and Centrino are so exceptional.

Re:No.

[cerelib]

I think that your counter-examples are different. In AJAX people are already using these technologies to make web applications, but if they decide to leave one out it is no longer AJAX. If a comp manufacturer wants to provide their own wireless card instead of Intel's then it is no longer Centrino, but still the same thing. OO is an idea, not a catchphrase. You can implement OO any way you see fit with many languages(even non-OO langs). Linux is then name of a specific kernel. I can't comment on the rest.

good xmlhttp site

[Anonymous Coward]

check www.litebay.org's search box for a good xmlhttp example.

Popularization is an important job ...

[__aadkms7016]

The person who makes a technology popular receives technical fame for a good reason -- by making more of the world aware of a good technology, in a way that leads to deployment, the world becomes a better place. Sometimes, popularization adds more value than invention to an idea.

Re:Popularization is an important job ...

[Goo.cc]

You're right, but let's not act like it is a new invention just because it suddenly became popular.

Thats nothing

[WindBourne]

The guy who submitted it, is the same guy who wrote the article and has the downed server. shesshhhh

This is laughable

[ikekrull]

We need to write out business apps in Javascript now because this is the only standard browser vendors can agree on?

Javascript, it's non-standard browser-specific extension syntax and the restrictive, incomplete and non-standard HTML DOM is an awful environment to write apps in, and it illustrates clearly just how dysfunctional the modern software industry is today.

AJAX is a shit way to write apps, it's central concept revolves around badly hacking around a problem that shouldn't even exist in a language that was never intended for use in such a way, its like we've got the worst aspects of every major technology available today, grudgingly provided by browser vendors who are want to take their ball and go home since nobody wants to use their proprietary ActiveX or XUL - in an incompatible fashion and we're supposed to see this as a step forward?

It's stupid, AJAX is stupid, and browser based apps are crap.

Re:This is laughable

[Tumbleweed]

It's stupid, AJAX is stupid, and browser based apps are crap.

Dear Sir or Madam,

You rock.

Sincerely,

Moi

Re:This is laughable

[akuma(x86)]

Sounds like x86 :)

Crap, crap, crap, loaded with more crap. But 99% of the world uses it due to market forces.

Re:This is laughable

[Anonymous Coward]

If you still contend that thick-client applications are the correct way to go for most data entry and information retrieval problems then you will be out of business soon. Server + Thin Client "AJAX" + browser allows for a far faster development cycle than thick-client apps.

Re:This is laughable

[Miriku chan]

aren't market forces a bitch? =)

boss: "i want ajax for this application"
you: "it's stupid i don't want to do it it's dumb i won't do it"
boss: "ok, you're fired. on your way out tell young programmer we just hired to come into my office, i have a project for him"

Re:This is laughable

[Some Random Username]

What kind of moron would work at a place like that?

Re:This is laughable

[Anonymous Coward]

someone mode the parent up to 12. It can't be stressed enough how ghetto AJAX is. I would absolutely hate to maintain an AJAX over, say, 5 years.

We have one from the 90s, and fixing problems in it is like performing voodoo.

Re:This is laughable

[cranos]

Someone who actually wants to work in the real world. It is an unfortunate truth that many projects are specced based on what's cool at the time rather than on what is the best solution for the problem.

Re:This is laughable

[Anonymous Coward]

I completely agree that these tech buzzes are weird. It reminds me so much of the ga-ga Internet boom. I guess that's what separates practical savvy techies from impractical onanistic "geeks." I really don't understand the fetishy attraction geeks have for technology that end users don't want, or for repackaging of things that have been around for years.

Take RSS. Yes, the way it works is a LITTLE different from push technology, but basically the end user experience is the same. Neither I nor most people had any use for push ten years ago, so why should we care now? Oh yes, it is all the current buzzword rage, and yes, Microsoft is rebranding it and including it in some vaporware browser, but whoop-de-do. Read the statistics and you'll see that few people are actually using it.

Flash, cookies, scripting... I'm not a tin foil hatter, I just don't use those things because they're dumb and intrusive. And based on the typical slashdot postings about the dangers and uselessness of those technologies to the end-users, I would have thought most slashdotters would agree with me. I hate to use Windows but when I do, I always do it with all scripting turned OFF, and I have never had a Windows virus. And I don't use java script in Linux either - I don't need it. So, now, whoot, whoot, Google Maps says download our software and turn on java scripting and with this cool AJAX crap you'll have some browser functionality. And the geeks say, whoot, less demand on the server, new toys, or rather, old toys with a new name, "AJAX" whoot, everybody's gonna have it!

And the end users once again, JUST LIKE ALWAYS, say -- We don't give a fuck about server load - that's not our problem. And, scripting is too risky to our machines -- we're not turning it on. So while the end users yawn and look away, the geeks cover themselves in mutually masturbated technological cum. Whoot whoot whoot!

If I hadn't been around so long, I would be thinking right now that it is all the paid Microsoft astroturfing weenies who have recently descended like a plague onto slashdot who are posting these uninformed technology strokefests. But I know better, because I have heard all the same bullshit from ga-ga geeks in the 90s, who never even THOUGHT about what the end users want and could only see so far as the pen protectors they were balancing on the ends of their noses.

AJAX - what a joke.

Re:This is laughable

[Some Random Username]

Funny, I've never had to do anything based on what's cool at the time. In fact, I've heard statements like "I don't care what you use, you are the tech guy, you make the tech decisions. That's what we pay you for". I also migrated a couple hundred machines away from cool and trendy linux onto reliable and secure openbsd.

Maybe if you are desperate for a job, any job, than you will end up with a crappy job. That doesn't make it the "real world", its just settling for crap. Or do people eating at McDonald's prove that that's the "real world" and people who want to eat a nice steak are living in a fantasy world and will never be able to have that steak?

Re:This is laughable

[hammeredpeon]

when you get out of the education market and into the rest of the world, where people want a quick response with the ease-of-deployment that comes with a web application, come back and tell us "ajax is stupid."

Re:This is laughable

[LukeWebber]

AJAX is stupid. Javascript is a crap language with none of the advantages offered by modern languages like Java and C++. 99% of all AJAX apps are certain to be an unmaintanable mess.

Re:This is laughable

[Anonymous Coward]

We need to write out business apps in Javascript now because this is the only standard browser vendors can agree on?

No, you offer a rich, browser-based user interface for your application. You write your application in a real language, and it runs on a server. If you'd like, you can also provide a non-browser-based user interface. If you can't offer multiple user interfaces without altering the application, then your application design is fatally flawed.

Re:This is laughable

[Tarwn]

Hmm, I think I fit your description above and while I don't believe AJAX is stupid, I don't believe I will be using it in the workplace.

Background: I worked solely on grant projects in university settings in 2000-2002. The past few years I have worked entirely in corporate and manufacturing settings on both contract and permenent status.

I understand the business need for having easily deployable, easily updateable applications. But I also understand the relatively ignored (in my experience) need for the company to have an application that will not need continuous maintenance at the pace that I foresee AJAX needing.

AJAX is based upon a single central idea, using Javascript requests to pull data down to the client and manipulate elements on the page. Since we are dealing with Javascript we also have to deal with the the fact that differant browsers have differant implementations of both the language and the DOM for the pages they are rendering. So hacks are introduced to make the AJAX application play well across multiple browsers.

Thats the first problem. We are designing a technology that is based solely on a second, often problematic, technology that continues to mutate and change with each new version of browser that hits the market. Hoping that an application written today, for todays Javascript definitions, with todays understanding of browser interaction, will still work exactly the same after a few more years of growth, bug fixes, patches, and version changes is similar to the hopes held by the developers who wrote many of the business applications I am currently forced to rewrite for newer OS's and patches on older dependancies.

Yes, I like writing web applications, in many circumstances due to the advantages inherent in having a single centralized copy of the application, but I am not willing to take that concept to the extreme of depending on a package of browser hacks. Just as a chain is as weak as it's weakest link, so is AJAX only as strong as the series of hacks that it is composed of.

In a business environment I cannot allow my applications to fail on a timeline measured, not in days, but in hours. No matter how quickly a group of developers responds to a patch that renders portions of AJAX unuseable, I will still have downtime in a web application, whose very existence was sold to management on the precepts of easy maintainability and client-software independance.

And then there is one point that most people miss when talking about server-side (vs client-side) web applications. Greater control of the code environment. With AJAX a great deal of code is executing on the clients machine, dependant on browser settings they may have messed up, anti-spyware applications that might be trying to interupt things, nifty toys they have installed on their desktop that are trying to gain access to their browser and credit-card info, etc. With a server-side application you have total control over the environment that your business logic is running on, total control over the application that is generating your content, etc.

I have been writing dynamic web content and applicaitons for a while now. I think AJAX is pretty nifty, and I might play with it a bit, but I would never bring it into a company atmosphere where business decisions could possibly be based upon it. I would return to thick clients before I deployed an application built on this technology.

Ultimately the use or non-use of this type of package is going to rest on the current development staff of each company. And I can only hope that my next position isn't with a company that chose nifty over maintainability and future-use, because I get a little tired of reverse engineering the last generation of failing apps at each job I take, and I don't see AJAX having the capability to last.

Re:This is laughable

[cranos]

I said many not all, you sound like you have the ideal job, however there are many many others who are stuck with PHBs who will change specs on a whim depending on what the "cool" technology of the day is.

The jobs where the Tech Guy is able to fully govern a project without outside interference are few and far between.

Re:This is laughable

[Some Random Username]

It didn't start out that way though. I simply proved myself, explained the situation, and was given control. There's no reason to accept a job where your boss fucks everything up all the time.

Jerking around tech guys wastes money. Explain to him how he's wasting money, and if he doesn't listen then look for a better job. Not every PHB is stubborn and stupid, lots of them listen when the complaint is "you are flushing money down the toilet" instead of "I don't like that".

Ajax compared to Flash

[ObligatoryUserName]

Now I'm not saying that these are mutually exclusive technologies (Macromedia itself has put out some examples of them working together), but as someone who started out writing a lot of Javascript and moved over to Flash in part to escape browser incompatibilites, what is the technical advantage of Ajax as compared to Flash.

As far as I can tell, Flash is more accessible (they've built in hooks for this), and Flash uses less bandwidth. (It comiplies to a binary format.) There's an open source compiler (MotionTwin). Flash also seems to provide a better user experience. (Compare Google Earth to Flash Earth.)

I know everyone here doesn't like Flash because it's used for advertising, but people here talk a lot about how wrong it is to attack a technology because of how some people choose to use it.

So, seriously, I've been thinking about looking into Ajax some more, but right now I don't have a good reason to. Convince this Flash programmer that Ajax is a better solution.

Re:Ajax compared to Flash

[maelstrom]

AJAX doesn't require the user to download a plugin as long as they are using a modern browser. Also, AJAX is not beholden to a single company who doesn't release their player in an open source format. I know I'm the weird exception, but I was running LinuxPPC and no flash client was available to me. If there would have been a full open source client, I could have compiled it myself. Firefox worked fine on that platform and hence, so did AJAX.

Re:Ajax compared to Flash

[ObligatoryUserName]

In Internet Explorer the XMLHttpRequest object comes from an Active X object, which is what Flash is in IE, an Active X object.

As far as an open source Flash Player the Free Software Foundation is now supporting GPLFlash, an open source Flash Player. ( http://gplflash.sourceforge.net/ ) A version of this project that plays older Flash files has been around since 2000.

Re:Ajax compared to Flash

[Osty]

Compare Google Earth to Flash Earth.

Two points:

1. I assume you meant Google Maps, not Google Earth. Google Maps is the AJAX (ugh, I hate that name) app. Google Earth is a rich desktop app.
2. Flash earth is cool, but it doesn't seem to provide anything more useful than Virtual Earth does. Certainly not in terms of UI. Sure, it may zoom in a little quicker but it's still dependent on how long it takes to load new images for closer zooms. Other than that, it's a click-and-drag, scroll-to-zoom interface just like VE's (and just like Google Maps with the proper set of Greaasemonkey scripts). In fact, it's even less useful than Google Maps or Virtual Earth because you can't search for sites, you can't add pushpins, you can't get directions, etc. It's a nifty UI, but I see no reason why you'd need Flash for this.

Re:Ajax compared to Flash

[temi]

Here it is, and while it is the ONLY difference it is a HUGE difference and one that is big enough to make vendors know to switch to AJAX.

AJAX will work with nearly any major browser off the shelf. poof. No downloading plug-ins once or twice based on how many browsers you are using, no nothing. Just come to the site and begin using the application.

With FLASH, you must download a plug-in. That may not sound like a lot but it is huge. It is at least one barrier for customers (who are by and large tech-retarded) to overcome just to use a vendor's service. And if there are multiple browsers there will be multiple plug-in downloads and there are times when the plug-ins wont work.

So bottom line is, by taking out the need for customers to visit a 3rd party, the User experience is exponentially increased and brand brainwashing commences immediately and without any hiccups. Believe me, no one wants to ever expose 3rd party tools when they are trying to sell something.

Re:Ajax compared to Flash

[ObligatoryUserName]

Yes, you're right, I did intend to say Google Maps.

I don't know why there's no search on Flash Earth, but the cool thing about it (besides overlaying both Google Maps and Virtual Earth), is the seemless transitions. Isn't one of the big bonuses to Ajax the end of the page-flicker? Yes, it's just scaling up the bitmaps and then replacing them with the other images when they load, but it seems less likely that you'll lose your place, as you can do with Google Maps.

Don't get me wrong, Ajax apps are cool, I just don't know when and why you'd want to use those techniques instead of Flash.

Re:Ajax compared to Flash

[ObligatoryUserName]

Flash comes with most browsers [not with Firefox, though I don't know why it always came with Netscape and I think it came with Mozilla before Firefox --- you might disagree, but I'm going to assume that if you're savy enough to install a new browser you can also install Flash].

Also, with Flash 8 (ok, new technology granted) there is a method to update the player without having to go to another website.

Re:Ajax compared to Flash

[maelstrom]

I don't use or plan to use IE. Flash has its place, but it isn't a web standard either. XMLHttpRequest is still supported out of the box in more places.

Re:Ajax compared to Flash

[Anonymous Coward]

Mac OS X has Flash and Shockwave installed _with_ the OS, so an end user does not have to install either plug-in manually. Mac OS X also has _one_ path where all plug-ins are installed, so _every_ browser on the system is able to access those plug-ins. If a plug-in is updated, _all_ browsers access the update.

What OS are you using that has such a problem with plug-ins, and the publisher can't/won't negotiate with Macromedia to make sure the plug-ins are preinstalled for their users?

Wait, let me guess, is it Windows from Microsoft?

Re:Ajax compared to Flash

[ddefenba]

Outside of the download the plugin issue (which isn't that large of an issue anymore) Flash movies must always run at a fixed size. The fluid nature of HTML is a huge bonus when it comes to creating RIAs--something that takes a long time to compensate for when developing Flash RIAs.

Re:Ajax compared to Flash

[rndmcnlly]

"Just come to the site and begin using the application."

That was the idea behind a techdemo/test game that a friend of mine and I made. AjaxWar, inspired by Wil Wright's SimWar, uses only javascipt on the client side to produce an N-players in N-games, bandwidth concious, non-polling, visually interesting (although most effects were disabled for the demo), robust, realtime strategy game. In the demo, the two browser windows are shown side by side but could have been behind NAT, firewall, proxies, etc on completely different networks than the server and each other. Oh, sorry, I know the demo requires flash (the real game required some modifications to php on the server side that we didn't want to make on a public web server).

Now, enough showing off. The thing we realized by the time we stopped working on the game is that doing things like making pretty multiplayer games with complex IO patterns is something thats really a lot easier, and more predictable using something like Flash or Java. It kinda felt like we were programming in a hostile atmosphere where you can't breathe without a helmet -- I mean can't get data pushed from the server unless you had a multipart encoded stream hanging in the ready. The latency was not bad at all, and neither was throughput of large chunks of data, however we reached a bottleneck when experimenting with several small updates in a short amount of time -- we couldn't reset our transfer mechanism fast enough to make something like an FPS viable at all. A majority of our time was spent expermenting with methods of moving data from the client to the server, politely, asynchronously, quickly, the actual gameplay was mostly an afterthought. While there aren't many web applications that demand the kind of IO we wanted, the pipe to the server is going to be a limiting factor for Ajax-ONLY type applications. Sure, you can use sockets in javascript if you require a certain browser and make the user click ok to a dialog, but if you have them doing that, you might as well have them install Flash. This issue of plumbing needs to be resolved before smart-client apps become ubiquitous.

Re:Ajax compared to Flash

[temi]

the first utterance of your post illustrates the point i am stressing here: "well my Mac OS X does..."

FORGET that whole idea of thinking and hoping that each tech-geeks favorite OS does things this way or that way and negotiate with 3rd parties to make things harmonious. Just let entities code in something that they know will work for all the browsers they care about (the majority) and be happy.

Your point about M$ not being able or willing to negotiate with Macromedia to have plug-ins pre-installed is also the whole point. Who cares if two companies cant agree on some deal so that millions of dollars transfers between hands that arent my own? I dont and neither do most users, they just want their shit to work. So basically, yes the Utopia of having harmony between corporations isnt here (and it never will be) so given that, deal with it, and the solution to dealing with it is....TADA, AJAX!

Re:Ajax compared to Flash

[Anonymous Coward]

What OS are you using that has such a problem with plug-ins, and the publisher can't/won't negotiate with Macromedia to make sure the plug-ins are preinstalled for their users?

Linux AMD64.

Re:Ajax compared to Flash

[lukelele]

ajax vs. flash .. to me ajax (ugh! i hate people who complain about that name!) wins. some points:

- firstly, and this is very important, if a page is made entirely in flash then a search engine can't glean text from it when it comes to crawl it if all your content is compiled into a swf. true, flash will publish your text as html comments, but this is a fairly lame work-around as keywords in comments don't rank particularly highly in google's algorithms. at least with a site that uses ajax, its first state will be accessable to text crawlers.

- secondly, jpg images look crusty in flash. even with jpg quality settings set high you still get a worse looking bitmap image than if you placed the image in html. so, flash, good for vectors, crap for bitmaps.

- the quality of text rendered in a swf is fairly terrible when it's small (i.e., your normal 10-12pt 'screen' height). unless you set the text properties to be 'dynamic', which limits how you can use it.

- text is unselectable (again, unless it has been set to 'dynamic' which it rarely is) so if people want to copy and paste something from your site then tough luck to them.

i use flash all the time, but not to build whole sites with. it's perfect for small embedded sections. but what ajax ultimately has over flash is that it uses native internet technolgies, and so many things from spiders to users rely on the web being the web.

Re:Ajax compared to Flash

[Anonymous Coward]

Dude, forget about Linux AMD64. Even Windows AMD64 is currently lacking a Flash plugin, because Macromedia the company is too high-strung to bother with such fringe platforms as x86-64.

This sort of petty and miserly platform support is EXACTLY why many web developers are hoping that AJAX beats the overly restrictive and control-minded Flash platform to death.

Re:Ajax compared to Flash

[jalefkowit]

AJAX will work with nearly any major browser off the shelf. poof.

Bzzt. Wrong.

"AJAX" will work with Internet Explorer, Gecko-based browsers, and Apple's Safari, and nothing else, because these are the only browsers to have included implementations of the XMLHTTPRequest object yet.

Oh, your client uses Konqueror? Or a cell phone? Or may ever use a user-agent other than the big three? Now you have to program a second, stripped down, clunky version just for that contingency. Try using the most widely deployed enterprise "AJAX" app out there -- Microsoft's Outlook Web Access -- in IE and then Firefox and you'll see what I mean.

Why does OWE degrade in Firefox? Doesn't "AJAX" work "off the shelf" in all major browsers? Well, the problem is that each of these browsers has their own incompatible implementation of XMLHTTPRequest. So you have to sniff out which browser the client is using and do your "AJAX" according to what it's expecting. (This is because of XMLHTTPRequest's origins as a proprietary IE extension to the browser API.)

Microsoft, naturally, only supports the IE flavor of "AJAX" in OWE. But you're not Microsoft and you probably don't get to dictate browsers like that, so you'll have to code around and cover all of them. If you're using an "AJAX toolkit", you're not seeing all this cruft because it's being hidden under a layer of abstraction; but that doesn't mean it's not there.

Because there is no standardized, according-to-Hoyle way to implement "AJAX", when you use it you do so at the risk of sacrificing something important -- forward compatibility. For some applications that's not a concern, but you might want to think about whether that's true for your app before you run and rewrite the whole thing in "AJAX" just because that's teh new hotness.

(Oh, and have you given thought to what happens when visually-impaired people use your kewl "AJAX" app?)

Re:Ajax compared to Flash

[ObligatoryUserName]

Flash movies must always run at a fixed size.

That's not accurate, Flash movies can run at a percentage size. In fact, Actionscript.com just recently put out a series of articles about full browser flash, though it's a capability that Flash has had for as long as I can remember.

Re:Ajax compared to Flash

[ObligatoryUserName]

- firstly, and this is very important, if a page is made entirely in flash then a search engine can't glean text from it when it comes to crawl it if all your content is compiled into a swf.

The search engine SDK (for people who make search engines) has been freely available since 2002. At the very least we know that Google does read the text in Flash files. (I honestly haven't kept track of other search engines - does anyone know?)

secondly, jpg images look crusty in flash.

In the past there were some bitmap display bugs in Flash. Tinic Uro, a Principle Engineer on the Flash Player, has a good blog post about the bugs they fixed in the latest release. I honestly don't personally know of any outstanding issues with bitmap display. Did you see any problems with the bitmaps in the Flash Earth page I linked to?

the quality of text rendered in a swf is fairly terrible when it's small

You have a point about older versions of Flash. You did have to take care with font selection and placement to get good quality at small font sizes. This is another problem that has greatly improved in the latest release. Flash 8 has a new font rendering system, "FlashType" (huzzah for the creative marketing team). The long and short is that it renders small type very well now. I've seen examples of the new type that I mistook for browser text before they were pointed out to be Flash.

text is unselectable

The selectability of type is a decision made at authoring time. It makes sense to have text selectable sometimes (eg body text), but not others (eg text on buttons).

Re:Ajax compared to Flash

[ObligatoryUserName]

Your point about M$ not being able or willing to negotiate with Macromedia to have plug-ins pre-installed...

You're misreading the post. Flash has come bundled with Windows and Internet Explorer for as long as I can remember.

Re:Ajax compared to Flash

[ObligatoryUserName]

That sucks that you have to run a separate browser for Flash. There is the Open Source player, but I don't know if anyone's compiled it for 64-bit CPUus or not.

At the same time, I'm not sure that Ajax has the lead on Flash for supported platforms. Flash, for example, works just fine in old browsers. If someone has Netscape 4 (some companies still have policies to support Netscape 4) can they view an Ajax site?

Based on jalefkowit's post in this thread, I'm getting a strong sense of deja-vu from this whole Ajax business - it reminds me of the beginnings of the browser incompatibility wars.

Re:Ajax compared to Flash

[Krach42]

Yeah, I don't know if he gets that there are ways to do things on the web that don't rely on Internet Explorer using an ActiveX control.

Re:Ajax compared to Flash

[pilkul]

Honestly, I've never programmed in Flash myself so I don't really know its merits as a platform. But one thing I can say is that every Flash application I've ever seen is crap, with the exception of web games. In every single non-game case where I've used Flash on a website, it could've been done better using HTML.

Could you point me to a non-game Flash application which could reasonably be described as "not crap"? If you do, then I'll reconsider my hate of Flash.

Re:Ajax compared to Flash

[ddefenba]

I was generalizing, but the content within a scaled 100% width movie is still fixed. If the 100% movie is in a browser window 800px tall, and the content within is 1200px tall, you won't see 400px of it and the browser won't show scrollbars unless you put your whole movie into a Flash scrollpane or custom create some equivalent. Either way, the point is that its a lot more work to do in Flash some things you get for free in the browser.

Re:Ajax compared to Flash

[slapout]

Probably because good Flash tools cost a lot of money.

Re:Ajax compared to Flash

[ObligatoryUserName]

I've always thought Breeze was pretty impressive. It's a collaboration suite for meetings, events, and presentations. The part of it that's easist to demonstrate is the presentation part, since Macromedia often uses Breeze presentations in their marketing - here's a Breeze presentation about Macromedia Flex. It's like a virtual PowerPoint presentation, but I think it's much more pleasant to watch a Breeze presentation than to click through someone's slides on the web.

LivePlasma, is certainly something that I wouldn't know how to implement in plain HTML.

http://www.slideroll.com/>Slideroll creates online slideshows.

The whole, zoom in and out on pictures thing used to be a good example, but Google Maps and Virtual Earth both know that trick.

I guess most of these examples are data visualization/presentation software, but then that's what most of the web is, isn't it? I personally prefer Flash as a video player, but that's not necessarily what we're talking about here.

I guess my question is, is there something inherient in Flash that you think makes it crappy?

  As you've said, web games, which are the most client-side intensive content on the web use Flash very well, is there some inherient reason you think these capabilites couldn't be employed for serious purposes?

Re:Ajax compared to Flash

[ObligatoryUserName]

I've programmed strictly server (no Javascript) applications, Javascript + server applications, and Flash + server applications. In my experience Flash is the easiest to develop, and has the highest user satisfaction. That's why I'm curious why there's so much excitement over Ajax when it seems so sub-optimal to me.

maelstrom was saying that Flash is bad because it worked as a zero-install environment for fewer clients than Ajax (using himself as an example with LinuxPPC). In my comment I was pointing out that for the majority environment, Windows with Internet Explorer, Flash and Ajax have the same status, they both require ActiveX controls.

Also, and I haven't researched this much, but posts in this topic lead me to believe that Ajax isn't well standardized ( XmlHttpRequest object differences ), and isn't as universally supported as I thought it was. I think the perception of wide-support might be artifically inflated because it works in "the browser I use now", without reguard to the population of clients that actually use the Internet.

One point you make is that you don't like having to trust Macromedia/Adobe for your operating environment. From my perspective it appears that Ajax has the opposite problem and it's much worse - not that you have to trust one company, but that you have to trust all of them (and one of them is Microsoft.) When one of them starts messing up their implementation everyone suffers.

Re:Ajax compared to Flash

[Anonymous Coward]

Macromedia has another product called Flex that's even more akin to AJAX than regular flash is. I think it generates Flash content, but app programming is done in a markup/scripting manner with server-side foo to transform it to send to the user.

Re:Ajax compared to Flash

[Mad Merlin]

"AJAX" will work with Internet Explorer, Gecko-based browsers, and Apple's Safari, and nothing else, because these are the only browsers to have included implementations of the XMLHTTPRequest object yet.

Quite untrue. Konqueror supports AJAX, I'm posting from it right now, and my Online RPG uses it in a few places. Opera also supports AJAX. That leaves us with what... text based or PDA browsers? Most of those don't even support Javascript, good luck getting Flash or something else similar working on it. You never did mention what you would prefer over AJAX, what would you prefer over AJAX anyways? I presume that whatever you would prefer would magically work on cell phones, PDAs and text based browsers too, as you seem to think that that's a major issue for AJAX.

Why does OWE degrade in Firefox? Doesn't "AJAX" work "off the shelf" in all major browsers? Well, the problem is that each of these browsers has their own incompatible implementation of XMLHTTPRequest.

If they have, I haven't encountered it. Besides IE doing it's own thing like usual, every other browser has the same implementation. Unusually enough, in this case, working around IE is pretty simple.

Now you have to program a second, stripped down, clunky version just for that contingency.

That can be said about the majority of web technologies, if you want to support IE, you get to jump through lots of hoops. If you don't care about IE, you can write standards compliant code and expect it to work and look the same in Konqueror, Firefox, Opera, Safari, etc. As always with web development, IE is the problem, working around it is where you will spend/waste the most time.

Having said all of that, like any other technology, you should use AJAX to enhance the experience, not have everything depend on it. Your web site/application/whatever should still be accessable without all of the handy dandy technology, regardless of what it is. That's much harder if you've used Flash or anything else that depends on a plugin for everything, because it means you need to totally rewrite code.

Re:Ajax compared to Flash

[SillyNickName4me]

In my experience Flash is the easiest to develop, and has the highest user satisfaction. That's why I'm curious why there's so much excitement over Ajax when it seems so sub-optimal to me.

Since flash is easy to develop for, it is a lot easier for a mediacore developer to make an application that is satisfying to the end-userm (not trying to imply that you are a mediacore developer here btw). This obviously results in better user satisfaction... for those users that can use your application that is.

AJAX (I hate that name) promisses to provide almost the same ease of development over time, without limiting yourself to those who actually installed the plugin required for using flash applications.

You may believe that that only concerns a very tiny fraction of the market when you assume that it only concerns those for which there is no flash plgin available (Linux on PPC was given as an example by another poster, there are many more such examples).

You should realize that in quite a few corporate environments users cannot )and are not allowed to) install a plugin, and many such environments regard flash as a potential security risk. As a consequence, there is a substantial part of the market that cannot use Flash based apps.

Then, AJAX is extendible without depending on a single vendor to hear and forfill your desired extentions, or put differently, you do not depend on the whims of a single provider.

So, Flash is only a better solution when:
1. You can guarantee that your clients have installed or can install the required plugin and
2. You don't and will never need things that Flash currently cant do.

In other words, FLash is a short-term solution with a limited scope and limited support, AJAX is an extendible technology with a broad scope and multiple vendors supporting it.

Yeah, it takes a bit more efford, but that is payed for by the solution lasting longer.

Re:Ajax compared to Flash

[SillyNickName4me]

I dont think IE comes with Flash really.

Re:Ajax compared to Flash

[SillyNickName4me]

It comes with Windows, not with IE.

(and yeah, I know about IE supposedly being an integral part of the OS)

Re:Ajax compared to Flash

[NutscrapeSucks]

What OS are you using that has such a problem with plug-ins,

MacOS X.

Neither Safari nor IE support the "LiveConnect" API, which allows for plugins and webpages to communicate with each other. Normally one can do "AJAX" style applications using Flash instead of XmlHttpRequest ... except on Macs. (Which is currently a big problem for me.)

Re:Ajax compared to Flash

[pilkul]

Thanks for the examples. But having looked at them I still fail to be convinced that Flash has serious uses.

Breeze looked classy at first glance. But if I think of what I would want to do if I was a student with a lecture to study in this format, I would definitely want to save it on my hard drive for future viewing. (What if the server went down right before the exam, etc.) But I see no easy way to save. It looks like I have to do View Source and use wget, possibly jumping through additional hoops like opening the swf file in a hex editor to discover the real location of the video files. I've been forced to do such things before and it makes me loathe tightly controlled environments like Flash.

The first thing I noticed when I went to the Liveplasma main page is that my mouse cursor appeared as a hand icon anywhere on the page, even if there were no buttons to click. I was confused for several seconds; I thought there was other stuff on the right side of the screen that hadn't yet loaded, or perhaps the page wasn't appearing properly in Firefox (I opened it in IE, but it was the same). Then I realized the whole page was a big Flash presentation despite the CSS-like appearance. So liveplasma is gratuitously not following UI conventions; not a good first impression.

Then, doing a search and seeing what liveplasma actually does, I see a bizarre map display. Even assuming that this kind of display has any advantage over a plain old list, there's too much useless movement; the entries on the map should just instantly pop up instead of wasting my time. This would be better and could be done in HTML/Javascript.

Zoom-in/out as you said yourself doesn't need Flash. Finally, my operating system comes with a video player and there's no advantage to using Flash as a video player as opposed to providing links to the streams. Savability is a big factor here again, as well as full-screen capability.

As you've said, web games, which are the most client-side intensive content on the web use Flash very well, is there some inherient reason you think these capabilites couldn't be employed for serious purposes?

Basically the reason is interoperability. As you can see from the above, I want to cut-and-paste, to save things separately, to be able to control the data using my own set of tools instead of being limited to whatever the Flash designer decided was fit. This problem doesn't really come up with games, that's why Flash is good for them. Perhaps it doesn't come up in corporate environments either --- but then it's hard to see a corporate situation requiring flashy videoish displays.

Re:Ajax compared to Flash

[ObligatoryUserName]

You might be right - it used to come with the browser downloads, but I couldn't confirm that as the case anymore - though it does still come bundled when you install Windows.

http://www.microsoft.com/presspass/press/2001/sep0 1/09-11xpmacromediapr.mspx

Re:Ajax compared to Flash

[ObligatoryUserName]

The Flash/Javascript Integration Kit (originally developed by Macromedia with an open license, now hosted on Open Source Flash) works with these Mac browsers ( Macintosh Opera 8.0, Macintosh Firefox 1.0, Safari 1.2.4 and 2.0 ) - if you're having problems with Flash and browser communication check it out. There are supposed to be better methods in the next version of Flash (which is out in a few weeks), but this works now.

Re:Ajax compared to Flash

[ObligatoryUserName]

That can be said about the majority of web technologies, if you want to support IE, you get to jump through lots of hoops.

Honestly, that's why I moved to Flash. It just works on all the browsers, and I never have to retrofit changes to keep up compatibility.

web site/application/whatever should still be accessable without all of the handy dandy technology, regardless of what it is.

I've heard this so many times it's really starting to lose meaning to me. Way back when I had to write a web app that didn't use Forms because not all browsers supported them. If this line of reasoning is taken to its logical extreme we should just all write text files instead of HTML, and people can telnet into port 80 to read the files, because you know, I wouldn't doubt that more computers have telnet than have a web browser.

Yes, you're drawing a line and saying that people without a certain set of specs or a certain program installed won't be able to see what you're doing, but you are doing that already. Not everyone has to settle on the same lowest common denominator. It's always a question of how low you want to go.

Re:Ajax compared to Flash

[ObligatoryUserName]

Since flash is easy to develop for, it is a lot easier for a mediacore developer to make an application that is satisfying to the end-userm (not trying to imply that you are a mediacore developer here btw). This obviously results in better user satisfaction... for those users that can use your application that is.

You know, this is the exact same argument that was originally made against developing apps on the web. Hey, look at Mirskey's Worst of the Web - HTML sucks, not everyone has an Internet connection you're leaving people out. It's the same argument, different tune.

You should realize that in quite a few corporate environments users cannot )and are not allowed to) install a plugin, and many such environments regard flash as a potential security risk. As a consequence, there is a substantial part of the market that cannot use Flash based apps.

As a Flash developer, I've heard this before, and it's never proven to be true. A few years back there was a study of Internet client capabilities and by a very small percent more clients were supporting Flash than were supporting Javascript. Should I have read that and sworn off Javascript?

that is payed for by the solution lasting longer.

I've heard that claim about Ajax, but I've lived it with Flash. Over the past 6 years I've never had a compatibility problems with Flash. I sure can't say that about my experience with HTML or Javascript.

Re:Ajax compared to Flash

[lukelele]

that's good news that a lot of those quality problems look to be fixed with flash 8. i'll have to find a trial version to try out.

and searching around i find you're right about google's ability to read text from swf files, though that doesn't explain one very recent problem that i encountered with flash and google indexing. a friend's site had a flash image with a link to the next page done in html frames. google indexed the first page of her website but didn't index anything else, obviously unable to crawl the link. i suggested she put a 1 x 1 pixel transparent gif with an html link to the frames page and within 2 days google had crawled the rest of her site.

Re:Ajax compared to Flash

[Mad Merlin]

Honestly, that's why I moved to Flash. It just works on all the browsers, and I never have to retrofit changes to keep up compatibility.

If they have the Flash plugin installed that is. I don't have any numbers, but I'd wager that the number of people with Flash (perhaps 30%?) is much much smaller than the number of people with an AJAXable browser (about 98%?). People are lazy, they don't want to go install a plugin to view your site. Why do you think IE still has so many users? How many corporate desktops do you think have Flash installed by default? If you ask me, Flash is a terrible way to try and reach a large audience.

Re:Ajax compared to Flash

[ObligatoryUserName]

I'd wager that the number of people with Flash (perhaps 30%?)

That's not an accurate assessment. According to an NPD Online - Worldwide Survey 97.6% of Internet enabled PCs support Flash 5. Like I said in another post, I've had people tell me - "people won't be able to see it, it's in Flash, not eveyone has Flash" and then never had a single problem or complaint. You may doubt the numbers, but Amazon.com has used Flash on their homepage, if it wasn't widely installed to you really think they'd have done that to their users?

I think there are a couple of reasons for the misperception about Flash install numbers but the biggest one is that, it's come bundled with the browsers forever. When everyone was using Netscape and IE wasn't a big player both browsers came with Flash already installed. Microsoft and Apple OSes have come with Flash pre-installed for 5 or 6 years. People used to notice when they had to go and update their player, but they've added auto-update functionality, and now most users never have a reason to ask themselves "do I have Flash installed?"

Re:Ajax compared to Flash

[NutscrapeSucks]

Thanks for the link ... we're using a simplier version of this hack (essentially an extra SWF loaded for each call) we found on a blog. I would still prefer that Apple support LiveConnect.

Re:Ajax compared to Flash

[ObligatoryUserName]

An invisible gif with alt-text is also a good trick if you need to provide a separate site for screen readers. (Not a trick I've used with Flash, but long ago when supplemental text-only versions of sites were more common.)

I don't pretend to understand Google and I don't know if being all Flash effects pagerank or anything like that, but Flash 8 is adding a set of embedded meta-data values to help search engines. I don't know the implementation so it might just get ignored like html metadata has been, but it's good to know Macromedia is trying to address concerns.

Flash 8 is coming out early next month, I beleive, so look for a free 30-day trial then. The nice thing about Macromedia trial versions is that they are fully functional for 30 dayas. Back when Flash 5 was new, I got a freelance job that wanted to use it right away (it was for "cutting edge" marketing so they didn't mind using a plug-in that had just come out) - So, being poor at the time, I downloaded the free trial which was released the same day as the full version. By the end of my 30-day trial I had made many times the cost of the full version of Flash using the Trial, and was easily able to buy a full version with my profits. --- If I have a pro-Flash bias, that experience might explain it. :)

Re:Ajax compared to Flash

[lukelele]

that experience might explain it

hehe. perhaps having never made a bean out of flash having used it since v4 myself contributes to my cynicality, in that case ;).

like i said, good to hear these concerns are being addressed, but boo to the fact it's taken this long to address some of the outstanding issues.

Re:Ajax compared to Flash

[ObligatoryUserName]

The thing with all these examples is, we're having a discussion about the merits of a technology based on examples of that technology. It would have been similar to arguing that we shouldn't develop nuclear power when all we had seen was the atom bomb. In the web world, it would be similar to visiting Mirsky's Worst of the Web back in 1995 and declaring, "nothing good can come of this!" If you really don't like these sites, that doesn't explain to me why you don't think you could build something better with the same technology.

Nonetheless, I'm going to follow on this discussion track a little more. I did have a hard time finding good/interesting Flash applications. The one that I honestly think is the best example, Flash Earth, is a remix of two Ajax applications. At the same time, we really are just beginning the transition to the application heavy web, and I wouldn't be surprised to see many more good applications spring up in the next 6 months.

Reguarding Saving - that's something that's up to the developer, though like all files you can dredge them out of the cache if you need to. Some developers like to share, going so far as to put View Source items in their right click menus to allow you to download the code. There's nothing about Flash that prevents people from letting you download elements. Personally, if people don't want to let you do that, I wouldn't hold that against the technology they're using. To give a non-Flash example example, a lot of Quicktime movie trailers don't provide download links anymore. I often do a view source, find the file reference, create a link in a new HTML file, right-click Save As, and download the movie. For some QuickTime movies that doesn't work, they've used Quicktime to create a shell for streaming the movie off the Internet. When I encounter either of these situations I don't think "Quicktime sucks", I think, "the developer was foolish for not letting me download advertising".

As far as interoperability goes, and from a hacker mentality, I really see you point. When I switch hats to a content developer/service provider mentality, I disagree that Flash is at a disadvantage to Ajax on this front. Let me put it this way, there's a big difference between providing public API's for your application, and having Greasemonkey fiddle with its bits.

Pretend I'm Google, and I've put out Gmail. Now along comes someone with a Greasemonkey mod that turns Gmail into a Peer-to-Peer network. (I'm talking hypothetical here -- I think.) Ok, now there's two things to consider: First, I might not want this hack that people have added on top of my site. It might get me in big legal trouble, and I might not even like Peer-to-Peer networks. Is there any way for me to stop this without legal action or without playing an escalating arms race of code changes with the modders? Secondly, what if I really like the mod, what if more people are using my site for the mod than for the original functionality and I don't want to break it. Am I stuck in development limbo? One of the big advantages of web applications is the Zero-install environment. If I fix a bug in a web application I don't have to push out changes to anyone, everyone who visits the site is using the newest version. What if fixing my bug means breaking eveyone else's hack? While the theoretical promise of the mod that's more popular than the original is alluring (see Half-Life and Counter Strike), this is really not a place I want to be as a web developer. I don't want to piss off my users just for maintaining my code. It's an entirely different thing if I've published an external API of course, that's not dependent on how I implemented my code - interoperable systems like Greasemonkey are.

I'll admit that in some ways the interoperability argument I just made is a bit silly, because there isn't anything inherient in Flash that prevents someone from creating "Greasemonkey for Flash". But that's the larger point. Down at the roots, Flash and Ajax applications are quite similar. They're both EMCAscripting they just have different object models and different run-time environments. From my perspective, the differences favor Flash.

Re:Ajax compared to Flash

[ObligatoryUserName]

the point is that its a lot more work to do in Flash some things you get for free in the browser

And vice-versa as rndmcnlly commented in his post. It sounds like you're familiar with Flash, and know that there are different ways to scale the elements, and to me that's an asset. (If you need to do something like you talked about it looks like there's some example code in the comments of the third full browser Flash article.)

I would pose to you, though, that for creating simple web applications you might want to use Flash's old default scaling behavior instead - which is to scale every element proportionally. After all, what application besides a document reader do you scroll? If Apple was right that bad usability arises when we hide elements in a right-click menu, what happens when you hide elements below the fold?

I used Flash's proportional scaling for one of the in-house applications I built and it worked great. The limited screen space made us carefully consider the design, and the users thought it worked well. I had one manager who was always having a hard time reading image-based websites because she had her resolution set very low, but when she brought up my proportionally scaling web application she had no problems at all. Things didn't look as pretty and smooth at low-res, but everything was in its palce, and everything worked.

That, btw, is what I consider Flash's ultimate future-proofing. If you use all vector assets in a proportiaonlly scaling Flash app, your application will work 30 years from now when we have 300dpi displays. There are a number of old content sites that I've noticed super-sizeing their content, because of how screen resolutions have changed over the past 5 years.

Also, there is a trick for using a browser's scroll bar with scaling Flash if you have one dimension fixed and the other one is scaled, but it's a little bit of a hack, and I'm not sure anyone's interested.

Re:Ajax compared to Flash

[Mad Merlin]

That's not an accurate assessment. According to an NPD Online - Worldwide Survey 97.6% of Internet enabled PCs support Flash 5.

Those numbers seem very high to me, I'd also consider where you're reading them (the Macromedia site...) for the obvious bias. Windows 98 had Flash as an optional install, it wasn't installed by default IIRC. Windows 2000 does not include Flash on the CD, or, if it does, it's not listed in "Add/Remove Windows Components" anymore, and is not installed by default. I have no idea about Windows XP or ME as I wouldn't touch them with a 10 foot clown pole, and I don't think Flash existed in time for Windows 95. It is very possible that XP does not include Flash by default however as I've seen many XP machines without it.

On top of that, even if they have Flash installed, a lot of people will disable Flash because it's so prevalent in (annoying) ads. You certainly won't find Flash on any of my computers.

Re:Ajax compared to Flash

[SillyNickName4me]

You know, this is the exact same argument that was originally made against developing apps on the web. Hey, look at Mirskey's Worst of the Web - HTML sucks, not everyone has an Internet connection you're leaving people out. It's the same argument, different tune.

In other words, you are saying that this is irrelevant, I agree.

I wonder why the ease of development and better user satisfaction was brought in in the grantparent post when you agree that it is at best of minor relevance.

As a Flash developer, I've heard this before, and it's never proven to be true. A few years back there was a study of Internet client capabilities and by a very small percent more clients were supporting Flash than were supporting Javascript. Should I have read that and sworn off Javascript?

That study is either 10 years old, complete bullshit or both.

Since NS 2.0 and some very early version OF IE, both supported (slightly incompatible of course) variations on javascript. This was in a time when few people had heard about flash at all.

Of the modern browsers that dont support javascript or a close variation, name me exactly one that does support flash.

I have 15 years of experience with supporting networks in large corporate environments, and was there before browsers existed at all. I have been involved in the building and testing of the first and second generation of 'public' webbrowsers, and from that I can say that the research you are pointing at (maybe provide a reference?) is simply bullshit now, and most likely has been for the last decade. Can I point at research to prove this? no, but simple logic will tell you this:
IE, Opera, all Mozilla variations and even some of the palmtop based browsers support javascript, and NONE, I repeat NONE of them natively support flash.

I have worked a lot with banks, financial institutions and such, and none of them allow installation of any software by endusers, and very few of them install flash.

I've heard that claim about Ajax, but I've lived it with Flash. Over the past 6 years I've never had a compatibility problems with Flash. I sure can't say that about my experience with HTML or Javascript

As long as your client has a flash plugin from Macromedia you do not have a compatibility problem. This is one of the reasons why it is easier to develop for Flash (see the first argument, which you yourself are arguing is irrelevant)

As long as you keep to standards, thereare very few compatibility problems with html and javascript, but they do exist of course.

Now, go try an alternative flash plugin (they do exist) and see how it goes there.

Bottomline, I can use html+javascript on any platform I use, from palmtop to modern PC to my smp sparc machine etc. I can use flash on exactly one of those hardware platforms, and only when running one of 2 specific operating systems.

If you want to develop for flash, be my guest, and I hope it does make yo a good living. There is nothing wrong with it as such, but if you believe it is the technically best solution then you really need a few hits with a cluestick. If you believe it is a longterm solution, well, then you depend on the future of Macromedia, if they go under your market is gone.

Re:Ajax compared to Flash

[SillyNickName4me]

It indeed does come with Windows, it is an optional component however and for all I can tell not installed by default, and you usually end up with an outdated version.

That said, one can indeed argue that IE and Flash are available in one bundle (called Windows)

That of course also points at why Flash might not have sucha bright future.. virtually anything that comes bundled with Windows becomes MS property over time, and if they have what they consider something better (more profittable) then that means it will go down the drain.

Re:Ajax compared to Flash

[cruciallimit]

Actually this can be accomplished very easy in flash by using a blank shell as the main movie that the html code references and set the size values to 100%, you then scale the shell movie to fit the content or loaded movies. This will in fact trigger a change in the browser scrollbar as needed... take a look at http://www.vehix.com...they/ do this very well.

Re:Ajax compared to Flash

[cruciallimit]

- firstly, and this is very important, if a page is made entirely in flash then a search engine can't glean text from it when it comes to crawl it if all your content is compiled into a swf. true, flash will publish your text as html comments, but this is a fairly lame work-around as keywords in comments don't rank particularly highly in google's algorithms. at least with a site that uses ajax, its first state will be accessable to text crawlers. Actually AJAX apps suffer from this same issue when most of the content is fed in dynamically to avoid page refresh issues. And I know the arguement is going to be that there is HTML content on the page initially and that part can be searched and indexed by search engine. This is actually possible with Flash as well by using Geoff Stearns Flash Object. This method will act as a detection script as well as provide static HTML content on the page for search engine. - secondly, jpg images look crusty in flash. even with jpg quality settings set high you still get a worse looking bitmap image than if you placed the image in html. so, flash, good for vectors, crap for bitmaps. In most cases this is an authoring issue and not a technology issue. There where a few bugs in some early players that caused a pixel shit, which was easy enough to work around. Flash can actually display the same image without noticable loss in quality yet at a much reduced size than a standard browser... I think thats a benefit to flash. - the quality of text rendered in a swf is fairly terrible when it's small (i.e., your normal 10-12pt 'screen' height). unless you set the text properties to be 'dynamic', which limits how you can use it. Somewhat true, yet again this can be looked at as an authoring issue. Theres has been some well documented ways to offer very crisp clean text in Flash that's easy enough to read just by making sure the text is on a pure pixel and not a half pixel. As a benefit however Flash offers support for any font you want, and therefore opens the doors wide open for fonts that may be easier to read, look better, etc... that standard HTML cannot offer. - text is unselectable (again, unless it has been set to 'dynamic' which it rarely is) so if people want to copy and paste something from your site then tough luck to them. As was mentioned this is an authoring issue, not a technology issue i use flash all the time, but not to build whole sites with. it's perfect for small embedded sections. but what ajax ultimately has over flash is that it uses native internet technolgies, and so many things from spiders to users rely on the web being the web. If people where just using AJAX to display data and refresh sections of the page for content I would agree that they are using native (but not standard) current (with no absolute garuntee of future support) internet technologies. However when developers start heading down the road of 'Flash like emulation' using javascript for animation, effects, etc... that arguement begins to loose water. Mnay techniques people are using to emulate Flash are makeing use of browser dependant support and requires the code to degrade for users of other browsers. This to my is bad as you punish users for not choosing your browser of choice (which is the same naive arguement people use against Flash by the way). People want to talk about not relying on a company for support... they do that already...they rely on Microsoft to display over 80% of their content. And Microsoft has a track record of making things 'different just to be different'....

Re:Ajax compared to Flash

[cruciallimit]

Those numbers seem very high to me, I'd also consider where you're reading them (the Macromedia site...) for the obvious bias

Man people like you crack me up...you could tell them the sky's blue and they'll argue that it's a colorful shade of gray. Like someone already posted to you, you really should do your homework before you start spouting things off. Flash traditionally has an 80% adoption rate in 12 months. That's higher than any browser and OS adoption. You want to say that people won't upgrade and people hate downloading a plug-in??? You show me the numbers where people have turned Flash off. You have that stat handy? Show me the numbers where people have uninstalled the plugin...any numbers for that?? Sorry but I can go off of the high tech "I've seen" stat your so quick to refernce.

take this quote from John Dowdell (and yes he is a Macromedia employee...stating FACTS)..

"According to AssetMatrix, Windows 2000 is the most-often used Windows version in medium- and large-sized corporations, edging out XP 48 percent to 37 percent. Put another way, roughly half of all Windows installs in corporations are Windows 2000." Operating systems require a big commitment to upgrade... as the OS was released four years ago, that's about 10% adoption per year, compared to 80% for a small browser plugin which doesn't change your daily environment.

Got any numbers showing that's false???

Re:Ajax compared to Flash

[ObligatoryUserName]

virtually anything that comes bundled with Windows becomes MS property over time

I'm not sure what you're referring to - most bundled Windows elements were created by Microsoft. The only shifts I remember were from one Microsoft product to another. Netscape wasn't bundled with computers by Microsoft, it was bundled in by OEMs.

Especially with more and more sites using Flash for video, I really don't see Microsoft refusing to bundle Flash. It would cause too much broken Internet functionality. Can you see reviews of Vista if they did so? "Windows Vista offers few improvements, breaks Homestarrunner" :)

I know some people will never be happy if something isn't a completely open specification open source endevor. I don't think that's realistic for one reason - too much openness is what killed off client side Java. Openness is what allowed Microsoft to embrace and extend it into oblivion.

I truely think Ajax is more vulnerable than Flash. The defining implementation of the cornerstone Ajax object was done by Microsoft; what makes you think they won't take advantage of that?

Re:Ajax compared to Flash

[ObligatoryUserName]

I couldn't help but notive that someone has just hacked the webpage for Geoff Stearns Flash Object. That seems to be the only page on the server effected. Was that done by someone here? Is someone here threatened by Flash? If so why?

Flash has an open specification and there are open source tools for creating it. Open Source isn't all about creating One True Implementation - attacking people supporting technologies you claim you don't even use doesn't make sense. Does it make you sad to think that other people might be happy? Chewbacca lives on Endor...

Re:Ajax compared to Flash

[SillyNickName4me]

I'm not sure what you're referring to - most bundled Windows elements were created by Microsoft. The only shifts I remember were from one Microsoft product to another. Netscape wasn't bundled with computers by Microsoft, it was bundled in by OEMs

You may not be aware of this, but many of the components of Windows are in fact not written by them at all.

In case of flash, MS is still trying to go for an alternative, and for video has had an alternative for like a decade. If they can push that and eliminate flash )and other alternatives, ie realplayer) they will do so.

Even most of Office does not originate at MS, was not written by them originally, but was bought and basicly changed into what we know as word and excel and such now.

They have a long history of trying to eliminate everything they do not control when they believe it is proffitable to do so, and I see no reason why that would not apply to flash.

Re:Ajax compared to Flash

[ObligatoryUserName]

In other words, you are saying that this is irrelevant, I agree.

I wonder why the ease of development and better user satisfaction was brought in in the grantparent post when you agree that it is at best of minor relevance.


Actually, I think I was ignoring what you had said and was making a separate argument against something you hadn't said. I've been replying to all the sub-threads and I may have gotten things a bit jumbled. Sorry about that.

I not sure that Flash is always easier to develop for that HTML/Javascript/Ajax (never having developed for Ajax myself). There are some things that are easier to do in both. I do agree that ease of development is a very minor consideration (except in extreme differences between technology), but user satisfaction isn't something I'd toss off. User satisfaction speaks to usability and effects the productivity of the people using the application. I have seen good improvements in productivity moving people from HTML/Javascript apps to Flash apps. I wouldn't discount that.

That study is either 10 years old, complete bullshit or both.

The study was one done a few years back and it was one of the Macromedia NPD studys. They don't seem to track Javascript anymore that I see so I don't know where it's at right now, but at the time when we were seeing those numbers my friends and I had a few hypothesises for why the numbers were that way. The big one was that the study was done at the time when pop-up windows were becoming a problem, but there weren't any pop-up blockers yet. (Or at least none that I knew of.) So, we theorized that hatred of pop-ups was driving people to disable Javascript. I know the community seemed to be moving in that direction at one point. Both Flash and Javacript had very high availability numbers (90-something percent), it's just that Flash edged out Javascript by 1 or 2 percent. I know it's surprising, but that doesn't imply that at one point in time it wasn't true.

I know you're going to say, "Macromedia paid for the study! Bias. Bias. Bias!", but I would make two points. One, Macromedia also sells the most popular Javascript authoring program, Dreamweaver. If you read their financial reports you know that they make more money on Dreamweaver. It goes against their interests to report low Javascript numbers. Secondly, historically, their studies have also tracked the adoption of their Shockwave plug-in. This used to be the most installed plug-in and they built a line of products around it, including servers for creating dynamic Shockwave content. Their studies have shown the gradual eroding of the Shockwave install base. I've used Director (the Macromedia tool that creates Shockwave content), and I have more than once wanted to use its plug-in on a project, but then I look a those numbers and recommend against it. Director is great if you don't need the plug-in (CD-ROM or DVD for example), but I don't think I'll ever recommend it for online use.

Of the modern browsers that dont support javascript or a close variation, name me exactly one that does support flash.

I don't know of any, but that a client has Javascipt built-in doesn't imply that everyone has it enabled. Some people have Flash installed, but run FlashBlock, don't they?

I know you want me to accept your credentials and experience to beleive that Flash isn't very widely installed in spite of the evidence I have otherwise, but I'm not going to.

Flash comes with Windows as a DLL, if you want to uninstall it there's a program you download from Macromedia to do so. I don't know of anyone who has done this in a corporate environment, but maybe you do.

I think you're trying to say (I have worked a lot with banks, financial institutions and such... very few of them install flash), "I have big clients and they won't use Flash." If you want to get into the "my potential clients are bigger than yours" argument, I'll just point out one clien

Re:Ajax compared to Flash

[SillyNickName4me]

Hmm.. replying to my own post.. anyway, I think it would have been better to say that whenever something is usefull for the Windows environment MS tries to either own it or eliminate it. Bundled software may not be the best example of this, but there it happened as well.

Re:Ajax compared to Flash

[ObligatoryUserName]

You may not be aware of this, but many of the components of Windows are in fact not written by them at all.

But branded as Microsoft right? Anyway, that's not really to the point.

Yes, Microsoft is going to try to compete, one element of that is the long-discussed-never-seen Project Sparkle. From the discussions of Vista, it sounds to me like they're going to make Avalon scriptable from "Trusted" webpages. If it's worth giving up the Flash install base for those features I'll be surprised.

I guess I'd wonder if you think commercial software development is worth it at all. I think Macromedia has really hit the sweet spot for being open while not being able to be embraced and extended. After the GPLFlash reverse engineering, Macromedia added wording to their EULA's that you couldn't reverse engineer the Player. So, since Microsoft didn't reverse engineer a player back when GPLFlash did, they now can't do so without attacking the validity of EULA's.

Before the Adobe merger/aquisition, there was always a concern that Microsoft would buy Macromedia. Now that they'll be Adobe, I really don't think Microsoft could aquire them without anti-trust problems - they're proably one of the, if not the, largest Windows & Mac cross-platform software developers. If they can't fend off Microsoft no one can.

Re:Ajax compared to Flash

[ObligatoryUserName]

See this post for why I believe the NPD studies commisioned by Macromedia.(You can find the relevant section of the post by seaching for "complete bullshit")

If you do see Flash in the Add/Remove Windows Components interface you're looking at the Stand Alone Flash Player. This is a separate program that can run Flash content outside of the browser. I believe it used to be installed when you got the Netscape-stlye plug-in. I don't know if this is still the case. (I have the Macromedia authoring tool, and that always installs it.) Flash bundled with Windows is a dll, and you need to download a program from Macromedia to uninstall it. It does come bundled with Windows XP, I haven't heard anything about if it will come with Vista.

a lot of people will disable Flash
If you're talking about FlashBlock, I beleive Macromedia has been working with them to make it easier to just see the Flash content you want to see; and easily turn on Flash when you need it and to turn it off to avoid annoyances.

You certainly won't find Flash on any of my computers.
I think your sample size is too small.

Re:Ajax compared to Flash

[SillyNickName4me]

Yes, Microsoft is going to try to compete, one element of that is the long-discussed-never-seen Project Sparkle. From the discussions of Vista, it sounds to me like they're going to make Avalon scriptable from "Trusted" webpages. If it's worth giving up the Flash install base for those features I'll be surprised.

It looks like they went for this AJAX thing for now also.. which in a way competes with Flash.

Before the Adobe merger/aquisition, there was always a concern that Microsoft would buy Macromedia. Now that they'll be Adobe, I really don't think Microsoft could aquire them without anti-trust problems

That has never stopped MS, and with some reason. They are a convicted monopolist, but the slap on the wrist they got means that it has been quite proffitable still to behave in an anti competative way for them.

Re:Ajax compared to Flash

[Teach]

And I'd add: because I can't code Flash in vim. Over an SSH session to my webserver.

For the past decade (scary I've been coding HTML that long, actually), I've basically used nothing but vi to develop for the web. Except for a brief stint with TextPad back when I used to use Windows.

So, Ajax I could do with my existing tools. It's just coding after all. For Flash, I'd have to obtain and learn a new operating environment. And from my perspective, the learning curve isn't worth the benefits.

You (ObligatoryUserName) have raised my estimation of Flash, though. More power to you.

Site already slow

[Saiyine]

Here's a mirror:

Service Unavailable

--
Dreamhost superb hosting.
Kunowalls!!! Random sexy wallpapers.

Add LAMP to the list

[merreborn]

Linux, Apache, MySQL and PHP, for the uninitiated

Still pissed, I think.

[Leontes]

I tried to get him to talk to me, but he was still muttering some shit about armor and went back into Erebus. So his current state: dead and bothered.

Thin Client, My Ass!

[_bug_]

This is nothing more than a repeat of what we saw when Flash started to get popular.

AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else) to get and manipulate all this data.

So truly thin-clients (think Lynx circa 1996, guys) are SOL. Now it's AJAX or bust.

And you're probably thinking "well who the hell uses Lynx or some other, archaic, web browser?"

Well there are those people out there, but that's not all. I'm thinking about the non-human factor, computer applications that come in whatever form to consume the information available on the web. Many (though not all) don't have a javascript engine to execute the various instructions needed to get at the data. So once AJAX becomes ubiquitous (enough), search engines will either need to start using smart crawlers that can execute javascript, or their indexes will start to really be meaningless.

And that's just one of (what I vision) many non-human processes that take web pages and process them (the data marked up by HTML... remember, that's what the web has always been about, data structured with HTML) to produce more useful information for users, sometimes human, sometimes other non-human applications that futher analyze, compress, etc.. the data they find.

When Flash hit the streets, we saw this problem come up rather quickly, although many simply chose (and still choose) to ignore the issue. You still can't (really) bookmark a single page inside a Flash movie... so if there's vital data you need, you have to watch/move through the movie to get to the key page you're after. AJAX will prove to be no different.

So what? Use RSS or web services or some other means to provide information to non-visual applications (everything besides a web browser developed after 1998).

But RSS,SOAP,etc. is simply re-inventing the HTML wheel. They exist simply because HTML isn't being used the way it was always intended to be. You can write an application to parse heading tags and present their contents in a list format. You can write an application to submit a query via a POST operation (form fields) and parse the results back to the user.

Simple shit. Being done since the 1990s with great results.

But not anymore. The web is abused so much we reinvent HTML with XML. Now we only need a 4kb file to present a 20 character string to a consumer process. Bloated. Ugly. Inefficient.

And you think XML will be the answer? HELL NO. XSLT has no business even existing, and yet there it is. XHTML? Give me a break.

The web is a piece.

AJAX is just helping to quicken the flushing of the web down the toilet, and not helping to clean it.

Re:Thin Client, My Ass!

[Anonymous Coward]

Wah wah wah. I'm a crank.

Re:Thin Client, My Ass!

[cosinezero]

Thin is relative. 65K is not a small application... to a C64. I've got over 2 gigabytes of flash memory and at least 128MBs of RAM just on the handheld devices -in my backpack-, all of which more than adequate to run an AJAX client.

Re:Thin Client, My Ass!

[aztracker1]

To be honest, I understand your concerns, I think it is more of a matter of implimentation, than the technology itself...

If used for an application that is web based, it's *VERY* good, since a user will generally have a single point of entrance (the login screen) it comes down to the purpose, the web is more than just a bunch of static information, and the primary use of AJAX is for web-based applications... and in cases where things can/should be bookmark-able, it can be done..

Though I agree with some of your sentiment, your rant is a bit off as this is less likely to be used for stupid things (like encoding an *ENTIRE SITE* in flash)...

Re:Thin Client, My Ass!

[_vSyncBomb]

For fuck's sake, mod the above post the fuck up! I read every >0 post on this booch, and this one is the most insightful (writing notwithstanding).

Not only does this cat realize that AJAX isn't any kinda new (as several others point out), he makes the amazingly heretical but totally fucking undeniable point that THE WEB SUCKS THE PROVERBIAL DONKEY BALLS.

And he's right, man, he's fucking totally right.

Re:Thin Client, My Ass!

[Bogtha]

AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else) to get and manipulate all this data.

No. "AJAX" uses the XMLHttpRequest object to dynamically load things from the server. You have been able to do such things in the past with hidden frame hacks, but AJAX doesn't require hidden frames. Anybody who has actually used XMLHttpRequest knows this.

So truly thin-clients (think Lynx circa 1996, guys) are SOL. Now it's AJAX or bust.

No, it's perfectly possible to develop a website that uses AJAX and is compatible with Lynx. It's no different to any other use of Javascript.

I'm thinking about the non-human factor, computer applications that come in whatever form to consume the information available on the web. Many (though not all) don't have a javascript engine to execute the various instructions needed to get at the data.

Except a Javascript engine is not required to get at the data unless you've constructed your website incorrectly. Furthermore, AJAX typically exposes data in an XML format as well, making it more useful to applications consuming data.

So once AJAX becomes ubiquitous (enough), search engines will either need to start using smart crawlers that can execute javascript, or their indexes will start to really be meaningless.

The only thing I can derive from this statement is that you haven't got the first clue about AJAX or Javascript in general. There is nothing about either that locks out search engines. It is only clueless developers that locks out search engines. Unfortunately, many developers listening to your rhetoric about "AJAX or search engines" are going to choose AJAX, not realising that they don't need to choose.

You still can't (really) bookmark a single page inside a Flash movie... so if there's vital data you need, you have to watch/move through the movie to get to the key page you're after. AJAX will prove to be no different.

You seem to have the misconception that bookmarks are incompatible with AJAX. This is not the case.

But RSS,SOAP,etc. is simply re-inventing the HTML wheel. They exist simply because HTML isn't being used the way it was always intended to be.

Again, you are giving the impression that you don't have experience with RSS or SOAP.

RSS is a format for providing a list of items that is intended to be updated on a regular basis. While you could use a subset of HTML for the list, HTML doesn't provide the semantics for the "updated on a regular basis" bit. For example, there's no equivalent to the <ttl> element type.

SOAP is a protocol for exposing objects, their properties and their methods to remote systems. HTML doesn't do this. HTTP comes close, but the only way to get browsers to be flexible enough to use HTTP's verbs and resources as substitutes for SOAP's methods and objects is to use AJAX.

I'm sorry, but your whole rant comes over as being rather uninformed. Sure, AJAX is no panacea, but your criticisms don't make sense.

Re:Thin Client, My Ass!

[graveyhead]

Nice response to the GP's flamebait, Bogtha.

I'd just like to add one other thing: he is also VERY wrong about XSLT. It's a fantastic language if you know what you're doing. You can take any XML based format and transform it to any other with a minimum of hastle - much less hastle in fact than transforming a data format from one type to another in *any other language*.

In addition to transforming one XML format to another, XSLT can also produce HTML and plain text output as well. It can turn XML into virtually anything - and it does so with a highly elegant syntax (alongside XPATH).

It's even possible to get it to produce some binary formats. For example, you can transform your own XML format into XSL formatting objects and then use a tool like Apache Ant to make the whole thing into a PDF. It's possible with this combination of technologies to build a website in which every single page is available as a PDF.

So, grandparent poster - please get a clue. I don't understand where your obsessive hatred of XML comes from. Perhaps you've had bad teachers or a bad expreience with XML code written by an ametueur.

Re:Thin Client, My Ass!

[graveyhead]

You know what's really funny about your rant against XML right after complaining that search engines won't be able to index? This google tool gives you *exact* control over what is indexed on your site. You provide google with data in guess what format?

The future is XML for data and HTML/DHTML/CSS for presentation. Plain HTML circa 1995 was the big hackish joke. The architecture of the web is coming of age.

Re:Thin Client, My Ass!

[kard]

>You seem to have the misconception that bookmarks are incompatible with AJAX. This is not the case.

ok. so how do you bookmark an ajaxed webpage?

for example, maps.google.com?

yes, there is a link called link-to-this-page,
but it is not the one shown in the url-bar.
it's not the one you get when you create a bookmark for this page.

or do you know something better?

Re:Thin Client, My Ass!

[_bug_]

No. "AJAX" uses the XMLHttpRequest object to dynamically load things from the server. You have been able to do such things in the past with hidden frame hacks, but AJAX doesn't require hidden frames. Anybody who has actually used XMLHttpRequest knows this.
This is covered in the "god knows what else".

No, it's perfectly possible to develop a website that uses AJAX and is compatible with Lynx. It's no different to any other use of Javascript.
You've got to be kidding me.

This isn't using JavaScript to do some kind of silly image rollover. This is using JavaScript to present data. Data that is obtained by executing the JavaScript.

Your taking page content and delivering it AFTER the HTML is loaded into the browser.

This means content is unavailable to clients that do not support Javascript.

Except a Javascript engine is not required to get at the data unless you've constructed your website incorrectly. Furthermore, AJAX typically exposes data in an XML format as well, making it more useful to applications consuming data.
The XML data exposed on an AJAX page is derrived by requests sent to the server through the execution of javascript. There is no other access to the data unless you're executing the javascript.

" unless you've constructed your website incorrectly."?! What, expose an entire library of documents within a single HTML file? Make it severla megs at least? Because that's the only way you're getting data to non-javascript clients. Sounds to me like getting data to non-javascript clients is only done by specifically constructing your site incorrectly.

The only thing I can derive from this statement is that you haven't got the first clue about AJAX or Javascript in general. There is nothing about either that locks out search engines. It is only clueless developers that locks out search engines. Unfortunately, many developers listening to your rhetoric about "AJAX or search engines" are going to choose AJAX, not realising that they don't need to choose.
Time to start thinking for yourself and get your head out of the books.

Data is exposed through XMLHttpRequest. This request is only performed only by clients that understand and can execute javascript. a basic search engine crawler cannot do this. As a result, the data available through your AJAX application is left unavailable to the search engine.

How else is data being exposed except through execution of javascript?

You seem to have the misconception that bookmarks are incompatible with AJAX. This is not the case.

Fine, go to Google Maps, specifically go through maps.google.com, and locate the white house. Now bookmark that and paste the link into your reply.

Oh wait.. you can't. Because your bookmark will only go to maps.google.com.

Now you can provide the lattitude and longitude, as well as an address, on the URL, however those URLs are provided for you directly. You have to craft that yourself. Which is exactly NOT what I'm talking about. I'm talking about surfing the page through normal use and bookmarking the page using your browser's bookmark feature.

You simply can't do it with an AJAX application unless you start bringing cookies into this.

RSS is a format for providing a list of items that is intended to be updated on a regular basis. While you could use a subset of HTML for the list, HTML doesn't provide the semantics for the "updated on a regular basis" bit. For example, there's no equivalent to the element type.

HTTP header's last-modified attribute. Different names and maybe you can derrive different meanings, but they provide the same information for this purpose. Keep performing a HEAD operation on the index page of your favorite news site. When the last modified is changed from what you have locally, you request the page, extract the headings, and create a list. Unless you're working with RSS feeds that contain week's old data, your TTL serves little more purpose than t

Re:Thin Client, My Ass!

[Bogtha]

This is covered in the "god knows what else".

No, it isn't. You said:

AJAX requires a client that supports javascript in the first place, along with XML and whatever other bits of things (hidden frames.. god knows what else)

I don't know what your native language is, but in English, that sentence clearly states that AJAX requires hidden frames. That is a completely untrue statement. If you want to backtrack and say that you didn't mean to say that, then fine, but don't try and pretend that isn't what you said.

No, it's perfectly possible to develop a website that uses AJAX and is compatible with Lynx. It's no different to any other use of Javascript.

You've got to be kidding me.

The principles of graceful degradation are very well established. Surely if you have any experience with Javascript you must know this, or at least heard of it.

Your taking page content and delivering it AFTER the HTML is loaded into the browser.

This means content is unavailable to clients that do not support Javascript.

No, it does not. Consider popups. The popup - the content - is delivered after the HTML is loaded into the browser, and yet it's perfectly possible to construct popups that degrade gracefully in browsers that do not have Javascript available. AJAX is like that, only a little more complex.

The XML data exposed on an AJAX page is derrived by requests sent to the server through the execution of javascript. There is no other access to the data unless you're executing the javascript.

Again, that's not true. The data you access via AJAX can be accessed by anything that speaks HTTP. Ever hear of "web services"? No need to limit the data exposed via use of AJAX to one website's Javascript.

How else is data being exposed except through execution of javascript?

The data is being exposed through HTTP and XML. Javascript is merely one way of getting that information into a browser.

" unless you've constructed your website incorrectly."?! What, expose an entire library of documents within a single HTML file? Make it severla megs at least? Because that's the only way you're getting data to non-javascript clients.

If that's the only way you can imagine making AJAX work, then you have a very limited imagination, and not much exposure to actual AJAX use.

Time to start thinking for yourself and get your head out of the books.

If anybody is being close-minded here, it's you. It sounds very much like you heard about the idea, assumed the worst with the aid of a few erroneous assumptions, and are now unwilling to even consider the possibility that your initial assessment was wrong.

Data is exposed through XMLHttpRequest. This request is only performed only by clients that understand and can execute javascript.

This is one such erroneous assumption. Consider an "in-page" popup, perhaps context-sensitive help. Clicking the button can retrieve the content in user-agents that implement AJAX, and it can act as a normal link for the user-agents that don't implement AJAX. No need for things to break for non-Javascript users.

Another erroneous assumption you are making is that exposing the data for non-Javascript user-agents is necessary and failure to do so is a mistake. Something like Google Suggest is a perfectly reasonable enhancement to make that has basic functionality for non-Javascript user-agents, and enhanced for user-agents with AJAX capabilities.

You seem t

Re:Thin Client, My Ass!

[Bogtha]

ok. so how do you bookmark an ajaxed webpage?

The same way you bookmark any other page.

It's not AJAX that breaks bookmarking, it's rewriting pages with client-side scripts when you should be sending the visitor to a new page that breaks bookmarking. That's a mistake you can make with any type of client-side script, there's nothing specific to AJAX that causes it, and any decent developer would avoid doing that. For example, Google Suggest doesn't break bookmarks.

AJAX has already failed

[Anonymous Coward]

Running arbitrary javascript is a security liability, which is why many people have it disabled. Whoops, there goes your latest buzzword.

TBL has one vision for the future of the web and AJAX proponents have another; "The web for drooling moron consumers, forced to use javascript and hence endure DHTML popups". The real future lies somewhere imbetween, without everybody attaching semantic metadata to every digital item and without clueless buzzword-weilding CTO's expecting to run arbitrary code on end users desktops.

DOM 3

[mov_eax_eax]

What i learned with the painful development with javascript, is that standards are good, using the DOM model instead browser specific extensions is a good thing, better compatibility, the API is more stable, for this reason i think that the right thing to do is embrace the Document Object Model (DOM) Level 3 Load and Save Specification standard for asynchronous communication instead XMLHttpRequest.

Re:DOM 3

[aztracker1]

Except that XmlHttp is already implimented, and available in the major browsers (gecko/mozilla, ie, opera8, and afaik even in KHTML/Safai)...

Standards are great, and a good thing which is better? A standard that nobody can use, or a non-standard that is widely implimented, and near ubiquitous.

Re:DOM 3

[Bogtha]

Unfortunately, the network communication part of DOM3LS was dropped from the drafts and didn't make it into the final recommendation, even though a number of browsers implement the draft's network API anyway. Given that Internet Explorer isn't likely to support DOM3LS, let alone an extended draft version of it, any time soon, you're probably better off using XMLHttpRequest.

Version I will support standards.

[Anonymous Coward]

But Version II and onward of Microsoft's AJAX toolkit will proprietize things.

Embrace. Extend. Destroy.

Re:Version I will support standards.

[Anonymous Coward]

Embrace. Extend. Extinguish.

excellent idea for a script!

[Tumbleweed]

That's something a script should be handling for every site - it has an account on Slashdot, and can see the mysterious future posts - if there's a link to their site in it, it sends an alert to the sysad.

Re:excellent idea for a script!

[Gherald]

That's something a script should be handling for every site - it has an account on Slashdot, and can see the mysterious future posts - if there's a link to their site in it, it sends an alert to the sysad.
It'd be much more effective to just grep slashdot's front page for a link to your site whenever you detect a visitor has been refered from slashdot. If there's a match, start blocking connections from everywhere except coral cache and the various automated article mirror sites.

Simple fix for cross-domain AJAX

[bexmex]

You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.

Use a proxy.

Create a page in your favorite scripting language that forwards the HTTP request for you. Then put that page in your domain, and make AJAX calls to it.

5 lines of ASP, PHP, Perl, or Python... or 20 lines of JSP. Easy!

Re:Simple fix for cross-domain AJAX

[elemental23]

An even easier way would be to enable mod_proxy and add two lines to your Apache config:

ProxyPass /foo http://www.example.net/bar
ProxyPassReverse /foo http://www.example.net/bar

Where 'foo' is the apparent target URI on the current domain and 'http://www.example.net/bar' is the actual target URI.

Re:Simple fix for cross-domain AJAX

[defile]

You can't (via "AJAX") query any site but the one that served the script without the browser imposing this scary security warning. We run the sites in question, they just have different domain names.

Use a proxy.

I wonder why I never thought of that!!

Changing my tune

[cbare]

Rich web applications... what a great idea.

I've been telling clients for years (since about 2000) to give up on any grandiose ideas of a highly interactive web site. Javascript and DHTML were just hype and didn't work worth a shit in the real world.

Ironicly, my main example was Google... a dead simple interface that lived within the limited means of HTML and was still extremely usefull. Nowadays, Google is leading the way into more interactive web applications. So, I guess it's time to change my advice.

Still, AJAX is basically a dirty javascript hack to achieve rich interactivity in today's browsers.

I hope the evolution of interactivity in the browser doesn't stop here. It seems like there's got to be a less hacky way. One good thing is that the use of XML should allow client side technologies to evolve independently without having to rewrite server-side code.

Anyway, it's about time!

AJAX vs VNC

[Anonymous Coward]

Five years ago I thought that something like VNC would become the preferred way to deliver server-based applications (email, for example) to thin clients. Instead we have AJAX. Why? I think that until recently network latency was too slow to use VNC from one side of the planet to the other. As a result we got HTML-based solutions which require less frequent round trips, but are less flexible.

Home broadband speeds are now fast enough that VNC-like "webmail" could be a good option, but maybe it's too late: we have already gone a long way down the HTML route, from which AJAX is the evolutionary development.

From the server perspective, AJAX is also easier to make lightweight: it's currently quite a challenge to support thousands of simultaneous VNC sessions without using vast amounts of RAM. Maybe some smart programming could solve that.

I'll just mention my favourite AJAX application, Anyterm: http://anyterm.org/. It uses an Apache module to implement a browser-based shell. Great for remote admin through firewalls.

Just developed 2 large AJAX-enabled apps

[mflorell]

I just finished about 4 months of work writing two AJAX apps using PHP with javascript and while the end result is what we were hoping for and the app runs beautifully, it took me a tremendous amount of time to code it as compared to a standard fat-GUI-app that runs on the client machine.

I basically did a port of the functionality I had in two Perl/TK apps, but I wanted portability and easy updates of code and I had just done a stress test of AJAX in Firefox and IE and they both seemed to handle the load OK so I started developing.

I did not use any tools aside from a text editor and the browsers to test in. The tools like SAJAX just created bloated code that crashed the browsers once things got too complex for them so I decided just to hand-code it from there on. I built in some session security and user authentication both of which ended up working rather well.

These apps are querying other pages to get updates on phone system extensions statuses(from Asterisk) and other bits of information and updating DHTML elements constantly, so they do generate a lot of HTTP requests and use at least three times of the bandwidth that the fat-client perl/Tk app used to, but the database and web server seem to take the traffic OK and we thought that both of the browsers did too until we did some time tests.

We were able to leave the AJAX app running in the same Firefox session for over 2 weeks before we had to reboot the machine for other reasons which was wonderful and much longer than we thought. But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.

In case anyone has read this far, the apps are GPLd and available on sourceforge. They are apps that extend the functionality of Asterisk PBX phone system extensions. You need to have Asterisk and the astGUIclient suite installed in order to test them:
astGUIclient project page

MATT---

Re:Just developed 2 large AJAX-enabled apps

[Nic-o-demus]

And if you're going to be doing AJAX with Firefox, then you may as well use XUL. I'm very excited for the day when we see intensive XUL/AJAX applications. THAT's going to be slick.

Re:Just developed 2 large AJAX-enabled apps

[Osty]

But, Internet Explorer never lasted a day. It seems that in the ActiveX element that handles XML requests(IE itself doesn't do it internally like Firefox does) there is a memory leak and within 2 hours our app was chewing up over 120MB of RAM and was getting slower. We tried several fixes and the only way to get the memory back was to kill the iexplore.exe process(This was on IE5.0 through 6.1). And that is the reason we recommend only Firefox for intensive AJAX apps.

The leak is not with the XMLHTTP object, but with Javascript itself. You have to be very careful about DOM manipulation order to avoid circular references that can't be garbage collected, and you pretty need to avoid using closures entirely (which sucks because closures are damn cool). Make sure you clean up after yourself when pages unload (detach events and such), and as long as you're careful you should be fine.

IE's problem is that the DOM is not a pure javascript implementation. Each DOM object is a COM object, and Jscript's garbage collector doesn't handle COM objects properly. Thus, if you get into a circular reference (a node has an expando property that references a jscript method that references the node), the GC can't clean it up because it can't clear COM objects. So long as the node reference stays around, the jscript can't be cleaned up and you're leaking memory.

There's a lot more to it than that, and a lot of other scenarios that can cause leaks. More information, including suggested practices to avoid leaking as much as possible.

Hopefully IE7 will fix these memory leaks, but I wouldn't hold my breath waiting.

Re:Just developed 2 large AJAX-enabled apps

[Maian]

An essential tool for detecting IE mem leaks: http://www.outofhanwell.com/ieleak/

Problem is...

[TarryTops]

There will be so many cool things that eventually the most cool thing will be to make/design/invent an uncool technology. That said, I like AJAX(remember I'm with the herd!)

Google Cache

[Anonymous Coward]

http://64.233.179.104/search?q=cache:9KCH9m8EYhMJ: hinchcliffe.org/+site:hinchcliffe.org+AJAX&hl=en

Enjoy

AJAX is nothing new, it's just hyped for marketing

[v3xt0r]

AJAX has been around for a long time.

The fact that the technique now has it's own trendy acronym to represent it (like DHTML = JS+CSS), just means more marketing possibilities for devious IT sales kacks.

stop calling ecmascript ajax

[Anonymous Coward]

When someone added DLL's and .so's to C they didn't rename the language or call it some special nickname. AJAX is nothing more than using a standard object to retrieve data in ECMAScript. Its like calling every program that uses the OpenSSL library CSLX. Its an insult to the people who worked hard on JavaScript and the DOM object model to rename their creations AJAX.

AJAX will stop XAML dead in its tracks.

[IGnatius T Foobar]

I can't believe nobody has mentioned XAML yet. Doesn't anyone remember hearing Miguel de Icaza ranting and raving about how XAML was going to spell the end of cross-browser, cross-platform web applications as we knew them, because everyone would be writing stuff that requires a browser that has the entire .NET API embedded inside it?

It's becoming very clear that AJAX is going to stop XAML dead in its tracks. Microsoft was pushing this whole "rich vs. reach" thing, but with AJAX you really can have it all. No need to restrict your user base to Windows XP or Vista in order to get rich controls in your web apps.

I think that's the more interesting story here. The monopolistic Windows desktop isn't going to disappear overnight, but the continued existence, improvement, and increasing pervasiveness of web applications will continue to make the non-Windows desktop more viable and widespread. (Click on the link in the previous paragraph to read a longer piece on why this is the more interesting story.)

Re:AJAX will stop XAML dead in its tracks.

[sean23007]

I fail to understand how AJAX can stop XAML. AJAX, while it is great, has a lot of limitations, and you have to worry about being cross-browser. Why would people stick with it when XAML is available, considering how much more awesome XAML is going to be. My hope is that Microsoft continues their late trend of making their specifications more open, so that Miguel de Icaza or someone else can integrate .NET/Mono into Firefox and port XAML over. If we could use XAML cross-browser and cross-platform, then AJAX and everything else are dead.

My biggest fear is that XAML will still kill AJAX even if it's not cross-platform. I really don't want to see that happen. Nor do I want to be developing in AJAX a year or two from now when all my competitors are developing in XAML, and I have to double my development time to test in IE but they don't have the same limitation.

Re:AJAX will stop XAML dead in its tracks.

[Jason Earl]

Reach, my friend, reach. XAML will be available on Windoxs XP and Longhorn and AJAX is available everywhere, and while AJAX has some problems it's available today.

So while the idea behind XAML might be nicer now, you can't really use it yet, and even when you can use it too many of your customers will be unable to use it. Give AJAX another year and it will be polished to the point where it isn't so clunky anymore. Heck, it's really not that bad now as long as you have Mozilla's Venkman around. That's what should really scare Microsoft. Most of the folks that I know of that are designing Ajax apps develop for Firefox first (because it has better debugging tools).

My favorite part is that my designer buddy can lay out the interface using tools that he is comfortable with, and I just have to make it work.

Why does anyone even read these anymore?

[CaptainTux]

Everytime a new technology hits the streets or gains a large audiance there are always those who hail it as "the next big thing" like this article is doing with AJAX. Usually, it's a giant pop then a slow fizzle back into the toolbox.

AJAX is great. But it's not like it's a reinvention of the WWW or the Internet or something like that.

Why not just call it 'iBrij'?

[Buttercup]

iBrij is Invisible Browser Requests In Javascript.

a step in the wrong direction?

[abes]

I hate web interfaces. I'm happy they've gotten better, and also realize that in many instances, there are no alternative, but in general, I don't think the web browser was made for such type of interactions, nor should it be relied on for such hardships.

While complex apps have been written for the web, not to mention the great things google has done, they are in the end still very hack-oriented.

I think what is really needed to get things off the ground as far as usability is something that is: (a) (really) cross-platformable, (b) language-agnoistic, (c) easy to run/use/create, (d) fast, (e) easy to use with most server types.

While by now I'm sure many people are ready to flame me that Java answers all of these, regardless of how you feel about it, it has not been the success that was once predicted. As long as the majority of internet applications are using the web for interfaces, it is not a success.

Many of the pieces are in place for such a thing. For example, Mozilla's framework may work, or perhaps the Trolltech toolkit QT, or maybe even Java. But with all of these there are still big obstacles. Can you make an interface in 5-10 minutes? How difficult is it to set up the server to handle the requests? Can you run the server easily anywhere (or will the cheaper hosting company only allow HTTP requests?).

Perhaps the best approach, is to continue using HTTPXMLRequests for data transmission, as that is the status quo, but for someone to come up with a complete solution to quickly build such interfaces. I think Interface Builder for Cocoa is a great goal for how one might put together such an app. Tie that together with something like Glade, or Renessance, it would make for a easy to allow for different languages/toolkits to use, and then have a standard API/library for communicating with the server. People can write bindings to their favourite languages, and you have something that is mostly cross-platformable. The only caveat, is for the scripting language, a correct interpreter is required per platform. One solution, would be to allow automatic download of the correct interpret for your platform if it is not detected.

AJAX/XUL/XAML

[Elixon]

AJAX is great. I know it. W3C becames SLOW! Does not move as fast as new technologies => more compatibility problems will arise... Future belongs to XUL/XAML but I prefer W3UIML (standardized version of XUL XAML) ;-)

OpenLaszlo is more portable

[hqm]

OpenLaszlo is an open-source tool for building Rich Internet Apps that compiles them down to Flash applications. The advantage is that the graphics are smooth, it runs pixel-for-pixel identical in virtually any browser, no cross-platform incompatibilities.

An OpenLaszlo app behaves essentially like an Ajax app; data requests are made for XML data (or media) in the background, and the user interface is presented as a seamless window-system style desktop app.

Simple Example

Re:OpenLaszlo is more portable

[josepha48]

problem is that that requires flash on the browser end to be installed. While not usually a problem, sometimes it is a requirement not to have ANY client side 'extras' ( applets, flash, plugins ) installed on the client. The XmlHttpRequest, which is really improperly named, it should be the AsyncJsHttpRequest object or something, actually allows me to do updates on a fill out form without refreshing the entire page. There is no XML in my stuff, just a JS onchange make the request, put result in div or span. I was required NOT to use flash or applets or plugins. So I went with JS / HTML and the DOM. Its worked well, and the XmlHttpRequest object is allowing me to take it to the next level.

Re:OpenLaszlo is more portable

[sd4l]

Yes, but the same sort of thing can be done without Flash (and not requiring a plugin). A comparable AJAX version of your Simple Example:

Another Example [openrico.org]

Much better:

[temojen]

Use apache rewrite rules to auto-coralize any references coming from popular sites like slashdot, fark, etc.

Why the hype?

[prophecyvi]

I have to ask why all this is news lately? There's nothing new about using JavaScript to asynchronously update a portion of a page. At my company (where I am the Web Services lead) we have been using this technique since 2001, and I don't begin to think we're on the leading edge of that. There have been people doing this since probably 1999.

I ask the question, but I really know the answer. Somebody stuck the word "XML" in it and it suddenly became the holy grail of Web programming. It's a good methodology for doing certain things, and I've honestly got to say if you didn't know how to do this before the last few months of hype, you're either not a Web programmer or you're on the bottom end of the Web programmer stack.

(Why complain? It's really, really annoying to have the things you've been doing day-to-day for 4 years be ignored while new people doing it are suddenly "powerful" and "cool" just because someone said it had XML in it.)

Re:Why the hype?

[Anonymous Coward]

AJAX new???

Don't think so..

this is the biggest pile of over-hyped nothing I've seen in a long time....

I only wish when I was writing xmlhttp/javascript web apps years ago that it had a nifty name...

Re:Why the hype?

[SilentReallySilentUs]

No not XML, it is Google. People saw Gmail and Google Maps, and now AJAX is all over the news.

Re:Why the hype?

[Bogtha]

I ask the question, but I really know the answer. Somebody stuck the word "XML" in it and it suddenly became the holy grail of Web programming.

Er, the name of the object doing the heavy lifting has been XMLHttpRequest all along. The XML biit is nothing new.

The reason why it's become so popular is GMail. It was the first really high-profile (semi-)public service that required XMLHttpRequest. This had two effects:

1. Bosses started asking "How can we do that?"
2. People deciding which browsers to support said "If it's good enough for Google, it's good enough for us!".

I don't particularly value either as a reasonable excuse to jump on a bandwagon, but plenty of other people do. Somebody made up a buzzword for it, and the rest is history. No need for XML to invoke its particular braand of buzzword mania.

Critique

[N8F8]

Normally I'm not one to comment on someone's coding style, but:

• You do realize you can print/echo multiple lines of output at once in PHP? I also recommend using "print" for normal stuff and "echo" for debugging - that's just my preference though.
  
• You also seem to program very linearly (I see a lot of stuff that should be functioned off).
• Endless "if" statements can be written more clearly with the "switch" statement.
• Stay consistant with HTML case. I would suggest sticking with XHTML lowercase for tags.
  
  

  If you want to get the most out of AJAX, pass the information back to the client in a compact XML form. I recommend a format with one element per record with attributes for record columns. The whole point of AJAX is to keep the information tyou pass for each request between the client and server to a minimum. Of course, I couldn't fin the XMLHTTPRequest declation in your code either.

Re:Critique

[nahdude812]

You deserve positive moderation.

You're the first person on Slashdot that I've read who actually seems to really understand what sort of things make best practices in AJAX.

Re:Critique

[mflorell]

Thanks for the critique, this was the first non-trivial large project I've done in PHP in about 4 years so I do admit that my PHP and Javascript were a little rusty going into this.

I usually do a lot of separate print or echo lines while developing and for ease of commenting out parts at times, just a preference of mine.

I found through writing this AJAX code that writing linearly is your friend. Yes, there is a TON of duplication in the code, but every time I started heavily using functions in Javascript, things started not working right, and nesting functions and calling functions within functions several levels deep will not always execute as expected, but the same code written in a more linear fashion will execute much more reliably in Javascript(NOTE: the only AJAX code in the project is in the 'agc' folder of the package)

Thanks for recommending switch, wish I'd known about that earlier, but I've been out of active daily development in PHP for years. I do plan on using that in future projects.

Consistent HTML case has always been a weakness of mine.

I'm actually not even using XML formatting for the passing back to the main script of the data from the XMLHTTPRequest scripts. I just use pipe-separated or one element of data per line output and parse the data differently for each type of request. The AJAX code in the project is confined to the 'agc' direcotry, I do have a lot of other PHP and Perl code in the rest of the package that has nothing to do with AJAX.

Thanks again, It's rare that you get good constructive feedback on coding if it's not a very widely distributed package.

Re:Critique

[pedroabelleira]

"in a compact XML form" Good one!

I blame W3C

[Elixon]

I blame W3C! W3C is too slow to address hunger for RIA on the Internet. W3C becames to be more playground for big corporations trying to extend their influence (or sabotage anything that could harm their business) and not a forum for consensual agreements to benefit everybody (if it ever was the meaning of W3C).

Re:I blame W3C

[Anonymous Coward]

The W3C has been doing admirable work -- the rest of the world has just simply ignored it.

As long as Microsoft refuses to produce one single browser that actually adheres to the W3C standards, what chance does the W3C have to wield any influence?

JSON instead of XML

[Trinition]

I've been doing a lot of experimentation with JSON (JavaScript Object Notation) instead of XML. You do everything youw ould do the AJAX way, but the data sent back to the browser is directly interpretable by JavaScript. Thta takes an ENORMOUS load off the client.

JSON-RPC is an extension for doing RPOC via JSON.

Re:JSON instead of XML

[Anonymous Coward]

Just for Slashdot archive reference before the JSON was farted out as a buzzword this I believe this was called "javascript literal notation"

War again? Which side you are on?

[Elixon]

Do we have to choose again what to support? Flash? AJAX/XUL? AJAX/XAML? AJAX/XHTML? JAVA? ...? Where are we heading to? To AJAX WARS? Didn't we just get out of the BROWSER WARS? Where is the problem?

Re:War again? Which side you are on?

[ObligatoryUserName]

Oh no, I didn't intend to imply that at all. Indeed, Flash and Ajax are quite similar in some ways, the scripting is ECMAScript for both. I just posed the question because I do this type of programming, but I haven't done much Javascript lately and was wondering if Ajax was worth my time.

XHTML is still better than HTML

[Trinition]

XHTML? Give me a break.

XHTML is still better than HTML. XHTML is logically parseable. HTML has all these silly rules about closing certain tags implicitly when another is opened, and what not. m I find writing an XHTML page MUCH lessa nnoying than writing in old HTML.

You're going a little too far.

[Some Random Username]

There are instances where an AJAX like web app is the right way to go. A few years back I made one (just using an iframe and text, no XML nonsense) which really couldn't have been done as well any other way, especially since it had to be updated at least once a week.

Just because something is an over-used, over-hyped fad doesn't mean it has no uses at all.

Only makes sense in American

[Anonymous Coward]

In commonwealth pronunciation "kill zed cat" makes no sense.

Not sure that's what he's arguing

[SuperKendall]

For many data and information retrevial apps, do we really need Ajax everywhere? Or should it be used lightly only when rich functionality is really needed?

What he's complaining about is that the AJAX world sounds cool on the surface but is very fragile just below - Javascript really is not all that standard, even across versions of IE. And witness the post about AJAX style leaks in the current IE that will chew up memory left and right. Do you really want to be answering support calls about user browser crashes? Because if you go to fast, too soon down the AJAX road that's where you are headed to.

Years ago I was doing XSLT to HTML transformation on the server instead of in the browser to avoid exactly these issues, even though I could have done the transformations client side saving expense on the server.

Perhaps the answer is, oddly enough, to simply have users run applets whose only job is to really run Rhino, the Javascript engine for Java. Then at least the conatiner AJAX runs in is standardized...

AJAX + (X)HTML = eeee

[Elixon]

Sorry, but it is kind of strange marriage. HTML/XHTML is not designed well to serve large AJAX application needs! XUL and XAML are better solution. But what should I do? XAML or XUL or maybe FLASH or JAVA? I've choosen XUL. But I'm not happy with it. I'm affraid that I will not benefit from it as I didn't benefit from browser wars.

Re:AJAX + (X)HTML = eeee

[bedroll]

Well, the best reasoning for using this combination is that you can make it work on such a wide range of platforms and you aren't tying yourself to anything proprietary.

If you go with XUL you have a similar argument, but you are tying yourself to a particular browser. Java, utopian language it may be, is slow under most RTEs and ultimately is proprietary. Though I don't know anyone who ever felt bad for coding with it... unless the end result ran like molasses. Flash seems under-used for legitimate applications, but the good Macromedia IDE is expensive and the whole thing is proprietary. XAML is, well, Microsoft's. If you're pro-Microsoft then that works, but then you might as well weigh your options about just making a "heavy" application with tried-and-true Windows forms.

AJAX + (X)HTML has its place, and can be used in some pretty large applications. A friend of mine recently finished an application that allows clients to submit forms directly to the SEC using an AJAX + HTML (I don't know if it conforms to XHTML) front end. That's pretty huge. Some of the forms have the possibility for hundreds of pieces of information to be included. The result is amazing, the user experience is on par with a stand-alone application. Best of all he doesn't care what platform or browser the client is using, so long as they're within this millennia on technology.

Re:AJAX + (X)HTML = eeee

[Elixon]

I'm working on AJAX CMS written in XUL. Actually it looks like the first XUL CMS I know about. I spent about half a year thinking of appropriate technology that will be flexible enough. I found that XHTML is rather unmanageable to be used with larger RIA. It's missing some of very important functions needed for CMS. I chosen XUL because it gives me 1. Advantage of cross-platform compatibility 2. Overlays and bindings that XHTML doesn't have (only acceptable way how to manage RIA that has not only forms but many other special functions like WYSIWYG, RDF lists, third-party plug-ins etc.) I have experience with it and it is very painful to write good RIA with XUL. :-) Actually it is rather SAD (opposite to RAD ;-). I must admit that XUL was rather "political" choice because from the programming perspective XAML is very similar. I think that XHTML is great but not as good as XUL/XAML/FLASH that was created with client-side scripting in mind.

SOA can live without AJAX

[Anonymous Coward]

SOA are mostly used to communicate between services. No user interface is required here.

I'm developing a SOA named XINS http://xins.sourceforge.net/. I've added an example on how to use AJAX with XINS. It was quite easy as the protocol for XINS is URL as input and simple XML as output. I think it could be useful for small API but when it comes to the user interface I prefer to use XSLT that transforms the XML to XHTML.

Thanks Google!

[SilentReallySilentUs]

AJAX was there for such a long time but nobody cared to use it until Google showed the way with their Gmail and Google Maps and now everyone is writing AJAX books and creating "frameworks" around it. All the web designers were previously focusing on getting their pages browser complaint and even reach all those user who use no-frame, no-javascript, no-cookies old browsers with little screens. Google took us a step forward by being bold and re-introducing AJAX to the world. Thanks to Google, we will see users change their behaviour, browsers standardize, and lot of interesting rich applications.

the current state of ajax books is....

[museumpeace]

coming soon. I just asked at Barnes and Noblel...they can search for upcoming titles...the first they will have on their shelves is november. one more to be published before new years. two or 3 on their radar for next year. I can't wait! anybody have new of an earlier publication? any docs on line?

Re:the current state of ajax books is....

[Pascarello]

Ajax in Action will be available in ebook version shortly. If you buy it from Manning.com directly, you can get the MEAP subscription. The MEAP subscription allows you to get the chapters as we finish them.

Eric Pascarello
co-author of Ajax In Action

Re:the current state of ajax books is....

[Pascarello]

Ajax In Action Sample Chapter Released! http://www.theserverside.com/articles/article.tss? l=AjaxinAction_CH4_PT1

not accessible Re:OpenLaszlo is more portable

[La Gris]

Great, How am I supposed to use a flash application with a braille terminal connected to a brltty device on Linux ?

Ajax is dead

[Nice2Cats]

Ajax is dead. He committed suicide after going insane following his contest with Odysseus about who should get Achilles' armor.

Christ, this is why I hate Slashdot -- the guy's been dead for at least 2,600 years, and the editors are trying to pass this on as news...when do we finally get to pick our own stories?

Preferences

[SpacePunk]

I prefer Ajax over Comet any day.

One word: Marketing

[cr0sh]

Think about it, this is older than the hills. Your "product" could be the absolutely best, most cool, most high-tech-ahead-of-its-time thing, and it could flop because you called it "gurbleflaz".

Give it a hype name, and presto, instant cred.

Yes - the technology behind AJAX has been there for quite a while, in some form or another. But it didn't have a name, something that easily rolls off the tounge and sounds "cool" to the average person (not too mention it also is a name people have heard before as a "good" product - so it hits those feel-good patterns in the brains of many people). AJAX - web technology, patterns hit: clean (the AJAX brand cleanser), good (the AJAX brand cleanser), does the job well.

So - keep this in mind next time you develop a product of any type: give it a good marketable name, something that rolls off the tounge and people can easily remember - then market/advertise it enough - and you will have a winner - even if the actual technology behind it is crap.

Case in point: Ogg Vorbis vs. MP3 - which one is better, which one is worse? Which one rolls off the tounge, and which one is more difficult to pronounce? The choice is clear. Couple that with the obvious fact that MP3 has been out longer and thus has more airplay, so to speak, and the "winner", even though arguably less superior in many ways (quality, size, and "openess" of the player/encoder - ie patents) to the OGG standard - is the one people will remember and use (and this is possibly why other competing standards aren't "winning", either - though a standard that comes out and plays on MP3 - like MP4, or something similar - might edge it out)...

Article Leaves out Echo2

[tjasond]

From my experience, Echo 2 is by and large the most complete and stable AJAX toolkit for Java. It has a very nice pure Java swing-like API and is very extensible. The Online Demos are very cool and definitely worth a look. If Atlas is the AJAX framework for .NET, Echo2 has got to be the equivalent for Java.

I've used it on TrackIt for a few weeks now and in my opinion, it is head and shoulders above any open source Java web framework, AJAX enabled or otherwise.

Where are the development tools?

[edxwelch]

This guy claims there are many development tools for Ajax.
So where can we find the javascript debuggers for IE, Opera and Safari?
This is the most important part of any Ajax development environment, as there will be a lot of complicated javascript and it needs to be tested on each browser you are going to support.

More hype

[Evets]

AJAX is constantly being hyped, but there isn't even a solid foundation out there yet. Very few websites have good ajax information, books are few and far between. Even sitepoint's book that is advertised as AJAX centric really only tells you to use an existing open source library.

There are a lot of great things that you can do - it opens up web applications a good deal - but there are still accessibility issues and support issues accross a few browsers.

Help me, save me, take me away....

[LordMyren]

"Ajax hasn't even been big a year yet and already open source development tools by the dozen are pouring out."

*gag* *choke* *vomit* A year?

What a load of crap. I hate how someone gives the blasted thing a name, google releases a web app and suddenly the shunned hated upon bastard child is the new golden boy for the web and everything modern. What fresh new technology! *spite* *snear*

I've been screaming at opera to include XmlHttpRequest for years now and basically been completely ignored. The only responses I ever got where `who gives a damn? -- no one uses that for real`.

But really,

All these AJAX tool kits are going to really fuck things up. XmlHttpRequest is just an asyncronous way to pull data off an HTTP server. Smart people realized the true value: not that you can make 50% of web browsers dance like puppets on strings, but that suddenly data exposed via HTTP can be accessed very immediately by anyone. Smart people who realized this built cool webapps around very very smart servers: that was the world of XmlHttpRequest.

Ajax on the other hand is pretty much synonymous with fancy web page that dont have to reload. IDE's to build flashy web pages for us are only going to further obfuscate and destroy the fact that XmlHttpRequest is simply a way to exchange data. Well designed asyncronous architecture was what made XmlHttpRequest so amazing, but its about to be burried under a mudslide of syncronous commands being sent back and forth to make the browser dance in some asnine way. Wake me when the buzz has died down some, I cant hear with all this racket going on.

[On the other hand, toolkits can be very handy. I was massively impressed with the Dojo toolkit when I scoped it out a while back. What other toolkits are people using these days?]

Myren

Acronyms galore

[bonch]

Could you use some more acronyms? I haven't gouged out my eyes far enough yet.

why this fluff about something 5 years old

[Anonymous Coward]

I hate to say that all this buzz around something which was there since last 5 years in one form or the other is not warranted that much attention. Everybody does the ajax style calls to avoid too many page turns right from simple validations to complex dom replacements. I see everywhere, AJAX getting so much attention just because google uses it ? god. what the hell is going on.

The best AJAX application I've ever seen

[Anonymous Coward]

Comes from a company called Convea, which I believe is just one guy and why I'm all the more amazed at it. It's certainly inspired me to rethink what is possible with a browser, and what great benefits web applications bring over conventional apps.

Check it out: http://www.convea.com/

Would you _PLEASE_ give us a break allready?

[Qbertino]

This is so going on my nerves I can't tell anyone.
Once again:
As long as JavaScript doesn't behave predictable across Browser DOMs just as CSS has learned by now to behave 95% predictable across plattforms and browsers this whole AJAX thing is NOTHING BUT F*CKING POINTLESS!
The concept of rich clients (what Ajax is all about) in ancient! The only thing that lacks is a cross plattform enviroment that people are willing to use by default in favour of dumb clients.
We've got Java (to difficult for most people - especially for those getting high on Ajax just now), Flash/ActionScript (good but reputation spoiled by same people) and XUL (Firefox/Mozilla only - xulrunner still in the works) but tres cool and a real GUI kit.

So, if you think rich clients are cool, build them in XUL. That's ten bazillion miles ahead of Ajax.

Ajax is nothing but, and I mean absolutely nothing but a marketing hype scheme started by these people. So would you please just ignore it. There are a lot of other much more mature technologies for this that would actually deseve the attention. I mentioned XUL allready, but those countless open source Flash/AS projects out there are also worth a look.

As in: Ook! stops Brainfuck dead in its tracks?

[Qbertino]

I suppose you mean that ever-present universal XAML that all the recent WindowsXP, OS X and GTA San Andreas patches and updates rely on?
Not to mention the upcoming Nintendo GBA Micro that runs a special implementation called Micro-XAML. ...

Ajax-related boards

[jtseng]

Could someone perhaps point me towards a good Ajax-related user forum akin to Javaranch or House of Fusion? Thanks.

I like to know...

[Anonymous Coward]

who the pointed headed bosses are that decide to build software on top of languages like Javascript. People who advocate this kind of thing need to die a slow, painful death. VBA is bad enough.

let me guess...

[namekuseijin]

... it felt a lot like writing a toolkit like GTK from scratch, and then developing the app proper. well, guess what? i'm sure the next time it'll take a lot less time, since now you have a framework already.

nothing prevents some such AJAX frameworks, both commercial and open-source, to become widely available in the days to come...

excellent idea for an unwanted slashdotting.

[Anonymous Coward]

"It'd be much more effective to just grep slashdot's front page for a link to your site whenever you detect a visitor has been refered from slashdot. If there's a match, start blocking connections from everywhere except coral cache and the various automated article mirror sites."

Or you could simply redirect Slashdotters to Goatse.cx and have some fun.

Re:excellent idea for an unwanted slashdotting.

[Gherald]

Thereby offending people instead of attracting them to your site?

Most webmasters /want/ as much traffic as they can handle.

This won't go down well in The Netherlands with...

[mikiN]

who:

- are Feyenoord supporters. [1]
- have AIDS, syphilis or the like. [2]

[1]: Ajax is a major league soccer club.
[2]: In Dutch, having a SOA roughly translates to having an STD.

excellent idea for an unwanted slashdotting-2

[Anonymous Coward]

"Most webmasters /want/ as much traffic as they can handle."

Commercial sites might, but personal sites don't need the big bandwith bill.

Re:excellent idea for an unwanted slashdotting-2

[Gherald]

Um, explain how only alowing coral cache and the slashdot mirror sites would be a big bandwidth bill.

Submitter and the 3rd person

[Anonymous Coward]

Dion Hinchcliffe writes "... Dion Hinchcliffe has a detailed article about how..."

What the fuck?

NO MORE WEB-BASED APPS

[evilviper]

I absolutely hate web-based apps, and can't imagine why ANYONE would WANT more of them.

Imagine if DNS was a web-based app... No automating it. No tying it together with other programs ("the Unix way"). In fact, it would be so incredibly inconvenient as to be borderline useless.

If you have an application you want people to remotely use, make a protocol for it, and let people write NATIVE clients. Not some bloated web browser that is slow, inflexible, unstable, etc.

Re:NO MORE WEB-BASED APPS

[vidarh]

Which is exactly why AJAX is great. A well written AJAX app means proper separation of application logic and userinterface. Personally I prefer to build a REST based interface, and let the web interface use that. That way it's trivially simple to build alternative clients if they like.

Javascript programmers are faggots

[Sebhelyesfarku]

Real men use real language

Ajax? SOA?

[TakaIta]

For Dutch people this is quite misleading. Sounds like some soccer players (Ajax) have caught a Sexually-transmitted infection - abbreviated as SOA in Dutch.

i thought Ajax was a footbal team :))

[Viriatus]

i thought Ajax was a footbal team :))

AJAX is nothing new,

[marbleye]

I am using this 'hidden frame technique' with javascript calls already for quite a while now and 'invented' this when a client needed a way to save data generated with a handheld PDA with barcode-scanner to order new stock.

Since there were no programmers to be found who could manage to write a 'real world application' (.exe) in a limited time, I built the whole thing as a mini-site using javascript to query the numbers in a database via a hidden frame, inputted by the PDA-thingie. It saves the stock ordered to a specially formatted file.
All is running on a local Apache server using PHP for processing data and reading a .dbx file with inventory data.

And for another client I wrote a site-searchengine, which displays results without refreshing the page...

IMHO this AJAX stuff is nice, but very bloated, I'd rather write custom Javascript myself.

For those Getting Started...

[networkGhettoWhore]

There is a great AJAX API/ToolKit for those just getting started. It is the easiest I have used so far in any of my applications.. It is called "AJFORM". I do not remember the URL however.

AJAX is old NeWS, Laszlo is non-toxic AJAX

[SimHacker]

AJAX is a new buzzword for old (but not bad) ideas.

Don't take this as anti-AJAX. That kind of architecture is great, but it's the notion that the new AJAX buzzword describes new ideas that annoys me.

Of course Microsoft has been supporting it since the 90's, but it goes back a lot further than that.

For a long time, I've been evangelizing and more importantly implementing interactive applications that run efficiently over thin wire (dial-up modems, ISDN, early internet before it was fast, etc), which are locally interactive and efficient because there's a programming language on each side of the connection that implements custom application specific protocols and provides immediate feedback without requiring network round trips.

Before he made Java, James Gosling wrote the NeWS Window System.

I did a lot of work with NeWS, as a user interface researcher, commercial product developer, and a gui toolkit engineer for Sun, implementing distributed applications as well as user interface widgets and gui construction tools.

I've programmed NeWS to implement many user interface widgets (pie menus, tabbed windows, terminal emulators, graphics editors), gui toolkits (Suns TNT Open Look Toolkit, Arthur van Hoff's HyperLook user interface construction tool), and applications (UniPress and Gnu Emacs text editor interfaces, Ben Shneiderman's HyperTIES hypermedia browser, PSIBER visual PostScript programming and debugging environment, PizzaTool for customizing and ordering pizza via FAX, a cellular automata lab, a port of Maxis's SimCity), and lots of other stuff.

Now I develop distributed applications with OpenLaszlo, which embodies all the great qualities of AJAX without the horrible compatibility problems and shitty graphics. Macromedia though OpenLaszlo was such a great idea that they made a proprietary knock-off called Flex, for which they charge $12,000 per CPU. The future of Laszlo is secure since it's free software with an open source license, but Flex is in Flux since Adobe is buying Macromedia.

I'm quite happy to have found OpenLaszlo, since it's got all the advantages of NeWS, it runs beautifully and consistently on all platforms, the people developing it really understand what they're doing, and most importantly it's open source. NeWS was a technological success, but a commercial failure, because Sun refused to release it like X11. But OpenLaszlo applications really do run everywhere consistently, support XML standards and rich dynamic graphics vastly superior to anything you can do in DTHML, and they're great fun to develop.

Here's a message I wrote on the news-makers mailing list (a mailing list about NeWS that I started and maintained during the Window System Wars of the 80's), discussing the difference between Adobe's approach to Display PostScript, X11's inherent deficiencies, and Sun's approach to NeWS.

To avoid confusion:

Re:OpenLaszlo is more portable and prettier

[SimHacker]

Flash is installed by default on most browsers. 98% of all browsers already have Flash installed. So the number of people who can't run your application is miniscule, and it's easy for most of them to upgrade for free. No other platform comes close to Flash's ubiquity -- it's more widespread than Java, SVG, UIL, XAML, or anything else on the radar.

The harsh reality of AJAX (besides the obvious fact that it has sucky graphics) is that it's extremely difficult to write code that runs the same in all browsers, and you have to relentlessly test against each different browser on every different platform that you plan to support. Flash has no such problem, because it's identical across all platforms.

The lowest-common-denominator graphics AJAX can support across all browsers are crude and clumsy. Google maps has to bend over backwards and depend on the server to draw a diagonal line with transparent PNGs on Firefox, but it can't use transparent PNGs on Internet Explorer, so it has to use non-standard VML instead. It can't simply do everything in terms of SVG or PNG or VML: it actually has to support BOTH PNG and VML, but can't take advantage of vastly superior SVG since it's not commonly deployed nor well supported! All that rube-goldberg technology, just to draw a stupid line.

AJAX applications require a huge amount of extra work to develop, and even more to maintain, because of the necessity of dealing with evolving browser incompatibilities. And the end result simply isn't worth all the effort, since the lowest-common-denominator graphics and the resulting user interfaces are so crude and limited.

For example, Pie menus should pop up in round and arbitrarily shaped windows, but it's impossible to even draw a circle with DHTML, let alone a spokes and speech bubbles!

AJAX practices must balance on a randomly swerving rasor's edge: the intersection of what works on all browsers at the time of implementation. But all the browsers are constantly evolving in different directions, so today's hacks and kludges you're forced to use to work around bugs in today's various browsers will make your application fragile, complex and hard to maintain, and it will probably break in future browsers. AJAX forces you to artificially limit yourself and refrain from using technologies like SVG, VML and PNG, or else you have to actually implement simple things like diagonal lines with several different technologies at once, sniff the browser, adapt at run-time, and fall back to server side rendering!

Maybe Google has the resources to develop and matintain several different ways of drawing a diagonal line over a map, but most companies and independent developers don't have as much human and computer resources to flush down the toilet on such a simple problem of drawing lines. Flash already solves that problem quite nicely thank you, and it's the most ubiquitous RIA platform that exists today, with open source development tools like OpenLaszlo.

-Don

New buzzword for old ideas

[SimHacker]

Mad Merlin wrote (about incompatible XMLHTTPRequest implementations): "If they have, I haven't encountered it. Besides IE doing it's own thing like usual, every other browser has the same implementation. Unusually enough, in this case, working around IE is pretty simple."

Yes there are many incompatibilities, so the only reason you haven't encountered any incompatibilities, is because you haven't tested your application on every possible browser and operating system, which you have to do in order to be sure your AJAX application will run across any platforms you want to support.

AJAX requires you to test against all browsers, because all browsers are subtly and not-so-subtly different. If you're not doing all that testing, then you have no way of knowing whether or not your AJAX application will really work on other people's browsers, and it probably won't.

You couldn't be more mistaken about the XMLHTTPRequest implementation in Internet Explorer being non-standard. In case you didn't know, XMLHTTPRequest was invented by Microsoft, and Internet Explorer was the first browser to support it. Microsoft's implementation of XMLHTTPRequest defines the interface, and all other browsers are implementations of Microsoft's specification. Better do your homework next time, kiddo.

It's incorrect to say that AJAX is a new idea, and it's also incorrect to say that Microsoft invented the idea. It's been around for a long time, in systems like NeWS, the Network extensible Window System, developed in the 1980's.

It puzzles me why a consulting company like Adaptive Path would want everyone to think that they believe AJAX is a new technology. It sounds like they don't know their history, and haven't been paying attention to networking technology for the past couple of decades, so they were blindsided by a technology that's been around for a long time, and now they want people to think they invented it. Now they're totally overpromising and hyping it, because they lack the experience to know its limitations.

Coming up with a new buzzword for an old idea isn't rocket science, and using the term AJAX makes people sound like newbies to me.

-Don

Re:New buzzword for old ideas

[Mad Merlin]

Yes there are many incompatibilities, so the only reason you haven't encountered any incompatibilities, is because you haven't tested your application on every possible browser and operating system, which you have to do in order to be sure your AJAX application will run across any platforms you want to support.

While not exhaustive, my use of AJAX works properly in Konqueror, Firefox, Opera, Netscape, Safari, and IE across Linux, OS X, Windows, and even a little bit of *BSD. That covers the vast majority of browsers, and it falls back on other methods for browsers without XMLHttpRequest. It didn't require any tinkering beyond the initial workaround for IE either.

You couldn't be more mistaken about the XMLHTTPRequest implementation in Internet Explorer being non-standard. In case you didn't know, XMLHTTPRequest was invented by Microsoft, and Internet Explorer was the first browser to support it. Microsoft's implementation of XMLHTTPRequest defines the interface, and all other browsers are implementations of Microsoft's specification. Better do your homework next time, kiddo.

None of that is news to me, however, if you'll read my original post, you'll understand what I'm talking about. The code snippet I linked to details how to create the initial XMLHttpRequest object in a portable manner, because as per usual, IE does it's own thing, while every other browser has the same interface. After you've got the initial object, yes, they all have the same interface, but not before that. As always, I don't design for IE, I write standards compliant code, and test in Konqueror and Firefox first. After that, I test in IE to make sure it doesn't mangle it too badly, but IE just flat out doesn't support a lot of things (such as position:fixed), so it's a matter of hoping it degrades gracefully in IE.

AJAX requires you to test against all browsers, because all browsers are subtly and not-so-subtly different. If you're not doing all that testing, then you have no way of knowing whether or not your AJAX application will really work on other people's browsers, and it probably won't.

You can say that about any web technology if you implement it for IE first. That shouldn't surprise anyone here. However, that's not true in the vast majority of cases when you disregard IE (to start).

Re:New buzzword for old ideas

[SimHacker]

Look at what you've written -- you just proven my point!

You admit your code doesn't run properly on all browsers, and that you have to write extra code to handle the case of browsers that don't support the features you require. You're telling me that you have to implement certain features at least twice in order to fall back to different methods for different browsers. That is my point exactly!

You say "so it's a matter of hoping it degrades gracefully in IE" -- that's only the most popular browser in the world, and you're "hoping"? You don't sound very sure of yourself that your code will work.

You're disenginuously griping about IE "doing its own thing" while admitting that you do know that Internet Explorer's XMLHTTPRequest object came first, and the other browsers imitated it.

Since you're well aware that IE had it first, you're being deceptive when you imply that there's some sort of standard that IE's failing to implement properly. The XMLHTTPRequest standard is defined by IE, and the other browsers are not imitating it properly. It's 180 degrees the other way around than what you're implying, and you know it.

Stop trying to weasle out of your original statement and twist the facts and to fit your distorted version of reality, when you know you're wrong. There are certainly enough problems with IE that you don't have to make up fictional problems just to make a rhetorical point.

You say you use "standards compliant code", but XMLHTTPRequest is not a W3C standard, it's a Microsoft standard. So you're using a Microsoft standard, and complaining about Microsoft's original implementation being incompatible with a mythical W3C standard that never existed, when it's the other browsers that incorrectly implement the standard defined by Microsoft.

You know you're full of shit, but you'd rather listen to yourself bitch about Microsoft than tell it like it really is.

-Don

Re:New buzzword for old ideas

[Teach]

Goodness. What a vitriolic post. I'm not Mad Merlin, but I think you're not reading his post as clearly as you could be.

You admit your code doesn't run properly on all browsers, and that you have to write extra code to handle the case of browsers that don't support the features you require.

Actually, he said that in creating the XMLHttpRequest object, IE requires a different technique than any of the other browsers. But after that, the code is identical. And further, he codes fallback support for browsers that don't support XMLHttpRequest at all. At least, that's how I read it.

The XMLHTTPRequest standard is defined by IE, and the other browsers are not imitating it properly.

Not quite, but you're very close. The XMLHttpRequest standard is defined by IE, and the other browsers are not imitating it. (period)

IE defined the thing (and we're all glad about this). They implemented it a certain way. If I read Mad Merlin correctly (and I personally have no idea if this is true), every other browser that supports XMLHttpRequest, 1) implements it differently than IE, and 2) implements it the same as each other.

You could interpret this to mean that the others are "doing it wrong". Maybe they're just doing it differently to be dicks. However, since XMLHttpRequest isn't a standard, I think the most logical explanation is that though they like the idea, no one likes Microsoft's (admittedly first) implementation. And further, they agree on the Right Way to Do It, and so they all do it that way.

Anyway, last point:

You say you use "standards compliant code", but XMLHTTPRequest is not a W3C standard, it's a Microsoft standard.

I don't think he's implying that XMLHttpRequest is a W3C standard. In fact, I don't think he's talking about XMLHttpRequest at all when he says "As always, I don't design for IE, I write standards compliant code."

I think he's just saying, "IE is notorious for being non-compliant with standards in general, so I find my life is a lot easier (and better for cross-browser compatibility) if I code to the standard where it exists and code to the majority consensus when browsers do it differently. Finally I check it in IE and try to work around its differences as a final step."

Seems fair enough to me, and not very much like he "knows he's full of shit."

But what do I know?

Re:OpenLaszlo is more portable and prettier

[josepha48]

Its not that difficult to write code that runs in all browsers. Also flash is not installed in 98% of all browser, it CAN be installed in most browsers. IE does not come with flash, that's why Macromedia has a download. Most linux distros have flash as part of the distro, some use the open flash crap that does not work right all the time.

My project requirement, not from me, but management, was NO plugins, NO flash, no Java Applets, period, end of discussion. Since openlaszlo uses flash it is out of the discussion.

Besides it costs me nothing to code in JavaScript, I can do it using notepad or vi. I have to buy a special tool from Macromedia to code flash.

FYI: just because flash is more portable, does not mean it is a better technology. Even if one were to say it is a better technology, it does not mean it will be more likely to be accepted.

Not sure about you, but every computer I have ever used, had to have flash installed manually. Also I have had problems with flash crashing firefox and mozilla, so I removed that plugin.

Lastly, JavaScript is easy to learn. Anyone who knows one programming language can learn JavaScript in a few days. Yes it maybe a little more work to get the JS to work right in IE and Gecko based browsers, but once you learn the differences, its not that hard to code for. 90% of my JS code works in all JS enable browsers, including links (not lynx). Biggest problem I have had is css, not JavaScript.

AJAx's downfal

[brunes69]

We have been using AJAX here for about 1.5 years (yes, before it was called "AJAX" - I still hate that name).

Anyways, the biggest problem with it is not AJAX itself, but the browsers. Both IE and Gecko seem to have huge memory leakage problems when it comes to repainting DOM nodes on the screen.

During normal use, where the whole page unloads each web page, this is not notiecable. But try writing an AJAX application whose page should be able to be open for hours or days. You will see that even dynamically updating 1/4 of the screen with new DOM ndoes every two minutes will cause the browser to consume all available memory on the box within 24 hours.

In IE, this eventually leads to nearly a full windows crash. In Firefox, the browser needs to be totally killed and restarted. Neither is a good thing(tm).

Re:AJAx's downfal

[Tastaturbeschmutzer]

Yes, thats the biggest problem I see with AJAX. I had to tell the users that they should close IE when it's getting slow.

Thats sad, but Firefox seems a bit better to me in this case.

Perhaps M$ have fixed it in IE7?

Re:OpenLaszlo is more portable and prettier

[SimHacker]

I don't know where you've been for the past half decade, but Internet Explorer and most other major browsers and pre-installed operating systems are bundled with Flash, so Flash really is already installed on most browsers, thanks to the fact that it's so commonly bundled and easy to download and upgrade.

There is no other viewer more widely installed than Flash -- not even close. The runner up Acrobat is more than 10% behind Flash's installed base. Why do you think Adobe is buying Macromedia for so much money?

Flash Player Statistics:
Flash: 97.6%, Acrobat: 87.1%, Java: 86.5%, Windows Media Player: 84.3%, Quicktime: 64.1%, Real: 58.9%, Shockwave: 55.4%, Viewpoint: 49.7%, SVG: 12.5%.
Flash Bundling Matrix:
Flash is bundled with Internet Explorer Win, Internet Explorer Mac, Netscape Win and Mac, AOL Win, AOL Mac, Opera, and with MacOS, Mac OS X, and Windows.

Your management is obviously stupid. My condolences. Not an unusual situation, but sad. Maybe you should look for another job.

You're totally wrong in stating that it's not that difficult to write code that runs in all browsers. Have you actually tried, or are you just saying that because you heard other people say it, and it sounds nice to repeat it?

Laszlo enables you to program Flash for free without buying any of Macromedia's tools. The cost of trying to write cross-platform JavaScript that runs in all browsers is your precious time and the quality of your application. There are some things more expensive than money, and you're wasting them if you're trying to use AJAX without being aware of its limitations.

Flash is much more portable than AJAX, and it is much better technology, by far, and it's widely accepted, much more so than any other technology. Flash graphics are much higher quality and more capable than anything that's possible with dynamic HTML, and you know it. Just try to draw a diagonal line in DHTML.

I can't diagnose what your problem is with having to install Flash manually all the time on every computer you've ever used, but I've never heard of anyone else with that problem, so you're probably doing something wrong.

JavaScript is easy to learn as long as you only need to use one version of the language, which is the case with Laszlo. But the subtle and not-so-subtle differences between different JavaScript implementations are extremely difficult to learn, and you waste a huge amount of time finding those differences by accident and then having to test against every browser use a bunch of half-assed debuggers and popup alert statements to diagnose the problems and come up with work-arounds for each browser.

Were you aware that JavaScript in Internet Explorer for the Mac does not support the push, pop, shift and unshift methods on arrays? Instead of a.push(foo), you have to go a[a.length] = foo.

If that's a surprise to you, then you're not qualified to write cross-browser JavaScript code. If you're using Array.push, pop, shift or unshift in your JavaScript code, then it absolutely will not work across all browsers, because it will crash on IE on the Mac, so you are fucked.

So does any of your JavaScript code ever use Array.push? If it does, then you're not writing code that will work in all browsers, and there are probably other incompatibility problems you're not aware of -- you'd better go back and rewrite all your code!

-Don

Array.push, pop, shift and unshift missing

[SimHacker]

By the way, before somebody tries to point out that you can wallpaper over the deficiency of Array's push, pop, shift and unshift methods missing from IE Mac JavaScript, by dynamically defining new compatibility methods in array by going "Array.prototype.push = function (obj) { this[this.length] = a; }":

You should realize that adding a method or any other key to the array prototype breaks "for (key in array) { ... }" so that looping over the keys in ANY ARRAY INSTANCE will return the method names you defined in the prototype as keys (although that behavior also varies between different browsers). So each and every one of your for loops have to get the value, check if it's a function, and ignore it.

Thanks a lot, JavaScript.

If you didn't realize that adding methods to array prototypes fucks up for loops in some browsers, then you're not qualified to program AJAX, because you're grossly underestimating the complexity of writing cross platform lowest denominator JavaScript that runs the same across all browsers.

AJAX evangelists are horribly hyping and outrageously overpromising the technology, strutting around like naked emperors, parading their ignorance of history and JavaScript programming.

-Don

Java Web Start is great, but...

[Trejkaz]

I'm a fan of Java Web Start too. The best thing about it is that it was supposed to break the horrible applet cycle which browsers got into a while back. Netbanks could use a standalone app instead of forcing users to deal with a whole-page applet (sadly, this never happened, and said netbanks still use their shitty applets.)

But actually, in recent days, I've seen people bitch about the size of the JRE download. Add to that the size of the app download itself and you have a problem for people on thin pipes.

AJAX apps might not save bandwidth over the WebStart approach... Overall, you probably still end up using more bandwidth than the guy who downloaded all the code up-front. But the important thing is that you can start using the app now, not in an hour's time.

And AJAX does use a lot less bandwidth than your traditional pull-the-whole-page web application. So it's a reasonably good middle-ground.

Of course, nothing stops you using Java on the client-side as well, to plug some of the holes where the browsers aren't as compatible. JavaScript can call Java and Java can call JavaScript back or manipulate the page DOM itself. :-)

Google maps vs flashearth

[Anonymous Coward]

The cool thing about flashearth is that my computer CPU usage goes to 85% load when the flashearth window is just *open* (Win XP, Flash play 7.0.19). When Google maps is open, there's no measurable extra CPU load. Flash is better, since it doesn't let CPU cycles just go unused.

Can You Tell Us More?

[edjonesva]

***** Hi, I was wondering if you could provide some video clips or screenshots of the AJAX stuff you saw at the MSDN event where they demo'd ASP.net 2.0 for release in November? Or maybe could you tell us more about some of the AJAX features you saw? Thanks. I'm sure alot of readers would be interested in seeing or hearing more about it the new AJAX stuff. *****