Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
AJAX - beyond the buzzwords

By n8f8 in Technology
Tue Aug 23, 2005 at 07:33:11 PM EST
Tags: Internet (all tags)
Internet

Since Google decided to use SOAP/XMLHTTP for their new map interface the geek web has been flooded with AJAX articles. Here I will discuss the importance of AJAX as well as some of the tradeoffs developers will encounter if they choose to use this technology. More importantly, I have also posted a version of this article with a running demo on my website (recommended). You can also download the article source and try it for yourself.


AJAX is a less than informative name for combining DHTML(JavaScript & HTML) and XML technologies to create fancier web interfaces. Wikipedia gives a decent definition for AJAX but I would describe it thus: Traditional web applications squirt out serial HTML strings to produce web pages, refreshing the entire page every time a user clicks a link or button. AJAX pinpoints only the information on a page that needs to be changed and gets the new information in the background. So ,regardless of who coined the term AJAX, it is a technique we will see employed more often.

Before AJAX, web developers resorted to various techniques (hacks) to pass bits of information back and forth with the server to update a page. One popular technique was to request pages within hidden IFrame or Frame elements that could then be accessed using JavaScript. Another was to popup a window that requested the updated data and wrote it back to the parent(opener) window. Developers also used hidden form fields and IE inline XML to store additional information on the client. In short, developers came up with many techniques to achieve what AJAX achieves to elegantly.

One of the core technologies behind AJAX is the XMLHTTP Request object - think of it as a tiny hidden web browser. The XMLHTTPRequest method was actually pioneered by Microsoft in IE4 for their Outlook Web Access email client software. When a user interacts with a page this tiny browser requests, in the background, just the information needed. Another technology, the XML Document Object Model (DOM), allows the developer to treat each page as a tree with branches and leaves that are easily added or changed.

Using AJAX is a tradeoff. You gain greater control over a document and reduce the amount of information that must be passed from client to server. You also avoid the annoying flicker of page refreshes on pages that need to be frequently updated. Unfortunately, you also increase the complexity of the application and risk browser incompatibilities. Instead of simply printing text back at the request of a client browser you now have to script the interaction back and forth between the client and server. These drawbacks and not ignorance, as some articles have implied, have caused developers to shy away from AJAX. Developers want to maximize the number of people who can see their pages. But times have changed. The vast majority of web surfers now use browsers that support AJAX.

Here is a simple application(download source here) to display funny definitions from a dictionary document located on the Project Gutenberg site titled 1811 Dictionary of the Vulgar Tongue by Captain Grose. On the server we will have a PHP Application server connecting to a MySQL database to query for random definitions. In PHP we will convert the recordset to XML for consumption by the client. On the client we will query the server at a timed interval using XMLHTTP and use the XML DOM to update the page using XML DOM methods.

Remember the tradeoff I mentioned? To use AJAX in the most beneficial way, you should focus on efficiency. Not just replacing the part of the page you wish to replace, but also minimizing bandwidth. For instance, assume this page weighs in at a slim 10Kb. If you wanted to display updated definitions (or stock quotes) by refreshing the page that comes to 60Kb per minute, 3600Kb per hour and so on. Using AJAX we can query our server for just the definitions, that weigh in around 1KB.

Before you go off and jump into a bathtub full of saved bytes to celebrate, remember to be miserly with the XML being passed each time. Don't waste space with hugeElementNamesThatWasteSpace. Below is an example XML fragment to demonstrate the "definition" XML being used on this page. I saved space by having one letter element and attribute names and placing the data in the attributes of each element. For those wanderering off in a rant over this technique, the purpose of this XML is simply transporting data within an application, not between applications. If the information were for external consumption I too fall into the camp with folks demanding self-describing syntax

<t> <r t="PELL-MELL" d="Tumultuously, helter skelter, jumbled together."> <r t="LURRIES" d="Money, watches, rings, or other moveablcs."> <r t="SNEAKING BUDGE" d="One that robs alone."> <r t="DEVIL'S DAUGHTER'S PORTION:" d="Deal, Dover, and Harwich, The Devil gave with his daughter in marriage; And, by a codicil to his will, He added Helvoet and the Brill; a saying occasioned by the shameful impositions practised by the inhabitants of those places, on sailors and travellers"> <r t="STAR LAG" d="Breaking shop-windows, and stealing some article thereout."> </t>

Also keep in mind that AJAX is much more powerful than simply a tool to build rotating banners. You can interact with the data to, for instance change the number of records returned, the refresh rate or toggle the program. It can be a methodology to build rich web applications that are much more responsive than typical click and refresh programs.

For this article I have intentionally kept the server end of things simple. We could create a Web Service with a nice WSDL definition, but I'll save that for another article if anyone is interested.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
AJAX is?
o DHTML 29%
o Cross browser XUL 8%
o Better than nasty refreshes 43%
o Harsh SOAP? 18%

Votes: 37
Results | Other Polls

Related Links
o Google
o map interface
o AJAX
o posted a version of this article with a running demo
o download the article source and try it for yourself.
o less than informative
o definition for AJAX
o coined the term
o IFrame
o Frame
o opener
o inline XML
o XMLHTTP
o XML Document Object Model
o vast majority
o Here is a simple application
o download source here
o Project Gutenberg
o 1811 Dictionary of the Vulgar Tongue by Captain Grose
o just the definitions
o Below is an example XML fragment
o Also by n8f8


Display: Sort:
AJAX - beyond the buzzwords | 130 comments (104 topical, 26 editorial, 0 hidden)
-1, buzzword filter failed. (2.00 / 8) (#1)
by Pooping in Urinals on Mon Aug 22, 2005 at 06:34:12 PM EST

RELEVANT MATCHES: AJAX, XML, Google, geek

"...[T]he first midget amputee getting bukkaked by 20 japanese buddhist monks and I bet your gonna say 'well thats what the miscellaneous column is for.'" -- army of phred

Why are you using 'buzzword' as a buzzword? [nt] (1.50 / 2) (#4)
by artis on Mon Aug 22, 2005 at 07:44:41 PM EST


--
Can you know that you are omniscient?
[ Parent ]
caveat emptor (2.72 / 11) (#2)
by circletimessquare on Mon Aug 22, 2005 at 06:41:55 PM EST

sorry for the forthcoming rant author, this is a very useful article, i just have a chip on my shoulder:

paraphrasing the (instructive and useful) author of this article:

  1. ajax the functionality has been around for 6 years or more
  2. the buzzword "ajax" and the google maps implementation that skyrocketed the word to buzzword status has only been around for less than a year
i'm usually not one to champion geek snobbery

but when geek snobbery is pitted against cattle herds of phbs spouting buzzwords with little understanding of the buzzword itself, geek snobbery is more appealing

folks: use ajax, it really is The Next Big Thing (tm)

but let the real lesson be how technology can be neglected and then suddenly thrust into the spotlight, simply because someone influential (google in this case) put their seal of approval on it

so, when you code, think like the google employee(s) who went with ajax the first time around: they did it because it was smart

don't code because there is a phb buzzword attached to the technology

friends don't let friends code with buzzwords


The tigers of wrath are wiser than the horses of instruction.

Submit this comment to the queue, +1 FP nt (none / 1) (#6)
by Ralp on Mon Aug 22, 2005 at 07:55:02 PM EST



[ Parent ]
Tech Demo (none / 1) (#7)
by n8f8 on Mon Aug 22, 2005 at 08:20:20 PM EST

I guess I envisioned two interrested groups of people for the article 1) Folks who keep hearing this stupid AJAX buzzword and don't have a clue and 2) Geeks who are sick of all the AJAX talk and just want to see a simple demo.

Most of the code for this article was written by me back in early 2002 when I wrote a cross browser chat app using XMLHTTP. I just rewrote the backend in PHP and tweaked the XML DOM code a little.

Sig: (This will get posted after your comments)
[ Parent ]

it's important and a good article (none / 0) (#8)
by circletimessquare on Mon Aug 22, 2005 at 08:51:57 PM EST

unfortunately, if you have any negative reaction to your story, it will simply be kneejerk backlash from any geeks who are sick of the ajax buzzword

modify your intro so that you tip your hat to their sensitivities about the issue (whether valid or not) simply because there's a lot of negative kneejerk geeks out there with easy access to the -1 vote button ;-P


The tigers of wrath are wiser than the horses of instruction.

[ Parent ]

Better? (none / 1) (#10)
by n8f8 on Mon Aug 22, 2005 at 09:13:58 PM EST

AJAX - beyond the buzzwords?

Sig: (This will get posted after your comments)
[ Parent ]
blessed, you cleaned it up nice (none / 0) (#11)
by circletimessquare on Mon Aug 22, 2005 at 11:43:42 PM EST

did you use ajax or comet? ;-)


The tigers of wrath are wiser than the horses of instruction.

[ Parent ]
even better (none / 0) (#9)
by circletimessquare on Mon Aug 22, 2005 at 09:00:00 PM EST

modify your title: "AJAX: beyond the hype" or something like that

because otherwise you'll have geeks scanning your headline and voting -1 simply on that anti-buzzword kneejerk ;-P


The tigers of wrath are wiser than the horses of instruction.

[ Parent ]

technology stability (none / 1) (#113)
by cycnus on Sun Aug 28, 2005 at 10:08:31 PM EST

true that such technology has been around for a while but I guess no-one really used it because:

1) until MS decided not to update IE6 there was a new browser with new functionalities every couple of years, meaning you wouldn't know if your app would still work fine after a while.

2) cross-browser was and is still hard to write and there were not that many good libraries to implement Ajax-style functionalities. Now there are quite a few and it makes coding simplier.

3) there were no really good and complete framework on the server side to implement that sort of functionality, meaning that you had to roll and test your own.

4) the cost associated with having to extensively code and test everything yourself rather than using working and rich third-party libraries and frameworks meant that Ajax-like functionalities were usually non-starters.

5) not that long ago the public at large was told a lot to switch off cookies and javascript in their browser, making things a bit more uncertain for JS-dependent apps. Now it seems that this trend has disapeared a bit.

6) until recently older computers (remember Win98, IE4?) with older browsers were still too ubiquitous to be able to count them out, making the job of developping rich-JS for a wide audience apps a misery.

7) I'm sure that google investigated heavily whether people were still switching off JS support or using older browsers and found out that they weren't. Otherwise google would not have relied on it so much for gmail and google maps.

So it may have taken someone like Google -an independent party in the browser war- to find out that rich DHTML functionalities could be implemented and work for enough people that it would become actually useful and pratical to do so .

[ Parent ]

that XML fragment (2.66 / 3) (#13)
by speek on Tue Aug 23, 2005 at 12:38:06 AM EST

Good god, why don't you just admit XML was a shitty choice for your communication syntax? You could save several more bytes of space by dumping the pointless angle brackets and one letter tag names and attribute names. Just send over the strings you want in the right order. That'd be about as robust as this crap, and a bunch shorter.

I'll never understand why people use xml for this type of crap.

--
al queda is kicking themsleves for not knowing about the levees

Well, (3.00 / 4) (#14)
by trhurler on Tue Aug 23, 2005 at 01:17:08 AM EST

It is worth pointing out that "saving space" is nearly last on any sane person's list of criteria for a serialization method these days.

--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
if you're going to use XML (none / 0) (#48)
by speek on Tue Aug 23, 2005 at 02:19:34 PM EST

then yes, saving space shouldn't be a priority. If it is, you've already made a seriously bad choice! Which was my point...

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

No, (none / 0) (#83)
by Harvey Anderson on Wed Aug 24, 2005 at 12:18:03 PM EST

it is not worth pointing that out.

[ Parent ]
Oh, sweet irony! (none / 0) (#104)
by trhurler on Fri Aug 26, 2005 at 08:12:15 PM EST



--
'God dammit, your posts make me hard.' --LilDebbie

[ Parent ]
interop (3.00 / 2) (#17)
by Hung Fu on Tue Aug 23, 2005 at 04:14:01 AM EST

XML is used because it's a self describing format, and nobody cares about the extra bytes anymore, particularly if you use GZIP compress it. However, I agree that this whole technology is shitty. A platform based on Javascript? What the fuck were they thinking

__
From Israel To Lebanon
[ Parent ]
self-describing? (none / 1) (#49)
by speek on Tue Aug 23, 2005 at 02:21:48 PM EST

To whom was this self-describing? And plenty of people care about the extra bytes - not necessarily because of bandwidth restrictions, but because of cpu limitations when it comes to serializing and deserializing thousands and millions of xml dom trees.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Bah (none / 1) (#22)
by Masklinn on Tue Aug 23, 2005 at 08:14:38 AM EST

While XML is clearly overkill in this case (raw text with simple separators would've been more than enough) it's nice when you send complex structures over the wire that you can then parse through the DOM api in order to rebuild the HTML DOM



[ Parent ]
it can be nice (none / 0) (#50)
by speek on Tue Aug 23, 2005 at 02:24:10 PM EST

but it's nothing that couldn't be done in plenty of other ways. AJAX isn't gaining anything by being xml based. And the crap example in the story just throws out all the advantages XML might have had over alternatives.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Content-Encoding: gzip (3.00 / 2) (#57)
by astatine on Tue Aug 23, 2005 at 04:36:06 PM EST

and watch the redundancy collapse, at the expense of a few more CPU cycles. I've had a half-megabyte of SOAPy crap collapse down into about 8k that way before.

Society, they say, exists to safeguard the rights of the individual. If this is so, the primary right of a human being is evidently to live unrealistically.Celia Green
[ Parent ]
not the problem (none / 0) (#60)
by speek on Tue Aug 23, 2005 at 06:24:32 PM EST

You have haven't done anything about the cycles spent serializing and deserializing xml. You also missed the irony of someone choosing xml for data that doesn't need it, and then worrying about space issues and "solving" it by choosing one letter tag/attribute names.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Cycles? (none / 0) (#68)
by piranha jpl on Wed Aug 24, 2005 at 03:20:18 AM EST

CPU expense from XML in an application like this is negligable.  I agree that his element/attribute naming was wrong, but have you considered XML and DOM could be more convenient?  In plaintext, not even line-endings are standardized.


- J.P. Larocque
- Life's not fair, but the root password helps. -- BOFH

[ Parent ]
an application like this? (none / 1) (#71)
by speek on Wed Aug 24, 2005 at 09:13:32 AM EST

You mean an app unlikely to get more then 2 concurrent users? Have to agree. But then, that kind of limits the potential of AJAX.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Web services (none / 0) (#63)
by schwar on Wed Aug 24, 2005 at 01:33:17 AM EST

If you are interacting with an application that has been developed using a web services then XML makes a lot of sense.

Since this is becoming industry standard it makes more sense to do it that way than making your own custom protocol with potential to create a maintenance nightmare for someone else down the track.

[ Parent ]

I don't get it (none / 0) (#73)
by speek on Wed Aug 24, 2005 at 09:25:36 AM EST

Maintenance nightmares are not caused by not following standards - they're caused by writing crappy, undocumented code. Using SOAP doesn't get you maintainable software if you wrote your stuff in crappy fashion. Not using SOAP, but writing nice, comprehendable code can just as easily get you an easy to maintain network of services. There's no shortage of ways to communicate over the wire.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Schwar has management written all over him. $ (none / 0) (#90)
by skyknight on Wed Aug 24, 2005 at 10:08:10 PM EST



It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
off topic question: (none / 0) (#107)
by zrail on Sat Aug 27, 2005 at 06:45:29 PM EST

is '$' the new 'n/t'? if it is I totally missed the meme jump.

[ Parent ]
I say it is, but suit yourself. $ (none / 0) (#111)
by skyknight on Sun Aug 28, 2005 at 11:30:06 AM EST



It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
Sometimes things become industry standards... (none / 0) (#91)
by skyknight on Wed Aug 24, 2005 at 10:10:10 PM EST

because somehow a bunch of idiots with too much power and not enough domain specific knowledge end up in the same room making decrees.

It's not much fun at the top. I envy the common people, their hearty meals and Bruce Springsteen and voting. --SIGNOR SPAGHETTI
[ Parent ]
ajax's heavy js turns developers into assholes (2.00 / 4) (#15)
by I ABHOR TROLLS on Tue Aug 23, 2005 at 01:55:05 AM EST

who are too lazy to support multiple browsers even when it is possible

We don't see anything special behind the words (1.50 / 2) (#18)
by United Fools on Tue Aug 23, 2005 at 04:42:43 AM EST

We opened the AJAX box, cutting out the words, and there is nothing in the back?
We are united, we are fools, and we are America!
-1, count the abbreviations! (1.00 / 2) (#19)
by Pat Chalmers on Tue Aug 23, 2005 at 05:52:06 AM EST



Not wasting space with clear tags? (3.00 / 3) (#23)
by nietsch on Tue Aug 23, 2005 at 08:39:57 AM EST

I have heard for a long time that xml takes up too much bandwidth, probably because of the overhead of longish tags and brackets. I have never understood that argument, is it so hard to put extra gzip compression into the transport layer? Even http can do that transparently.

Using undescriptive tags like the one you suggest break the easy self-descriptiveness of xml. If you need it that much i suggest you reduce your communications even further and start using induvidual bits to code your info. Using single letters for (important)variables names is bad coding practice, why should it be different for xml?

Languages wars are good (none / 0) (#24)
by Masklinn on Tue Aug 23, 2005 at 08:46:37 AM EST

I have heard for a long time that xml takes up too much bandwidth, probably because of the overhead of longish tags and brackets. I have never understood that argument, is it so hard to put extra gzip compression into the transport layer? Even http can do that transparently.

But some UAs have... issues... with gzip-compressed HTTP packets (see MSIE)

And compressed or not, XML tags are still overhead, and sometimes unnecessary one (even more when the XML scheme is fucked up) and full of useless/redundants elements on top of the already redundant XML shit)

XML and XML based languages may be useful, but they're not the best thing since sliced bread as many XML junkies would want us to believe, and currently they're more often than not misused (java apps alone generated about 75% of the useless abused XML nonsense by dropping heaps of their poo in each and every damn blasted configuration file when good ol' .conf/.properties files would have been more than enough more often than not)



[ Parent ]
Huh (none / 0) (#25)
by Hung Fu on Tue Aug 23, 2005 at 08:54:00 AM EST

(java apps alone generated about 75% of the useless abused XML nonsense by dropping heaps of their poo in each and every damn blasted configuration file when good ol' .conf/.properties files would have been more than enough more often than not)
Properly done XML configuration is light years better than property file stuff, particularly when combined with beans. With a sophisticated enough schema, including references, collections and inheritance, XML can become just as powerful as programmatic configuration. Not to mention it's helpful for aspect-oriented programming and essential for inversion of control.

__
From Israel To Lebanon
[ Parent ]
well (none / 0) (#26)
by Masklinn on Tue Aug 23, 2005 at 09:07:50 AM EST

Properly done XML configuration is light years better than property file stuff, particularly when combined with beans.

The point was not a cock contest but "which tool for which job". In most configuration files I see, XML not only obfuscates the overall file but isn't even needed, file would be simpler, leaner and more efficient (both space-wise and parsing-wise) without the fucking XML bloat everywhere

With a sophisticated enough schema, including references, collections and inheritance, XML can become just as powerful as programmatic configuration.

Who gives a flying fuck about that? XSL is already turing-complete, who cares? who uses it that way? No one, because it'd be stupid at best, because there are better tools for the same job.

The point is not that XML is useless, it's clearly not, it's that it's overused, overabused and overkill in most situations where it's currently used.



[ Parent ]
Not talking about XSL (none / 0) (#27)
by Hung Fu on Tue Aug 23, 2005 at 09:36:15 AM EST

In most configuration files I see, XML not only obfuscates the overall file but isn't even needed, file would be simpler, leaner and more efficient (both space-wise and parsing-wise) without the fucking XML bloat everywhere
Efficiency and space considerations are the last thing you want to worry about in a configuration file. The real issue is having enough power to replace programmatic configuration with declarative configuration and supporting interoperability. XML delivers on both counts. Property files just suck.

Who gives a flying fuck about that? XSL is already turing-complete, who cares? who uses it that way? No one, because it'd be stupid at best, because there are better tools for the same job.
I'm not talking about XSL! I'm talking about using XML to configure javabeans via a factory class.

Who gives a flying fuck? Who uses it that way? J2EE developers who want to set up servlets, filters, interceptors, etc. without resorting to programmatic configuration. Developers who want to set up complex transaction management and security frameworks using AOP. Basically, anyone doing large scale application programming with half a brain should use XML for configuration. Property files are nearly always inferior, because there is no defined schema, no power or structure and they simply aren't designed for interoperability.

__
From Israel To Lebanon
[ Parent ]

ugh, terrible (none / 0) (#52)
by speek on Tue Aug 23, 2005 at 02:39:36 PM EST

XML in configuration files as you describe has essentially become a full-blown scripting language. And XML-freaks seem to think that just because it's all XML it means they're not having to learn a new language with every app that does this, when, in reality, you have to spend hours reading the manuals of each app to understand their particular semantics. And then on top of that you have the verbose, hard-to-read disgustingness that is xml.

At that point, using an actual scripting language would be a much better option.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

You don't get it (none / 0) (#67)
by Hung Fu on Wed Aug 24, 2005 at 03:16:41 AM EST

XML in configuration files as you describe has essentially become a full-blown scripting language. And XML-freaks seem to think that just because it's all XML it means they're not having to learn a new language with every app that does this, when, in reality, you have to spend hours reading the manuals of each app to understand their particular semantics. And then on top of that you have the verbose, hard-to-read disgustingness that is xml.
It's not a full-blown scripting language, it's declarative rather than programmatic, that's the whole point! There are no imperative statements. Secondly, you aren't having to "learn a new language", you're just wiring beans together using the Javabean standard (i.e. getters, setters, null constructor). Of course you have to read the manuals, but the Java beans have a 1-1 relationship with Java classes so you can apply existing knowledge rather than having to look up arbitary bindings to a scripting language.

Personally I don't criticize methodologies until I've tried them myself. Have you ever tried this approach, or AOP or IOC? It's one of those things you just have to do to understand just how useful it is.

__
From Israel To Lebanon
[ Parent ]

just plain untrue (none / 0) (#72)
by speek on Wed Aug 24, 2005 at 09:22:03 AM EST

I've used Apache Avalon, and I've used Spring. I've also written two IoC frameworks myself, one Avalon-like, and one that uses AspectJ. The XML for Avalon and Spring was not just "wiring beans together using the Javabean standard". It was XML that was specific to Spring and Avalon, and it was necessary to read *those* manuals to know how to do it. A declarative script is still a script, "full-blown" being a very subjective term. I find most people turn their Ant scripts into procedural algorithms because writing it in a purely declarative manner is actually harder for them.

I'm not sure what you mean by "arbitrary bindings to a scripting language". In Groovy, I can access java objects naturally, using Java syntax, talking to those objects methods. Property files are even simpler.

Everyone regrets now that Ant was written with XML, and eventually everyone will regret the same thing about Spring. You'll see.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

What's "Groovy"? (none / 0) (#74)
by Hung Fu on Wed Aug 24, 2005 at 09:49:44 AM EST

You see, to use Groovy a developer would need to read the manual too, and because it's a full-blown, imperative scripting language it would probably be even more complex than understanding the simple and intuitive XML you'd find in, say, Spring.

And then some idiot would start putting lots of unnecessary code in the configuration files which would have to be maintained and so on.

The language of choice for any application should be just as strong as is necessary, no more. The point of configuration files is to separate the imperative and declarative code. Imperative code shouldn't be in configuration files. Property files are too weak, scripting languages are too strong. XML is perfect.

Despite what you say, a declarative bean schema is not equivalent to a script. You simply cannot do certain thinsg with the XML configurations. It's a powerful restriction and encourages developers to do things The Right Way.

Everyone regrets now that Ant was written with XML, and eventually everyone will regret the same thing about Spring. You'll see.
But Ant and Spring are completely different. And it's not true that "everyone" regrets that Ant was written with XML, only people who prefer old-style makefile cruft and who don't like change do.

__
From Israel To Lebanon
[ Parent ]
indeed (none / 0) (#78)
by Masklinn on Wed Aug 24, 2005 at 11:32:43 AM EST

the simple and intuitive XML you'd find in, say, Spring

Ok, i've been had, it was a very nicely crafted troll and you got me, but you blow yourself with that one. Every sane man knows that XML files are not simple, and are about as intuitive as coding in ASM



[ Parent ]
It depends on the schema, of course (none / 0) (#81)
by Hung Fu on Wed Aug 24, 2005 at 12:13:02 PM EST

XML itself is extremely simple and minimal and there lots of editors for it that can automatically validate. But like I said the Spring XML schema is particularly simple and elegant.

<bean class="package.User">
    <property name="name"><value>John Smith</value></name>
</bean>

What part of that is difficult to understand?

__
From Israel To Lebanon
[ Parent ]
Great example (none / 0) (#121)
by v1z on Wed Aug 31, 2005 at 08:44:19 AM EST

<property name="name"><value>John Smith</value></name>

*shudder*. This is exactly the type of problems you get with xml files. It's easy to parse programatically (relatively, anyway), but it's hard to read, and hard to write by hand.

<property name="name"><value>blah</value> ? If you find that intuitive, you've been using xml too long. The *intutive* way would be:

<properties>
 <name>blah</name>
 <otherprop>somevalue</otherprop>
</properties>

Either way you're no better off than having any other type of file -- it's application specific, making it xml instead of ascii/utf-8 doesn't make it easier to read, or parse. It does make it easier to check automatically -- but you only get a syntax-check. If the schema validates, you still know nothing of wether the sematics are correct.

Configuration files *are* shared data, you want to parse them in a cron-job, make automated reports with a perl-script, check for security (mis)configurations in your homemade perl script (say, to check for allow/deny ip addresses) -- and having them in a standard format is good. But 9 out of 10 times it doesn't help to have them in XML. All it means is that instead of parsing line-by-line, you parse element by element.

The only benefit I see with using XML in these cases, is that it naturally scopes information, and allows for easy iteration over "objects" or groups of elements. The alternative syntax:

bean: "somebean"
  name: "blah"
  otherprop: "something else"

is "harder" to parse, because you don't have a ready made parser (using XML DOM). If you're iterating you have to keep state manually -- basically do everything the xml-parser does for you. Ofcourse, writing a parser for the simpler syntax is easier -- and you could even write parser that emits xml.

Well, it's a long and winding post, but the bottom line is XML is a very bad choice for human parsing. It's verbose, hard to read, and hard to write by hand. Which makes it a poor choice for storing configurationfiles, but a good choice for serializing other data.

[ Parent ]

no (none / 0) (#109)
by speek on Sun Aug 28, 2005 at 08:20:10 AM EST

And it's not true that "everyone" regrets that Ant was written with XML, only people who prefer old-style makefile cruft and who don't like change do.

I don't think the inventor of ant prefers makefiles.

And regarding learning "XML" - XML isn't something you learn and then you know Spring. Each and every application that uses XML in their own way represents it's own language to learn. XML has bought you nothing there, and that's my point. Using Groovy buys you nothing as well, except that it's a more natural syntax to be scripting in.

And I've been around far too long to believe we can protect ourselves from idiots by limiting our tools. Idiots always win that battle.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

internel XML (none / 1) (#30)
by n8f8 on Tue Aug 23, 2005 at 10:02:31 AM EST

Without wasting too much time: in this case the XML is the method I use to pass information within the application, not to share it with other applications. The need to keep bandwidth consumption is greater than the need for prettyElementNames. XML is still bettee than text because I can use DOM methods when the data gets on the client to access any part of the XML document and the page itself.

Sig: (This will get posted after your comments)
[ Parent ]
Silly (none / 0) (#95)
by Fireklar on Thu Aug 25, 2005 at 09:04:04 AM EST

That's just silly. gzip would reduce the size of the file far more effectively that using reallySmallElementNames. Assuming that's not an option, why use XML? Most of the reasons for using XML is that other people can read it. If other people aren't going to read it, why use XML?
-Fireklar
[ Parent ]
DOM (none / 0) (#98)
by n8f8 on Thu Aug 25, 2005 at 10:58:10 AM EST

At a minimum because you get to use DOM methods.

Sig: (This will get posted after your comments)
[ Parent ]
Why not just output HTML... (none / 0) (#103)
by wvenable on Fri Aug 26, 2005 at 06:07:58 PM EST

...and set it with innerHTML than going through the bother of actually processing the response from the server?

You don't need the DOM methods, you don't need anything at all.

[ Parent ]

innerHTML is the DOM (none / 0) (#105)
by n8f8 on Fri Aug 26, 2005 at 10:22:01 PM EST

I've done it that way too. innerHTML is often faster than creating DOM nodes.

Sig: (This will get posted after your comments)
[ Parent ]
-1 If you are not a real developer don't vote. (2.25 / 4) (#41)
by tweetsybefore on Tue Aug 23, 2005 at 01:04:12 PM EST

I personally do not like the word AJAX. It is all hype. I just call DHTML like it is supposed to be called. That being said this article contains no javascript source code whatsoever. It is an article written just to hype up this guys website and improve this guys pagerank. This is not the best article on how to do DHTML either. It also fails to mention a bug with firefox that many may come across when using the XMLHttpRequest object. If you do requests synchronously such as

req.open("GET","url",false);

firefox will hang for a while, perhaps a second or more.

Another bug he unfortunately left out is the caching behaviour is different for Internet Explorer and Firefox. In order to make IE behaviour the same as firefox you must use  

req.open(...);
req.setRequestHeader('If-Modified-Since','Fri, 15 Nov 1977 09:42:28 GMT');
req.send();

Although the author adresses the bug in his code with a crude Math.random() hack he fails to mention the existence of the bug in the article. This is an amateurish oversight that could result in hours lost in time if one were to start trying things out on their own.

An experienced developer and documentation writer would not have made these mistakes. I suggest all who care about good documentation and development to -1 the article.

I'm racist and I hate niggers.

Tard (none / 1) (#43)
by n8f8 on Tue Aug 23, 2005 at 01:40:28 PM EST

The JS is on the linked site because A) This article isn't for the hardcore WebDEv who thinks he knows it all B) The linked page has all the code you could want. I originally had some JS but Kuro5hin doesn't allow the PRE tag so it looked like shit (CODE doesn't keep spacing). Also note I recommended reading the linked article primarily because the code is actually being demonstrated and it keeps a rolling tally of KB saved (a major point of using this method). I could have gone over the code line-for-line but I weas trying to address the topic in a relatively non-technical way. I fail to see how my "crude crude Math.random() hack" is worse than your HTTPHeader hack. Of course, when I wrote the code back in early 2002 the existance of that bug might not have been well documented.

Sig: (This will get posted after your comments)
[ Parent ]
Your Math.random() hack isn't guaranteed to work. (none / 0) (#53)
by tweetsybefore on Tue Aug 23, 2005 at 02:52:34 PM EST

Although the possibility is small it still exists. Setting the headers is the correct solution and it will always work.

I'm racist and I hate niggers.
[ Parent ]
screw ajax (2.75 / 4) (#46)
by j1mmy on Tue Aug 23, 2005 at 01:53:59 PM EST

I had been building an AJAX app but found that it got very javascript-heavy with all the XML parsing it had to do. What I ended up doing is spitting javascript back from the server instead of xml, and eval()'ing it on the fly. Adding new functionality is far, far, easier.


Huh? (none / 0) (#47)
by n8f8 on Tue Aug 23, 2005 at 02:15:57 PM EST

I coult 22 lines for two functions to query the server and return an XML object -cross browser. How is that JS heavy? Beyoen that the code is just simple DOm stuff. getElementByID, innerHTML, childnodes, etc.

Sig: (This will get posted after your comments)
[ Parent ]
simple DOM stuff? (none / 0) (#51)
by speek on Tue Aug 23, 2005 at 02:29:02 PM EST

Why aren't you considering the lines of code that deal with the DOM? Maybe his point is that he was able to avoid all that as well.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

You mean... (none / 0) (#55)
by n8f8 on Tue Aug 23, 2005 at 03:25:42 PM EST

Hard to imagine being able to access an object and change its content or append children faster than the getElementById? What do you do that is faster?

Sig: (This will get posted after your comments)
[ Parent ]
faster? (none / 0) (#61)
by speek on Tue Aug 23, 2005 at 06:31:13 PM EST

I thought we were talking lines of code here. How about just talking to the object directly? Simply accessing it because it's a variable in scope. The parent poster sounded like he just sent javascript to be eval'd, so then there's no accessing objects at all, it's just a call to eval.

Also, if the only way you use a DOM is via getElementById, you're again not really using XML for what its good for. A simpler data format would serve better.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

what library do you recomend? n/t (none / 0) (#87)
by tweetsybefore on Wed Aug 24, 2005 at 12:25:43 PM EST

I'd like to see what you do.

I'm racist and I hate niggers.
[ Parent ]
I don't use Javascript (none / 0) (#110)
by speek on Sun Aug 28, 2005 at 08:29:00 AM EST

As much as possible. If I were going to write a rich-client app, I'd be inclined to write a Java Web Start app and use Swing for the gui and RMI for remote communication back to the server. If it's an external internet app, I'd probably use normal http web requests to communicate with the server. If I had some extraodinarily complicated data to send back and forth this way, then I might resort to SOAP calls, or I'd look at Caucho's Hessian protocol for binary xml.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

Wimp n/t (none / 0) (#115)
by tweetsybefore on Mon Aug 29, 2005 at 01:51:57 AM EST



I'm racist and I hate niggers.
[ Parent ]
true (none / 0) (#119)
by speek on Mon Aug 29, 2005 at 08:51:20 PM EST

My tolerance for pain in this area is extremely low.

--
al queda is kicking themsleves for not knowing about the levees
[ Parent ]

an example (none / 0) (#75)
by j1mmy on Wed Aug 24, 2005 at 10:03:18 AM EST

Lets say you're doing something with google maps and need to draw different-colored dots on the map.

AJAX

  • You write javascript to execute an XMLHTTP request.
  • The server responds with a chunk of XML.
  • You write javascript to parse the XML.
  • Once parsed, you have a latitude, longitude and color.
  • You create a GIcon for the colored dot.
  • You create a GPoint for the position.
  • You create a GMarker from both of those.
  • You add the marker as an overlay on the map.
Not AJAX
  • You write javascript to execute an XMLHTTP request.
  • The server responds with the Javascript to create the icon, point, marker and add it as an overlay.
  • You execute the javascript.
Want to add colored squares? No need to write more Javascript on the client to handle those XML elements, just spit back the new javascript from the server.


[ Parent ]
Security problem (none / 1) (#76)
by Hung Fu on Wed Aug 24, 2005 at 10:22:06 AM EST

If a message is spoofed an attacker can then make the client execute arbitary javascript. Not good.

__
From Israel To Lebanon
[ Parent ]
Unchanged situation. (none / 1) (#88)
by hummassa on Wed Aug 24, 2005 at 01:09:35 PM EST

If the initial (HTTP) message is spoofed, the attacker can make the client execute arbitrary javascript anyway. Nothing changed.

[ Parent ]
Not necessarily true (none / 1) (#89)
by Hung Fu on Wed Aug 24, 2005 at 01:20:40 PM EST

if the initial message is over SSL.

__
From Israel To Lebanon
[ Parent ]
Four words: (none / 1) (#93)
by hummassa on Thu Aug 25, 2005 at 07:13:51 AM EST

man in the middle.

[ Parent ]
1 word (none / 1) (#97)
by Hung Fu on Thu Aug 25, 2005 at 10:06:22 AM EST

certificate

__
From Israel To Lebanon
[ Parent ]
Back to the beginning. (none / 1) (#100)
by hummassa on Thu Aug 25, 2005 at 04:01:25 PM EST

If your initial connection is SSL'd you should NOT be able to xmlhttp without SSL. This is a browser issue. If your initial connection is MITM hijacked, the browser will complain about the certificate, ok. If any xmlhttp connections are non-SSL, the browser should complain either, so no problem either. If the xmlhttp connections are xmlhttpS connections, then if hijacked the browser will also complain about the certificate.
IOW: everywhere you can use AJAX, you can use get-pure-Javascript-chunks-from-server, without problem and with a performance gain.

[ Parent ]
Ok, now I see (none / 0) (#102)
by Hung Fu on Fri Aug 26, 2005 at 11:18:08 AM EST

You're right. Sorry for wasting your time, but I'm glad we went over the issue anyway.

__
From Israel To Lebanon
[ Parent ]
And, furthermore... (none / 1) (#94)
by hummassa on Thu Aug 25, 2005 at 07:15:29 AM EST

doesn't the browser complain if you try to switch from ssl/non-ssl requests?

[ Parent ]
Application logic the same (none / 0) (#123)
by n8f8 on Wed Aug 31, 2005 at 04:22:04 PM EST

The application logic is the same you just perform it on the server rather than the client. Picking one method over the other may amount to determining what the improvement in responsiveness will be to the client. In the Google Maps example since JS being served up in the traditional click-response model on the implementor's server is likely less responsive than the Google data server, you are adding to latency by running on the additional server. Running it client side you redue it to a exchange between the client and goole maps only after the first click.

Sig: (This will get posted after your comments)
[ Parent ]
pajax (none / 0) (#120)
by truckaxle on Mon Aug 29, 2005 at 11:48:06 PM EST

I must shameless admit that I have evolved to the same practice of sending javascript directly which is generated by a server side Perl script. For the application I was working on I needed at least a 2 Hz update rate and encoding data into XML only to be unencoded (or should I say encumbered) was unnecessary overhead.

Firefox users hot sauce at a discount.

[ Parent ]
What about blind people with Lynx? (3.00 / 5) (#56)
by regeya on Tue Aug 23, 2005 at 03:39:12 PM EST


[ yokelpunk | kuro5hin diary ]

IBM is working on that apparently n/t (none / 1) (#84)
by tweetsybefore on Wed Aug 24, 2005 at 12:19:56 PM EST



I'm racist and I hate niggers.
[ Parent ]
Peace, Love, Linux (none / 0) (#99)
by regeya on Thu Aug 25, 2005 at 01:46:39 PM EST


[ yokelpunk | kuro5hin diary ]
[ Parent ]

Food Fite = internal After Effects 6 name (none / 0) (#106)
by xmnemonic on Sat Aug 27, 2005 at 06:31:58 PM EST



[ Parent ]
IQ is a relevant thing (3.00 / 2) (#62)
by Armada on Tue Aug 23, 2005 at 08:04:22 PM EST

AJAX : DHTML :: Intelligent Design : Creation

Branding is hip. Adaptive Path wins.

Welcome to six years ago (3.00 / 2) (#64)
by Mason on Wed Aug 24, 2005 at 02:05:03 AM EST

I wrote applications using IE's XmlHttp interface way back when.  Now that Mozilla implements it and it has a cutesy name, it's the next big thing?  Please.  I got bored with it in a few months.

For those interested, I wrote an article on 15 Seconds on how to make these sorts of applications, in November of 1999.  My, what an idealistic young sprout I was back then.  I guess the only clever bit of the article is using XmlHttp queries from Excel, so that web and Office clients could be written to access the same web app.  Not a bad alternative, if you absolutely have to use Office.

Like all other web technologies, it is just a tool (and one that's been around a while).  The usual metaphor about hammers making everything look like nails certainly applies.

short xml tags or http compression (none / 1) (#65)
by dimaq on Wed Aug 24, 2005 at 02:07:01 AM EST

I've played with http/html compression a little and eventually figured out that for normal (static or php-generated) html plages it's not particularily useful because uncompressed html shows up (imcomplete page that is) faster in the browser.

now if you are going to receive full responce in AJAX (I presume that is the case if you use DOM), then compression wuold make perfect sense. and if you were to use compression (hopefully transparent kind built in the http/xml protocol), then perhaps the tag length wouldn't be an issue - because tags are very repetitive and tag and attribute names will compress well.

use of xmlhttprequest (none / 1) (#66)
by Silver6 on Wed Aug 24, 2005 at 02:26:54 AM EST

I have been building a website and found the xmlhttprequest object as a way to update the content of the page without reloading, thus saving time and small amounts of bandwidth. Though it is probably not the next huge thing, it is EXTREMELY powerful. It is possible to build things like an entire product form that the user can enter data into, edit after noting errors, even find out if his credit card checked out, without ever reloading the page. It also makes powerful web-based applications much more feasible. Imagine a workspace with draggable <div> areas with dynamically updating data. This type of thing is trivial with xmlhttprequest.

I'm not sure if it is mentioned somewhere in the article, but the easiest way to use this to update page content is with the .innerHTML property of <div> areas. It is as simple as document.GetElementById('divname').innerHTML = xmlhttpResponse; I have it working with a .php page, so I can dynamically run php scripts and spit out the results, even if they contain html in them without ever reloading the page. It is a very useful and underused tool. Email me if you want to see my scripts, I may be able to help you figure out how to get this type of thing working.

i guess (2.50 / 4) (#69)
by the77x42 on Wed Aug 24, 2005 at 04:07:50 AM EST

until i see it implemented with porn i'm not convinced.

dhtml and javascript turn the web from an easy-to-write information exchange into a complicated, twisted world of divided zealot coders.

web technologies are the porn stars of our time. they look pretty and we ogle at their behaviour, but underneath they're a mess and eventually succumb to viruses and droopy tits.


"We're not here to educate. We're here to point and laugh." - creature
"You have some pretty stupid ideas." - indubitable ‮

Divided? (none / 0) (#77)
by sapped on Wed Aug 24, 2005 at 11:14:46 AM EST

dhtml and javascript turn the web from an easy-to-write information exchange into a complicated, twisted world of divided zealot coders.

Divided? That's DIV zealot coders to you buddy.

[ Parent ]
XMLHttpRequest Debugging (none / 1) (#79)
by dumky on Wed Aug 24, 2005 at 11:59:08 AM EST

For those interested, here is a script for Firefox+Greasemonkey that allows you to debug the asynchronous server interactions within a page, XMLHttpRequest Debugging user script.

I guarantee (none / 1) (#80)
by Harvey Anderson on Wed Aug 24, 2005 at 12:10:54 PM EST

this article, itself a rehash of information already out there, is meant to be used on the author's resume.

Right (none / 0) (#82)
by n8f8 on Wed Aug 24, 2005 at 12:14:42 PM EST

Whatever.

Sig: (This will get posted after your comments)
[ Parent ]
So what is your motivation? (none / 0) (#108)
by Fen on Sat Aug 27, 2005 at 10:34:59 PM EST

Just curious. You post a bunch of technical stuff that may make up most of an "AJAX for dummies" book here. Why? I suppose it is right, but why bother? Aren't there music videos to watch?
--Self.
[ Parent ]
I don't get it (none / 0) (#112)
by cycnus on Sun Aug 28, 2005 at 09:36:04 PM EST

I don't get why people complain and bitch about this article: it's good, to the point, informative and useful.
Of course there is plenty of stuff on Ajax on the net and anything the author mentions will be somewhat redundant, but that's also true of any technical book, article and course ever written, yet we still need those I think.

Anyway, to me that article is a useful summary of references and it's in my del.ico.us bookmarks.

[ Parent ]

It's more philisophical (none / 0) (#114)
by Fen on Sun Aug 28, 2005 at 11:19:18 PM EST

What is the motivation? How will this help his career? Tech is just tech. If it can help a career or make money for the author, then it is worth writing an article about.
--Self.
[ Parent ]
why does it have to be? (none / 0) (#116)
by cycnus on Mon Aug 29, 2005 at 03:55:46 AM EST

Why do you assume that what drived the author had anything to do with career advancement?

Can't anyone do anything just for the pleasure of it being useful to other people?

Frankly, anyone writting in Kuro5hing solely for the purpose of adding something to his resume is just sad.

[ Parent ]

Resume item? (none / 0) (#117)
by Fen on Mon Aug 29, 2005 at 11:02:14 AM EST

I don't imagine it would be even smart to. Perhaps on a webpage that could be linked in. That's what I figure it is. There's nothing wrong with career advancement. I submitted an article on PCI-express to get feedback for a class. That's career advancement. Got an A by the way.
--Self.
[ Parent ]
Because.. (none / 0) (#122)
by n8f8 on Wed Aug 31, 2005 at 04:15:01 PM EST

I keep reading articles that either mention AJAX without explaining what it means or make the explaination overly complicated. I think my example is the easiest, basic, working example you'll find too. Personally I haven't had a customer adventuresome enough to use AJAX yet but probably will by next spring.

Sig: (This will get posted after your comments)
[ Parent ]
Rehash? (2.50 / 2) (#85)
by n8f8 on Wed Aug 24, 2005 at 12:22:25 PM EST

Originally the article didn't include much of the background stuff, but people complained so I added it in. Now I'm a plararist. Thanks. Go ahead and find identicle code elesewhere. Shit, just find an article with has simple a demo as I produced. You won't because I wrote it from scratch. At least give me credit for parsing the vulgar dictionary into a database. Some of those definitions are hilarious.

Sig: (This will get posted after your comments)
[ Parent ]
Ok. (none / 0) (#86)
by Harvey Anderson on Wed Aug 24, 2005 at 12:23:30 PM EST

Mad props! :)

[ Parent ]
Autosuggest box (none / 0) (#96)
by Roma on Thu Aug 25, 2005 at 09:45:15 AM EST

The most notable usage of XMLHttpRequest is autosuggets boxes. Google.com was the first who popularized this technique in their google suggest. Google very extensively use XMLHttpRequest in ther mail service gmail. The usage of XMLHttpRequest has made gmail absolutely different from other web mails. So this JS object contain hidden power able to completely change the web space.

Livesearch was earlier (none / 0) (#118)
by KWillets on Mon Aug 29, 2005 at 03:04:36 PM EST

Livesearch came out months before Google suggest. But I must admit I didn't know about it until I found a mention on a discussion of Suggest.

It's an open source search-as-you-type front end.

[ Parent ]

we need better toolkits (none / 0) (#124)
by jcarnelian on Wed Aug 31, 2005 at 07:08:06 PM EST

The underlying technology, JavaScript, DHTML, DOM, etc. is pretty messy and inconvenient to program by hand.  But, then, the same can be said for a lot of low-level window system layers.

We need better toolkits for programming applications for those kinds of clients.  People should be able to put together AJAX applications without having to ever see a piece of JavaScript code.

I have not been very impressed by the AJAX toolkits I have seen so far.  What AJAX toolkits have you used and would you recommend?

Toolkits (none / 0) (#125)
by jolly st nick on Thu Sep 01, 2005 at 09:51:09 AM EST

I think by using the word "toolkit" you put your finger on the issue.

I've been in this business long enough now to have gone through a number of paradigm shifts, from batch to "menu driven" to even driven/modeless. Ajax is not a paradigm shift, it's just one technology that allows you to reduce the modality of a UI. As such it's good and bad. Good: it demonstrates the feasibilty and general architecture of truly interactive web apps. Bad: it's a pastiche of technologies, some of which have poor standardization support (DHTML and Javascript) and some of which are not particularly good for this purpose. XML is the poster boy for inefficiency here: it's lexically inefficient and chock full of capabilities that are completely unnecessary and will only slow adoption on things like PDAs.

What this means is that it's probably the greatest opportunity that Microsoft will ever have to lock down the browser market suince the anti-trust decision. And they'll do it by a mix of slighly nefarious strategies (embrace/extend via non-standard ecmascript and DOM) and fair and square strategies. Really, the fair-and-square strategies are going to be enough. They'll make stitching together an IE/IIS/Sql Server application a snap in their IDE -- if they can make it possible for most developers to muddle through MFC this way, proprietary AJAX will be a snap. They've done some interesting work in this vein towards creating a solution like this for authentication and authorization, instead of publishing a biblical sized API, by making these concepts almost something you can touch and manipulate. The inefficiency of XML is a great opportunity for them. They can build something like ASN into their browsers on all platforms: desktop, PDA and mobile, and voila! All the capabilitiy, greater performance, better bandwidth efficiency and, above all, incompatibility.

With my developer's hat, I don't want to live in a world dominated by any vendor -- even a vendor I like and admire. With my manager's hat, I have to get stuff done quickly, and a vendor who jumps the gun with a non-standard implementation but cuts my up front risk is going to win.

[ Parent ]

Interesting point (none / 0) (#126)
by HappyWalrus on Thu Sep 08, 2005 at 05:56:40 PM EST

However, as the browser market gets slightly more cluttered, and Firefox / Mozilla / Safari users get more numerous, the number of sites willing to code for ONLY IE will continue to diminish. Especially as that 'geek' sector- which is a profitable one to aim at no matter what- continues to use Firefox more and more.

As a second comment, when was the last time you saw a SEAMLESS integration from Microsoft? That took less than ten years? By then, Linux may already have the functionality you're saying would kill it if M$ were to build it. It's already got Eclipse, which is at least as good as Visual Studio.

[ Parent ]
Microsoft doesn't matter (none / 0) (#131)
by jcarnelian on Sun Oct 09, 2005 at 09:44:45 AM EST

AJAX support has been in IE for a long time, yet it only became popular once Mozilla/Firefox added the support. Microsoft simply isn't setting the agenda anymore, and it doesn't matter what they add to IE.

[ Parent ]
seamless AJAX framework---no JavaScript required (none / 1) (#127)
by garretwilson on Fri Sep 09, 2005 at 06:12:22 PM EST

You asked for an AJAX framework that takes care of HTML and JavaScript automatically. Guise(TM) for Java does just that. Try http://www.javaguise.com/. (I'm biased---I wrote the framework.)

[ Parent ]
Nice ajax powered demo of a log search tool (none / 1) (#128)
by lun23123 on Mon Sep 19, 2005 at 05:04:32 PM EST

Click Here : Splunk Log Search / Analysis
This does some neat stuff with typeahead and dynamic page loading stuff.

Homepage line (none / 0) (#129)
by lun23123 on Wed Sep 21, 2005 at 09:16:37 PM EST

Here's the home page : www.splunk.com

[ Parent ]
as for AJAX functionality.. (none / 0) (#132)
by joeldg on Sun Oct 16, 2005 at 10:13:30 PM EST

For those of you have questions about functionality should see the extremem examples of forms here: http://peoplesdns.com/ajax/?edit=2 very functional, adds a lot to edit pages, does some pretty cool stuff..
--------- joeldg
AJAX - beyond the buzzwords | 130 comments (104 topical, 26 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!