Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Practical Ajax Projects with Java Technology

samzenpus posted more than 7 years ago | from the more-ajax dept.

98

Simon P. Chappell writes "Is there anyone left in our industry that hasn't heard of Ajax, the ultimate client-side technology for web developers? Like many, I've read several books on it and now I'm even brushing up on JavaScript so that I can try it out. There is, however, an aspect of Ajax that often seems to get lost in the rush to play with the new browser tricks; Ajax enhanced web applications still need to work closely with server-side components. To even up the balance of books that concentrate on the browser end of Ajax, Apress brings us Practical Ajax Projects with Java Technology by Frank W. Zammetti.

This is a book for anyone developing web applications with Java server-side components. It does assume a minimum level of Java ability, but not that you should know any specific frameworks. If you know basic Servlet and JavaServer Page programming, then you'll be fine for working your way through the frameworks presented in the book.

The book is divided into two parts. The first part is just three chapters and covers the principles of programming using Ajax and Java. Chapter one is the "hurrah for Ajax", obligatory examples and brainwashing. A discussion of the "classic web" and its problems leads into examples of the new web and Ajax enhanced websites. Chapter two is an introduction to the technologies behind Ajax for those who may be less familiar with JavaScript, the DOM, XML and parsing XML using JavaScript and Cascading Style Sheets (more usually known by its acronym CSS). Don't expect to learn these technologies from scratch out of this chapter, but if you have some amount of exposure to them, it will remind you of all the bits that you'll need for Ajax. Chapter three then does a similar thing for the server-side Java technologies. Again, if you snoozed through Java classes at school, don't expect this to get you caught up, but it will refresh your memory on the useful pieces.

The second part of the book holds the seven example projects. These are the meat of the book, given that the title promises practical projects and I think that the book pretty much delivers on its promise All seven projects are interesting; six are practical and the last one is just good old fashioned fun. The projects build in terms of size, so the first one is the simplest and the game, coming last is the most complex. The first project is a type-ahead suggestion engine, modeled after Google's Suggest. Next we have an Ajax-based webmail client. Chapter six builds a RSS newsfeed reader (because, as the book says, every Ajax book has to have one). Chapter seven is a photo sharing application, which, while it may not compete with Flickr, is quite usable for its size. Chapter eight is an organizer. Umm, needless to say you'll either love this or ignore it. (What can I say? If I was organized enough to use an organizer, I'd be organized enough not to need it!) Chapter nine brings yet another chat program to the world.

Last, but as the phrase goes, not least, chapter ten is the grand finale of the example projects. As befits the author's fine sense of humor, the final project is a game; Ajax Warrior! This application has graphics designed by a professional graphic artist and looks far above any other example application that I've ever seen.

As soon as I saw that Mr. Zammetti had written a book, I rushed to be the first to volunteer to review it. This will need no explanation to members of the Struts mailing list, but for the rest of you it might help if I explain that he is that wonderful combination of a funny and helpful guy. I knew that anything he wrote was going to be first rate technically and was also going to be written in a light and relaxed style; always a winner in this kind of book.

I liked the fact that Mr. Zammetti covers a number of approaches to writing both the client and server-sides of the applications. For the server-side of a number of the applications, he uses plain JavaServer Pages, yet for others he uses industry-leading frameworks including WebWork and Struts. On the client-side he continues to mix it up, with some applications using "naked" Ajax, others using DWR, AjaxTags from Java Web Parts, DWR, Dojo, JSON and Prototype.

One more thing to like about the book is that the applications actually look very nice and quite professional. Perhaps the folks at 37signals shouldn't be nervous, but Mr. Zammetti has certainly raised the bar for the appearance of example applications for books.

The flip side of the use of multiple frameworks and Ajax libraries is that all of the breadth means reduced depth. Each of the frameworks and libraries is introduced and demonstrated, but then just as it begins to get interesting, it's off to the next one. If you're looking for more depth in each introduced item, then this book may not be for you.

In conclusion, this is a useful and practical book for those wishing to write web applications that combine Ajax front-ends with Java technology on the server-side. Strongly recommended.


You can purchase Practical Ajax Projects with Java Technology from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

98 comments

Sorry! There are no comments related to the filter you selected.

If you plan to use lots of Ajax (4, Insightful)

CastrTroy (595695) | more than 7 years ago | (#16550688)

If you plan to use lots of Ajax, it's probably better to build your own framework rather than using 3 different ones so that you have all the functionality you need. There really isn't all that much to AJAX, and it's not to hard to build your own framework to support all the features you need.

I'm not impressed by Ajax (2, Funny)

Channard (693317) | more than 7 years ago | (#16550918)

I mean, it and its crew sure as hell couldn't stop Flash Gordon, and it did for the Emperor Ming. I for one don't want to be writing code only to be be speared by some giant spaceship coming through my back wall.

Re:I'm not impressed by Ajax (0)

Anonymous Coward | more than 7 years ago | (#16552040)

I for one don't want to be writing code only to be be speared by some giant spaceship coming through my back wall.

True, tho I hear Mac users are that way inclined.

Re:I'm not impressed by Ajax (1)

fzammett (255288) | more than 7 years ago | (#16552152)

A man after my own heart! :)

Re:I'm not impressed by Ajax (1)

tootlemonde (579170) | more than 7 years ago | (#16553018)

The poster is referring, of course, to War Rocket Ajax, in the 1980 movie [imdb.com] version of Flash Gordon.

Guard: General Kala, Flash Gordon approaching.

Kala: What do you mean, "Flash Gordon approaching?"

Guard: On a Hawkman rocket cycle. Shall I inform His Majesty?

Kala: Imbicle! The emporer would shoot you, for interrupting his wedding with this news.

Fire when Gordon's in range.

(City defences fire on Flash, until he turns around.)

Kala: He's escaping, idiot! Dispatch War Rocket Ajax! To bring back his body!

And later on:

Guard: Rocket Ajax returning.

Kala: With Gordon's body?

Guard: I presume so. Communications are off for some reason.

Kala: Are they in the proper approach pattern for today?

Guard: Negative. They are not.

Kala: Open fire.

Guard: On Ajax General??

Kala: OPEN FIRE! All weapons! Now!! Charge the lightning field. I take personal responsibility, in the emperor's name.

-- The Quotes [guntner.com]

Re:If you plan to use lots of Ajax (5, Informative)

jgertzen (975712) | more than 7 years ago | (#16553090)

DISCLAIMER:I am the lead architect of the ThinWire RIA Ajax framework, therefore proceed with your filters on if you wish ;-)

I think you have that backwards. For anything but the most trivial of Ajax programming, you should use an existing framework. Trivial examples fall into what the Gartner group classifies as "Ajax Snippets" http://www.adtmag.com/article.aspx?id=17953 [adtmag.com] , which are simply quick hacks onto an existing web applications. And really, if you're adding a lot of snippets to your existing web application you should still use something like Prototype http://prototype.conio.net/ [conio.net] .

Sure, the basics of XMLHttpRequest (XHR) are straight forward and can be mastered by anyone. And sure, you can hack the DOM or DHTML old school style... but you really should ask yourself one question... why? There are so many good Ajax toolkits and frameworks that you really shouldn't concern yourself with low-level stuff like that. Additionally, truely rich internet applications (RIA) require a lot more than just basic snippets. I'm not a big fan of Gartner one way or another, but I do find thier classification levels helpful. For those who aren't familiar with them, here they are:
  1. Snippets - Enhancing existing web applications (Slashdot; other tech site that I shall not mention)
  2. Widgets - Snippets + UI Components such as Tree & Grid (IBM Online Help; Yahoo UI Widgets; Backbase)
  3. Specialized Framework - Single purpose, mostly client-side logic (Gmail; Google Maps; Yahoo Mail, Tibco GI)
  4. RIA Framework - General purpose, tightly coupled client & server side architecture (ThinWire http://www.thinwire.com/ [thinwire.com] , Echo2)
IMHO, category 1 & 2 should be used for enhancing existing applications that cannot be replaced outright. Category 3 should be reserved for those building a consumer portal that must have a totally unique look & feel, and even in that case using something lightweight like prototype should be your starting point. And category 4 frameworks should be used for all new enterprise application development.

Check out the following to get a feel of what an RIA application is like: -Josh <G>

Re:If you plan to use lots of Ajax (1)

CastrTroy (595695) | more than 7 years ago | (#16554330)

Using frameworks that don't let you hack down at HTML,CSS and JavaScript level to me seems like it will end up working like MS's ASP.Net. Drag a bunch of controls on a page, and everything is supposed to work fine. Until it doesn't. I think that using frameworks that give you most of the functionalilty that most people need, however, like I said, if you're planning on either doing a large number of projects or using a lot of AJAX in a large project, that it's better to have something that you know you can modify easily. When people tell me that I shouldn't concern myself with low level stuff, I ask, what happens when I have to? Having a framework that you control from the top to the bottom makes doing things at the bottom a lot easier. However This isn't a good solution for everybody, but it is an option to consider. If you are only using a little bit if AJAX, it can also help to build your own, because it can be small and do exactly what you need it to do, without being overly confusing.

Re:If you plan to use lots of Ajax (1)

lewp (95638) | more than 7 years ago | (#16560804)

Something like Prototype gets a load of testing and bug fixing beyond what you could ever hope to do in your own framework. With the subtle undocumented differences in behavior between the various popular and not-so-popular browsers, this is an important thing.

Personally, I don't like the frameworks that attempt to emulate desktop GUI toolkits with JavaScript widgets and such, but I do think that starting from scratch rather than using a nice library basically amounts to asking for a series of long and painful bugfixing sessions you could have easily avoided had you not been so stubborn.

Since I started using Prototype and Behaviour [bennolan.com] , I've found that my code works a whole lot more often across a whole lot more browsers. It's shorter, better looking, easier to read, and easier to maintain as well.

Re:If you plan to use lots of Ajax (1)

darkchubs (814225) | more than 7 years ago | (#16554334)

Im a convert..

Re:If you plan to use lots of Ajax (1)

Silverstrike (170889) | more than 7 years ago | (#16560978)

I dunno, your framework doesn't look like it scales too well ;-)

Links are DOA.

Re:If you plan to use lots of Ajax (1)

roman_mir (125474) | more than 7 years ago | (#16554612)

That's right. [slashdot.org]

Ultimate?? (4, Insightful)

Reality Master 101 (179095) | more than 7 years ago | (#16550818)

...the ultimate client-side technology for web developers?

Er, I like some of the results that people have made from AJAX, but to call it anything like the "ultimate client-side technology" is utterly bizarre and casts extreme doubt on the reviewer's credentials to review anything computer-related. I think it's safe to say that everyone that has studied AJAX has one overwhelming common opinion:

"For the LOVE OF GOD! Why the hell in the year 2006 do we need to write anything in this godawful buggy language? There HAS to be a better solution. THERE HAS TO BE! STFU, there HAS to be! Please, GOD, there must be!! [breaks down in tears]"

If AJAX is the "ultimate", then we might as well all take the poison kool-aid, because human civilization is an abject failure.

Hear! Hear (0, Offtopic)

Mateo_LeFou (859634) | more than 7 years ago | (#16550902)

hehe... that happened to me this morning. Did you know that javascript will go ahead and add a closing select tag for you when you use e.g. targetdiv.innerHTML += 'select name=whatev'

At least I think that's what was happening. Instead I did
str += 'select name=whatev'
then put all the options in, then did

innerHTML = str;

(If anyone can show me what I was doing wrong -- other than writing an AJAX app -- I'd appreciate it)

Re:Hear! Hear (1)

ShadowC_ar (1017138) | more than 7 years ago | (#16550964)

Not using DOM compatible functions perhaps?

Re:Hear! Hear (0)

Anonymous Coward | more than 7 years ago | (#16551028)

You used innerHTML...

You should have done something like

var selection = document.createElement("select");
selection.options[selection.options.length] = new Option("Name", 'Value');
.
.
targetDiv.appendChild(selection);

Re:Hear! Hear (2, Informative)

AKAImBatman (238306) | more than 7 years ago | (#16551216)

Did you know that javascript will go ahead and add a closing select tag for you

What were you expecting it to do? Once you give the HTML to the browser, it attempts to parse it, add it to the DOM, and render it. It can't do that if you've still got open tags. So it assumes that you forgot to close your tag, and closes it. The exact same thing would happen if you accessed the DOM through Java, C/C++, or any other language.

This just goes to show the problems with the innerHTML psuedo-standard. People think that HTML consists of a bunch of strings, when it's actually a complete Object model that we are able to store serialized versions of. While innerHTML can be convenient for even the experts, it's going to do strange things if you don't understand what you're doing.

If you didn't understand a word of that, then I recommend that you visit your friendly standards organization [w3c.org] and start reading. Until you understand exactly what you're doing, you are in an unfit state to program DHTML constructs. Trust me, you WILL regret it later if you don't get the basics down NOW.

Since someone else posted the proper DOM answer to your issue, here's the innerHTML answer:
var code = '<select name="whatever">';
 
for(var i=0; i<myoptions.length; i++)
{
//Tailor for your code
    code += '<option name="option'+i+'">'+myoptions[i]+'</option>';
}
 
//As of right here, "code" is still a String object.
 
//Here we add it into our DIV. The browser will parse the HTML, and create a renderable object model out of it.
mydiv.innerHTML += code;

Re:Hear! Hear (1)

AKAImBatman (238306) | more than 7 years ago | (#16551298)

Ack. I made a bug! (Yet another reason why innerHTML is evil.) Just below the "//As of right here..." should be the following line:
code += "</select>";
The code in my post above will probably work, but closing the tag ensures that you don't accidently add something into the middle of your "select" when you go to modify your code.

Re:Hear! Hear (1)

Achoi77 (669484) | more than 7 years ago | (#16551482)

Heh, I thought you were just trying to emphasize your arguement on the "javascript will close the tags for you" thing. I was gonna comment on it joking about not adding in a closing tag but I was afraid of being downmodded for not being clever enough to catch that.

Re:Hear! Hear (1)

AKAImBatman (238306) | more than 7 years ago | (#16551748)

Heh. Yeah, I was just a liiiitle too quick with the submit button. ;)

Re:Hear! Hear (1)

Heembo (916647) | more than 7 years ago | (#16551518)

Screw the DOM functions - they have not been very browser compatible, traditionally.

var htmlText = '';
for(var i=0; i {
htmlText += ''+myoptions[i]+'';
}
htmlText = '';
mydiv.innerHTML += code;

Re:Hear! Hear (1)

AKAImBatman (238306) | more than 7 years ago | (#16551662)

for(var i=0; i {
htmlText += ''+myoptions[i]+'';
}

Seems someone forgot the <ecode> tag...

mydiv.innerHTML += code;

Funny, this code looks a LOT like the example I posted above you. Especially since you appear to have forgotten to change this line. :-/

Screw the DOM functions - they have not been very browser compatible, traditionally.

The basic DOM functions are about as browser compatible as you can get. It's the DOM0 and IE specific stuff that you'll get in trouble for.

Re:Hear! Hear (1)

Doctor Memory (6336) | more than 7 years ago | (#16552388)

The basic DOM functions are about as browser compatible as you can get. It's the DOM0 and IE specific stuff that you'll get in trouble for.

Heh, for me it was the other way around. I wrote some JS to screen-scrape a page couldn't figure out why var fld = document.getElementsByTagName("input")["somefield" ]; wasn't working on IE. Then I read the spec and found that Moz/FF actually enhanced GEBTN() to return a node list indexable by a string, whereas IE stuck to the standard and just returned an integer-index-only node list.

Re:Ultimate?? (0)

Anonymous Coward | more than 7 years ago | (#16550904)

atlas! I'm serious!

Re:Ultimate?? (1)

dgan (867727) | more than 7 years ago | (#16551014)

Its actually a very good technology and you don't have to re-write everything and unlike what most people think, you don't need RPC or to write Javascript. And of course, it all depends on how you use it. Good engineering practice always wins in the end.

Check this out:

http://www.bzbyte.com/a/shop/EZAjaxDescription.jsp [bzbyte.com]

Ultimate??-Aspirin. (0)

Anonymous Coward | more than 7 years ago | (#16551288)

"Its actually a very good technology and you don't have to re-write everything and unlike what most people think, you don't need RPC or to write Javascript. And of course, it all depends on how you use it. Good engineering practice always wins in the end."

Are you sure? Because Slashdot always tells me to hate anything buzzwordy and AJAX is it. So now I'm totally torn. Believe slashdot? Or not believe slashdot. I think I'll go lie down. I have a headache.

Re:Ultimate?? (1)

pherthyl (445706) | more than 7 years ago | (#16551546)

Well I checked it out, and it absolutely sucks. You're trying to get an interactive framework where every request has to do a roundtrip to the server. That's completely backwards, and it shows. Try the demo and see how laggy everything is. Sure it's nice you don't have to rely on the browser's buggy javascript implementation, but the lag associated with this approach is unacceptable. It's funny how they state that not having to rely on user's possibly slow machines is an advantage of their approach. Never mind that any reasonable machine (ie, built in the last 10 years) will be far faster than the network latency involved in doing it their way.

Re:Ultimate?? (0)

Anonymous Coward | more than 7 years ago | (#16553172)

True, there is actually many ways to avoid a round trip to the server, and also in this framework. However most ajax applications must constantly go to the server for each operation because that is where the reall business gets done. The more client based (javascript) the app, the harder to write, debug, and more easy it is to hack.

What's the use of a client side javascript application if it takes 5 years to implement and impossible to maintain and debug.

Re:Ultimate?? (1)

Pseudonym (62607) | more than 7 years ago | (#16553828)

If you look up "ultimate" in the dictionary, you'll see it actually means "final" [oed.com] . Since there will clearly never, ever be another client-side application platform ever again, "ultimate" seems appropriate.

What are you looking at me like that for?

OK, OK. AJAX is the penultimate client-side platform. Happy now?

GWT / Echo? (0)

Anonymous Coward | more than 7 years ago | (#16550938)

How come popular frameworks like GWT and Echo is left out without mentioning in this book. GWT is writing code in Java and integrating with Java server side (servlet) technologies and similarly echo with a little bit different approach. -Rafiq http://www.ajaxtoday.com/ [ajaxtoday.com]

Re:GWT / Echo? (2, Interesting)

borkus (179118) | more than 7 years ago | (#16551438)

I've just started cracking a few books on AJAX and I think this book avoided the libraries you mentioned for a couple of reasons.

*The book's goal is to teach you how AJAX actually works through coding JavaScript and JAVA in a sampleproject. GWT (I'm not real familiar with ECHO) very much abstracts what's going on at the browser level. In short, you could make AJAX apps with GWT, but you wouldn't really learn how AJAX apps function. For the purposes of illustratring how AJAX works, the libraries in something like Dojo work better.

*There is a surfeit of libraries and tools for AJAX. I've seen plenty of books that just catalog libraries; unfortunately, that broad coverage tends to keep you from using the technology in depth. If anything, until you start using one set of tools, you never really know what best suits your needs. It seems like it doesn't focus on just one toolkit anyway.

In short, the books gives you exposure to a few different libraries as you work through the projects so you can make a more informed choice later when looking at tools like GWT.

Re:GWT / Echo? (1)

fzammett (255288) | more than 7 years ago | (#16552252)

Actually, this book avoided those libraries for one simple reason: they weren't out there (or at least well-known) when the book was being written... GWT in particular only came onto the scene right near the end of the writing process... echo may have been around before then, but it wasn't high on the search results lists, and hence the author skipped it (actually, like GWT, he only really became aware of echo near the end of writing the book)

I know this because I have an "in" with the guy, so to speak ;)

Re:GWT / Echo? (2, Interesting)

nate nice (672391) | more than 7 years ago | (#16551806)

Mainly because GWT and Echo are way too advanced for a book such as this.

Why just tell people they could use these amazing toolkit paragdims when you can sell them a book explaining how the pipes run?

GWT and Echo and related technologies are really great. I like GWT more because of it putting everything client related on the client side. I see this as the future of Web programming and we will see more and better tools to facilitate this. One being better program caching with checksums and client/server versioning to allow for download once, run every time Websites in the EOC (Everything On Client) model.

AJAX problems (0)

Salvance (1014001) | more than 7 years ago | (#16551022)

One of the most often overlooked issues with AJAX is the huge bandwidth that most AJAX implementations consume. Everyone is out rushing to build AJAX apps into even the simplest applications, and the result is slow loading time and greatly increased server loads. These enhancements often don't enhance the user experience any more than adding an extra cupholder or pinstripe add to the functionality of a car.

Many small to medium sized companies host on shared servers and think "Oh, I have 1TB of transfer, so I can build really cool AJAX apps and watch the customers flock to my site", and then wonder why their site can't handle more than a few concurrent users. The developers implementing AJAX apps need to consider the server-side infrastructure, and often ignore this (or are forced to ignore this by their managers) simply to have "pretty sites".

The site that I help work on found this out the hard way. We tried using a simple AJAX enabled 'send to a friend' form. It looked GREAT, but kept causing our server to hit its allotted CPU max. Since we removed this feature, we've had a 10-fold increase in traffic (not as a result), but have never come close to reaching the CPU max. Sure, it could have been a poorly written AJAX app, but I think it's almost undeniable that a static html + php site is far better suited for performance when a company has limited bandwidth/CPU.

Re:AJAX problems (1, Funny)

Anonymous Coward | more than 7 years ago | (#16551098)

Wow, what's it like to have absolutely no idea what you're talking about?

Re:AJAX problems (0)

Anonymous Coward | more than 7 years ago | (#16551490)

mod parent up :) no, seriously.

Re:AJAX problems (0)

Anonymous Coward | more than 7 years ago | (#16552860)

I once added to much AJAX to a solution and all the tables turned green.

Re:AJAX problems (0)

Anonymous Coward | more than 7 years ago | (#16552970)

Sorry, I brained my damage - "too much".

Re:AJAX problems (3, Insightful)

thelifter (1017186) | more than 7 years ago | (#16551236)

If you're maxing out CPU, you have problems bigger than the use of ajax. Ajax usually results in using the same bandwidth differently. You make more server requests than a traditional app, but the requests exchange smaller amounts of data. It's possible to misuse any technology and blame the technology for your own incompetence. Sounds like you've achieved the latter.

Re:AJAX problems (0)

Anonymous Coward | more than 7 years ago | (#16553156)

Maybe that's the nonsense that the authors of books about AJAX tell you. From my real-world experience, I can tell you that they're full of ass shit.

We recently considered switching our existing internal Web-based email system to an AJAX-based system. As part of our trials, we set up three of our test servers (identical to the ones we currently have in production) each running one of three commercial AJAX-based email systems we were going to try.

I must say, our existing CGI-based solution worked far better. It used only a fraction of CPU time (both client-side and server-side) that the AJAX-based systems required. The memory usage of the AJAX-based systems shot through the roof. We had to toss 16 GB of RAM into one of the test servers in order to obtain the same level of performance as our existing CGI-based system, which does just fine with 1 GB.

The users within the office were not happy with the AJAX solutions. These non-technical users reported the AJAX systems as feeling far too slow. Some even reported browser lockups. And this was the case for all three products we tried!

Maybe the developers of these AJAX systems were fools. But I'd have to guess that they're not. All three products, as different as they were, exhibited the same types of problems. We've used non-AJAX products from them in the past that have worked just fine.

Considering how so many developers are having problems getting AJAX to perform sufficiently well, I'd think it's not a problem with the developers, but rather the pathetic technology they're struggling to get functional. AJAX is the problem, not the developers.

superstitious (2, Insightful)

Bill Dog (726542) | more than 7 years ago | (#16556354)

AJAX is not some magical voodoo that is somehow uniquely capable of bringing down a web server. All it is is a means for doing an HTTP request, just like for a web page, in the background, without re-requesting and re-rendering the whole page. That's it. Just HTTP requests to a web server.

If you want to use it to make a web page that hits the server on every mouse click, you can. That's your business. But you could also code it up the traditional, non-AJAX way, to also hit the web server on every mouse click. AJAX is no more the problem than submitting forms is.

I must say, our existing CGI-based solution worked far better.

That's not an alternative to AJAX. I'm building an AJAX app that is serviced via CGI. CGI is just a way to respond to a web request. Whether a form post, a get request, or an AJAX request. It sounds like you don't really know what you're talking about.

Re:AJAX problems (1)

ollywompus (599105) | more than 7 years ago | (#16551380)

"One of the most often overlooked issues with AJAX is the huge bandwidth that most AJAX implementations consume. Everyone is out rushing to build AJAX apps into even the simplest applications, and the result is slow loading time and greatly increased server loads." THANK YOU for recognizing this. As someone who couldn't code their way out of a BASIC 101 class, I'm the last to comment on any of the technical aspects of AJAX development. But I do have to wonder why more people who DO code AJAX apps aren't paying attention to the person that really matters in this case: the end user. Case in point: Yahoo Maps, the old non-AJAXy application, worked great IMHO. It was easy to use, intuitive, and fairly accurate (if I queried Seattle, I didn't end up in Canada at least). All of a sudden, there is the new Yahoo Maps Beta. And I'm sorry, but it sucks in my opinion. Why bother with something like that? Why change something that didn't need it? AJAX-iness is all well and good, and there are apps that really benefit from it (I love Flickr, for example), but there are situations where it's just an exercise in stupidity to update something in that way. -olly

Re:AJAX problems (1)

onion2k (203094) | more than 7 years ago | (#16551450)

I think you need to pay heed to the advice in your sig. A simple AJAX application is definitely not going to crush your server unless a: it gets slashdotted, b: your webserver is written in C64 Basic, or c: you're an idiot who puts things live without testing them properly first.

My money is on b.

Re:AJAX problems (1)

Salvance (1014001) | more than 7 years ago | (#16551590)

Hehe ... I wish I remembered enough C64 basic to write a webserver in it. You made me wonder if such a thing exists ... apparently it does [vnunet.com] (or did a few years ago).

Maxing out CPU on a shared server is actually really easy. With 100's to even 1000's of websites sharing a single server, you learn very quickly what can and can't be run effectively. For instance, if more than a couple people use the web based mail system on our server, we get CPU warnings... this doesn't mean we use up the whole CPU, just our small portion of it.

Re:AJAX problems (1)

Thunderbear (4257) | more than 7 years ago | (#16567876)

You'll need a TCP/IP stack running on the c64 before a webserver will be any fun to use.

Re:AJAX problems (4, Informative)

Civil_Disobedient (261825) | more than 7 years ago | (#16551834)

Everyone is out rushing to build AJAX apps into even the simplest applications, and the result is slow loading time and greatly increased server loads.

While this no doubt happens all the time, the main advantage of AJAX-enabled web applications is reduced load on the server. For instance, our intranet application uses the Tapestry framework, and the built-in tables component (at least for the 4.0 version) was useless because it required constant, complete page refreshing when all you really wanted to update was the contents of a table. We rolled our own table component that's fully ajaxificated and it's been nothing but positive for our end users and our servers.

Re:AJAX problems (1)

loconet (415875) | more than 7 years ago | (#16555160)

Assuming you are using the XML approach as supposed to JSON, have you actually measured the load difference between the old page refresh and the new shiny Ajax requests? There is still http requests coming and going but now instead of the server simply spitting out html, the server has to spit out and parse gigantic XML datasets to update a simple table (assuming you were refering to an html table). In my experience, Ajax is counterproductive for most simple things and tends to increase the load of the server more often than not. Then again...it could be an implementation issue. ;)

Re:AJAX problems (1)

Civil_Disobedient (261825) | more than 7 years ago | (#16562174)

There is still http requests coming and going but now instead of the server simply spitting out html, the server has to spit out and parse gigantic XML datasets to update a simple table (assuming you were refering to an html table).

Actually, we made a couple of compromises to traditional MVC design because we wanted to be able to control the contents of the cell (i.e., instead of just displaying simple text, it could be a link, or an image, or a javascript control, etc.). This necessitated implementing a template system that allowed for java expressions inside the table definition, which is tied to Java objects that are then tied to database tables (via Hibernate). Long story short: the server generates the table, so straight HTML is sent back to the client, already rendered properly. All the client has to do is replace the table body with the new table body via innerHTML.

Originally we were sending XML back to the client, which then had to be parsed, but this was a real headache because we couldn't use any logic in the template, only properties. So, for example, let's say a column is designed to display a list of company names, but some of those names will be links to a Company Information page, depending on whether they exist in our system. If they don't, just display the text. I have yet to see a system that allows for this kind of absolute control over the contents of a table at the object-level. Yes, it does violate MVC, but the tradeoffs were well worth it.

Since clicking on the "next page" for a table would require the contents to be rendered all over again anyway, this saves the overhead of all the other stuff on a page that doesn't change. That includes scripts, css definitions, etc. Sure a lot of that is cached, but no way is a whole page render going to be less than 1K, which is (seat-of-the-pants calculation) how much your average table is going to need.

Re:AJAX problems (2, Insightful)

Bill Dog (726542) | more than 7 years ago | (#16551900)

Writing code that uses more network bandwidth than you've got is not an AJAX problem. It's a "writing code that uses more network bandwidth than you've got" problem. One could achieve the same thing in Java. That doesn't make it a Java problem.

"I've read several books " (3, Insightful)

truckburnt (1017180) | more than 7 years ago | (#16551044)

"Like many, I've read several books on it and now I'm even brushing up on JavaScript so that I can try it out".

Who reads several books on a technology before they "try it out"?

Re:"I've read several books " (1)

mattcoz (856085) | more than 7 years ago | (#16551372)

I certainly don't, I never even read a book before trying anything out. I've always found it much easier to learn by doing. If I don't know something or have a problem, I google it and find an online reference. A lot of people go the book route though, most of the people where I work for example. No surprise that they often come to me for help.

Re:"I've read several books " (1)

Dragonslicer (991472) | more than 7 years ago | (#16554690)

I'm more concerned that someone would have to read "several" books about it in the first place. It's what, one class and five methods that do at least 90% of the work? A competent programmer shouldn't need more than a couple hours, if even that long, to understand it pretty well.

"Ultimate client-side technology" ? Please! (2, Interesting)

MasterC (70492) | more than 7 years ago | (#16551056)

s there anyone left in our industry that hasn't heard of Ajax, the ultimate client-side technology for web developers?


Hah! Ultimate? Hardly.

AJAX is a hack to add more "dynamicallness" to web sites. HTML currently relies on HTTP and HTTP suffer a fatal flaw: it is client-initiated. Put another way: it's a poll technology. There is no way to allow the server to initiate a connection to a client.

As sites integrate more and more AJAX you tend to notice that what they are ultimately striving for is a standard desktop application. But it won't work as is and so AJAX is just a mere band aid. Ever try to use Google calender or gmail with a slow/latencied connection or when their servers are busy? I've had to wait over 30 seconds for an event to display in their calendar without any GUI notification that it's working. This can be mitigated but my point that such failures as a GUI are prevalent in AJAX applications because they're trying to be something they can't -- a desktop app.

I don't care how nifty AJAX makes web sites but don't call it "ultimate". Please.

No, the "ultimate" technology will not include HTML, HTTP, or JavaScript in their current incarnations as all have fatal flaws that just can't measure up to a standard desktop app in terms of functionality. This would be fine if the goal was different but it's not and it's precisely why (all things being a equal as possible) I will never bet on an online office suite trumping a true desktop app.

Nevermind that what web apps are heralded for -- cross-platformness -- requires a lot of effort to make happen. IE, FF, opera, and safari just don't act the same way in terms of rendering and JS functionality. There are so many things working against this AJAX movement that I'm amazed that it works (mostly).

Re:"Ultimate client-side technology" ? Please! (0)

Anonymous Coward | more than 7 years ago | (#16551452)

There is no way to allow the server to initiate a connection to a client.

I guess that's why we call it a client and a server, isn't it? This has nothing to do with HTTP but is inherent to the client-server model (which is actually a pretty good model). If it is a 'persistent' connection you are looking for you're in luck, plenty of protocols support that. Sure if you use inferior technologies such as JavaScript/AJAX you can't use those, but there are very reasonable alternatives. (Whatever happened to that good old cross-browser, cross-platform, high performance, much more widely supported than is often assumed, javascript interoperable web technology called Java Applets?)

Re:"Ultimate client-side technology" ? Please! (1)

nate nice (672391) | more than 7 years ago | (#16551958)

This is how I view technologies that allow you to program in a language and compile it to DHTML and Javascript. Essentially the same idea as an Applet. I think we now have the power on the client side for the bandwidth and the execution.

Re:"Ultimate client-side technology" ? Please! (2, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#16551522)

Put another way: it's a poll technology. There is no way to allow the server to initiate a connection to a client.

Mainframes worked the same way, and that didn't stop them any. In fact, it would be stupid to have a server trying to contact a bunch of firewalled client boxes out on the Internet. Besides not being scalable, the pull design of the web ensures that the clients are protected against exactly that sort of communication.

I think the issue you're concerned about is that there's no way to maintain an open channel. i.e. IRC maintains an open connection. Telnet maintains an open connection. FTP maintains an open connection. Pretty much everything except AJAX can maintain a connection rather than having to poll for the latest content at regular intervals.

I agree that such a design can be annoying, but it's something of a requirement for the web to function properly. Right now, you've got a few ways around this:

1. Use Mozilla APIs in a signed web application to obtain a low-level TCP/IP connection.

2. Find a Draft Web Application standards compliant browser, and use that so you can open a TCP/IP connection. (Good luck on that.)

3. Use the Livescript interface between Java and JavaScript to maintain a TCP/IP connection over a hidden applet.

4. Use an IFrame pointing to a servlet that keeps the connection open. Every time the server wants to tell you something, it "pushes" (i.e. writes and flushes) a few JavaScript commands down that pipeline. Those commands get executed immediately, thus providing a remote event system. The JavaScript code monitors the connection and automatically reconnects if the connection is lost. (This is what most web<->IRC portals do.)

5. Redesign your application. You're probably trying to do something that's a bad idea in the first place.

Re:"Ultimate client-side technology" ? Please! (0)

Anonymous Coward | more than 7 years ago | (#16551576)

While it is something of a hack on top of a hack on top of a hack, it is possible to do server initiated communication and build a clean framework around doing so. If an app is written such that the client initiates a request to the server which will result in a multipart response, the server can then use the established connection to deliver new data to the client at any time. If each part of the multipart message can actually be interpreted by the client as a complete response, it becomes possible to do all kinds of nifty 'push' related things. Do a search on COMET (blame Alex Russell, of dojo fame, for the name) for a discussion this and similar methodologies. What I hate is that both Ajax and Comet are concepts that are built on top of a less than perfectly sufficient underlying api (javascript) so you spend most of your engineering time working around issues with the platform rather than implementing application functionality. And we are about to undergo a change to an entirely new generation of web browsers (ie 7, ff 2) which do nothing to try to resolve this problem.

--sam

Re:"Ultimate client-side technology" ? FUD (1)

thelifter (1017186) | more than 7 years ago | (#16551758)

Most of the anti-Ajax FUD comes from people who've never really tried to use it - people for whom the light bulb hasn't turned on yet. First of all, it's really not as hard to make things work on multiple platforms as the naysayers claim. I have complicated AJAX interfaces that work just fine in IE, Firefox, and Safari. It's the same basic cross browser testing we've had to deal with for years. You just have to take the time to actually do proper testing and after a you gain some experience you learn which techniques work on all browsers and which ones don't - so you write a function to abstract the browser quirks into their own black box. All in all, the more you do it, the more productive you get.

I'd say that AJAX is probably a risky move for public facing apps unless it's just to dress things up, but for intranet/business apps it is very real right now.

I'll grant you that throwing around words like Ultimate might be a bit much, but it is possible to make web apps behave more like desktop apps than ever before. I don't see Ajax replacing Word, but I do see it replacing Peoplesoft and SAP.

Re:"Ultimate client-side technology" ? FUD (0)

Anonymous Coward | more than 7 years ago | (#16551816)

so i get from this complaint....the problem with Ajax is the A......as in asynchronus?.......derrr...yes try having an open connection to 1000+ web users....see how that goes

Re:"Ultimate client-side technology" ? FUD (0)

Anonymous Coward | more than 7 years ago | (#16552852)

Most of the anti-Ajax FUD comes from people who've never really tried to use it - people for whom the light bulb hasn't turned on yet. First of all, it's really not as hard to make things work on multiple platforms as the naysayers claim. I have complicated AJAX interfaces that work just fine in IE, Firefox, and Safari. It's the same basic cross browser testing we've had to deal with for years. You just have to take the time to actually do proper testing and after a you gain some experience you learn which techniques work on all browsers and which ones don't - so you write a function to abstract the browser quirks into their own black box. All in all, the more you do it, the more productive you get.


The problem with AJAX is the "J". JavaScript can be disabled by the user and your site will stop working unless you have fallbacks. Often the user is not the one who has disabled javascript in their browser, rather their admin has.

If you want a page to work reliably 100% of the time, you simply cannot use AJAX/Javascript. It is a toy, nothing more.

If I cannot achieve what I want with standard html output from a web server then I'll write a client application and distribute it to the target users, this way you have a real application that can be trusted to work and is far more functional.

Re:"Ultimate client-side technology" ? FUD (1)

Bill Dog (726542) | more than 7 years ago | (#16556452)

Glad to hear you run your own company. I work for someone else, and for intranet use, browser configurations are standardized organization-wide, and they're absolutely demanding AJAX/JavaScript apps. They don't want the hassles of distributing and upgrading and troubleshooting on individual workstations any more thick-client apps than they have to. They want the new ones all browser-based. And they don't want the flashing, page-reloading, old-fashioned "standard html output" experience, they want the new desktop app like feel, that Google and others have given them a taste of.

Re:"Ultimate client-side technology" ? FUD (1)

MasterC (70492) | more than 7 years ago | (#16553330)

Most of the anti-Ajax FUD comes from people who've never really tried to use it...


In a nutshell: AJAX work pays my bills; it still is a band aid; far from "ultimate" worthy; I never said cross-platform (misnomver)/cross-browser was impossible (you still have to put up with all the crap that comes with...the *whole* architecture of HTML + CSS + JS not being implemented the same). Not intending to toot my own horn, but I've done things with AJAX that I haven't seen anywhere on the net.

So, in short: don't pigeon hole me with the clueless people. Do you even know what FUD means? Lambasting a claim of ultimacy on a band aid of a solution is not instilling fear nor uncertainty nor doubt. Wait: gross assumptions made on the internet about someone else? Never! :)

I don't see Ajax replacing Word, but I do see it replacing Peoplesoft and SAP.


Google has spreadsheets and word processing. It has been attempted, is being attempted, and will continue to be attempted. I'm saying I'll never bet on them winning with the current incarnations because they are grossly inadequate for the task.

Re:"Ultimate client-side technology" ? FUD (1)

thelifter (1017186) | more than 7 years ago | (#16553566)

You're a little touchy, Tiger. I don't think you're clueless. Far from it. From your sig you've obviously heard of VI and for that I owe you my eternal allegiance and will invite you to take an honored position in my WoW guild.
I just think you're being a little pedantic about all this. Ajax is good stuff and it's going to get better. What should we be using? Flex? Applets? ActiveX controls God forbid?
Let's keep a positive attitude and we'll defeat the terrorists one absolute positioned div tag at a time.

Re:"Ultimate client-side technology" ? FUD (1)

MasterC (70492) | more than 7 years ago | (#16559118)

I just think you're being a little pedantic about all this.

The original claim was that AJAX was the "ultimate client-side technology" and if I have to be pedantic to explain why it's not then so be it. Is AJAX an improvement over the absence of it? Sure, I never claimed to the contrary, but this also not the line of discussion.

I described a couple attributes of what would be "more ultimate" since AJAX clearly is being used (or is trending that way) for things it can't do and is based entirely on non-standardly implemented languages.

And for that my post gets labeled as FUD... If down-playing a buzzword "technology" that gets pawned as "the killer app" gets me labeled as a pedanticist and a FUD-spreader, well, then I'll take one for the team to do so.

Long live vim and "position:fixed".

Re:"Ultimate client-side technology" ? FUD (0)

Anonymous Coward | more than 7 years ago | (#16557036)

For intranets you're much better off using flash or flex than ajax. Better features to development time ratio. It's more or less like building a desktop app by now, except that you are limited in the number of protocols you can use to communicate with the server.

Incorrect. (1)

Civil_Disobedient (261825) | more than 7 years ago | (#16551920)

There is no way to allow the server to initiate a connection to a client.

Wrong. Read up on Comet request processing. For Jetty [webtide.com] , for Tomcat [theaimsgroup.com] , and for Glassfish [java.net] .

Re:Incorrect. (1)

nuzak (959558) | more than 7 years ago | (#16552432)

The three methods of Comet involve using "slow close" (aka server push) style, piggybacking on a response from the last request, or polling. So tell me how he's actually wrong in saying that the server can't initiate a connection back?

Of course client/server designs in general aren't designed for servers to contact clients. Otherwise, you have something more like peer to peer.

Re:Incorrect. (1)

Civil_Disobedient (261825) | more than 7 years ago | (#16562258)

The three methods of Comet involve using "slow close" (aka server push) style, piggybacking on a response from the last request, or polling.

Yes to the first part, no to the second. They use a keep-alive so the connection isn't closed, so you're right if you count the initial request for a page (which is initiated by the client). But that's not polling, which is repeated requests from the client. Once the connection is instantiated, you only need to keep the connection alive, but you don't have to keep asking the server, "Have you got anything new for me?"

This used to be a problem (at least for Java servers) because that meant you had to keep a thread open for each connection--thus the max number of threads that your server is configured to handle equals the max number of concurrent connections, which is no good for a heavily-trafficed site. But with non-blocking IO you can get around all of this.

Re:"Ultimate client-side technology" ? Please! (1)

Shados (741919) | more than 7 years ago | (#16552330)

Yeah, because the fact that a server cannot initiate a request matters soooooooo much in a lot of more advanced architecture, like SOA. Obviously AJAX isn't for everything, but for a lot of things, it does peachy.

Also, your problem with waiting on Google's app without notification would be there in a normal desktop app too: AKA: the issue is simply that the GUI didn't put the proper feedbacks. Nothing in the typical implementations of AJAX prevents the developer from adding such notifications ---> if google forgot it, its google's fault, not the technology's.

Echo2 is good! (1)

wordybird (1007475) | more than 7 years ago | (#16551090)

http://www.nextapp.com/ [nextapp.com] Echo2is awesome. Use it. love it. K. Bye.

AJAX and Java: two painful technologies. (0)

Anonymous Coward | more than 7 years ago | (#16551178)

I must say, this is quote a combination of technologies that have caused me nothing but trouble!

I know Java has a lot of fans, but I've found it to be nothing but trouble. It's clear why it failed on the client side: poor UI responsiveness, excessive memory usage, and a lack of decent integration with the host desktop. The only reason it succeeded on the server was because Sun and IBM both managed to hype it so much.

At work, I have to deal with Java EE on a daily basis, but my college background included much Common Lisp. Every day I encounter situations where Common Lisp could have been used for a much more concise, performant and reliable solution than the Java-based implementation we're actually using.

JavaScript is a very neat language. I've seen people do some remarkable things with it. But AJAX is not one of them. Every AJAX site and service I have used, including those offered by Google and Yahoo!, have made me yearn for either a standalone desktop application, or a simple CGI webapp.

Neither Java nor AJAX manages to strike a good balance in any of the areas where they are used. Both suffer from some rather serious performance issues, for instance. Java consumes a great number of clockcycles, and relatively large amounts of memory (even with the shared classfile support of JRE 1.5). AJAX often manages to waste excessive amounts of bandwidth. Between the two, I see my system performance suffering greatly.

The more I see certain groups pushing AJAX and Java, the more I'm inclined to my Common Lisp roots. Common Lisp is about simplicity, but not at the expense of power. That's the sort of thing we need when developing massive web applications.

Hello world, Ajax sucks (-1, Troll)

Anonymous Coward | more than 7 years ago | (#16551300)

Hello world, Ajax sucks

Save $17.00 by buying the book here! (0)

Anonymous Coward | more than 7 years ago | (#16551496)

Save yourself $17.00 (!) by buying the book here: Practical Ajax Projects with Java Technology [amazon.com] . And if you use the "secret" A9.com discount [amazon.com] , you can save an extra 1.57%!

Why? (2, Interesting)

CaffeineAddict2001 (518485) | more than 7 years ago | (#16551558)

Howard Roark's criticism of the parthenon:
"Look," said Roark. "The famous flutings on the famous columns---what are they there for? To hide the joints in wood--when columns were made of wood, only these aren't, they're marble. The triglyphs, what are they? Wood. Wooden beams, the way they had to be laid when people began to build wooden shacks. Your Greeks took marble and they made copies of their wooden structures out of it, because others had done it that way. Then your masters of the Renaissance came along and made copies in plaster of copies in marble of copies in wood. Now here we are making copies in steel and concrete of copies in plaster of copies in marble of copies in wood. Why?"


Does anybody else get the same feeling when working with the web? We have had incredible advances in technology yet we keep using HTML and JavaScript as our base for no other reason than tradition and because that is what people expect.

Re:Why? (1)

Conception (212279) | more than 7 years ago | (#16555976)

Actually, I think its more because that is what everyone has.

As an example, Flash can do above and beyond that of HTML and JavaScript, and people use it because everyone has it.

Playing to the largest audience, not tradition, is why we stick to our guns, as it were.

Re:Why? (1)

LQ (188043) | more than 7 years ago | (#16556812)

We have had incredible advances in technology yet we keep using HTML and JavaScript as our base for no other reason than tradition and because that is what people expect.

No, it's not tradition. It's all about installed-base inertia - many millions of online platforms that already grok html and javascript. Anything new faces the twin hurdles of fear and sloth or consumer resistance in marketing terms.

GWT (2, Interesting)

nate nice (672391) | more than 7 years ago | (#16551706)

Stop it with these nonsense books and just pick up GWT. Understand that putting it all on the client side is more powerful and in practice generally more reliable and just as fast as server side tool kits, if not more so.

I believe this is the real benefit of AJAX methods that go beyond the asynchronous client/server communication.

Now you write Java programs that are compiled into complete Javascript programs that work on IE, FF, Safari and Opera with generated DHTML, etc. You use whatever you want back on the server side. The Javascript generated for you will probably be as good as anything you can write in JS and most likely more complex and better tested.

This is such a better parigdim than having the server create these user forms and controls using minimal Javascript and then posting back for more forms. Or simply sending all the forms over in a bloated DHTML mess. Now we have actual programs on the client side that behave like Websites and rich clients.

Make a site in GWT and see how easy and fun it is. It's a whole different world of Website and very clearly the future. Maybe not GWT, but having a Javascript program as the Website and the server agnostic. I would assume we will see better Javascript caching and a client/server versioning system to make sure users have the latest version of a site making for insanely fast Websites that are downloaded once with only calls for content and no longer infrastructure.

Re:GWT (2, Interesting)

fzammett (255288) | more than 7 years ago | (#16552384)

I'm actually glad that GWT was just coming into focus after the book was nearly finished because I suspect you wouldn't have liked what I had to say about it :)

GWT, to me, is very cool technologically. I certainly appreciate the heck out of it as a coder. It's definitely a beat product.

But as someone who is involved in determining how things get done at work, I'd have a very hard time ever recommending it for anything but small projects that a single developer could do.

For years we've all (most of us anyway) been striving for that goal of having page designers, those that are good from an artistic standpoint, and the coders who take the pure markup and CSS and add the bits that make it work. GWT turns this approach in it's arse because now you need coders to do it all. Oh yeah, you can have the graphic artist sitting next to you during development, but that's not nearly the same thing. GWT reduces web development to pure coding, and I think that's the opposite of where we've been trying to go for years.

Now, I don't know how many organizations actually realize this separation... I suspect not as many as those pushing that idea would suggest... but that doesn't mean it isn't the goal to strive for (unless you really just plain disagree with the concept in the first place).

I've been doing Java coding for quite a few years now, and one of my least favorite things to do is GUI development. Java always, to me, made it more convutled than it should be. Bringing that to webapps doesn't strike me as a great idea. I realize some people feel quite the opposite on this point and really love GUI development in Java, but that's my opinion anyway.

It's just my opinion, but I view GWT as something that is great for those small projects where your only going to have a single developer anyway, but I don't view is as quite as suitable for larger projects where you want there to be a difference between the page designers and the coders.

Re:GWT (3, Interesting)

nate nice (672391) | more than 7 years ago | (#16553558)

I have to respectfully disagree.

You mention that now the coder has to develop the GUI and do the CSS. This is totally wrong. If the CSS classes are defined ahead of time, the programmer simply has to set them and all the different CSS states a UI object will have. this is usually done in the design segment of the software lifecycle.

Now the graphic artist can work on stylizing a Website and developing images, etc. They can also design the layout and have the programmers make sure each UI widget is in a panel that lays this out. Then, once again, the graphic designer styles the work.

And really, GWT doesn't make you do much GUI design at all. After the layout is done, a programmer only needs to create each UI object and be done with it. No different than in ASP.net or any other server side UI creation scheme.

GWT is amazing in that it forces the development to look at CSS as the designing part and Java as the logic part. The logic sets the design, but this isn't atypical by any means.

And GWT in my experiences has been successful on fairly large projects. It's fast, the easiest to debug for any Website and fairly compact.

I believe it's a radical shift in the paradigm of Website development and a great one at that.

I love the idea of a Java to Javascript/DHTML compiler, CSS centered design and wonderfully encapsulated asynchronous client/server communication. GWT allows you to make complex Web Apps that were near impossible to make a year ago.

I see the light anyways. And it's only going to get better. It makes Web programming more like programming. It's what I've dreamed of for years.

The AJAX flagellation sect (1, Insightful)

Anonymous Coward | more than 7 years ago | (#16551944)

Is there anyone left in our industry that hasn't heard of Ajax, the ultimate client-side technology for web developers?

Yes, me. The only AJAX I've heard of is the DHTML rebranding that presumes scripting is enabled and breaks the back button. AJAX is something for idiots to inflict on themselves.

Re:The AJAX flagellation sect (2, Insightful)

LDoggg_ (659725) | more than 7 years ago | (#16552086)

Ajax only breaks the back button when it us use for a site's navigation.
This is just as bad as when someone develops a site entirely in flash.

Sure the technology can be misused, but the fact that some people misuse it, doesn't make it a bad technology.

Re:The AJAX flagellation sect (1)

jrumney (197329) | more than 7 years ago | (#16552920)

The only AJAX I've heard of is the DHTML rebranding that presumes scripting is enabled and breaks the back button.

Well, let me introduce you to some more useful and entertaining [english.ajax.nl] ways to use Ajax.

Re:The AJAX flagellation sect (1)

jrumney (197329) | more than 7 years ago | (#16552952)

D'oh, missed a closing quote on the first link [colpalcommercial.com] , and slashdot scrubbed it.

Re:The AJAX flagellation sect (1)

tf23 (27474) | more than 7 years ago | (#16560548)

That's what that button label'd "Preview" is for ;)

Re:The AJAX flagellation sect (1)

jrumney (197329) | more than 7 years ago | (#16574316)

Thanks, Captain Obvious. Any idea what this checkbox labeled "No Karma Bonus" is for?

Icefaces (2, Interesting)

coldtone (98189) | more than 7 years ago | (#16551988)

On the topic of Java and Ajax you should check out icefaces [icesoft.com] , its a great Ajax framework and its completely free, and does not require any javascript programming.

Check out their Component Showcase [icesoft.com] .

Java BluePrints also has guidelines for Java/Ajax (1)

larryfreeman (785589) | more than 7 years ago | (#16553290)

The Java BluePrints web site has guidelines on using Ajax and Java: http://java.sun.com/blueprints/ajax.html [sun.com] It presents guidelines on using Ajax with the Java EE 5 and J2EE 1.4 SDK. The Java EE 5 sample code has been tested with Sun's open source application server (http://glassfish.dev.java.net/ [java.net] ) -Larry Freeman Manager, Java BluePrints Sun Microsystems

Ajax this, Ajax that. (2, Interesting)

loconet (415875) | more than 7 years ago | (#16554178)

Anyone else sick and tired of all this Ajax hype? I wonder how much damage is all this hype causing. Just a while ago my boss asked me to implement a simple one single text field and button form with Ajax because he wanted to make sure the submission was "responsive". After trying to persuade him otherwise and failing, it is needless to say, a simple project became a mess very quickly with very little benefit for the end user. Ajax has its place and usage, I think that's what these books should be focusing on rather than selling it as holy water.

Totally agree. HTML injection == Coding Horror!!! (1)

javabandit (464204) | more than 7 years ago | (#16554938)

"Coding Horror!!!" to draw a phrase from McConnell and the bible, Code Complete...

IMHO, AJAX and dynamic Javascript-based HTML injection really have very few use-cases where they should be used. Take for example Google Maps. If you want a dynamic application (from a browser) that graphically interacts with the user in a virtually real-time fashion, you are going to have to resort to AJAX and HTML injection.

But why in the hell would you use AJAX for a plain-old form-submission and a response page? Or for reporting? Or in an application like Cognos ReportStudio (talk about coding horror). Another example of this horrible misuse is Microsoft's AdCenter. Why in the hell would they resort to AJAX reporting versus just a plain old "submit the form and get the response". It just doesn't make sense.

Not only that, but does anyone else have a nightmare with trying to debug dynamic HTML injected apps? I mean you don't really know if the problem occurred prior to the submit, on the server side, or on the client side after the response was received. And you will have to use both a regular debugger and a Javascript debugger to find out.

AJAX belongs in the pile of overused/misused technologies in software engineering...

Anybody got anymore to throw on that pile?

Anyone writing Ajax games? (2, Interesting)

bryanbrunton (262081) | more than 7 years ago | (#16555106)

I recently released my version of web-based Risk, called Grand Strategy. It is an Ajax application written using DWR (Direct Web Remoting) and the Dojo Toolkit.

It is by far the most sophisticated Ajax base game I have seen. I'd be interested in comparing it so other Ajax based games.

Has anyone seen or developed an Ajax based game I could take a look at?

Grand Strategy [denizengames.com]

Re:Anyone writing Ajax games? (1)

realjordanna (892230) | more than 7 years ago | (#16555478)

There is a poker ajax game [ajaxian.com] . Ryan Dewsbury has written a multiplayer ajax poker application written with GWT. The front end is written with Java which the google web toolkit compiles to javascript.

Re:Anyone writing Ajax games? (1)

fzammett (255288) | more than 7 years ago | (#16556030)

I suppose its worth noting that this book has a game project in it... interestingly, you can get that particular chapter for free: http://www.theserverside.com/tt/articles/article.t ss?l=AjaxWarrior [theserverside.com]

By the way, Grand Strategy looks very nice indeed, I'll enjoy giving it a closer look as time allows.

Re:Anyone writing Ajax games? (1)

lazy_playboy (236084) | more than 7 years ago | (#16563996)

Bah, I can't login with the username I've created. I'm using firefox on Mac OS X.

AJAX - which one (1)

Kittenman (971447) | more than 7 years ago | (#16555472)

Is there anyone left in our industry that hasn't heard of Ajax, the ultimate client-side technology for web developers?

Interesting comment. I hosted a meeting here last week and someone mentioned Ajax. Several people hadn't heard of it. Main contenders were either a domestic cleaner or a Trojan war hero.

Atlas! (1)

KlomDark (6370) | more than 7 years ago | (#16555648)

After many months of using various AJAX libraries, I watched the Scott Guthrie Introduction to Atlas video. (You can get to it from http://www.asp.net/learn/videos/default.aspx?tabid =63#atlas [asp.net] , and was astounded at how much easier it makes it.

No more having to come up with all kinds of weird JavaScript to do the simplest things. Throw a few normal controls inside of an UpdatePanel, set your triggers, and you've suddenly got a much more responsive web app.

The whole ScriptManager makes it insanely faster to create AJAX apps, no mucking with JavaScript at all. And the JavaScript emitted by the script manager automatically adapts to the browser you are on, FireFox or IE. Surprisingly, being a Microsoft product, some of it actually works better on FireFox. That was a big surprise.

Now I'm just waiting for the actual release. Don't want to get too far into a project with the CTP version, cause you know _something_ will change between the CTP and the actual release.

I'll probably get fried for saying it here, but Microsoft has done a very good thing here.

Stay close to the metal (0)

Anonymous Coward | more than 7 years ago | (#16555784)

I know there are a million ways to go, but I've had really good luck doing ajaxy things [mhive.org] with the prototype library [conio.net] and custom taglibs. If your interface is off the beaten path, jsps w/ custom tags give you a ton of control and are great for div loading - meaning they help you keep things on the server side as much as possible, which is always a good thing when dealing with javascript.

Doug

"Ultimate" crap again ... (1)

unity100 (970058) | more than 7 years ago | (#16555816)

"Is there anyone left in our industry that hasn't heard of Ajax, the ULTIMATE client-side technology for web developers?"

And pray tell me, when and WHO have bestowed the ultimateness over ajax ? Its just another mesh-up of old existing stuff, all of which were not ultimate "technologies" when they came up, and all of which have not became "ultimate" any time after, just as ajax. Just another "new" thing, like many other "new" things to come in future.

That seems like a stupid rant in order to boost up the hype around ajax.

Not quite true. (1)

Dr. Photo (640363) | more than 7 years ago | (#16556358)

There is, however, an aspect of Ajax that often seems to get lost in the rush to play with the new browser tricks; Ajax enhanced web applications still need to work closely with server-side components.


Not quite true. You can use an XMLHttpRequest to pull data from any site, if you know where in the document to look. Even if the page returned isn't well-formed XML, you can still screen-scrape, then put the data to use on your page.

One acronym. WCAG !!! (1)

javaxJason (898629) | more than 7 years ago | (#16559568)

Ajax may be nifty, but for all intensive purposes it should be a last resort for enterprise applications. Most large corporate applications should consider 508 compliance and web accessibility guidelines. With that said, one simple requirement of accessibility renders Ajax useless -- an application must work without javascript! Its true that postbacks and page loads may be a pain and may be slow under heavy loads, but Ajax is not the accessible solution. From the VERY little that I've read about Curl...it seems to be a much better solution...at least the content is actually loaded and not dynamically created in the DOM. On the other hand there is the issue of applets. Anyone agree, know a little more about Curl, or other accessible solutions?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>