Hi folks... let me see if I can address some of the questions/issues raised in the first few posts...
First, about Javascript being a difficult to understand language, or being broke differently on various browsers... I suppose it will always come down to a matter of opinion, but I don't myself view Javascript as any more difficult to understand than most other languages out there. I'm doing probably 95% Java development at this point in my life, and I certainly wouldn't say Javascript is any more difficult to understand than is Java. Someone may come along and claim Ruby, or any of 100 other languages is an easier language to grasp, and for them it may be true, but I don't think most people are scared off by Javascript's "complexity" these days :)
About it being broken in various browsers... yes, that's true to a degree. However, over the past maybe 2-3 years, the brwosers have all pretty well implemented ECMA standards, so you won't find a whole lot of issues these days. True enough, some still exist, and of course they tend to bite you hardest on a weekend at 10:30 at night trying to meet a Monday deadline :) I for one don't think calling the situation "horrible" is really fair any more... a few years ago, absolutely yes, I'd agree, but not today. Today its managable, albeit not perfect, if you stick to standards.
On the issue of threads... It's certainly true that some things can be difficult because the language is not inherently threaded, and you certainly won't find things like synchronization, mutexes and critical sections to deal with (for better or worse!). However, because Javascript uses a single processing thread in all implementations I'm aware of, it in fact makes some things easier... you can usually get away with simple locking mechanisms based on variable values and such. Take a look at the source in this chapter of my book for instance... the issue raised about picking up an object can't really happen because of the way the code is implemented. Now, some can argue that it's in a sense making an asynchronous request into a synchronous one, and while not strictly accurate, there's a nugget of truth to that. In the case of this particular project though, it makes sense to do it that way, in other cases it might not.
As for using AJAX being suicide... well, having written a book on AJAX, something would be wrong if I actually agreed with that, right?!? :) I don't think its suicide, at all. In fact, with more RIA's coming online, I'd say its probably more suicidal to ignore it! I don't think there is any question that AJAX, and Javascript in general, can somtimes be tricky. No one should underestimate the expertise needed to do it well! Even beyond the pure implementation details, there are a lot of considerations that go into it, i.e., accessibility, complexity, training, etc. So should you approach with some caution? Yeah, for sure. Then again, I'd give the same advice about Hibernate, Spring, JSF, EJB, and virtually everything else. NEVER make a technology decision because its the hip new kid on the block, and don't just assume something that everyone tells you will make your life easier is going to be easy and smooth from the start!
Diego mentions toolkits, and I think this is an excellent point. There are tons of AJAX/Javascript toolkits and libraries out there to choose from. Some are excellent, some not so much. Unless you have a good reason not to use one, like in this game project for instance where I needed to have full control over things (and also because its specifically written for a book as a learning tool!), I would advise against using "naked" AJAX. Other projects in the book do in fact use various libraries, and in my day job we use libraries as well. I'm not myself a huge fan of GWT, but Echo2 certaily looks very cool, and others are also fantastic (Dojo, DWR, APT, etc). Regardless of that though, the point is that either any of them can save you from a lot of problems associated with AJAX and Javascript, and even putting aside the problems they avoid, they also tend to save you time, and that's a Good Thing(tm).
As Sergey mentions, most of the time, aside from debugging, you don't have to know all the details of HTTP to do web development. Likewise, having to know all the details of XMLHttpRequest is generally not required. There will always be times when that knowledge helps, but generally, it's extra.
That's why something like my own AjaxParts Taglib is a really nice thing IMO... it avoids even having to know Javascript, which probably most other libraries do require, to some degree. Either way though, your not dealing with *all* the details, and that's what ultimately matters.
As I say pretty clearly in my book, AJAX is far from a new concept. I have an app, still in production today, that I wrote in 1998. You hit the initial URL, and you download about 300k of markup, most of it in hidden
s. Then, as you work, certain
s we hidden or shown as appoppriate, and the fields in them populated with data. When the server is needed, the request is sent through a centralized bit of Javascript (it was just one master form that got submitted), and the request is targeted at a hidden frame. The response includes a bit of Javascript that populates the appropriate
, and shows the next one. This is AJAX without XML, or XMLHttpRequest. Of course, I didn't know I was doing anything special at the time or I would have given it a name and been all rich and famous now! ;) To me, it was just an approach that made sense.
That's where we are today, but in a much cleaner and richer form. Don't get hung up on the technology. Don't think as much as what toolkit to use, or what difficulties Javascript might present. Instead, think of AJAX as a paradigm, an approach to developing webapps. The underlying concepts are whats important here, and what ultimately changes the game for many people for the better. It's not a perfect world, I agree, but its getting better all the time, and the basic ideas are what count at the end of the day. For me, those ideas are both good and frankly obvious as how modern web development should be done... it's not even a question for me whether AJAX is good a bad, it's simply a question of how best to go about it.
