Chatting with Eric Pascarello（Ajax in Action coauthor）

This month, Java.sun.com writer Robert Eckstein sits down with Eric Pascarello, co-author of the bestselling AJAX in Action and moderator of the JavaScript and HTML forums at JavaRanch.com, to discuss the future of JavaScript, AJAX, and the Internet in general. Want to learn more about Web 2.0, AJAX, and JavaScript? Read on for all the details.

Eric, you've coauthored a bestselling book on AJAX, which is a significant part of what many people are now calling "Web 2.0." Let's start with that. What exactly is Web 2.0, and how do you see it changing our lives over the next 10 years?

For those that are not sure what Web 2.0 is, I will give you some background before I give you my take on it. Web 2.0 was popularized by O'Reilly Media and MediaLive International back in 2004 for their conferences. It became a buzzword used to explain the new breed of application. These new applications (Google Maps, wikis, Live Polls, etc) are bringing together a slew of technologies that were introduced in the 1997 to 1998 timespan. These technologies have been around for a long time, but their power was not harnessed until lately.

"Web 2.0" has no defined definition or standard. What might be Web 2.0 for one person may not be to another. Some people say it has to use AJAX techniques, while another says it has to be XHTML, and another person says it has to be interactive. A common joke is if you see a web application and it says it is in Beta, then it is Web 2.0.

"Web 2.0 is a new breed of application that breaks the traditional mold of a classic web page experience. [I]t allows the user to interact more closely with the data ..., it gives the user easier access to data..., it gives the user a more connected feeling... it gives the user the ability to interact with the page.... All of these things need to be accomplished without the user having to do extra work..."

- Eric Pascarello,
co-author of AJAX in Action

That being said, I can tell you the answer to my personal definition of Web 2.0. Web 2.0 is a new breed of application that breaks the traditional mold of a classic web page experience. That means it allows the user to interact more closely with the data (Google Maps), it gives the user easier access to data (auto complete fields), it gives the user a more connected feeling (live polling/searching of data), or it gives the user the ability to interact with the page (wikis, comments, polls, etc). All of these things need to be accomplished without the user having to do extra work and (the big one) has to be easy to use and understand.

How does AJAX fall into this whole Web 2.0 talk? AJAX is allowing us to give content to the user in an easier manner without having to post back the page. One basic example that I love to point out to everyone is the simple Double Combo (linked selection elements) powered by AJAX. In a traditional model a double combo would require us to either post back the page to the server or insert all of the possible elements into JavaScript arrays when the page is initially loaded. Now with the XMLHttpRequest object or even iframes, you can take away the page rendering/loading times by doing the request asynchronously in the background.

This will give the user a better experience since they will not have to deal with extra loading times, they will not have to deal with view state problems (scrolling of page, form field values, etc), and they will be connected with real time data from the server. A simple control like this is Web 2.0, since it is making a user's life easier.

The last part of the question is how will this change our lives in the next 10 years? Well when the Internet was first thought up, it was to transfer text. Then images and simple HTML elements were introduced and so on. No one would have imagined that we would be streaming video, paying bills, talking to friends on the other side of the world, and so on. Will we see a true Semantic Web or a Web 3.0? I see the "Internet" as being the center of everything where almost everything will be connected. I will be able to go to my person homepage, see my email, check the news, watch my TV show, and also see if I need to pick up milk since my fridge will be connected in too. Most of this can already be done; it will just be more integrated. Imagine a virus that defrosts your fridge! Just like the famous "640K ought to be enough for anybody" or "Computers in the future may weigh no more than 1.5 tons" quotes from years past, you just can never really tell where we are heading.

Obviously, there's been a resurgence of interest in JavaScript due to AJAX over the past year or so. Is AJAX here to stay? Will it be replaced soon by something flashier? Or is it one of several steps in the direction of a new, totally dynamic Internet?

The thing I always tell people is I never thought that people would be getting paid a lot of money to code JavaScript. Companies cannot get enough JavaScript developers with 10 years of AJAX experience with all of those ad postings online. (Hope you got the joke there!) Put succinctly, the interest in JavaScript has increased since people are realizing its true power. Seasoned server-side developers that use OO techniques always saw poorly written JavaScript examples for form validations, menus, mouse trailers, status bar scrollers, and whatever bad JavaScript effect you can throw in.

With the emergence of AJAX and developers that understand OO, the landscape of JavaScript shifted. People that saw JavaScript as a toy language started to change their minds and more and more people jumped on board. You now have libraries that are properly written and tutorials that are now using OO techniques. You could barely find any of this information three years ago.

Is AJAX here to stay? Well, yes and no. The concept of AJAX methodology of a programming style/technique will be here. Over the next few years what we know about AJAX will become different. Not because it is hype, but because people are getting behind the concept and standardizing it. Will JavaScript 2.0 see light? It has a better chance of happening now since people want a more powerful clientside tool to work with. Moving to JavaScript 2.0 will be more of a power struggle and that is a different story altogether. So you can see that AJAX is the stepping stone of moving JavaScript into a new direction.

Will AJAX get replaced soon? With standardization and seasoned developers working with AJAX, it is definitely here to stay and keep on growing. Remember, AJAX is not dependent on a certain server side technology, so you have Java programming language developers working beside C#, VB.NET, PHP, ColdFusion, PERL, and so on. That is why it is here to stay.

In your book AJAX in Action, you talk up front about the four defining principles of AJAX. Tell us a little about this, as well as the concept of AJAX rich clients. It seems like the pendulum of thin-or-fat clients is always swinging back and forth. What have we learned over the past ten years? Or is there no magic formula that works for everyone?

For those of you that do not have a copy of AJAX in Action in your hands or looked at the table of contents, in Chapter 1, we cover four defining principles of AJAX. These principles try to break the perception of how we see a classic page-based application model. Some people consider this "the pre-Web 2.0 model."

The four principles are:

1. The browser hosts an application, not content
2. The server delivers data, not content
3. User interaction with the application can be fluid and continuous
4. This is real coding and requires discipline

In general, we try to break you of the notion of the classic web page model. Instead of hosting content, it helps to think of the server as a location that simply serves data. In fact, some people have said that a server-side page can now be thought of as a web service that asynchronously spits out data that a client is able to interact with. The important thing to remember is that the interaction does not have to be interrupted.

In other words, we do not have to post back the entire page to check to see if we have a new message. We can send a request to the server and update a single element on the page. Meta-refreshes are now a thing of the past. That is how the user can have a continuous, uninterrupted experience with the web page.

A great example of this is how Gmail autosaves your email drafts for you. How many times have you used an email application in the past and the browser encountered an error, and you closed the wrong window when getting information and lost all of your work? The simple feature of the autosave to the server is saving lots of people from banging their heads and pulling out hair in frustration.

"The one major flaw I see right now in developers is that they do not understand what is behind AJAX and how it actually works. I know people want to see results right away, but it is also important to know what is going on under the hood."

- Eric Pascarello,
co-author of AJAX in Action

When you look at the thin and fat clients you need to really weigh in on what your users expect and, conversely, what it is going to cost them. For example, a simple autocomplete control can save your users a lot of keystrokes and you get more accurate data on the server. It is really easy to want to add user functionality on a page that is going to help you in multiple areas.

However, just because you are using AJAX does not mean you should forget all of the classic principles. The best thing that any developer out there can do is to take one control and make it powered by AJAX. Change a double combo over to AJAX, add an autocomplete control, or add live search functionality. I had one person tell me that she added an autocomplete control to her application, and her boss gave her a bonus for making his life easier. Something that simple can really make a difference.

Tell us a little about the ideal server-side architecture for web applications serving AJAX content.

One thing that a server-side developer needs to know is that the server does not know the difference between a traditional postback to the server or a request made by the XMLHttpRequest object. All of the same rules apply. I think when developers first understand this, they will realize that it is not a big deal. What is different with AJAX is that we are not serving back entire web pages. Instead we are sending back XML and strings. The strings can be plain text, HTML elements, JSON (JavaScript Object Notation)... even Morse code in periods and dashes.

What is scary is that a lot of developers that are new to the server side are not performing the basic rule of validating the data. I have seen examples connecting directly to a database using passed parameters from the client and not checking to see if there was SQL or JavaScript injection. Trust me, there's nothing like starting a Monday morning sipping your coffee at work and finding that your table with 100,000 rows is gone! Explain that to your boss! So, my perfect server-side architecture will make sure that the data is validated as the first step!

When I do my talks at conferences and local user groups, I always get the question: "Should I use XML? After all, isn't that what the X in AJAX stands for?" Well, on the server it really depends on what you, the developer, are comfortable with. Another factor is how the data needs to be handled on the client. If you already have a webservice that is XML, then you should use it, and convert the XML response to the proper display output on the client. However, if you need to send back a simple string, why use XML when you have the responseText on the client?

My rule of thumb in this area is this: do not over-process the data. If you have to iterate through the data on the server in one format, and then iterate through the data again on the client in another format, and it gives you no extra benefit, then you are probably handling your data wrong. My favorite technique is to use the JavaScript String's split() method on the responseText. One line, I have my data in an array ready to be used. No looping required. Same thing applies with JSON. I use eval() and I have my data ready. Don't try to reinvent the wheel.

Will it also carry over to the server-side? Sure. There are already server-side frameworks with AJAX functionality built into them. Companies see that it is important and they do not want to fall behind. I see it giving the developers the benefit of more added features and functionality.

As a JavaScript and Java technology developer, how should I get started with AJAX?

This is a common question I always am asked on JavaRanch.com, my blog, or by email. And the really easy solution is to find a book, website, conference, or user group that talks about the basics of AJAX. The one major flaw I see right now in developers is that they do not understand what is behind AJAX and how it actually works. I know people want to see results right away, but it is also important to know what is going on under the hood.

Let me elaborate: imagine seeing the fastest looking car ever built, with a price tag of a million dollars. It is a dream come true. From the looks of it, it can do everything in your wildest dreams. So you go in debt, sell your house, live under your desk in your cube, and buy the thing. You sit in the leather seats with no air conditioning and no power windows on a hot summer day. You start the car and it starts to purr. You put it in first and floor it and, oh no! You go from 0 to 5 in 60 seconds since, under the hood, it has a slow, weak engine.

That is how I feel when I see people jumping into AJAX without knowing what they are getting into it. In AJAX in Action we give you what you need to build a successful application. You can rip out that little engine and add a real motor to that car. Now you can be a cool-looking driver in a fast car that runs the way it is supposed to.

So, what else should you know? Well, you need to know that you should not use browser detection, but instead you should use object detection. You should also use Object Oriented JavaScript and learn how to make your code reusable. So go pick up a book, find a good web site, and come find me talking at a conference or user group near you. You can always see where I am talking by checking out the calendar.

Thanks, Eric. And best of luck to you in the future.

Thank you.