Slashdot Mirror
Ajax Is the Buzz of Silicon Valley
Carl Bialik from the WSJ writes "Ajax, or 'Asynchronous JavaScript and XML,' is allowing webpages to update as quickly as desktop software, powering applications like Google Maps and attracting money from Silicon Valley investors, including for a collaboration-software company called Zimbra. The Wall Street Journal reports: 'Zimbra's chief executive, Satish Dhamaraj, says that when he started his company in December 2003, "I really thought that Ajax was just a bathroom cleaner." Now his San Mateo, Calif., business has amassed $16 million in funding from venture-capital firms including Accel Partners, Redpoint Ventures and Benchmark Capital, the firm that famously funded eBay Inc. Peter Fenton, an Accel partner, says Ajax "has the chance to change the face of how we look at Web applications" and could boost technology spending by corporations, because Ajax is also being used to develop software for big companies, not just for consumers.'"
Hmm... That's pretty interesting
Though I'm reading /. I should be working on my AJAX app for medical billing. AJAX allows us to send the structure of a complex billing system to the client, then update the data at the speed of clientside Javascript. Even allows us to pull scanned medical images ina fraction of the time it used to take because we are only loading the image selected, not all the thumbnails and other wrapper data.
But I don't get why Google Maps gets the credit for this. Microsoft (yuck!) developed this concept for web based Outlook years ago, and it has been implemented by many smaller developers since then.
Perhaps all this press will get Javascript behaving between browsers and platforms. That is the worst part of AJAX coding!!!
I only came here to do two things; kick some ass, and drink some beer...looks like we're almost out of beer.
Same here. I've had "ajax" apps out there since 2001. Almost all sites I work on I put that in. I also almost always either return an xhtml fragment and do the innerHTML dance or use js xmlrpc to connect to the server's api and use js to update the ui. But it's a kludge, really.
I use it as little as possible, and only when I absoluly have no other choice.
I never tell the managers I use this. They think using replacing nulls with zeros on integer fields is acceptable in a data warehouse environment. Eh, the hackish workaround I've had to implement!!!
In any case, if you really want to go crazy, then build a light xmlrp server in python to act as a bridge, then py2exe it (if you so desire) and run it on the client. Then have a local html+js call it via localhost:someport and it will go out and get the data out on the intarweb. Presto. You've just eliminated the central server. Expose everything as a xmlrpc services, and have only a static web server, with ONE html file. Save to desktop, run, and get the full intarweb, with no cross-domain limit.
And the python bridge can be custmized to do whatever (use Twisted? SOAP, encryption, whatever) and make it generic enough to be completely reuseable.
Beyond Ajax!
"Piter, too, is dead."
With most of the tasks that I've found a use for "AJAX" I've never used XML. Rather, we should just be referring to the general sense of using either XMLHttpRequest/Iframes as "Ajax" to keep things simple for consumers.
Which is why the term is meaningless drivel.
It works and it is far easier than you suggest. Also, the code is VERY VERY small compared to any other type of language. In my case 200KB for everything HTML,JS,PHP (goes into mysql). Compare that to our 28MB of vb src.
I'm just finishing deployment of a web based app that does some complex data rule enforcement and rating calculation server side, the gui is client side, the server handles logic and stores the application. By designing your apps the correct way, you minimize data transition, data changes up... only changes down (enforced by counters), leave the GUI code as exposed JS. My project is for private company with 600 agent groups, in 8 states, providing 5 different insurance applications. So realisitically 1800 daily users.
The code to provide the same functioning application with JS is a fraction of all other languages we have and do write apps in. JS contains the data -> through JS code logic -> updates the DOM. Yes it's almost that simple. For most business apps, it doesn't get much more difficult for any traditional data processing.
Plus, no more distribution, to 8 states.... no more making sure that the software they use is up to date, and has the latest fixes/corrections/rate adjustments. It's lightweight, fast, and centralized, not to mention, easy to code/maintain and the only tricky part is handling js client side bugs, but you keep that code very siple and well tested, and have it try to communicate with you if it gets errors that it is able to report, so you can fix them sooner rather than later.