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!

Ajax in Action

samzenpus posted more than 8 years ago | from the read-all-about-it dept.

Book Reviews 270

Simon P. Chappell writes "There's always a danger when a new technology buzzword hits the ground running. The danger is that when it finally slows down enough for us to take a good look at, it'll be found to be empty hype with less value than a mime performance on a radio show. This time the buzzword is Ajax and it's moving so fast that you can almost hear the sonic boom. The authors of Manning's new Ajax in Action have managed to catch up with Ajax long enough to take a look at it for us. Their book explains what Ajax is, how to use it and how, for once, the hype may be underselling the prospects for this new buzzword." Read on for Simon's review.

The majority of the book is for programmers engaged in the development of web applications; especially those who are interested in taking their applications beyond the traditional ``click and wait for the response from the server'' model that we've become accustomed too.

The first section, and particularly the first chapter, would be suitable for anyone who is curious about Ajax. The first chapter answers the questions of what it is, and why it deserves all of the positive press that it's received. If you're introducing Ajax at work, this might be the chapter of recommended reading for your managers and software architects.

Alright, enough introducing the book, now let's take a look at just what Ajax is. Ajax itself is an acronym created by Jesse James Garrett in his, now classic, article Ajax: A New Approach to Web Applications. Ajax, we are told, means Asynchronous JavaScript and XML. This is our first clue that Ajax is not a single, new thing. Ajax actually turns out to be a combination of existing technologies mixed up in a fairly new way.

The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests. Ajax, the technology, is the amalgam of these individual technologies. Thus, Ajax is both new and well proven at the same time.

Perhaps it's also possible to view Ajax as the natural resting place of the pendulum of application development. Programmers, since the beginning of application development have been trying to balance user experience and ease of installation and maintenance. First we had mainframes with their centralized usage model. Next we got the PC with it's entirely disconnected usage model. This was followed by the Client/Server model that tried to be connected yet offloaded it's processing to the client. The world wide web came next and browsers as the ultimate thin clients forced all of the processing back onto the server again. Finally now, with Ajax, we have what seems like a good balance of server side processing, with responsive clients that provide the rich user interface that users want. The pendulum of centralized versus decentralized has found it's rest point.

The structure of the book is fairly standard. The first section, three chapters, concentrates on imparting the concept of Ajax to the reader. The first chapter begins with the concepts, chapter two takes the reader through some very simple first steps, while chapter three explores how the Model View Controller pattern (MVC to it's friends) applies in the Ajax world and looks at third party, free and open-source Ajax libraries available today.

Part two of the book explores the core techniques of Ajax. Chapter four explores the difference between a web application and a desktop or Ajax application, that of a single page being the entire application. Chapter five explores the role of the server, looking at what resources are available for the server-side coding, including available languages and frameworks as well as ways and means of exchanging data with the server.

Part three looks at what the authors call ``Professional Ajax'', the techniques that make a difference when creating real world applications. Chapter six covers the design of the user experience. The user experience for a major application basically is the application for the user and so getting this right is of fundamental importance. Chapter seven explores security and some of the actions that the developer can take to both ensure access control and protect confidential data. Once the basics of Ajax are mastered, this may well be the most important chapter in the book. Chapter eight covers performance and what can be done to assist application speed and resource usage in practical use. Perhaps the most important measure for an Ajax application is the perceived speed and responsiveness that it delivers. The asynchronous processing is a huge factor in achieving these user perceptions.

Part four shows Ajax by example, with four chapters of example applications and a fifth chapter addressing building stand-alone applications using Ajax.

There is much to like about this book, but top of the fold for me is the clear and concise explanation of just what exactly Ajax is and why it has the power to make a difference in the web application arena. At a time when more people speak of Ajax than actually understand it, this book has the power to bring forth understanding.

This is a very dedicated book. It takes no time to teach the reader the individual technologies that compose Ajax, rather it concentrates on using those technologies. If you do not know JavaScript, or Cascading Style Sheets or do not understand the W3C's DOM model or asynchronous messaging then you would be better served at this time by learning the individual technologies and saving this book for after you've mastered them.

Other than the standard book page over at the Manning website, there is no dedicated book website. This is perhaps unusual, but 30 seconds on your search engine of choice should get you started. Failing that there is a good Ajax page available at Wikipedia.

This is a magnificent book. Not because it's well written and has good example code in it, although it is and it does. Rather, it is magnificent because of the high speed target that they have accurately hit and described in a clear and hype-free fashion; for this the authors are to be commended. If you want to create dynamic web applications, get this book."


You can purchase Ajax in Action 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 ×

270 comments

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

I'm sorry (0)

CrazyJim1 (809850) | more than 8 years ago | (#14102317)

I'm not buying a book written by Jon Stewart.

Re:I'm sorry (0)

Anonymous Coward | more than 8 years ago | (#14102420)

italics fixed?

God spoke to me (1)

Animats (122034) | more than 8 years ago | (#14102577)

1)Sept 2003: I was down Pittsburgh, and I heard a voice that said,"Good News". It confused me, but I felt compeled to come home to my old church.

With the Holosonics Audio Spotlight [holosonics.com] , you can now make people think God is talking to them! Range from 20 to 200 meters. And the speaker is just a flat black disk about a foot in diameter.

It's really clever. It works by projecting audio as two ultrasonic signals, which produces a very narrow beam. You can't hear the ultrasonic components, but the difference between them becomes audible some distance from the speaker, because air isn't entirely a linear medium. Some museums now use these things, so that the recorded message for a display is only audible in a small area. We're going to be seeing more of these very soon; the price is about to drop.

So if you hear voices in your head, start looking around for 1' diameter disks pointed in your direction. Move around a bit; the beams are very narrow.

Re:God spoke to me (1)

petermgreen (876956) | more than 8 years ago | (#14102860)

what exactly makes you say the price is about to drop?

patent expiry?
insider information?
some technical development?
just a hunch?

Re:God spoke to me (0)

Anonymous Coward | more than 8 years ago | (#14103025)

Isn't it obvious? God told him so.

Re:I'm sorry (0)

Anonymous Coward | more than 8 years ago | (#14102651)

god doesn't exist

Re:I'm sorry (1)

c_forq (924234) | more than 8 years ago | (#14102684)

But I am a god, you insensitive clod!

It's a joke. Laugh.

Re:I'm sorry (0)

Anonymous Coward | more than 8 years ago | (#14102774)

Why, thank you for sharing that. The datum has been stored away for use should the unimaginable happen and that nuggest of information should actually have any use to anyone other than yourself.

And just because we would hate to see you feel like you gave more than you got in this exchange: my right foot itches.

SLASHDOT MODERATION IS FUCKED (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14102322)

AMEN

Score: 0 (Logged-in users start at Score: 1)

AJAX explained... (5, Funny)

nother_nix_hacker (596961) | more than 8 years ago | (#14102340)

No need to buy this book. Just consume one of these and you will awake the next morning know how to use javascript and XML in unison to produce yet another del.icios.us clone!

http://www.cleansweepsupply.com/pages/skugroup1068 .html [cleansweepsupply.com]

I think I buy into this "ajax" thing (5, Informative)

gtrubetskoy (734033) | more than 8 years ago | (#14102343)


Paul Graham's got an opinion on Ajax in his Web 2.0 essay [paulgraham.com] .

I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. It's not so much about the tools you use (which are indeed JavaScript and CSS pretty much), it's more about the architectural view of the application, where you think of the browser hosting your application rather than content and the server produces data rather than content and how Ajax coding is not just get-the-javascript-to-work-and-move-on like in the old days, but rather not unlike any other language, requiring same level of discipline.

Anyhow, the book explains it better, I recommend it.

Can AJAX finally bring us "push technology" (2, Interesting)

DeadSea (69598) | more than 8 years ago | (#14102409)

Could we finally get push technology with AJAX?

I'd like to have the following, all of which have been cumbersome and refreshy to implement in a web browser so far:

  • A news page that I can leave open and automatically gets new stories added to it without refreshing. (CNN that I can leave open and know that stories will apper within a minute of them being posted)
  • A stock ticker that is always up to date. (Yahoo finance that I don't have to refresh)
  • Weather forcast and current conditions that change in real time.
  • Some way to glue all of them together into the same page ala RSS

Re:Can AJAX finally bring us "push technology" (1)

br0ck (237309) | more than 8 years ago | (#14102460)

Both of these do exactly that:

From Google: http://www.google.com/ig [google.com]
From MS: http://www.start.com/ [start.com]

Re:Can AJAX finally bring us "push technology" (2, Informative)

arkanes (521690) | more than 8 years ago | (#14102471)

No. AJAX, for all it's hype and buzz and crapola, does not fundamentally change the client/server nature of HTTP and the web. AJAX applications that load data do it by polling, exactly the same as meta refresh tags and timer-based javascript refreshes have been for 10 years.

Re:Can AJAX finally bring us "push technology" (1)

KilobyteKnight (91023) | more than 8 years ago | (#14103000)

AJAX applications that load data do it by polling, exactly the same as meta refresh tags and timer-based javascript refreshes have been for 10 years.

Polling... yes.
Exactly the same way... no.

Ajax is not the end all of programming technologies, it is, however, very useful. I'm completing a rewrite of an internal project for work using xajax. The user interface is so much better than before it's amazing. It has allowed me to add the little usability pieces that just aren't possible with traditional methods. For example, dynamically generated drop downs based on live user input similar to the "To:" field on gmail.

Yes, it could have been done without Ajax, and in fact it was. However, the look, the feel, and the ease of use for the end user has improved dramatically.

Re:Can AJAX finally bring us "push technology" (2, Informative)

CastrTroy (595695) | more than 8 years ago | (#14102490)

You really can't do "push" with webpages, or their data. You could make something that looked like push, but in reality is actually just polling. The problem with this is that AJAX is supposed to reduce the amount of traffic to a website. If you have users constantly polling you for information, you're going to increase your load. I guess it would be better than polling and getting an entire page every time. We'd need to change the way AJAX works in order to get something that was truly "push".

Re:Can AJAX finally bring us "push technology" (1)

Jerf (17166) | more than 8 years ago | (#14102492)

Everything except the last is pretty easy, although your websites will of course have to actually implement it, or you'll have to do a lot of work yourself.

The reason it's easy is that it would work much like old push technology; you'd actually pull the information periodically. You can have some problems with unavoidable memory leaks in the web browser, but other than that it would be easy.

That last one is interesting, and while it is also possible would require a lot more work by a web-based RSS aggregator; at that point I question why you're not just using a current RSS aggregator.

(That's probably the biggest downside of AJAX; web browsers are mighty big hammers now, but many problems still aren't nails.)

Re:Can AJAX finally bring us "push technology" (1)

Scarblac (122480) | more than 8 years ago | (#14102563)

Well, no, but what you can do is make your refreshy polling things more lightweight and more invisible, so that they sometimes give the illusion of being a push technology.

Re:Can AJAX finally bring us "push technology" (2, Informative)

jd142 (129673) | more than 8 years ago | (#14102566)

I think you can do all of these things since you can have javascript in a while loop/sleep or whatever and then every x number of seconds have the javascript call the function to update the page. I don't do a lot of client side programming, precisely because I can't guarantee what's on the client, but javascript should be able to do that.

The examples you have here though can also be handled by a meta-refresh. Unless you wanted different sections of the page to update at different intervals. So that the stock is updated every second, the news every 30 minutes, the weather every 15. Then unless you set the meta-refresh to the lower time, ajax would work for these things.

You could also be really old school and use frames with meta-refresh.

Although I will confess that I have only started with ajax, it seems to me that it is better suited to apps that are also passing client side input or changes.

But I could easily be wrong.

Re:Can AJAX finally bring us "push technology" (4, Interesting)

_xeno_ (155264) | more than 8 years ago | (#14102649)

Nope. Push is dead, NAT killed it. (Well, a whole bunch of things killed it, but essentially you can't connect back to a client any more, and there are a whole host of reasons why you generally don't want to leave connections open.)

However, you can do what email clients have done for ages: poll. And that's what things that emulate what you're talking about essentially do.

Essentially, with AJAX, you'll have some JavaScript program that uses the good ol' window.setInterval to poll the server every five minutes or so. It gets back an XML document that contains a list of changes, if any, to the page you're looking at. If the data has changed, it then uses the DOM to alter the page to display the new information.

Effectively, though, it's just a page that refreshes automatically via JavaScript. Because it can pull back an XML document, it doesn't have to download ALL the HTML stuff to get the data. Because it's in the background, it doesn't have to "destroy" the page to load the new information, allowing it to be added to an existing page in a seamless manner.

It's really nothing new, exactly, it's just that the most popular browsers (Internet Explorer, Firefox, Opera, and Safari) all support XMLHttpRequest in some form now, making it feasible to use it without cutting out some section of your user base. It's just message passing in JavaScript.

Re:Can AJAX finally bring us "push technology" (2, Interesting)

TheRaven64 (641858) | more than 8 years ago | (#14102779)

NAT didn't kill push. Push technology is very possible using XMPP, rather than HTTP as the presentation layer. You build something like XMPP Publish-Subscribe on top of it, and then plug in a browser. The browser sends your JID to the server (or a proxy JID if you want anonymity) and subscribes to the pub-sub node relating to the page / web app. Every time the server wants to send to some information, it can. You keep a TCP/IP connection to your XMPP server open while you are online, and the web server can connect to this and send you data in the form of XML stanzas. Then all you need is a Javascript (or whatever) onXMLRecieved() function that takes the new XML and applies it to the DOM.

I saw a proof-of-concept demo of this over a year ago. It would be nice to see it integrated into Mozilla...

Re:Can AJAX finally bring us "push technology" (1)

sukotto (122876) | more than 8 years ago | (#14102712)

I have this already. It's called Google | Personalized Home [google.com] (requires a gmail id). Wish it was more customizable, but I really like it.

Re:Can AJAX finally bring us "push technology" (0)

Anonymous Coward | more than 8 years ago | (#14102745)

Those are stupid ideas.

The last thing I want is being half-way through reading a paragraph, and have that paragraph disappear because it was bumped out by a new story.

I want new material when *I'm* ready for it. The "Reload" button does that beautifully.

BTW, anyone knows how to get Firefox NOT to honor the http-equiv="refresh" meta tag? I find it just as annoying as pop-ups.

Re:Can AJAX finally bring us "push technology" (0)

Anonymous Coward | more than 8 years ago | (#14102913)

click the red x before the page refreshes.

Re:Can AJAX finally bring us "push technology" (0)

Anonymous Coward | more than 8 years ago | (#14103012)

Sorry doesn't work. The red X is disabled. Tested on www.cnn.com with Firefox 1.0.7.

Poll and Pull slowly (2, Informative)

jhliptak (619614) | more than 8 years ago | (#14102819)

You can only do one thing with AJAX: change a section of a screen with data from a server without reloading the entire page.

What does that mean for push? It means that you can't do it. There is no real way to establish a connection from server back to the client.

So then what's the excitement all about? There are two things you can do with AJAX that a "normal" web app can't do:

  • You can poll a server and update a portion of your web page. This method of polling can provide all four of your requests. The downside is that your polling and making requests you don't need.
  • You can pull slowly. This is a technique where you make a request and you don't expect to get a reply until there is new data. So you draw your page, make a request for newer information and when it becomes available, the server will finally reply. The downside here is that there is a limited number of unresolved requests that most web browsers will allow and your server needs to be very smart about thread and socket allocation.

Re:Can AJAX finally bring us "push technology" (3, Informative)

doublec (891422) | more than 8 years ago | (#14103048)

Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.

This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of connections that it uses and this eats one of them up (Some versions of IE only use 2 connections). This could prevent other AJAX or normal HTTP requests from occurring.

The same problem exists with the 'hidden IFRAME' approach. One interesting workaround is to have a hidden flash applet on the page whose sole purpose is to create a persistent connection to the server. The server can send data to the flash applet which then calls javascript callbacks on the web page. This does not eat up a browser connection as flash has its own connection pool. As it's a normal socket you can also use any protocol for the events you want. The downside is that if the user goes through a strict firewall that only allows outgoing http traffic on port 80 you're stuck.

I describe some of the options here: More on Ajax and Server Push [bluishcoder.co.nz]

Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections [aflax.org] . It uses AFLAX which allows easy communication from Javascript to an embedded flash applet.

The approach I've gone for is to use the flash idea, falling back to a delayed AJAX call response, then to a hidden IFRAME depending on browser support. This approach does what you want - allowing the server to push to the client.

Re:Can AJAX finally bring us "push technology" (1)

catalyst (77856) | more than 8 years ago | (#14103060)

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.justfuckinggoogleit.com">justfuck inggoogleit</a><br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp ;&nbsp;....no, but seriously, google's customizable homepage does all of this, and i wouldn't call it cumbersome in the slightest. i have it open all day, as a low-bandwidth and low-real-estate aggregator that allows me to keep an eye on everything important to me, from the <a href="http://www.nyt.com">nyt</a> to <a href="http://www.somethingawful.com">sa</a>.

Re:I think I buy into this "ajax" thing (4, Insightful)

AKAImBatman (238306) | more than 8 years ago | (#14102415)

I too initially thought "What's the big deal, it's just JavaScript". But I'm now actually reading the "Ajax in Action" book, and it looks like there is something to it. Anyhow, the book explains it better, I recommend it.

You make it sound so new and mysterious.

AJAX is simple. We now have a cross-browser method for making server requests in an asynchronous fashion. Combined with the fact that the demise of Netscape 4 means that we can finally code for the DOM, and you've got a recipe for success. It's not anything magical or mysterious. In fact, you could do it with hidden IFrames long before AJAX even became a buzzword. The key is that it's useful and semi-standard. Which means that we can finally deploy all those cool web apps we've wanted to deploy for years but couldn't.

Re:I think I buy into this "ajax" thing (2, Interesting)

OakDragon (885217) | more than 8 years ago | (#14102477)

One of the nice things about AJAX is that it just absolutely blows people away. The click, they expect a page load or a refresh. But it's just there. It really breaks the user's image of what is about to happen. It allows web applications to transcend the "toy" level, just a little.

Imagine Slashdot never re-loading a page. We could watch as posts spring into existence in real time. A little spooky, if you ask me. :)

Re:I think I buy into this "ajax" thing (3, Interesting)

CastrTroy (595695) | more than 8 years ago | (#14102678)

This is what bothers me a little bit. Sometimes when I'm at a web page that uses Ajax, I'm expecting the page to refresh, or do something else when I, say, click on button. Sometimes you don't even notice stuff happening, and you're sitting there waiting for some page to load, that is never going to load. I know how the web works, so I expect things to happen a certain way. When pages use AJAX, they change the way things are done, and start to confuse those that really know what's going on.

Re:I think I buy into this "ajax" thing (1)

estebanf (814656) | more than 8 years ago | (#14102795)

Well, ajax is just an advertisement word for something that's everything but new.... but, we can't blame it for your lack of awareness :)

Re:I think I buy into this "ajax" thing (1)

CastrTroy (595695) | more than 8 years ago | (#14102980)

Basically what I'm saying is that 99.9% of web pages refresh when you click on something that is supposed to perform an action. When AJAX like technologies are used, the page doesn't refresh. When applications don't behave the way people expect them to, it creates usability issues.

Re:I think I buy into this "ajax" thing (2, Insightful)

arkanes (521690) | more than 8 years ago | (#14102511)

where you think of the browser hosting your application rather than content

And this is where you go wrong, and why AJAX sucks, and will continue to suck - web browers are (fundamentally) shitty application platforms, for very important reasons that will not go away. The future of web applications, the future where they don't totally suck and aren't jury rigged one-of inconsistent half-assed things, is in specialized thin clients.

OR of course... (0)

Anonymous Coward | more than 8 years ago | (#14102344)

This could just be more hype...

So.. (4, Funny)

PhrostyMcByte (589271) | more than 8 years ago | (#14102354)

I guess we are in for a much cleaner internet?

Re:So.. (1)

corcoranp (892008) | more than 8 years ago | (#14102402)

Only if they use the Anti-Baterial kind...

Re:So.. (2, Funny)

Tumbleweed (3706) | more than 8 years ago | (#14102665)

I guess we are in for a much cleaner internet?

Yeah, but it's gonna smell like a hospital.

Intersting book site (4, Funny)

smitty_one_each (243267) | more than 8 years ago | (#14102367)

My only disappointment was that the popup on mouse-over didn't say "Hello, world", which would've been funny on a couple of levels, and opted for something practical like telling you how to BTFM.

Feyenoord Ajax (4, Funny)

Anonymous Coward | more than 8 years ago | (#14102370)

I have used this idea Ajax and I found the alternative Feyenoord to be superior in every department. However there is worse to be found on the market, after trying out PSV Eindhoven I demanded my money back.

Someone on Slashdot (0)

Philip K Dickhead (906971) | more than 8 years ago | (#14102394)

Forgot to close the ITALICS tag. I wonder if I can do it for them...

Re:Someone on Slashdot (1)

Philip K Dickhead (906971) | more than 8 years ago | (#14102418)

I guess not!

Re:Someone on Slashdot (1)

sacdelta (135513) | more than 8 years ago | (#14102615)

I believe it is that last bit of italics from the article itself.

Re:Someone on Slashdot (1)

Philip K Dickhead (906971) | more than 8 years ago | (#14102857)

It is - and the tag wasn't closed. With CSS, we get a page all Italics.

speared in the nipple (1)

ericcantona (858624) | more than 8 years ago | (#14102396)

I'm afraid this ajax will suffer the same fate as the original and be speared in the nipple [mac.com] , by the Next Big Thing (TM)

Re:speared in the nipple (0)

Anonymous Coward | more than 8 years ago | (#14102695)

You'll notice that Ajax 1 actually spears Simoisius in the nipple. I don't know of any Simoisius in Seclusion, but they had best guard their nipples. Ajax 1 is on the hunt.

Re:speared in the nipple (1)

h0nk3y (933455) | more than 8 years ago | (#14102767)

As the previous poster points out, Ajax was the nipple spearor, not the nipple spearee. Other places he speared people included the gut, the head, the side, the neck and the chest. I didn't remember so much spearing going on in that tale. Hopefully this new Ajax will play much nicer with his internet neighbors...

The book (3, Informative)

dantheman82 (765429) | more than 8 years ago | (#14102411)

I ordered it recently from Bookpool.com [bookpool.com] and although they claim that it's out of stock, I still ordered it and recevied it not too long after. Otherwise, if you'd rather get it a little sooner, try out Amazon [amazon.com] .

Also, a very interesting resource is available through Pragmatic Programmer [pragmaticprogrammer.com] , a beta book which means you can get PDF updates as they are written until it is shipped in hard copy in Feb. 2006. Already a book of 160+ pages, they already had a section on creating your own version of Google Maps (and more relating to SAJAX and other PHP implementations). The beta book, while only a little extra, is highly recommended!

Not efficient. (0)

Anonymous Coward | more than 8 years ago | (#14102421)

I mostly noticed how my PC (2.8ghz and doing nothing else) paused for a moment as the Ajax component started to do something. Excellent!

Good read so far (1)

jenkin sear (28765) | more than 8 years ago | (#14102423)

The central idea behind Ajax is pretty good IMHO- moving as much of the presentation-tier processing as possible to the client system. It's certainly a cleaner design- separation of concerns means you can get away from some of the nastier (and kludgy) template languages like PHP, Cold Fusion, and their ilk. You can also see a future where JSP, Velocity, and ASPX pretty much go away from the application stack- yes, you still need some templating system to produce the XML or javascript that your application is consuming, but it dramatically decreases in importance. Further, your application tier code can devote itself to modeling your business logic, and not get distracted by trying to simultaneously serve the right stylesheet to Mac IE5 users while calculating shipping to uzbekistan...

The alarm bell ringing in my brain is that all of this is structured around a fairly blunt tool in javascript. It does a great job at what it is designed to do- but it seems to require coercion to handle some more sophisticated needs. When I start building a large, complex application, I really prefer to have namespaces to compartmentalize things. It seems like you need to use tricky external libraries to gain the features needed for external support- with the classic issues around leaky abstractions that this causes.

The book has been a good read so far (I'm halfway through)- but already, it seems like they are bending over backwards to get around the lightweight nature of the language. I'm not arguing for strong typing- but encapsulation would probably help people write better bug-free code. Anyone out there know if there's any reasonable prospect for these structural issues in javascript being addressed at the language level instead of the library level?

Re:Good read so far (2, Insightful)

RetroGeek (206522) | more than 8 years ago | (#14102515)

The central idea behind Ajax is pretty good IMHO- moving as much of the presentation-tier processing as possible to the client system.

Which to me sounds like a stab at re-inventing Java applets.

All the problems you describe (name spaces, libraries, etc) are already solved in Java. In addition, you are not at the mercy of browser JavaScript bugs.

The only downside is the initial startup time for the Java applet, as the local JVM must be loaded, THEN the applet.

As for the JVM version, you can check for this in your applet before you start the dependant code, and you can ask the user to d/w the JVM.

The technology Java Web Start [sun.com] provides an easy to use framework.

Re:Good read so far (1)

jenkin sear (28765) | more than 8 years ago | (#14102636)

Sure, we could use JWS and applets; I've written quite a few. And there's no doubt that java is a better systems language than javascript.

But for some reason, the world has pretty much rejected both technologies. It's probably a combination of things- you need some level of skill before you can just start messing around with java (maybe an IDE, but at least an understanding of how to invoke a compiler and all that). Of course, it's also easy to blame M$ for their adopt and extinguish policy- adopt a craptastic JDK version and let it sit there like a festering boil for seven years until everyone gives up.

I guess if I were designing an app and could control the execution environment, I'd much prefer to use SWT and communicate back to a remote server with RMI, SOAP, XMLRPC or some such- but if I had to write something that worked in most available browsers, I think I'd see a better compatibility mix from an Ajax / Javascript environment.

Re:Good read so far (1)

RetroGeek (206522) | more than 8 years ago | (#14102758)

something that worked in most available browsers, I think I'd see a better compatibility mix from an Ajax / Javascript environment.

Huh?

Using JavaScript you are at the mercy of the Web browser and its implementation. At the most basic AJAX level, IE and Mozilla/Firefox use different methods to instantiate the object which actually does the background communication!

All MS needs to do is change their method, and now you are re-writing all your client side apps to test for yet another method.

Not that I am not using this, but it is only for light interaction.

Re:Good read so far (1)

estebanf (814656) | more than 8 years ago | (#14102845)

just wait here... java applets die by their self mediocrity. They were slow, ugly, long loading and insecure. It doesn't matter that they were wrote in java (great language), it's the crappy framework what sucked.

Javascript namespaces (4, Informative)

brunes69 (86786) | more than 8 years ago | (#14102538)

"Namespaces in Javascript are dead simple, because of function scoping:
window.MyNamespace = new Object() {
function NamespaceMethodA() {
// alert('hi');
}

function NamespaceMethodB() {
// do b code...
}
}

NamespaceMethodA() // Causes exception

MyNamespace.NamespaceMethodA() // works.

Want to "import" a namespace? Include this function in one of your base .js files

function import( namespace ) {
for( i in namespace )
window[i] = namespace[i];
}

You can now do import(MyNamespace) and all it's members will be locally scoped.

The problem in Javascript is not namespaces - it is the fact that there's no way to mark a method/variable as protected/private. So you need to resort to old C-style crap like appending _ to private members if you want to enforce your contracts.

Re:Good read so far (0)

Anonymous Coward | more than 8 years ago | (#14102603)

The alarm bell ringing in my brain is that all of this is structured around a fairly blunt tool in javascript. It does a great job at what it is designed to do- but it seems to require coercion to handle some more sophisticated needs.

I'm no java expert and I don't know didly about AJAX but having said that, why not just use java instead of javascript? My understanding is that pretty much any java code can be run within a browser unaltered. The only difference between a "normal" java program and one to be run in a browser is that the browser version has a few lines of additional initialization code that has to be run at startup.

Re:Good read so far (2, Interesting)

TWooster (696270) | more than 8 years ago | (#14102627)

Well, if you're running web applications, a good bit of IP is in the code, which is client visible. I suspect the best way around all of this is to develop a strongly typed language which compiles down into javascript. Javascript then becomes the intermediate language rather than first-crack. Additionally, the compiler can name variables and functions things that have no relation to the underlying logic of the code, making it much more painful to reverse engineer. (Much like reverse engineering a .NET program, except skipping the translation into human readability.)

Additionally, you could compile with optimizations to meet the capabilities of different browsers. Hell, toss in a little bit of encapsulation in the language "libraries" to avoid all of those layer/div issues. Etc, etc.

Javascript is good at what it does, it just wasn't meant to do quite that much.

Also, anyone wonder why there isn't a "valid CSS" to "IE broken CSS box model" translator? Maybe I ought to write that...

Re:Good read so far (1)

jenkin sear (28765) | more than 8 years ago | (#14102969)

Of course, it might be easier to just compile Firefox / Gecko as an activeX control and embed it in IE... then you could hack in an updated ecmascript interpreter.

Re:Good read so far (1)

oni (41625) | more than 8 years ago | (#14102656)

separation of concerns means you can get away from some of the nastier (and kludgy) template languages like PHP, Cold Fusion, and their ilk.

What?? How do you plan to produce all that pretty xml if not with a server-side language?

I use AJAX with coldfusion all the time. I have an AJAX Service (is that what we're calling them?) that returns the answer to a FAQ question. The AJAX app shows the list of questions. When the user clicks one, it calls the service. The service has to query the database to get the answer to that question. The service is written in coldfusion. php or perl or whatever would work too.

Re:Good read so far (2, Interesting)

jenkin sear (28765) | more than 8 years ago | (#14102705)

Right- that's my point, actually.

Your cold fusion code is now acting an application tier language- it receives a simple query (give me the answer to my FAQ question number 3), and it queries the DB, formats the result as XML, and goes back to sleep.

However, a classic cold fusion site handles the page layout, loads in whatever resources are appropriate for that locale (english, german, japanese, whatever), queries the database, formats the results as a bunch of table tags, and outputs everything.

So you've effectively split your tasks into three tiers- presentation tier (in javascript), application tier (in cold fusion), and data tier (mysql or whatever). You're using cold fusion as middleware- I'd suggest that this is a fine strategy for a one or two developer site, but that you may wish to look to a more maintainable / suitable language for middle tier development- but that's just my $.02.

Re:Good read so far (2, Interesting)

JulesLt (909417) | more than 8 years ago | (#14102801)

Mozilla hace already started implementing some parts of the next version of the ECMAScript spec into JavaScript, and it looks like ActionScript 3.0 has actually gone from being behind JavaScript to being ahead (support of packages and namespaces). The issue, of course, is with what IE and jScript bothers to do (probably nothing if it undermines the XAML/Windows Presentation layer thingy). I still have that same alarm bell ringing, in that you're definitely using a spoon to slice a steak. The browser was never really designed for running dynamic applications, but we've ended up with a set of tools that just about allow it, and enough customer demand to make it worth the effort, but that still doesn't make it the right tool - it's just one millions of people already have. The main plus-side, of course, is that point of 'no installation'. Then again, some Ajax pages are becoming absolute monsters to download that they may as well be apps. So that makes me think of what else is out there that is better at dynamic applications - i.e. actually designed for developing them - and I ended up wondering how long it will be before we rediscover the Java Applet - there's got to be a good reason why Google are pushing rollout of the Sun JVM with the toolbar . . .

Hype (1)

mr.newt (244023) | more than 8 years ago | (#14102449)

the hype may be underselling the prospects for this new buzzword

I'm pretty sure the way hype works is someone says that the current level of excitement about a product is underselling it- this is no different. Particularly, saying that something isn't hype and exaggerating it even further are not good ways to stop hype. It is by definition overselling something. If it isn't hype, just say it isn't hype.

And this is before I even add in my opinion that AJAX is indeed hyped way beyond its usefulness already.

Is anyone else sad this caught on? (0)

PhrostyMcByte (589271) | more than 8 years ago | (#14102451)

XMLHttpRequest isn't very intuitive.

The other better technologies which have been in development will now have an impossible time getting ground to stand on. I fear we will never get out of this now :(

Re:Is anyone else sad this caught on? (1)

Miniluv (165290) | more than 8 years ago | (#14102578)

This has always been my problem with the Internet. Supposedly the best technology wins, but in reality the good enough and already here technology tends to win. Occasionally we get gems like HTTP, but more often we get crap like SMTP.

Re:Is anyone else sad this caught on? (0)

Anonymous Coward | more than 8 years ago | (#14102715)

I don't disagree with the basic premise you're making about which technology wins but I don't think that it's believed that the "best" (assuming that by best you mean technologically superior) tech wins. I think the most useful and customer focused tech wins which in its own way is the best tech. Part of being the best is being practical, here now, and customer/user focused. Technologies that pander to the geeks and nerds of a market segment never do as well as those that are first to market and pander to the common user. This isn't a bad thing it's just how free markets work.

Re:Is anyone else sad this caught on? (0)

Anonymous Coward | more than 8 years ago | (#14102605)


I don't know why AJAX caught on either. once you get the XML, you have to jump through tonnes of hoops to massage the info into usable formats.
I've actually been doing something very similar (and eisier) to this for years.

since NS 3.0 you've been able to use the img.object to send one way info back to server at any time.

add the img.onload and img.onerror and pass back a 1x1 invisible gif on success or nothing on failure and I'd have a simple pass/fail reporting procedure on that method

IN IE 4+ I'd us a hidden IFrame to make requests requiring complex return values from the server. it could be completely in Javascript, for updating form elements or Javascript and HTML and pass up the contents of wrapper elements to be directly plugged into the main page.

NS 4.x let me do thew same thing with an ILAYER (I'd hide the ILAYER tag in an IFRAME and have the best of both worlds).

Prior to those, going way back to NS 2.0 1px high control frame at the bottom of the "app" to return javascript for form apps.

Re:Is anyone else sad this caught on? (1)

ForumTroll (900233) | more than 8 years ago | (#14102632)

I'm with you on this one. In my opinion, Ajax looks like one big nasty hack and definitely not a clean optimized solution to the problem. I can just imagine the mess of Ajax infested applications I'm going to have to try and debug in the future. I've seen way to many developers just trying to use Ajax for anything and everything recently whether it's appropriate to the situation or not.

A peeve of mine mine (1)

nothingbutcoupons (923501) | more than 8 years ago | (#14102452)

"The fundamental ingredients in Ajax are in-browser JavaScript, Cascading Style Sheets, the browser's internal DOM model and asynchronous HTTP requests." DOM Model = Document Object Model Model This is just like NIC Card and PIN Number.

Free AJAX T-Shirt! (2, Informative)

ChaserPnk (183094) | more than 8 years ago | (#14102462)

OK, I know this isn't much of a deal, but it's still good if you buy a lot of books. If you buy AJAX in Action and another Manning book from major bookstores, you'll get a free AJAX T-shirt. A list of bookstores [manning.com] has been posted.

I don't work for Manning, but I'm so in love with their books. The Java GUI programming book alone is worth a million to me. I refer to it almost everyday. I've looked at similar O'Reilly books and they don't even come close! I'm about to purchase Manning's .NET book pretty soon as well.

Happy reading.

ugh (1)

Andrewkov (140579) | more than 8 years ago | (#14102470)

If that lame mime reference is any indication of how this book is written, I'll take a pass on it. ;-)

troll]kore (-1, Troll)

Anonymous Coward | more than 8 years ago | (#14102481)

SLING yo0 can [goat.cx]

Read the FAQ (2, Funny)

nizo (81281) | more than 8 years ago | (#14102485)

...mime performance on a radio show...

If you are having mime problems perhaps this [faqs.org] will help?

testing testing (0)

Anonymous Coward | more than 8 years ago | (#14102489)

testing testing 123

mark my words (0, Flamebait)

hedge_death_shootout (681628) | more than 8 years ago | (#14102509)

AJAX is great, but it only really comes into its own when married with another brand new technology:

  HAHA - ("HTML And HTTP Applications")

Keep your eyes peeled - AJAX + HAHA is going to be huge!

9/10? (0, Troll)

syrinx (106469) | more than 8 years ago | (#14102522)

Surely you mean 8/10?

Clear your mind (1)

Billosaur (927319) | more than 8 years ago | (#14102533)

From the review: You will learn how to ensure your app is flexible and maintainable, and how good, structured design can help avoid problems like browser incompatibilities. Along the way it helps you unlearn many old coding habits.

To quote a famous 900-year old green swamp-dweller, "you must unlearn what you have learned."

This sounds intriguing. Anything that could help mitigate the problems of interfacing and data presentation on the web would be a blessing.

Compatibility (4, Insightful)

kstumpf (218897) | more than 8 years ago | (#14102540)

AJAX represents a new paradigm in UI design for web applications. I don't think there's much question about AJAX's value. You will see two problems though: 1) browser compatibility, and 2) bad code and interface design.

You have to think hard when deciding if your client base is ready for it. The same browser issues exist with AJAX that exist for any other "new" client-side technology. By relying on it, you will exclude visitors.

As for my second point, get ready for a lot of bad AJAX. People have a hard enough time designing interfaces as it is (think of all the bad ones out there), and building dynamic ones that work like people expect them to will be that more complicated.

Italics (0)

Anonymous Coward | more than 8 years ago | (#14102541)

Um, dummy editors - the entire page is in italics because you forgot to close your markup...

Italics (1)

alta (1263) | more than 8 years ago | (#14102569)

Can someone insert an [/i] tag after the bn.com link up there?

Where have I heard this before? (1)

Minwee (522556) | more than 8 years ago | (#14102576)

"Mr. Chappell, Ajax seems to have the momentum of a runaway freight train. Why is it so popular?"

*yawn* (0)

Anonymous Coward | more than 8 years ago | (#14102600)

Someone wake me up when there's a cross-platform graceful-degrading _standard_ for javascripted web apps.

In the meantime I've got another buzzword for you: HTML5 [whatwg.org] .

Only the term is new. (0, Redundant)

prestidigital (341064) | more than 8 years ago | (#14102606)

Ajax is not new. It is also not limited to JavaScript or XML. As long as scripting languages have been able to talk to embeddable controls (small "c"), one has had the ability to make calls to embedded objects that can make asynchronous transactions and return the results to web pages. My colleagues and I have been doing "AJAX" since 2001.

AJAX is ok but... (1)

jar240 (760653) | more than 8 years ago | (#14102617)

...I prefer Comet [cleanandflush.com] .

Chris

Broken HTML? (1)

Xarius (691264) | more than 8 years ago | (#14102618)

Disclaimer: I use Opera

Has anyone else noticed that the entire part of this page past the end of the article is in italics?

How the hell can you miss a closing tag so easily?

Off-Topic I know, but it's the first really broken HTML slipup I've seen on Slashdot.

and of course... (0)

Anonymous Coward | more than 8 years ago | (#14102738)

...it's on an article about web development. Go figure!

Sorry, but (1)

Strixy (753449) | more than 8 years ago | (#14102654)

If it has Java in the title anywhere... I'll pass. It probably has a PDF plugin as well.

Real-world usage (2, Informative)

m2pc (546641) | more than 8 years ago | (#14102658)

I am a developer for a huge PHP/SQL project and we are creating our 2nd generation system using AJAX. As a server/client developer this technology is allowing us to create a much better user experience.

I agree that AJAX has its downfalls ("back button" breaking, JavaScript usage, etc.) but most of these issues are present in "web sites" not "web applications". With a real Web Application, you have more control over the user in terms of requirements, etc. than a public web page.

To get around state change issues, we designed the system to load initial state values on page-load, then update page elements dynamically with AJAX. This cuts down on travel time to/from the server, and if the user hits the "Refresh" button, the state isn't broken.

Re:Real-world usage (1)

Vladislas (537527) | more than 8 years ago | (#14102928)

That's also a good idea, for Accessibility or for those with JS turned off. Personally, I code everything as though JS didn't exist, and then add all that extra functionality on top. In AJAX, I go so far as to simply send back a stripped down version of the page from the server, with its MIME type set to text/xml, parse it and update the AJAX-enabled page accordingly. Saves time and extra work of making up a new XML schema, and also makes life easier if you use Struts. It's as simple as mapping a page to itself.

If it doesn't focus on the technologies being used (3, Interesting)

Tetravus (79831) | more than 8 years ago | (#14102739)

it's useless.
AJAX is a simple concept. Really, it is. Getting three different coding paradigms to work together harmoniously is not so simple. Throw in available AJAX libraries, JSPs and Atlas pages and you've got layers upon layers of coding cruft that need to be understood before a functional, stable, web-app can be built.

If this book stays at the architecture astronaut [joelonsoftware.com] level without ever delving into the why of the code structure of the example programs, then it may serve as a cookbook but certainly not as an informative manual that can provide a baseline from which coders can build their skills.

Perhaps the book is better than the reviewer makes it out to be, but he offers no real justification of the 9/10 score awarded, so it's hard to say. Just for giggles, I should note that when Richard Stevens' seminal Advanced Programming in the Unix Environment, 2nd Ed. [slashdot.org] (being possibly the most comprehensive and useful programming book I've ever read) was reviewed it also received a 9. How do these two books compare?

A Shorter, More Direct Alternative (5, Interesting)

kimanaw (795600) | more than 8 years ago | (#14102798)

I read the sample chapters of the reviewed book and was underwhelmed. Chapter 4 spent way too much time trying to sound "impressive", with lots of UML diagrams and Design Patterns references. Plus, 615 pages for AJAX ? Unless 400 of those pages are weblinks to online references, I'm afraid its just killing a lot of trees.

I just picked up Foundations of Ajax [apress.com] , and its a good, focused 273 pages, of which nearly half is resources and tools for implementing. I haven't had a chance to download and try out the examples, but the reference links all look like great resources. While I wish they'd skipped the usual Chapter 1 "Here's the history of the web" that any reader of the subject matter already knows, all in all, its a great way to cut thru the BS and get rolling with the AJAX concepts.

In summary:

  • If you want to learn UML, buy a UML book
  • If you want to learn Design Patterns, buy the GangofFour book.
  • If you already know how to put together a webpage, write some Javascript, and maybe a little CSS, and just want to understand how it all to hangs together in AJAX, then Foundations of Ajax [apress.com] is probably a better choice than "Ajax in Action".

AJAX inthe Real World (5, Informative)

Heembo (916647) | more than 8 years ago | (#14102804)

In may ways, that book is out-of-date. Here is what is working for me *today*. There are many possibiliites, but my focus is Rapid Application Development - and these tools help me rock and roll, fast.

Last week I was tasked to replace several standard (but sometimes complex) HTML business forms with an AJAX solution. Here are the best tools I found after lots of research time. This is bleeding edge; but functional in Opera, Safari, IE XP, FF XP, FF OSX, no small feat.

1) AJFORM - submit a form via Javascript using HTTP post or get without refreshing the page. (next release in a few days, keep an eye on it, its brilliant and easy to use) http://redredmusic.com/brendon/ajform/ [redredmusic.com] 2) YOUR SERVER CODE - I use Java, but anything including ASP, CF, PHP - its all works. (Standard HTTP). Just needs to spit out XML, easy feat. 3) GOOGLES XPATH LIB - those of you who use Sarissa, drop it - she does not support Safari. Google's XPATH lib does, well, on all browsers you need. http://goog-ajaxslt.sourceforge.net/ [sourceforge.net] - this is the best and easiest way to "search into" XML data. You can use native DOM calls, but it takes about 10x as much time to get it right.

With AJFORM and Googles XPATH lib on the client, I was able to quickly and effectively start making business forms in AJAX that were "scarry fast" and WOW'ed all the folks who are paying the bills! YAY!

Whats your architecture for AJAX?

Ajax in action... (0, Offtopic)

PietjeJantje (917584) | more than 8 years ago | (#14102876)

Ajax join Arsenal in the final 16

Tuesday, November 22, 2005 Posted: 2159 GMT (0559 HKT)

AMSTERDAM, Netherlands (Reuters) -- Ajax reached the Champions League knockout phase as two second-half goals by substitute Nigel de Jong gave them a 2-1 win over Sparta Prague in Group B on Tuesday.

De Jong struck after 68 minutes with a powerful close-range header and grabbed his second in the 89th when he struck a low 16-meter drive past keeper Jaromir Blazek.

Sparta captain Martin Petras got a late consolation for the visitors who battled until the end but lacked the firepower up front to trouble the Dutch side.

With one match left Ajax have 10 points from five games and will finish second behind Arsenal, who have 15 points after beating FC Thun 1-0 with a late Robert Pires penalty.

http://edition.cnn.com/2005/SPORT/football/11/22/c hampions.groupb/ [cnn.com]

AJAX is Open-Source Lotus Notes? (1)

sanman2 (928866) | more than 8 years ago | (#14102889)

So aren't the main attractions to Ajax that it has Lotus Notes type of functionality, but without that pricetag?

My problem with Ajax... (1)

Cow Jones (615566) | more than 8 years ago | (#14102942)

... is not the technology (which isn't new, as several others have already commented) or the hype (which is fine by me), but the way this buzzword has come into existence. The article that started it all is "Ajax: A New Approach to Web Applications" [adaptivepath.com] , written by Jesse James Garrett. I admit this is somewhat irrational, but from the moment I saw the guy's smug face, I was on my guard. The article confirmed my suspicions - he puts up some pretty diagrams explaining something that people have been doing for years, gives the thing a catchy name, and goes down in history as The Man Behind Ajax. Mission accomplished. The acronym AJAX doesn't even describe the thing well: the XML-part is absolutely optional, and often does nothing more than slow down performance and "put XML into the application somewhere".

Maybe he deserves some credit for giving it a name. Maybe. All I know is that every time someone mentions Ajax as the "next big thing" (and maybe even puts up a link to that horrible article again) it sets my teeth on edge.

/rant

Reminder about browser abilities. (2, Insightful)

dghcasp (459766) | more than 8 years ago | (#14102979)

Don't get me wrong, AJAX is really cool. But if you develop your site using it, you'll be making your site inaccessable to anyone using MacOS9 or older browsers on Windows or *nix.

From the records of the site I maintain, about 6% of all accesses are from browsers that can't handle AJAX.

Incidently, from my over-optimistic decision to do all the layout for the site in CSS, those 6% also took 75% of the time and are responsible for 1/2 of the .css file being "hacks." Never again. Tables rule.

Awesome book. (1)

dep01 (730107) | more than 8 years ago | (#14102994)

Sitting right here on my desk right now. I highly recommend it.

Is Ajax the next big thing or is Google? (1)

heroine (1220) | more than 8 years ago | (#14103017)

The hype is supposed to be around a small programming technique but it feels like the only reason anyone cares about Ajax is because Google's outstanding advertising uses it in some capacity. But isn't it really advertizing that's big?

A few years ago multithreading was the next big thing, but no-one starts a company today to specialise in multithreading. Now multithreading is called Asynchronous JavaScript+XML and we're supposed to think it's more substantial than multithreading because no-one can be told what it is without experiencing it for themselves, taking a red pill, and learning everything there is to know about CSS, JavaScript, XML.

Based on the appliications, it's multithreading and it's just as hard to see entire companies revolving around it today as it was in 1997.

Ajax Killed Himself (5, Insightful)

laoc00n (933461) | more than 8 years ago | (#14103029)

Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

< /i > (1)

0kComputer (872064) | more than 8 years ago | (#14103035)

did it work?
Load More 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>