Adobe Flash is no doubt a favorite tool for a lot of web front-end developers and designers. It is widely supported on a variety of platforms and browsers and features a rich and cohesive set of tools and instruments. Some people even say it is the next evolutionary step of the Web.

Why not then?

Even though Flash is great, it has its drawbacks ( of course, I wouldn’t be writing this blog post otherwise ). Here I am talking about a completely Flash made website, not just small fragments of it.

• It is extremely SEO unfriendly. Although Google stated back in the middle of 2008 that they have improved readability of Flash sites, this still isn’t enough compared to a well-made HTML website.
• There are no links. If you want to send a link to a friend – no dice. If Google actually learns how to crawl such websites, what links is the crawler going to give? There is only one URL in such a site – the domain name. Best case scenario in Google listings would be a single-page website with a lot of heterogeneous information
• The web is all about content over design not vice versa. Traditional technologies today are so good that what people usually do with Flash ( and can’t with other stuff ) is make something which looks more like an art gallery than a website. This is extremely counter-productive for any business – end-users visit a site not to experience eye-candies but to get some content. Just like a fashion review – you need to pay attention to the clothes, not to the models. The focus should stay on the content and not on the decoration. Period.
• Browsers are not really made for that. Yes, you know what I am talking about – when I go to a site and have to wait 7-10 secs just for the Flash to load and then start-up, this makes me a bit nervous. And as I have previously stated on this blog, loading time is crucial for web visitors. Each second can be costly.
• Background music. Well, OK, it may be just me but I hate background music. Yes, I can stop it but I didn’t want it in the first place! I have 10 tabs running right now and I really don’t want some strange music streaming from somewhere without even notifying me. Yes, this is not just a Flash flaw but it looks like it is easy enough for Flash designers to get tempted by this option.
• “Let’s reinvent the web!” Hmmm… this sounds a bit like Microsoft but it is actually Adobe trying to do it. Correct me, if I am wrong, but isn’t “flashy” a bad term for a website? You get crazy, incoherent navigation, strange things popping out of nowhere, all kinds of elements moving, resizing and changing shapes all over the place. Long live vector animation! But wait, where did the visitor go… ?

I am sure you can think of many more reasons not to prefer Flash but these were my top list. These are also not too technical – we could talk about inter-compatibility with other technologies for too long.

Enough ranting already – I will show you some tricks which can make Flash history. Our goal is to create a website which is both visually compelling and SEO-friendly – a simple 5-pager with some help from PHP.

Back to basics

Good ‘ol Javascript. It needs some polishing from a well-known library, of course – otherwise you risk banging your head against the wall for some time. In short, we will use traditional html + css + javascript technology which will help us get some really nice effects. We will then add some nifty AJAX to maintain a good and flowing experience for the user but still making a SEO-friendly site with active links and most importantly – a graceful degradation. If the visitor is using a stone age computer without JS support ( or is simply using some JS blocking browser extension ), they will still be able to get to the content. They won’t experience all the sweetness but they will get what they wanted after all – the content.

Javascript Libraries

You can find tons of them out there. I have personally used PrototypeJS and jQuery but have had a good look at YUI, MooTools and Rico, too. Good things are told about Dojo, but I haven’t really looked into it. Some time ago jQuery was much lighter than PrototypeJS and that made many people switch. Today the difference is not so great as jQuery can get down to ~18k and PrototypeJS to ~20k ( gzipped and minified ) but let’s not forget that PrototypeJS’ effects’ library Scriptaculous ( scriptaculous and effects only – no builder, slider, sound, controls and drag&drop ) add another 15k. So, jQuery turns out to be twice lighter.

So, I chose

jQuery

Go get the most recent version from here. The version I am going t use is 1.3.2  as it is the most recent right now. And some additional plugins – we will talk more about them later but I can recommend Color, Timers and fxQueue. The first one gives you the ability to smoothly change colors ( including background and border ) of elements via animate(). I am taking a minimalistic approach and some may argue that the Color plugin is not that much needed, but if we want some candies, we’ll have to use it. The Timers plugin is not an overkill either – it is a nice wrapper for setTimeout() and setInterval() and does some good garbage collection so that no memory leaks from the browser. You can, of course, use a variety of great plugins from jQuery’s plugins’ repository.

And because this post is getting too long, I will begin with the actual stuff in my next blog entry – stay tuned!

If you have ever tried to develop a robust ajax application, you have probably reached a point where you want the client to be notified about a change on the server in “real time”. The most simple example – you need to create a chat application and want the client to instantly receive new messages upon their arrival on the server. And, if you like me, are not a fan of Flash ( which may be one of your major flaws ) and want to achieve this using only ajax techniques, you have found out that is not that simple.

There is no real channel between the server and the client

In that case you have no real permament connection between the server and the client and there is no real way of “triggering” events or sending data from the server to the client in any traditional way. Moreover, ajax does not support the client “listening” and waiting for a server’s call ( well, that’s a client after all ). You googled for some time, asked some fellow developers and almost all you could find was – “Just use javascript’s (notorious) setTimeout() or setInterval() function to repeatedly poll the server and check whether there is new data for the client”.

Like, for example ( using jQuery ) :

function read(){
  jQuery.ajax( {
    'url'     : 'chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      //if there are new messages - write them on the wall
      if( messages ){
	//write messages to the chat wall
      }
    } );
  }
}
 
setTimeout( function(){ read() }, 2000 );

( I will not show any server-side code examples as they are simple enough – the method being /chat/read/ would just read from the database and return new records. Moreover, what we have here is not what we’re trying to achieve – the example here is for descriptive purposes only. )

Is that what we call highly-responsive, flexible applications, you’d ask? No. This technique has several drawbacks:

• it sends http requests from the client to the server and gets response ( most of the time empty ones ) on every X number of seconds. X usually is a far too small number and that can translate into way too much wasted bandwidth, if we are talking about a high-traffic website and if we need that polling done for multiple actions
• it can eventually make the client hang-up as most modern browsers ( except for Chrome – or at least – what Chrome pleads ) don’t have smart javascript garbage collection and all those requests can be quite costly.
• it is not really highly-responsive – it has a lag of 2 seconds which may be enough to make the users nervous
• this just doesn’t feel like the right way of doing things

Comet

Well, I need to be honest – the Comet technique ( also known as long-polling ) seems like nothing new but I personally was not aware of it’s power till recently ( Eelco pointed it to me ). But you will be amazed how many open- and closed-source projects have no idea that it is out there and do not try to use it. And it is simple – you make a request to the server, it gets it and just… waits. Waits till there is meaningful data to be returned or returns something less useful ( like null ), if the request is about to timeout. On a standard apache configuration that would mean 5 minutes – you can make just one single request on every 5 minutes, not on every 2 seconds ( which a traditional ajax app would do ). That is 150+ times less requests, less bandwidth, less javascript functions’ calls and the application would feel much more responsive.

There is, however, a small side note to mention…

PHP Sessions are not keen on long-polling

And, if you hadn’t read this post, you’d have had some hard time finding this out. It is just that in every normal application, you can be 97% sure you will be using sessions. And in most of the time, you will rely on the built-in php sessions’ handler. So far, so good. But the small problem is that you cannot simultaneously be running different scripts ( or more than one instantiation of a script ) which use one and the same user session ( that, again, was a discovery by Mr. Pagebaker ). PHP will just queue all subsequent requests which try to interact with that session, until the first one has been closed. Well, that is not much of an asynchroneous technique either then. Getting back to our chat application – if you want to long-poll the server and wait for new messages ( what we will call read() ) and simultaneously send new messages to the server ( write() ), the application will not write() until the read() request has finished ( which we have set to 5 mins, if in the worst case there is no new data to be received ) – that is absolutely not what we need.

Frameworks to the rescue

But, as all self-respectful developers, you have adopted a php framework which provides an alternative to the native php sessions’ handler – be it file, database or any other geeky approach. I’d prefer CakePHP where it is simple – just open your /app/config/core.php and find

Configure::write('Session.save', 'php');

change that to

Configure::write('Session.save', 'database');

and uncomment the few lines below that line with respective data.

So, now let’s see what we have:

Our client-side script ( jQuery again ):

function read(){
  jQuery.ajax({
    'url'     : '/chat/read/',
    'cache'   : false,
    'dataType': 'json',
    'success' : function(messages){
      if( messages.length ){
	//write to chat wall
      }
      read();
    }
  });
}

It is important to notice that even though I have not shown the write() function, you should use jQuery’s Ajax Queue Plugin, so that our write requests are kept in good order. That is not needed when we read() as no subsequent read() requests will be fired before the first one has ended.

And, our cakephp chat controller method:

public function read(){
  $lastMessage_id = $this->Session->read('Conversation.lastMessage_id');
  if( $lastMessage_id === null ){
    echo $this->Json->encode( array() );
    $this->Session->write( 'Conversation.lastMessage_id', 0 );
    exit(0);
  }
  $now = time();
  $timeout = 300;
  while(!connection_aborted()){
    $messages = $this->Conversation->read( $lastMessage_id );
    if( !empty( $messages ) ){
      $this->Session->write( 'Conversation.lastMessage_id', $messages[ count( $messages ) - 1]['Message']['id'] );
      echo $this->Json->encode( $messages );
      exit(0);
    }
    elseif( time() > $now + $timeout ){
      echo $this->Json->еncode( array() );
      exit(0);
    }
    sleep(1);
  }
}

In short – we get the last message id from the user session then use it to fetch newer records from the model. If there are none and the user hasn’t left our webpage, we start looking for new messages once again and so on. We also keep track on the time we have spent so far in that iteration – we don’t want an ugly timeout, that is why we just send an empty response, if we have reached a critical level ( $timeout = 300 in that case ).

For simplicity, I do not use views in that example but it is highly recommended that you avoid using the JSON component and use views instead ( who knows, you might need a different format in the future ).

Notice the sleep(1) line – we don’t want our CPU to burn out after a few hours of work, so some time for rest is highly recommended. You may, of course, use smaller intervals but at your own risk.

That is it for now – feel free to comment and thanks for reading