Ajax, Flex or Silverlight?

by Martin TylerMarch 30th, 2009

Although Comet is a term originally coined to describe a general technique, the focus has always been on pure JavaScript clients, and the term is often restricted to JavaScript.

Some of the more mature Comet servers also provide APIs in other languages to access the same functionality that the browser JavaScript client can access. These APIs have mainly been for standalone applications using Java and .Net or for testing, but also for other browser technologies such as Flex, and more recently Silverlight.

At Caplin, a number of our customers use our Java client API, for applications and for browser applets. Recently some customers have also used our .Net client API.

Our focus has always been on the browser though and in recent years we have invested a lot of time on our products surrounding the core Comet server, including Caplin Trader, a rich Trading browser front end. Being Ajax, Caplin Trader can host Flex, Silverlight, and Java components. We demonstrate the use of these technologies in Caplin Trader, but as yet do not provide easy to use extension points or APIs. In Caplin Trader all of our standard display components, the business logic, and the layout management are written in JavaScript. Few browser applications are as advanced as this. Maybe some of the web desktop style demos come close, but unlike Caplin Trader, they appear to be technical showcases rather than real world applications.


Despite the buzz around Ajax in many communities, it is still a barrier for some large corporations and we come up against people wanting to write Trading front-ends in Flex. We have both won and lost these battles, and time may tell who was right, but most likely there will not be a clear cut conclusion.

I have thought long and hard about the choice. It is not a straight Ajax versus Flex debate, because we are selling a framework that happens to use Ajax and has lots of pre-built functionality, on both the client and the server-side. Our goal is to make our front end is a lot more customisable and extensible without having to write any JavaScript at all—at the moment some customisation is like this and some requires you to break out the text editor and write some code. This is often the scary part for a customer; the tech team may be unfamiliar with JavaScript development, but have people more attuned to Flex development, or at least with Flex they feel they are using something more akin to the kind of development they are used to. Flex provides a more straightforward development package. It is provided by a single source, Adobe. Some people may be put off by having to pick and choose from a whole host of Ajax libraries and tools.

Flex can give you a fairly instant feel-good factor. It has an Eclipse based GUI builder that makes you think you have achieved something very quickly. Adding any real world functionality to a dumb GUI obviously takes some time though, but often the technology decision has been made by then.

Adobe also provides Comet like abilities through their LiveCycle Data Services product. This can be integrated with the back-end using JMS; again the Developer familiarity bell rings here, but that does not necessarily make it the right tool for the job. It is generic, which can be advantageous, but you will probably be reinventing the wheel.

So why do people choose Flex? Being an Ajax focused Comet site I’d expect a slightly biased view here, but I am interested in what it is people like about Flex. Are there things the Ajax community needs to do to combat some of things mentioned here?


Then we get to Silverlight. Unfortunately Microsoft has not made it as easy for software vendors to create Silverlight APIs from a standalone .Net API as you would hope. I believe Lightstreamer has had a .Net client API for some time, but have only just released a beta of a Silverlight API. I am assuming this was not because the Silverlight API is totally different, but due to the hurdles of the technology.

Silverlight and Flex are both moving targets to a certain extent. Some aspects of Flex require the latest Flash plug-ins that do not have the vast install base of the previous versions. Silverlight 3 will be released sometime this year, and appears to add a lot of new functionality.

How do people in this space view Silverlight? At Caplin, we have not yet had to face off against someone wanting to develop their own Silverlight trading application, but I can see this happening in the not too distant future. I imagine that Silverlight has many of the advantages of Flex, and possibly many more, but will it catch on and will it pose a threat to Ajax?


Flex and Silverlight both provide advantages over Ajax development, or at least perceived advantages. The wealth of Ajax technology out there is both an advantage and a disadvantage, for some the simplicity of going with the single vendor solution is the easy choice. In a large organisation the old adage ‘Nobody ever got fired for buying IBM’ might apply here, I think some development teams are choosing the safe route, which in a lot of cases might not be the best option.

When the choice to build something from scratch is Flex/Silverlight versus Ajax, I can understand why some would go with Flex or Silverlight. However, when the choice is building it yourself with Flex/Silverlight versus using a more complete existing Ajax solution the balance is tipped firmly towards Ajax. This does not just apply to Caplin Trader—there are other Ajax based solutions in all kinds of sectors that offer far more than a programming library.

I have not said much about native Comet support in Flex or Silverlight, as I do not think it is the key factor here. Adobe provides LiveCycle Data Services, Microsoft do not seem to provide anything like this yet—and some other vendors support Flex and/or Silverlight with their Comet servers. Alternatively JavaScript can be used to bridge into these technologies which allows you to mix and match.

22 Responses to “Ajax, Flex or Silverlight?”

  1. Scott Barnes Says:

    Nice read Martin! :)

    I’d be curious to see the types of solutions folks like yourself could build in all 3 and get a better picture of the hurldes one would face? As it’s an extremly difficult conversation to have as all 3 have strengths and weaknesses and comes back to a variety of “other” variables (ie tooling investment, workflow, bug counts etc)..

    Enjoyed the read.

    Scott Barnes
    Rich Platforms Product Manager

  2. Don Moir Says:

    I have focused on real time browser communication for many years now. I used to use a hidden java applet for socket connections and javascript/html for the UI. Using this in the past I was not able to use port 80 because apache uses that port and because of sand box restrictions as it was same domain only.

    Now with Flash, Java 1.6, and SilverLight 2.0 ??, the crossdomain problem goes away. That is no sand box restrictions for communications. This is very important.

    With Flash and Java I can use sockets. If sockets fail I can use HTTP. The provides the best that is possible.

    Here is an example that I am beta testing. All communications go over port 80 regardless if the connection is made with sockets or thru http.



  3. G K Chaitanya Says:

    Hi Martin,

    What is your opinion about using the BlazeDS(or LCDS) for an integrated AJAX/FLex client GUI. Does switching to Comet (Caplin etc) provide any advantage over adobe technologies? Since I am mostly a developer, product delivery is not as important as using the most effecient technologies. Also, which is more preferred for large scale web hosting??


    G K Chaitanya

  4. Martin Tyler Says:

    Since we went down the Ajax route and our own Comet server and other backend components, it is hard to give a fully objective opinion on which is a better technology if you were starting from scratch with each. Obviously from our commercial angle that question doesn’t come up since its our stuff (already built) vs doing it yourself in Ajax/Flex/Silverlight.

    As a technologist I would love it if we had the luxury of time to try building in all three technologies, but the best we can do is keep up to date with the latest developments and try a few proof of concepts. Unfortunately to paint the full picture a proof of concept isn’t that good, as anyone involved in software development knows most of the time and problems come in taking a PoC to production.

    I know people have done or are working on things like this in Flex and Silverlight, but as point solutions rather than products like ours and they do face quite a few hurdles. We have also seen people do it themselves in Ajax and taken a very long time too. As I mentioned in the article I think the decision often comes down to developer bias - we all have it, our preconceived ideas about different technologies, and the fear of the unknown.

    I plan on taking a closer look at BlazeDS/LCDS soon. My hunch is it won’t perform as well as Caplin Liberator since it wasn’t designed for such a focussed purpose. It could be that it is better if you want to integrate it to databases and JMS systems - but in the trading and market data world those systems aren’t as common, so APIs designed more for the job are better suited.

  5. Don Moir Says:

    When planning to support multiple methods such as Flex, Java, SilverLiight etc… In my case it has come down to the UI. The actual server connections and messages are fairly portable. I have done 3 implementations for Flash, C++, and Java and all pretty straight forward. If HTML is used for your UI then as a common denominator you are good to go.

    I have issues with the whole JavaScript/HTML approach. It’s weak and hard for me to believe it is the status-quo. So be it… It’s the most widely supported option.

    I am choosing Flash at this time, because it is the 2nd most widely supported option but I am not limiting myself to it. I can easily use Java or Silverlight based on the need. This need may come in the form of devices such as cell phone etc. So get a common server message base together that is not language dependent that ports easily.

    I have already taken traditional web services out of the loop for communications. That is, I don’t depend on PHP or other services that may need to go thru apache. This just introduces more overhead.

    All my server/client messages are binary although I could easily support XML, I don’t have a desire or need to do that at this time. The binary transport is the most efficient. xmlRequestObject is text only cross-browser. (note FF xmlRequestObject does support binary). JavaScript is not well suited for binary conversion at any rate.

    BlazeDS/LCDS: I have never used either but I have studied the source code. Basically they use AMF objects which are streamed Flash objects. If you want to tie yourself to this format then thats fine. I don’t particular like this idea… laughing at the moment trying to decide what I do like these days… My messages range in size from 3 bytes to 4096 bytes. I can tack these on to an AMF object which adds about 33 bytes at a minimum to each one of my messages. So a 3 byte pulse message becomes a 36 byte pulse message. If you have 10000 open connections, thats an additional 330,000 bytes that need to be sent.

    HTTP connections: Once the HTTP connection is established, the downstream from server is for all intents and purposes, the same as a socket connection. Upstream from client normally incurs the overhead of the HTTP headers which can be anywhere from about 300 to 500 bytes.

    Flex and Java 1.6 support cross-domain socket and HTTP connections. SiverLight 2 supports only HTTP cross-domain connections


  6. Brian Lesser Says:

    The best option will vary by client. A .Net IT shop - especially where systems integration and customizations are done using MS tools - may look at Silverlight first because their long term development and maintenance costs with it may be less. In my own case (I work in a University IT shop), I watched Macromedia struggle to bring out a set of modern UI components that ran well. We did an early experiment with them and went back to HTML (actually we used Dojo). As Flex matured and after the Flex SDK and BlazeDS went open source we had another look. In the end Flex became the most cost effective way for us to build and extend applications in our shop. One problem we face that makes Flex compelling is that many of our ERP-like applications have unwieldy user interfaces that are unlikely to improve quickly. So the context we work in is not just buying a server here or another small application there, but deciding how to cost effectively integrate and customize all the bits and pieces and still provide an effective user experience. I should mention that on the back end we are mostly a Java and Oracle shop. We use Spring a lot and are watching the BlazeDS/Spring integration effort with interest.

    Adobe has an interesting but somewhat fractured and expensive story to tell on the Real-Time Communications side. BlazeDS’s binary protocol (AMF over HTTP) provides excellent performance - something users really appreciate. LiveCycle DataServices is expensive but does provide what you might call real-time record sets (DataServices) which is a powerful tool for building real-time data applications with conflict management. Flash Media Servers’s Remote Shared Objects also provide a nice higher level abstraction for some real-time work. Finally, Adobe has introduced Peer-to-Peer features into Flash (RTMFP) which changes the real-time application game again.
    I imagine Microsoft will do similar things.

    For what it is worth, I think Comet is a fantastic idea and wish all browsers supported it better.

  7. Martin Tyler Says:

    Interesting comments guys. I am actually away at the moment so can’t comment in full, but I would be interested if anyone has any BlazeDS/LCDS experience that can comment on performance with regards to scaling to high numbers (both clients and data rates)

  8. Brian Lesser Says:

    I can only comment on the large dataset part of this where I’ve seen very good performance from the Flex Remoting Gateways (BlazeDS or ColdFusion). DataServices in LCDS is more complicated as it is generally doing more. The BazeDS benchmarks I’ve seen are from James Ward at Adobe:


    It would be interesting to see similar benchmarks against various servers and AJAX libraries for a variety of use cases.

    Don’s comments are interesting. I don’t know that you would need to send your own pulse messages if you were using BlazeDS?? But applications with frequent small messages may preform very differently than applications that have to transfer and keep in sync lots of data.

  9. Don Moir Says:

    Some comet benchmarks from Greg Wilkins:


    With performance testing, you should include connections via sockets, HTTP 1.1, and HTTP 1.0.

    A couple notes about RTMP / AMF:

    You incur the AMF overhead for every message you send, not just a pulse, just using that as an example. BlazeDS has I believe a single byte pulse. Every other message has about 33-40 bytes of header overhead. This is used by flash and not necessarily by you. In my case those are just wasted bytes. In the case where Java or SilverLight was communicating with BlaseDS, it could be that these are not needed as well. An AMF streamed message can contain multiple flash objects so this dilutes the header abit. Really the AMF format is not bad, but you can do the same thing with fewer header bytes. I am nit picking but thats a good thing. You do have the advantage of an established product.

    If using RTMP in Flex/Flash it will attempt to use a socket to port 1935. If this fails it will try HTTP. I don’t think you can use sockets with RTMP to port 80. You can go directly to HTTP as well with RTMPT. I tested some of this using my own server. When using RTMPT and Flash was still trying to connect to my server after I had shut the app down, I just about lost it lol… I think some kind of bug in the Flash IDE. Basically, I just canned the whole AMF thing for my own purposes but this does not mean that BlaseDS/AMF are not useful tools.

  10. Brian Lesser Says:

    Hi Dom,
    When you make an RTMP request Flash will try several ports before failing over to RTMP over HTTP (RTMPT). Here’s the port/protocol sequence:

    1935 RTMP
    443 RTMP
    80 RTMP
    80 RTMPT

    I wrote about it a long time ago here:
    …though the article is seriously out of date and is focused on Flash Media Server… I don’t know how LCDS compares but the request sequence was baked into the player if you didn’t specify a specific port. If you configure FMS correctly you can accept RTMP or RTMPT (or for that matter RTMPe or RTMPs and soon RTMFP) on any of those ports. If you don’t configure the server correctly it might look like rtmp has to have port 1935 but that is not really the case.

    Many people don’t like the timing the Flash player uses and call specific ports in their own timed sequence in order to get a connection faster. They will often try rtmp over ports 80 and 443 first before failing over to rtmpt on port 80.

    It’s been a long time since I experienced Flash refusing to die when I closed a browser window. I used to experience that with audio. You’d close the window and you could still hear streaming audio for a while. It was an alarming experience! As I recall it was an IE/Flash problem. If variances between browsers is a challenge for AJAX library developers it is also true that Adobe has an ongoing challenge making the Flash player work correctly in every version of every browser.

    What I found interesting about Ward’s benchmark was the break down into server execution time, transfer time, parse time, and rendering time. Naturally his focus is on Flex, but I wish there was something similarly detailed that compared other options to Flex/BlazeDS. Binary formats will enjoy advantages in many cases but certainly not in all.

    I imagine the overhead you see may be helpful in some cases but I don’t know the specification well enough. I guess I should go back and really dive into it… One feature that is nice is the way objects can carry type information. For example an object can be tagged as an instance of a class on a server. When it arrives in the Flash player it is automatically instantiated as an object of that class. It’s quite handy.


  11. Brian Lesser Says:

    Sorry to drone on about AMF, but I thought I’d have a look at what the specification says about headers. First I looked at Adobe’s published specification and didn’t find anything useful when I skimmed through it. :-(


    So then I found this:


    It seems to say that headers in an AMF stream can be 12, 8, 4, or 1 byte in length. They provide an example where there are two twelve byte headers and four 1 byte headers in an AMF stream.

    At any rate I don’t really want to spend too much time defending what Macromedia and later Adobe did with AMF or RTMP/T/e/s or even RTMFP. I’m sure they made some design choices that are less than optimal for some use cases. Also there is the split between what is open source and what isn’t and what is free and what other parts of their platform cost. The cost burden used to be especially painful with Macromedia’s initial pricing for the 1.x releases of Flex and the Flash Communications Server. And I think most people acknowledge that bundling the Flex SDK and LCDS was a terrible mistake. But that’s a longer story…

    I was just trying to answer part of Martin’s question about why people choose something like Flex. On that subject I can only speak from my own experience. In a small IT shop with a broad range of applications to support and integrate, with a big commitment to Java and Oracle based applications, and with strong demand for custom applications that often incorporate information from our ERP systems Flex is a cost effective choice. Mileage for others may vary.

  12. Don Moir Says:

    Hi Brian, Thanks for the clarification on connection sequence… For me it did not matter. My testing only included RTMPT to see if I could make use of a NetConnection object client side. It is good to know that you can direct RTMP to port 80 and then RTMPT. The end result for NetConnection object is that it did not buy me anything.

    With AMF there is an initial header that describes the AMF version, the type of response, etc. There are also object headers etc. The initial AMF header is the one I am talking about. This header must be included before any flash object is sent both client side and server side. Flash does this automatic client side. This header is what causes your NetConnection onResponse function to be called and in this header there has to be text like ‘/1/onresponse’ among other things… The initial handshake/connection bytes also seems to be somewhat elaborate. The information described in your link is not the same thing as what I am talking about. It is difficult to find absolute information on this. It took me awhile gathering info here and there and then I ended up studing the BlazeDS source haha… If you want to verify this… setup a simple server then do a NetConnection to server. Use NetConnection.call (”donsRant”,onResponse,bytes); You will see the header I am talking about and ‘donsRant’ will be part of that header.

    In the real world companies need to be cost effective and usually choices are made for economic reasons. When I nit pick bytes etc, it comes from a long history of having to do so with very minimal hardware. Its just me doing what I do lol… Using BlazeDS is not an option for me… I have connections coming from various sources that send messages in other formats so I am choosing the best path for me… but I have left the AMF code in the server :)

  13. Don Moir Says:

    Martin, sorry to go a bit off topic… just sometimes things need to be detailed…

    Just some quick notes:

    o - each and every flash object sent or received must include the header bytes in question

    o - the following is somwhat conjecture: The AMF format is binary. You cannot send AMF binary streams from client to server using xmlHttpRequest cross-browser. In Firefox you can but simply not worth it in JavaScript. BlazeDS also supports XML so that can me used but I don’t know in what capacity and how it all fits in.

  14. Brian Lesser Says:

    Hi Don,
    I assumed that the initial amf/http header that you see is repeated for each object if you are doing simple polling. If you configure BlazeDS for long polling or for streaming I don’t think you will incur that cost for each object or message. On your last point AMF is only a win if you are using the Flash player as part of your application. So projects like Spring or Zend support it in order to support Flex/Flash clients. In the past I’ve heard of people delivering real-time updates to AJAX interfaces via the Flash player and AMF or RTMP but unless you need audio or video I don’t know why you would do that today.

  15. Don Moir Says:

    I see you must be confused a bit from my statement that I only tested RTMPT for the most part. I suppose what I meant to say is that I was only concerned about RTMPT. I did lots of testing with straight RTMP and RTMPT. Either way the AMF headers are there. (not counting HTTP headers of course… that is a given for RTMPT or any HTTP communication) … I am of course not talking about HTTP headers.. But please do not take my word for it… Setup a simple server… do a NetConnection.call … trust me the AMF headers are there and must be… It is the way that flash and blazeDS handshake for every message… In flash client side you never see them… Another thing you can do is take a look at the BlazeDS source code… Lots of digging and looking there… I would not make such statements if I had not been thru the ringer with it…. The AMF headers for petes sake have nothing to do with HTTP long polling or otherwise… lol

    Here’s the BlazeDS source download link:


    Correct that AMF pretty much ties you to Flash… So really that says that BlazeDS is not a very good overall solution..

  16. Brian Lesser Says:

    Hi Don,
    I’m confused. On one hand you are writing about RTMPT and on the other about BlazeDS. But BlazeDS does not support RTMPT. So BlazeDS does not incur the overhead associated with tunneling RTMP over HTTP. BlazeDS only provides AMF over HTTP. You can setup channels for short polling, long polling, or streaming, but you cannot setup an RTMPT channel in BlazeDS. If I can find some time I’ll setup a simple BlazeDS chat and count bytes.
    Yours truly,

  17. Don Moir Says:

    Hi Brian,
    I really don’t want to belabor the point, but lol, I am saying that AMF messages have overhead in the header, not talking about the transport… really I was not trying to make a big deal out of it, but it is there for flash and not you. Now if you want to see this, do what I said in form of a simple server… This will prove it absolutely prove it to you… and this proof is independent of BlazeDS… With BlazeDS you can gleen alot about what is going on… Again nothing to do with RTMPT directly… Setting up BlazeDS is going to take you time… It is far easier to do a simple server as proof as to what I am saying… this all has nothing to do with HTTP… nothing to do with tunneling… nothing to do with long polling… EVERYTHING to do with the AMF format…

    Martin I think you have raised a topic that could best be incapsulated in a book… haha

  18. Brian Lesser Says:

    Hi Don,

    I ran a couple of tests and suspect the results may make you laugh out loud!

    I setup a ColdFusion messaging application following João Fernandes example here:


    It worked fine and uses the bits of BlazeDS that are bundled in ColdFusion.

    Then I went and installed the trial version of a very nice utility called Service Capture:


    It does a great job of showing you what you send and receive over a NetConnection. I’d heard of it before but never got around to trying it. It’s fantastic!

    So then I sent 14 short text messages and waited for the next poll to bring them back to two separate panels (28 messages returned).

    The results are interesting:

    First there is the http header that is returned with each poll:

    HTTP/1.0 200 OK
    Date: Fri, 10 Apr 2009 16:39:23 GMT
    Expires: Sat, 25 Dec 1999 00:00:00 GMT
    Content-Type: application/x-amf
    Content-Length: 1884
    Connection: close
    Cache-Control: no-cache
    Server: JRun Web Server

    Second there is the flex.messaging.messages.CommandMessage that was returned.

    It appears to include a timestamp, headers object, correlationId, messageId, timeToLive, clientId, destination, and operation number, some of which are null. It also includes a body that contains the 28 individual messages that actually contain data.

    In my test each message was contained in the body of the CommandMessage and is an instance of flex.messaging.messages.AsyncMessage. Each message also contains a timestamp, headers object with a gatewayid, correlationId, messageId, timeToLive, clientId, and destination. It also contains a body which has the actual strings in it.

    The text message I was actually receiving was only made up of four characters. 4 times 28 messages is only 112 characters. When you add up the http header and the AMF body you get a total of 2,167 bytes to deliver 112 characters. That’s a lot of overhead for those messages! Of course you could argue that the messages are unrealistically small – even for a chat. So I did a test where I received twenty 40 character messages (800 characters) which took 1780 bytes to deliver.
    Are the header objects I see in Service Capture the 30 or so bytes you mentioned? I don’t know. Service Capture provides a lot of information including the total bytes but I didn’t find a way to break everything down to the byte level using it. And, at this point, I don’t need to in order to get an appreciation for the overall overhead involved with Adobe’s use of AMF3 in BlazeDS and ColdFusion.

    But I still have no idea how much of that overhead could be removed if you were creating your own AMF enabled server and how much is required because that’s what Flash has to have. I’d love to know why every byte is there, how much of it is needed because that’s how Flash serializes data, and the use cases the rest of it is supposed to support. But I have to stop now.

    Cheers and thanks,

  19. Don Moir Says:

    Hi Brian,

    Actually I am crying and laughing… I just identified some more problems with flash that can break millions of sites… you can read it here: http://forums.adobe.com/thread/199162?tstart=0

    Thank you for doing that test. There is nothing you can do about the HTTP headers so that is just a given… That size can range from about 300-500 bytes or more… It depends on proxies, browsers, etc… The headers are independent of AMF.

    Most likely the 30 bytes you see in the Service Capture are the ones I am talking about. This can be 30 to even 50 bytes… Now you can assume this is small compared to the other odd 2000 bytes… Some of this are HTTP header some handshaking… But if you do a straight RTMP connect (not RTMPT) at my server I just see the additional unneeded 30+ bytes… These must be accepted because flash sends them. They must be recieved because Flash expects them. I am looking to support 100,000 plus users and so every byte means something to me…

    The AMF format is not bad… I am not saying that… Although, it is awkward to construct and contains extraneous information that I do not need…

    There is more to this story but I am kind of wasted on it… haha


  20. Brian Lesser Says:

    Since we got into RTMP protocols a little, I thought some of you might be interested in this post:



  21. Paul Brant Says:

    Scott Barnes,

    All 3 and more are available in a single solution called Nirvana ( http://www.my-channels.com).

    Our showcase (http://showcase.my-channels.com/) application demonstrates all 3 working together side by side.

    We have clients developing SilverLight trading applications today.



  22. priyanka Says:

    Ajax as i suggest. i have used in my site http://www.7moneywonder.com only some part.
    click on intraday service in website. this page only designed in ajax

Copyright 2015 Comet Daily, LLC. All Rights Reserved