News Stay informed about the latest enterprise technology news and product updates.

Ajax performance issues: Everything old is new again

Issues in Ajax performance can resemble issues encountered in traditional object-oriented development. Developers must understand the ramifications of using JavaScript code and think about how they write every line of code, stresses Bob Buffone, chief architect at Nexaweb.

Bob Buffone was involved with Rich Internet Applications before they were called Rich Internet Applications. For a long time, he has been interested in the performance issues that can challenge the creators of Web applications.

You really need to go back kind of to the basics and think about how you write every line of code, which really is not a bad thing.
Bob Buffone
Chief architectNexaweb

As chief architect at Web client development tool maker Nexaweb Technology, Buffone is often called upon to help customers solve newly emerging Ajax performance issues. He discussed those matters last month at The Ajax Experience conference in Boston.

After listening to Buffone, at least one conclusion that can be made is that some Ajax performance issues are similar to those found in server-side object-oriented development. To avoid pitfalls, developers have to go back to basics, yet again.

Buffone told Ajax Experience attendees that the number of requests and the size of requests required at "startup time" (when the JavaScript of a page is invoked) is important to the ultimate performance of an Ajax application.

Moreover, in his research, Buffone has uncovered some basic JavaScript performance "gotchas" -- few of which are actually surprising. For example, he advises developers that global property access is much slower than local property access. Too, calls to get data or data objects can be extremely slow, and so developers must take care in writing related portions of code.

In general, in using an operator, "it should be very particular to what you want to accomplish," Buffone said. "Simple objects are always faster."

In short, knowing your code, and how it does what it does, is more important than ever. And it can be even more difficult, Buffone chided, in an era in which there is a lot of "cutting and pasting" going on as developers reuse existing JavaScript code.

We spoke with Buffone after his session on performance tuning Ajax applications.

Q: On some level in terms of performance issues for Ajax it seems the "gotchas" are similar to object software issues that predate Ajax. As you have pointed out, simple objects are faster than complex ones. And data access is an issue.
Yes, well you know this is an interesting thing I struggle with all the time. The issues are kind of the same as back in 1996 or 1998 when you had very limited processors and you were trying to do lots of stuff in C++ and MFC or whatever. You would run into the same kind of issues.

The migration to the Web has been such that a lot of people are using JavaScript who aren't familiar with it. They are coming from a different background -- from Java, C# or C++.

And, for example, people coming from Java -- when they first start working in JavaScript -- don't worry about the issues of working with it.

More information on Ajax performance and security
Ten ways to improve testing, performance of Web 2.0 applications  

Helping Ajax developers prevent exploits  

Ajax security: A dynamic approach

But really what is happening as people try to leverage the Web as a platform, is they are really trying to push the envelope of what JavaScript can do and what the browser JavaScript engines can do. So you really need to go back kind of to the basics and think about how you write every line of code, which really is not a bad thing.

I just think the methodology that people have taken is kind of a hack-and-attack mode, not really starting with a structure and understanding the basic concepts.

Q: Even in the early Web days, teams would test out to different browsers, but in some places they got away from that.
I hear all the time about people's Web applications that just don't run or they are going to have to scrub a project, or they have decided they can't run on Internet Explorer 6. Some of the issues are related to the different browsers. The JavaScript engines are different on each browser, and IE 6 is actually pretty bad at performance.

So what ends up happening, and this is a trap everybody falls in, people use FireFox and Opera to develop their applications, and their applications run really great, but most of the world is using IE 6 and IE 7. You have to be really diligent. You have to understand how things run on the different browsers and take a function-by-function look at things.

When I first started -- maybe it was just the environment I came up in -- people were very diligent about looking at the code and doing code reviews and making sure that in each line of each iterator your looping over-stop was constructed in the right way. And that has been lost in the last few years.

Q Well the hardware was getting faster …
Sure. So hardware gets faster and faster and that means you can get sloppier and sloppier and the hardware will make up for it. Now, when you build up all those bad habits, and you throw yourself into a place where you need to be really diligent about doing things a certain way in Ajax and JavaScript, and all your bad habits catch up with you.

Dig Deeper on Software Performance Management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.