Is Ajax development slowing down?

I was asked an interesting question by a friend the other day. "Is Ajax development slowing down?"

I noticed the same trend; I just did not really think that it was a big issue. It seems that there is a slow down in the amount of information that is coming out on the net. We do not see as many impressive stories on sites like Ajaxian.com, before there would be tons of information on my queue to read to make sure I did not miss anything. Now that queue is getting smaller day by day. You do not see people ranting how bad Ajax is on Slashdot, I always laugh at comments there wondering if they know the difference between a website and an application. (AH different topic, get back on track). I remember when my book got reviewed there along with the others. Oh the laughs!

I see four reasons why there seems to be a slow down with Ajax.

First reason: It is SUMMER in the northern hemisphere! I know I been spending my free time working on my yard. I been power washing my fence, building a pond to relax by with the wireless connection, and cutting my grass (really it is not grass, but a bunch of weeds I act like is grass) instead of sitting in front of the computer coding. (I vowed this summer I would not write a book! I needed to get rid of my geek tan.)

Second reason: Seems like frameworks are maturing and that people are fully developing applications before they release them. Yes we still see betas and versions .000001ABC. Before we used to see an example, click on a button and it would say "Feature not implemented yet since it is in Beta." I would laugh and wonder why it was rushed out unless someone out there needed an ego boost or a new job.

Third reason: Seems like people are focusing on more of the technical issues of Ajax now and not the wow factors. I am seeing more research done on memory leaks, best practices/patterns, and so on. It seems like people are trying to get everything nailed down so we can understand it more on a technical level instead of an inspiration level. (Yeah that wounds corny, but werne’t you inspired when you saw Google Maps or an autocomplete for the first time?) I know I been doing more research projects of my own than actually coding new applications. Personally I have been looking into making sure that the request from the server is what you wanted. I talked about on issue with pop up blockers with responseText way back on my blog here. I have done this talk at the Ajax conferences (the Ajax Experience and AjaxSeminar.) There are other issues such as Norton Internet Security screwing up my code (seeing problems with this with my production code, bosses on my rear end about it) and other 3rd party components. Good old adblocker causing JS errors and my JS client side to server side log keeps catching them. AHHHH…..Off track again….

Fourth reason: The last reason is one I have seen from doing my talks at local user groups in the Washington DC/Baltimore area. It really seems like new developers in the realm of Ajax are taking their time looking at what Ajax has to offer. They are looking at frameworks versus a custom solution. When I first started I saw these people jumping right into the mix, now I see them actually evaluating their options. But I do see the same errors popping up with these users. Message boards and forums I post on see new users with the same questions. So it looks like information out there is still missing. (Or are they the ones jumping in without actually investigating?)

So what is my one line answer to this question?

So is Ajax development slowing down? I say no, I say it is maturing!

Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for building Dynamic Web Pages

Planning an Ajax Boot Camp

Locations to be determined by your input

I have been helping people work with Ajax applications since Ajax has become popular. On all of the forums I post on and the emails I receive, the same mistakes appear over and over again that bring developer's applications to a halt. My goal was to create a course that will teach any serverside developer how to code a maintainable and scalable Ajax solution. A lot of tutorials out there that developers are using are full of bad practices.

Things that developers always do not think of is what is the consequences of not using caching on the client, what happens if I poll the server, what happens with session, and what causes that memory leak? I see people using too much business logic on the client and I see others not using enough. Others are using the XMLHttpRequest object wrong which does not show up under normal use, but get a user with an itchy trigger finger and it is all over. There are tons of things this camp will cover and I plan on posting the course outline in the near future.

The Ajax Boot Camp will be two days full of lectures and hands on programming. Locations of the camps are still currently being determined. If you would like to see us come to your part of the United States, add a comment or send me an email to askEric@pascarello.com. I know people asked me when I am coming to your area to talk; this is your chance to get me there!

Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Building Dynamic Web Pages

"Instance Callback" with JSON?

I have seen a lot of questions lately on message boards and JavaRanch.com forum on how can I keep "OO Style of coding" with "instance callback" when working with a JSON request that we have no control over. A lot of people do not want to just call a funciton that outputs the results of a JSON request like most examples show on the net. Developers want to manipulate it in functions that deal with a sepcific object. With the cross-domain JSON request, we tend to loose this object since we are appending a script tag to the page. Sort of hard to pass a "this" object reference as a string.

So I thought I would show you a basic example of how we can call an external JSON api and have it work the way we want it too. No more loosing our object reference, no more polling for the request, and no more passing hardcoded variable names to these apis.

What I did is create a wonderful object that has an array. I call a function in this object to make a JSON request. I pass in the object, function I want to call when the response comes back, and the URL of the JSON api.

This function appends our passed in object references and callback function to this array. The JSON api calls array when it returns the response. The call() method hooks up the object reference and magically we are back in our OO world of object goodness.

Now what is the flaw in this code. Well when you look at it you can see there can be issues with the way I read the array index than append the value. So if you have a lot of requests fired at the same time, we could get that wonderful mismatch. In most cases this code should be just fine to play with.

You can get the code and see it in action here: http://www.pascarello.com/examples/JsonYahooExample.html
(Remember that the yahoo apis do have a limit so if it stops working, too many people looked at it today!)

Eric Pascarello
Coauthor of Ajax In Action
Moderator of HTML/JavaScript at www.JavaRanch.com
Author of: JavaScript: Your Visual Blueprint for Building Dynamic Web Pages