I’m not in marketing, but I think the name is not 100% bogus. I like names to tell me what things are used for, not how they work.

The reason we built this library is so that people who are building “AJAX” apps can communicate with Flex in order to enhance and complement their AJAX apps. The way this is accomplished is by creating proxy objects that allow JavaScript to call into the Flex DOM.

I think the “Flex/AJAX Bridge” name clearly communicates the intent of the library. Names like “Flex/DOM Bridge” or “Flex/JavaScript DOM Proxy Library” might be more detailed in how the library works, but less clear in how the libraries should be used.

On the term AJAX:
As everyone knows, the term AJAX has come to be sort of nebulous — people certainly use it for applications that do not use XML, for example.

Be that as it may, people have a general understanding of the word AJAX, which is that it is a way to provide greater interactivity using existing Web technologies.

Anyway, feel free to disagree. But I hope the name doesn’t stop you from checking out the library if it’s of interest to you. :-)

Was there any need to call this a Flex Ajax Bridge? I mean when you actually look at it, it is simply providing you with the ability to control the Flex app via Javascript and thus interact with the DOM.

I don’t mind people jumping on the ol’ flavour of the week term “Ajax” however Ajax is specifically a technique for getting the client to do asynchronous data retrieval.

The manipulation and presentation of the data is done within the DOM via Javascript.

The Bridge provides a bridge between Flex and the DOM NOT Ajax which is, as stated earlier, a technique.

You really need to get the Marketing people out of your labs. Adobe developers should hang their head in shame. :)

So please please please please rename it the Flex DOM Bridge. That is technically what it is.

Now on to Accessibility.

If you are developing a Flex app, most large public sites now have legal accessibility requirements (Ford had to redesign a 100% flash site to provide a text only version).

So what will most businesses have to do? The most likely solution is parellel Flex and JSRS (not Ajax) development. JSRS is compatible with JAWS.

This means your back end CF services will need to be developed in such a way that any RIA interface can be delivered.

My main point in emphasizing the non-visual aspects is to make people aware that there are lots of things that Flash does well that people may not know about; the visual aspects are in your face (by definition).

Thanks for your thoughts and answer :)

I hope Flex (and the Flash Platform) doesn’t get relegated to becoming just an invisible middle tier for DHTML/AJAX Clients e.g. “hidden” flash application thats just handling FES calls, storing data etc etc.

Also hope that Adobe makes a good marketing push for Flex 2 Applications in the more “boring” Enterprise space too (e.g. internally deployed business applications) etc….at the moment with the Flex/ AJAX bridge and the “Web 2.0″ APIs releases, seems like the focus is on the Internet/Consumer Application space.

In terms of performance… I can’t speak to the Yahoo or Google implementations, but remember that Yahoo is based on Flex 1.5, which is much slower than Flex 2.0. (There is a new VM written from scratch that executes bytecode ~10x faster than the old VM).

Ironically, one of the potential use cases for the Flex/Ajax bridge is for performance(!). Because the new VM is so fast, it may make sense to structure your AJAX app so that performance sensitive portions of your application run in the Flash VM.

You will indeed need the Flash Player to use the FES Ajax client.

I can’t see those videos on Labs for some reason but i assume you’ll still need the Flash Player to use the FES Ajax Client?

cheers