Some personal thoughts on the Flex/AJAX Bridge…
Before moving to the Flex project, I ran engineering for the HTML tools division at Macromedia. Back then, we thought a lot about advanced DHTML techniques, including the technique of using XMLHTTPRequest to update portions of a page locally, which has since come to be called AJAX.
As you can see from my posts, I eventually ended up moving to Flex. AJAX is wonderful and has its share of strengths, but I find working with Flex to be more fun for me personally. Flex is a great way to put together richer and more complex front ends. It has a runtime that is consistent across browsers, and an object model that is designed from the ground up to support networked application UIs.
I’m still a big fan of AJAX. I believed in it way back when, and I believe in it now. But Flex can do a lot that would be difficult in AJAX, both visually and in terms of data connectivity.
I’m quite curious to see how people use the two together. I’m convinced that some of the raw building blocks inside of Flash/Flex (e.g., binary sockets) have a lot to add to the AJAX puzzle.
P.S. In my last post, I mistakenly called this the Flex/ActionScript Bridge, which is obviously much less interesting. :-) Thanks to Robert Penner for pointning this out to me.
What do you make of the Ajax Client for FES?
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
Ajax client for FES is also very cool, although I do not have hands on experience with it. It handles data push, synchronization between client and server, etc. For my own projects, I’ve been using FES (with Flex) and it has saved me a lot of headache in data synchronization. It’s great that this will also be avaialble for AJAX apps.
You will indeed need the Flash Player to use the FES Ajax client.
Applications that use Flex compared to similar applications that use AJAX – I.E. Yahoo Maps (Flex) and Google Maps (AJAX), run 10-15 times slower. Developing in Flex may be fun and all, but I sometimes wonder if everyone isn’t too quickly jumping on the Flex bandwagon.
Like I said, there are good reasons to use AJAX and there are good reasons to use Flex, and in fact there are good reasons to use them together.
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.
Cool
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.
I would definitely like to get the visual aspects of Flex out there as well. :-)
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).
I’m going to repeat what I posted on Ben Forta’s blog here and hopefully get a response:
->snipsnip<-
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.
Seems to have cut out the message so here goes again:
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. :)
I’m not sure if you’re just poking fun (there *is* a smiley at the end of your comment…) or are actually disappointed in us. Given that you’ve posted this on both Ben’s and my blog, I’ll try to give as thoughful an answer as I can.
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. :-)