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
I'm watching the flash-based Zimbra demo right now, and they're bragging about innovations like "conversation view" and "tags" on messages. Which gmail has had for a long time. Yes, I know gmail is essentialy AJAX, but this is the demo for the Zimbra collaboration suite.
Why would anyone think Zimbra was innovative based on this demo?
This statement is solely an opinion. Kindly take it as such in all cases.
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."
This shows you the power of a website and a buzzword. I think xmlHttpRequest has been around as an ActiveX object since IE 5. More recently Mozilla added native support. Hopefully the IE7 team has done the same thing. At any rate I've been using this technique for 5 or 6 years. When I first learned about it I thought WOW, this is really going to revolutionize the web! A web page can be a little client/server app, just sitting there handling requests all day. No need for any crapola to maintain session state between refreshes. I always wondered why Microsoft never did anything to promote it. ASP.Net seemed to ignore the concept entirely, instead encouraging page refreshes whenever anything happened. Now its being promoted with a catchy name and it takes off like a rocket. Go figure.
XmlHttpRequest by itself is really easy to use. You submit a request asynchronously using the Send method, and you write an OnReadyStateChanged event handler which watches for readyState "Complete" and does whatever you want with the returned data, which can be either XML or just plain text. For example, plop it into the InnerHTML of a DIV, or in IE you can do a client-side XSL transformation. The Ajax implementations I've seen are just javascript object wrappers for this. Sajax adds browser compatibility, which is nice if you are working on the web, but if you want to use this technique for typical corporate intranet apps where you know IE is the only browser, you really don't need to bother learning about Ajax. Just look up the XmlHttpRequest object and you'll see how simple it is.
I think about how they bilked someone out of $10 million who will probably never see a return. At least we're makin' jobs!
JOhn
Campaign for Liberty
Anyway, what I see is that AJAX will allow me to push all of the controller (MVC) logic onto the server. And I can hide script logic as needed (though can be done with jsp's or servlets/JSF). Aside from making remote scripting easier (i.e. don't need to rewrite functions), it will allow me to write code that looks more procedural and manageable than straight HTML. So it's another tool to add to the arsenal--hence the article sounds like more hype than new tech.
The weird thing is ESR thinks that more javascript than html-content is a train wreck waiting to happen. I would disagree here with something like AJAX in the mix.
Then again, AJAX is old tech and DHTML will likely have a greater impact.
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.
AJAX was invented by Microsoft in 1998 so they could write a decent Outlook web client.
So technically, it's only 7 years old.
(shhh... don't tell taco... his head will explode if he learned that Google didn't invent it)
No way... Ajax is the mountain that I look at out my office window everyday...
http://www.firsttracksonline.com/aspen02.jpg
It's starting to look good, BTW. In case anybody cares.
T
How will it improve user experience if the users cant find pages on your site, because search engines can't index them, because you jumped on the AJAX bandwagon, and abused the concept by implementing it ALL OVER the front-end of your web site.
There is a time and a place to use AJAX. Some people do not understand. Oh well.
I think you need to read this article to better understand the time and place to use AJAX... http://alexbosworth.backpackit.com/pub/67688
Good Luck!
the only permanence in existence, is the impermanence of existence.
Actually users will care when they try and do google searches for information and can't find information because the crawlers are unable to properly link to dynamic document that hides behind a single URL. I'm kind of troubled how the web browser is becoming the universal application container. There are some things that stateless HTTP and browsers just aren't really designed to do i.e. dynamic applications. I work in this area so I to live with it but overall it feels like we're regressing.
Just a thought: automated webpage translation services like Babelfish and Google's language tools can translate arbitrary webpages yet preserve images and navigation. This only works because the web works via hyperlinked text documents. But if you want to read a website that uses AJAX for navigation, these systems will break -- they can't intercept your XmlHTTPRequests. And even if there was a browser extension that could do that, it would be unclear what text needed to be translated and when. So here's one example of a useful tool that depends on HTML transparency, broken by more programmatic clientside techniques.
-Brendan
IMHO best practice should be to keep the static content of these apps (eg. help screens, terms and conditions, privacy policies etc) as regular, indexable HTML whilst using AJAX where the user experience is interactive.
One of these days I'm moving to Theory - everything works there
Many of the Java applets I've come across simply either won't load at all, or slow down the browser's loading of the page by five seconds or more while the little Java icon in my system tray loads and pops up with its "welcome to Java" callout. This is on a 3.06 GHz laptop with 512 MB RAM.
Flash won because it did what most people wanted to do (animation and games) faster and more efficiently than Java applets.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
Actually I didn't make my point very well. HTTP alone isn't the problem. It still sucks but it's the poor data management between HTTP and the rendered UI that is the just rediculous.
Think about what's happening in an AJAX application:
Text defining the display (HTML) is downloaded (HTTP) within which a script is embedded (JavaScript) that requests more data be returned as but in a slightly different form of text (XML) that needs to be unmarshalled and interpreted in an application specific way to extract document manipulation operations (DOM). That is *completely* and *utterly* rediculous.
I didn't know ANY javascript before 48 hours ago, right now I am writing ajax for production use. You dont need to use/understand XML to use ajax, and javascript is simple as fuck to use. I assume you already know html, so really, stop bitching, start reading.
http://www.w3schools.com/js/default.asp
http://en.wikipedia.org/wiki/AJAX
Selling software wont make you money, selling a service will.
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.