Implementing Ajax in IE may not be an issue anymore but there are actually additional tweaks you could do to upgrade the performance of Ajax in IE. It all goes back to JavaScript and there are specific coding designs that a developer could change in JavaScript to upgrade JavaScript’s performance in IE.

The first challenge is to prevent constant symbolic look-up. By default, IE is ok in symbolic look-up however; constant IE look-up will eventually push the IE to the brink of slowing down. IE will take more time in rendering the website when it has to constantly look up the symbol’s meaning while being paired to a function. You can easily optimize this by using “var” in status. This is especially applicable when you’re applying a variable in the specific part of the code.

The next challenge is to cache the indicated variables. Caching is a known problem especially in IE when implementing Ajax. The fact that its asynchronunous make it hard for IE to understand that some parts of the Ajax shouldn’t be cached especially the information fetched from the server. In this case, you have to cache the variable since its part of the program that should be cached to ensure the commands are practically rendered. What usually happens in caching is that you slowly build up the variable so that it could be implemented properly.

However, that will take time since IE will have to interpret each build up individually. Instead of getting the information individually, why not get everything at once? After all, the data that you’ll be retrieving aren’t that big that it will require slow build up process. You can do this by using “var” and string the build up together. That will get the required documents altogether without having to cache each part of the document.

When you have cached the variables for IE, the next step is to cache every pointer. This is not complicated but very tiring since each variable will have different. The only challenge here is again, too much caching could lag your IE because of too many information. Using “var” and combining all the elements, you’ll be able to render all function pointers without having to drag IE.

Last but not the least; avoid using “with” in JavaScript especially when you’re planning to us this program in IE. We all use “with” because it has set a new parameter where the variable and other programs they should work with. However, the downside of with doesn’t cover its bad side. When “with” is constantly used in the program, the scope chain is affected and eventually the program will slow down in IE. Although IE will still read “with’ it will practically slow down its function – much like what a symbol does in IE.

To sum it up, always use “var” especially when you’re dealing with variables. After that, make sure that each pointed in the variable is cached to optimize your communication to the server and lastly, forget about “with” as there are other ways of using parameters without dragging IE program down.

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

Posted by MixedSoup | No Comments »

JSON and XML are the two programs that have been lovingly adapted to JavaScript to create Rich Internet Applications. JSON stands for JavaScript Object Notation. Considered as the subset of JavaScript, the “application” has been launched in 1999 and since then it has slowly created a buzz in complimenting JavaScript. XML on the other hand is a mark-up language that could be used in different languages. That mean it can easily adapt to any languages such as JavaScript.

Although these two are great in themselves, there is an ongoing debate on what works best with JavaScript to create RIAs. XML have been around with Ajax since it was conceptualized (that’s why the name Ajax). As a general mark-up tool, it can easily adapt to JavaScript. However, JSON has gathered enough developers to support it that it has now been considered by budding developers.

So what is the difference between JSON and XML? Let’s take a look at the basic facts about them and see what could be used in JavaScript.

Why JSON?

Essentially JSON is built for Data Structuring. When you take a look at it, JSON takes care of the Data Architecture of the Ajax based program. It has been widely accepted because it caters to the general need of Ajax. When you take a look at it, Ajax is a very broad program that needs to be harnessed. JSON is very easy to configure and it generally answers the need of every programmer. Compared to XML, JSON is also shorter to configure. In XML you could go as far as 7000 lines and could only go 75% of the data configuration. However, for JSON you can actually reduce it to a mere 1,500 lines. That’s far easier and controllable. Debugging is also easy and as far as any developer is concerned, a thousand lines could even be manually checked.

Why XML?

As we have noted, XML takes the longer route in developing the specific program. The reason for this is that XML is more concerned with the specifics of the program compared to JSON. Besides XML is a general purpose program so you have to configure it for JavaScript. The great thing about this program is that it gives you more freehand expression in your Application. Some see it as XML’s disadvantage but the way I see it, XML’s longer version of coding is a good thing since its full customization. Security is also better because surprisingly, XML is very simple. Because of its long lines it usually requires an expert developer.

So what now?

My personal take in this debate is that XML and JSON has their own claim to fame. Some are suggesting that JSON is the new XML in relation to Ajax. However, Ajax is one of the highly flawed programs when it comes to security. JSON might be able to answer Ajax based programs in some ways however XML could also answer some of the problems in Ajax especially when you’re talking about security and customization.

Posted by MixedSoup | No Comments »

Today we’ll take a look at two simple Ajax tricks that could enhance your web page.

Trick Number 1: More Ajax calls in a webpage

Every webpage could be loaded with Ajax calls so that there is a possible interactivity. However, if you’re thinking of loaded a webpage with different Ajax calls with more than two, you’re out of luck. Every webpage in almost any browser allows only up to two Ajax calls at the same time. That means you’ll have to work with two calls and that’s it.

However, there’s actually a good work around to this restriction:

Remember that a webpage will only allow two Ajax calls AT THE SAME TIME. That means the third or fourth Ajax call should not load at the same time with other programs. The trick is to delay the loading time of other Ajax calls. You can make the configuration on <body onload=”>. Delay the loading time of an Ajax call by inserting window.setTimeout(”ajaxcall()”, 400);. You may have to specify each call so that each program will have to load. That’s only a minor inconvenience of you’re planning to load more than two calls. Just remember to give your UI enough time to load. Think of Gmail as the program loads in the e-mail and then the contact list. There is a delay so that interaction between two programs is possible. That is also ideal so that programs in the webpage will have better interaction.

Trick Number 2: Dealing with Multiple UpdatePanel

Considering that you already have more than two or three panels that are constantly being refreshed. That means the bandwidth requirement for each webpage is higher and will basically load slower. The reason why some developers wanted to have streaming interactivity is because of the function that they give to the webpage. But sometimes, there is no new information in an UpdatePanel that refreshing it is not worth it. Most developers just go with the idea of having the page refreshed so that new updates will be possible.

But there’s actually a trick where a page doesn’t necessarily refresh based on time but rather on function.

This could be done by changing the UpdateMode property of each UpdatePanel. In the UpdateMode, change the property to “conditional”. That way, the specific UpdatePanel will only change when something new in the specific part of the program will change. There is an additional benefit of doing this. The server will never have a hard time of updating every UpdatePanel.

These are the two configurations that you can easily do to your Ajax based webpage. The challenge is not on the client but actually on the server. Usually the challenge is only at the start of the configuration but once it gets done, everything will just work out according your specifications. The Ajax based webpage is a challenging work and even though it has been more than two years since the hype started, there are still tricks that we still do not know. More to come….

Posted by MixedSoup | No Comments »

Ajax is known to lessen the bandwidth requirement of a webpage so that it could be loaded faster in any computer. As Ajax bases its power on the server and not on the client, the page could easily be loaded as long as they are rendered correctly.

Let me repeat the last part – RENDERED CORRECTLY. As you may have already heard, Ajax is a complicated program and it will take months or years before a developer can truly say he or she knows Ajax. Even though you already know Ajax, it’s still not guaranteed that the program will work fast.

Here are a few tricks that you can do to your coding that may enhance the speed of your program. Note that these tricks would work in major browsers so we don’t need to present two version of the program.

Remember that it all boils down on how you properly code JavaScript. Its quiet a rarity to find a program that’s not working well because of XML so we have to focus on JavaScript to ensure that everything works well and fast.

The first trick is simplifying the relationship of JavaScript to HTTP. Web pages will ultimately have an HTTP to ensure the program is implemented online. But the transition from JavaScript to HTTP maybe a challenge for varying reasons. One of the tricks that you can do for your program is to simplify the script and styles in JS and CSS respectively. That way the program will have to deal with straight information without having to pass through different codes. As much as possible use smaller pictures and simplify the layout. If there’s a possibility that you can use HTTP compression after all of the simplification that will definitely reduce the processing time.

The second trick is to use tools in coding development. But were not talking about the program generator, but were talking about tools that will help determine the bug as we go along. Instead of looking at the program in general after it was finished, why don’t you check the program just as you go along? That way, you can easily rest in checking the finished product. For Ajax, tools such as Fiddler and Ajax View from Microsoft certainly work well in checking your program. These programs could work in IE and Firefox.

However, there are additional programs that you can implement to ensure the codes are rendered simply yet very effective. Among them is Firebug. The program could easily determine the bugs in your program especially on JavaScript. Next is the Web Developer add-on. Simply put, it evaluates the program whether or not it will work. Last but not the least is the DOM Inspector. DOM is a very important aspect of JavaScript especially when communicating with HTTP and render information from the server such as pictures and graphs.

The challenge now is to see how these programs will efficiently work. Remember that IE and Firefox still require something different. Use these tools properly so that optimization could be achieved in IE and Firefox.

Posted by MixedSoup | No Comments »

One of the biggest challenges of any developer is to enable the webpage to all visitors as fast as possible. Unfortunately, our knowledge always precedes our available technology. Although we can create very interactive websites with the ability to watch videos while having to look for information on the webpage itself, it requires advanced technologies that every one cannot afford.

Until today, there are still people who rely on dial-up so that they can access the net. Most of today’s websites are optimized for broadband speed but the broadband speed still needs some work so that people can access the website faster. Although Ajax already uses lesser bandwidth, the fact that we can even make it faster opens up so many possibilities in web development and more information for users.

HTTP Overhead Removal

In loading the webpage, the heading will always be the first one to be rendered in the website. In browser based processes, the server will look for the heading and render them in the website. That does not exempt Ajax for this type of rendering. It is just smart thinking or standard protocol that a webpage will have a HTTP head for proper identification.

However, Ajax should not be able to have a speedy rendering. Ajax has the ability to render parallel information towards the client but with the presence of an HTTP Overhead, the client and the server will only communicate in one way. Removing the overhead and changing it with a simple tag will enable parallel communication.

Building Static Content

Static content in information transfer refers to the ability of either the server or client to stream information faster. This could be done by giving all the information at once instead of rendering the data one by one. This is a problem especially when you are dealing with a lot of information in one request. The program will definitely be crippled if the information is too much. That is why when building static content, developers has to compress the information before they are released to the client.

There are so many compressing programs especially in JavaScript languages that could be used and compressed. In an Ajax based application, the information are usually transferred as CSS which is already a lightweight component. But when the user has the ability in compressing the information more, CSS could load information faster. And when they use the program CSS will render everything in one shot so Ajax should be able to load the information without even refreshing the webpage when the client requests for it.

The key component in optimizing your website is selecting the right compressor for CSS and JavaScript. There are two tools that I know of and use that looks really efficient in this category: gzip and shrinksafe. You might want to check those out if you have a large Ajax based webpage and combine them with the previously mentioned practice for faster loading websites.

Posted by MixedSoup | No Comments »

Here are places it’s useful to use Ajax: (This is a collaborative wiki list – feel free to add your own ideas to it)
1. Form driven interaction.

Forms are slow. Damn slow. Editing a tag (the old way) on a del.icio.us bookmark? Click on the edit link to load the edit bookmark form page, then edit the field and hit submit to wait for the submission to go through, then return to the previous page and scroll down to find the bookmark to see if the tags look right. Ajax? Click on the edit link to instantly start changing tags, click on the submit button to asynchronously send off changes to the tags and quickly see in place what changed, no reloading the entire page.

a. Form driven interaction- Subset:Linked Select Menus.

Imagine a T-Shirt with 3 options; Size, Color, and Style. When tracking inventory for your product, you know you have Large, Red, Polo shirts in stock, but you’re out of Small, Blue, T-Shirts… It is frustrating to the user to pick this combination and then receive an error on the checkout page stating that you are out of stock… and then have to go back to the selection process and reconfigure the item… Using AJAX, you can check the stock of the options as the user picks them and only return or show the items which are in stock.

b. Form driven interaction- Subset: Autosave.

Think of someone writing in Word. Which button do they use the most? Save.

With javascript you can do one better. Not only can you have a save & continue that works just like the del.icio.us forms – you can autosave! Remember to tell the user this, as simply knowing this relaxes quite a lot of people. Properly explained count-down clocks are prefered, for obvious reasons.

2. Deep hierarchical tree navigation.

First of all, applications with deep hierarchical tree navigation are generally a nightmare. Simple flat topologies and search/tagging works very well in most circumstances. But if an application really calls for it, use Javascript to manage the topology ui, and Ajax to lessen the burden on the server by lazy loading deep hierarchy data. For example: it’s way too time consuming to read discussion threads by clicking through and loading completely new pages to see a one line response.

3. Rapid user-to-user communication.

In a message posting application that creates immediate discussions between people, what really sucks is forcing the user to refresh the page over and over to see a reply. Replies should be instant, users shouldn’t have to obsessively refresh. Even Gmail, which improves on the old hotmail/yahoo mail ‘refresh inbox, refresh inbox’ symptom, doesn’t really push Ajax far enough yet in terms of notifying new mail instantly.

4. Voting, Yes/No boxes, Ratings submissions.

It’s really too bad there are no consistent UI cues for Ajax submission, because submitting a vote or a yes/no response is so much less painful when the submission is handled through Ajax. By reducing the time and impact of clicking on things, Ajax applications become a lot more interactive – if it takes a 40 seconds to register a vote, most people would probably pass unless they really care. If it takes 1 second to vote, a much larger percentage of people are likely to vote.

5. Filtering and involved data manipulation.

Applying a filter, sorting by date, sorting by date and name, toggling on and off filters, etc. Any highly interactive data manipulation should really be done in Javascript instead of through a series of server requests. Finding and manipulating a lot of data is hard enough without waiting 30 seconds between each change in views, Ajax can really speed this up.

6. Commonly entered text hints/autocompletion.

Entering the same text phrases or predictable text phrases is something software/javascript can be good at helping out with. It’s very useful in del.icio.us and GMail, for quickly adding tags/email addresses.

7. Long Running Queries/Remote Calls

If a query or a call to a remote webservice is going to take a long time that cannot be avoided, Ajax works well to manage the time a user waits for the call to return. For example, SWiK uses Ajax to fill in results from webservices detailing new projects: a user doesn’t have to wait for Google webservice to return before starting to edit a new project

8. Computationally Expensive Operations

Unfortunately, Javascript has a tendency to be quite slow. Complex math or number crunching just isn’t Javascript’s forte. Additionally, heavy Javascript computation can slow the basic user interface to a crawl. An XMLHTTPRequest call can be helpful here, pushing expensive computations to beefier remote servers.

9. Server Savings

Sometimes, a process users do over and over on a site requires only a small amount of new data to be sent over the wire, but loading entire new pages can be a strain on the servers in bandwidth and resources. Ajax can be used to load pages more efficiently, as seen in various tests. Of course the ease of making new or multiple requests from the server using Ajax also means that it’s easy to overtax server resources as well.

10. Interactive Panning And Moving Over Data

Moving and scanning over large data sets makes it impracticable to pre-load all of the data. Loading the data just ahead and just behind the user gives the appearance of the entire data set being accessible, and helps eliminate loading times. A great example of this is Google Maps’ scrolling tiles system that gives the effect of moving over a map by picking up tiles behind and placing them ahead of the user, filling them with new data requested via Ajax.

Posted by MixedSoup | 1 Comment »

Ajax was able to prove to us that you do not need to refresh the whole webpage just to access single information in one part of the webpage. When efficiently built, an Ajax-based website could easily become a powerful website with interface that was not thought of years ago. Today we see websites that can update itself without even changing the whole webpage.

For example, an Ajax based newsfeed generator will just display the latest news in one part of your page while you enjoy a game or two in another part of the browser. One big example of multi use in a single website is PageFlakes.com. The website is highly efficient that an empty box could even be embedded with an application or a game such as videos from YouTube.com or mini-games that can be embedded in other websites.

But the rendering of these Ajax based websites with standard coding has its disadvantage. Among them is cross browser compatibility. Unfortunately, IE is does not want to go with the easy way of accepting standard codes. We may be able to see this in IE8 but that feat was supposed to be done many years ago.

Going back to coding, the interoperability of the website makes coding even more difficult. If you are developing an application composed of API and mash-ups, you will have a very difficult time developing the website. Considering 80% of the users today are on IE, developing a website is very difficult.

That is where Microformats come in. Using Microformats, you should be able to load a website in different browsers in only one coding. Microformats are basically a technique on how we code an HTML format. To understand this format better here is an example of a standard website rendered as simple HTML:

<div>
<div>David Stern</div>
<div>Been There Inc.</div>
<div>***-***-1234</div>
<a href=”http://sample.com/”> http://sample.com/</a>
</div>

This is what happens when you sprinkle the same code with Microformat markup:

<div class=”vcard”>
<div class=”fn”>David Stern</div>
<div class=”org”> Been There Inc.</div>
<div class=”tel”>***-***-1234</div>
<a class=”url” href=” http://sample.com/”> http://sample.com/</a>
</div>

The above format was build in a known variation of Microformat called HCard which basically connotes that you have a virtual card with all the information that you want to place. Since it is associated with HTML one of the smartest ways of using Microformat is through AHAX, a variation of Ajax that uses HTML.

But that does not mean it can be transported to Ajax. The beauty of Microformat is that it can easily operate on almost any language aside from being compatible to other browser. In this case, this unique mark-up could be applied to a number of APIs.

One classic example is the Google Maps API. Regularly we will be able to integrate the usage of this API and will interact with different browsers. You will notice nothing as a user but developing this function is very difficult. With Microformat, the information stays basically the same. The trick comes from the fact that it uses common formats such as MS Excel’s .csv so that it could be read with different browsers.

Posted by MixedSoup | No Comments »