Slashdot Mirror
Why Microsoft and Google are Cleaning Up With AJAX
OSS_ilation writes "Google uses it, and Microsoft is pursuing it, so there's a lot of hype and hubbub surrounding AJAX (Asynchronous JavaScript and XML). AJAX brings together some hot properties, JavaScript, HTML/DHTML and HTML, according to Julie Hanna Farris, founder of Scalix, a Linux-based, e-mail systems vendor. Scalix is using AJAX in Scalix Web Access (SWA), a Web-delivered, e-mail application. AJAX enables advanced features like drag 'n drop, dropdown menus and faster performance capabilities, which are now making their way into Web applications, she said. These kinds of capabilities represent a significant leap in the advancement of Web apps."
Farris: Microsoft is probably interested in AJAX for the same reasons everyone is interested in AJAX: the ability to deliver desktop quality applications through the Web.
and charge "subscription fees" for it too.
perpetually dwelling in the -1 pits
Man, are they ever hyping this stuff. This story doesn't seem to actually cover anything new, it just hypes AJAX more!
:-(
The truth is that the stuff we've seen in AJAX so far is nothing. I don't know about anyone else, but I've used it in regular webapps as nothing more than an interface enhancement. People don't even really notice the fact that the web pages work much smoother.
That being said, there's a massive untapped potential in this technology. I've got demos of Video Games in AJAX, as well as a full Desktop. I tried to get Google interested in the video games concept, but I'm afraid they ignored my communication.
Javascript + Nintendo DSi = DSiCade
Microsoft basically invented AJAX, yet they're the ones behind the curve.
Microsoft invented the XmlHttpRequest functionality, AND they've been using AJAX (before that's what it was called) in Outlook Web Access (OWA) for years. Nobody else in the company seemed to have caught on to it though.
If you need web hosting, you could do worse than here
Microsoft was using Ajax before anyone ever even heard of google. Outlook web interface anyone? Cmon, at least be semi-accurate.
Sounds familiar, could have sworn I read something about this here the other day.
Anyway. Let's not fill this page up with 'Dupe' complaints. Macromedia are probably gonna have to re-think things (in the new Adobe environment, of course) since they were convinced that Flash would be the vehicle of choice in developing what they call Rich Web Applications. They'll now have to sell it on the basis that you can get a hell of a lot of functionality out of very few lines of Flex code.
It's gonna be interesting.
Drill baby drill - on Mars
I don't mind dupes. I don't really think about spelling- or grammatical errors (queue jokes because I'm not careful here). But do we, readers of slashdot, really need to be lectured what AJAX is?
Google uses it, and Microsoft is pursuing it, so there's a lot of hype and hubbub surrounding AJAX (Asynchronous JavaScript and XML). AJAX brings together some hot properties, Javascript, HTML/DHTML and HTML, according to Julie Hanna Farris, founder of Scalix, a Linux-based, e-mail systems vendor
What's next, summary teaching us what programming languages or computer is?
Bah, this is slightly annoying.
So we should ditch Javascript, but keep Asynchronous Javascript And XML? Isn't that like dumping gas-powered engines but keeping gas-powered cars?
Asynchronous And XML?
With out Javascript AJAX doesn't work.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
AJAX brings together some hot properties, Javascript, HTML/DHTML and HTML
So what you're trying to say is "AJAX brings together Javascript."
We always knew Comcast was corrupt, here's the proof: http://tech.slashdot.org/comments.pl?sid=1909890&cid=34545432
Anyone remember the old Gary Larson cartoon? Man talking to dog, bubble above dogs head captioned, "what dogs hear."
"blah blah blah AJAX, blah blah blahblah AJAX!!1!. blahblahblah Google blah AJAX, blah Microsoft sux."
The .Net alternative IS AJAX. VS.Net 2k5 has AJAX components built in. It takes a mater of seconds to get AJAX running in 2k5. There are also plug ins available for VS 2k2/2k3 to run AJAX.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
The .NET alternative, which comes as a part of .NET 2.0/Visual Studio 2005, is Atlas.
Here's an overview.
Just wait until microsoft defines is "standard" AJAX interface.
What i would like to see is the US goverment and other countries to force them to adopt clean, industry defined standards like the XML, HTML,CSS, AJAX and not an assimilated badly digest crappy way of doing things that breaks the WEB. They should be more humble since the WEB has given a good chance for all companies to develop and sell new products, and microsoft is no exception here, aldo they have wakeup lately to this.
Exactly. We need a better engine.
I'm not sure if your comment was intended as a pointed jab at the buzzword status of AJAX or a serious suggestion that JavaScript is crappy, but I'm assuming the second.
There are some things about JavaScript that are really annoying. First, the object orientation seems very odd. It is well-rooted in the language, but it is quite annoying not to have real object namespaces (yes, you can use closures, but they're annoying and kludgy), real constructors, and that sort of stuff. It's almost as bad as Perl's hash + namespace = object idea, and worse in some ways.
What I'd like, I guess, is a language that is very similar to JavaScript, but has a real object-oriented system and better support for things like loading code dynamically. It's clear that JavaScript or some future variant of it is finally being used the right way--to make pages dynamic instead of just annoying--but right now it's very cumbersome. Loading Gmail, for example, is quite slow, because it (IIRC) downloads a huge chunk of code at the beginning. Perhaps someone (maybe me) could write a wrapper system in JavaScript that uses XmlHttpRequest to load JavaScript code on demand. But some sort of modular functionality ought to be officially added to JavaScript, before it's too late and we end up with the next "___ Wars"... this time it will be the fight between JavaScript frameworks.
ttuttle is a rankmaniac
Who will be the first to try and patent something "using AJAX..."?
I think that if AJAX picks up and starts to be used everywhere, we should standardize a system so that optionaly, a web browser can inform the server that it has the option to connect to it using an open port on that system. It would really help things if the browser didn't need to connect to the server every few minutes to check for new data. That way, instead of my browser connecting to Gmail's servers every 60 seconds to check for new mail, Gmail's servers can connect to my browser and tell me only when I have new email. This saves processing and bandwidth and increases usability.
This turns AJAX into more of an actual internet protocol, and I think it would really improve things.
Browsers could spend alot less effort kludging together DHTML and javascript and ride for free off of the JVM. I understand the JVM is a separate download, but browsers can include it as part of their install. I don't see why were a celebrating the creation of such a kludge with random inconsistencies across browsers and platforms that are far worse then what you find when targeting the JVM.
What is it with this EVERYTHING on the Internet is a webpage. The browser is the only client these days outside IM and P2P warez trading for 95% of users. And even though Javascript was never intended for 'real' programming it is the only language all browsers implement so it is what everyone is forced to use. It wasn't supposed to be this way and it doesn't have to BE this way.
If nothing else, if we want to download clients and run them in the browser, having them talk to a backend server for the data, why not get a more appropriate language? Java would be perfect if Sun weren't a bunch of asshats, but just because it won't ever be truly Free or cross platform is no reason to reject other candidates. Tcl/Tk has had a fully sandboxed browser plugin for a decade and it is 100% Free Software. It runs on every known platform where IE or Mozilla runs and could be ported anywhere else needed. I'm sure it isn't the only one. Or do we continue shoehorning everything into html?
Democrat delenda est
AJAX is great. It means that web deployed applications are now almost as good as the regular applications we've been using for over 10 years! Just imagine: We can enhance Javascript to support more OO features and reflection and add JIT and it will become just like Java! Yaaay! Then we can add support for stronger typing and compiling to native code, and then it will be just like C! Yaay!
.NET natively support this. For other languages there are plenty of frameworks that will add that capability.
It is funny to watch technology reinvent itself in fast-forward.
I work for a company that did AJAX long before it was called AJAX. And now that it is the next hot thing they are moving away from it. Why? Because they already learned the lesson that everyone else is about to figure out: AJAX is a b*stard to code and maintain. It is easier to write a client-server application in a traditional language and web deploy it than to write this crazy JavaScript + XML + HTML + DHTML + CSS stuff.
Java and
I just don't get the hype. What can you do with an AJAX interface that you can't do better with a native client application?
Sure, browsers work on every platform, and AJAX apps don't need a download, that's great. But the same thing could be done with java if everyone had a JVM, or anything else.
AJAXs means reinventing the GUI, only with a more difficult to use, hacked together API
autopr0n is like, down and stuff.
If you are typing on a web page that uses XMLHTTPRequest, then you should treat it as if you were running a live program remotely. I.E. the web page could forward information about everything you type, how you move your mouse, etc, without an explicit 'submit'. Example : it if were an email app, and you typed 'my boss is a dick and my SSN is 555-55-5555' in an edit control, and then thought better of it and erased what you typed and killed the browser window without submitting, the contents could already have been captured and forwarded to the host with XMLHTTPRequest and you never knew it. Looks like a good cross site scripting opportunity.
Of course, you usually don't know if a page is using XMLHTTPRequest in a hidden frame unless you look really hard, so I guess the bottom line is never type anything on a web page you don't want the world to see. On the other hand, AFAIK (which doesn't mean much) this hasn't shown up in practice, so maybe it isn't that big a deal.
As a web user I don't give a shit what the application is made of as long as it works and doesn't open me up to all the security nightmares of the day.
Do I care that I can get a full desktop application on the web? I don't because I already have one and free too. Video games? Nope, got'em and they're better too.
Do something I don't have. If it can get me laid all the better.
Deleted
Not only that, but apparently, only Ajax creates Drag'n'Drop and drop down menus. You learn something new everyday! Here I thought that it was Javascript and CSS that did that.
The sad part of throwing buzzwords around is that people latch on to them and have no idea what they entail. "I want to use some ajax for my website. Do it." ??? Somebody just realized that they can use the XmlHttpRequest object and some server-side processing to save users from the need to refresh or load a whole new page. The rest of the visual goodies have nothing to do with Ajax, just some good old Javascript+CSS.
And that, my liege, is how we know the Earth to be bannana-shaped.
Hi, My name is Dion Almaer, and I run a site called ajaxian.com which focuses on news, resources, and all things Ajax. We also have a podcast called Audible Ajax. Let us know if there is anything that you would like to see covered, and if there is anything cool in the Ajax world that we have missed. Cheers, Dion
Here is a fairly long list of websites that use AJAX -- http://en.wikipedia.org/wiki/List_of_websites_usin g_Ajax
Sun and Fun
Why is this article marked under the 'Java' category by slashdot? That's amazingly silly. xmlhttprequest has *nothing* to do with java.
BeauHD. Worst editor since kdawson.
JavaSript is not related in any way to Java. It was a cold day in November 1995 when Bill Joy, in contract negotiations between Sun and Netscape, told them "sure, go ahead and use the name JavaScript."
Sort of funny when you think about the current protection of the Java trademark, or whatever it is.
p.s. yes I was there
More like, "Google uses it, and Microsoft invented it".
Indeed. This story is absolutely unbelievable revisionist history and nonsense. I've written about my feelings of AJAX (in fact I was honored to see that an AC already referenced it in this thread), and this article is exactly what pisses me off about the new-to-web-apps "AJAX" converts. This messaging expert is yet another dumb-ass trying to get in on the Web 2.0 action to earn some VC funding. She even used the word "paradigm" to really put up the flags.
So you can't use it in software that might be sold to, for example US Government customers -- no national laboratories, no NASA, etc.
UNLESS -- you write your own accessibility aids and write your own UI framework that compiles into both an AJAX version and a web accessible version.
That's a tall order. However, there is help.
You can write your web pages in HTML with XForms and let XForms handle the dynamic page aspects, and then offer up the HTML+XForms as the accessible version. (See the DHTML Accessibility Roadmap.)
Everything that the AJAX cloud of applications does with the XMLHTTP object and updating the DOM on the fly to display choices can be done with XForms.
Then, you can use one of these mechanisms to convert the server-side XHTML+XForms file into AJAX:
If you want to serve up the XHTML+XForms directly, and not rely on any AJAX technologies, try these:
So, try them out, and see how much easier it is to write accessible code and properly separate your data and presentation layers when you use XHTML, CSS, and XForms. Then, choose a middleware solution or a browser-based solution and go forward knowing that you can meet architectural requirements without getting bogged down in JavaScript toolkits.
It really stinks when you want to play with these technologies, but as a federal contractor, not something we can do.
I don't think there are too many screen readers our there that can handle AJAX quite yet.
Hmm.. screen reader built onto Firefox? Notices when stuff changes. I could build that. Sweet.
Not really.
We have this mechanism with active FTP.
On this page http://slacksite.com/other/ftp.html
there is pretty good description how it works.
This is not high risk, because the port need to be opened for a short time.
And after the connection is created, there is no need to listen more on this port, just keep the connection.
You will accept connection only from the host in the url, and will not accept connections from other hosts.
It's almost platform independent. The main problem which primarily afflicts Microsoft's use of AJAX, such as in Outlook Web, is the way that the "A" in AJAX is "started".
Basically to initiate an HTTP asynchronous request, the Javascript code must create a special object which encapsulates the request and communication. Althought the interface and use of this object is for the most part standard, the way in which it is initially created is not.
So if you want a platform independent AJAX app, you pretty much need a bit of code which does things the Microsoft way when the standard ways don't work. Like:
Now, Microsoft-written applications which use AJAX only try the MS ActiveX methods, and not the standard XMLHttpRequest() function. Thus, although most of the application could have worked in any browser, this simple omission by Microsoft insures it only works under IE (and locks you into their technology).
It should also be noted that AJAX is a methodology and not a strictly defined API. For instance most AJAX apps rely heavily on the DOM API, which Microsoft mostly but not entirely adheres to. So there's lots of things that can cause platform independence problems if not coded carefully.
Because the success of the Web is primarily about linking together data. HTML has proved itself as a flexible way to express that data, to link it together, and (increasingly) to structure it. That's what the language was designed for. Remember, HTML was not intended as a language for layout or for graphic design. If you trade in HTML for code (as you propose*), then the structure and semantics of that data is then locked up in the code, walled off from the rest of the Web. You lose all the benefits of standard representation and network effects - which matters, because the best web apps rely on data. For example, fragment identifiers, browser extensions, web crawlers (e.g. for search), the ability to target different device characteristics through CSS, and accessibility features all rely on HTML (granted, AJAX tends to be weak in supporting some of these, e.g. accessibility). You also, incidentally, wall of your code from the rest of the content of your page.
* Admittedly I haven't looked at applets in years; maybe there has been some movement toward resolving this problem.
Although Ajax started out life talking about JavaScript, html, css, etc. It was never defined as an acronym. In my opinion the promise of "Ajax" is not XMLHttpRequest. The shift is in the architecture. Instead of a full request/response/redraw cycle, we can do what any application framework allows, in that we can talk back to the server based on any action (click, hover, sneeze) get some response, and dynamically change something on the page. This change is powerful and a no-brainer. Imagine if you clicked on a button if you email client and every widget re-drew itself each time! We have to not go crazy though. The bests uses of Ajax are often subtle, as we don't want to leave behind our users. One of the great things about the web is that my grandma knows how to use it. See a link. click it. Same for a button. Learn a few buttons (back/forward/reload). We need to make sure that our web applications are still usable. With ajax you can INCREASE usability if you are careful, but you also have the power to do the opposite.
>> Standard (everybody but IE): req = new XMLHttpRequest();
Um, since Microsoft INVENTED the fist XMLHTTP object, they could not use the "standard" method; It did not exist.
As they did it first, it was the de-facto standard that everyone else copied.
Now others have copied it, blessed it as "The Standard"(TM) and now people bitching because MS has not gone back and changed the way they do it?
That is pretty stupid.
I guess it is just like Americans telling the Brits they should *speak English*.
Jorgie
Javascript is fine. Not perfect, but it is usable. It is HTML that blows for web apps. There are just so many basic things you can't do in HTML such as listboxes and treelists. And the widgets HTML does have are really nmeant for simple forms, not complex user interfaces. Sure, you can find ugly and slow Javascript implementations but what we need is a UI language such as XUL which can describe a fully functional application UI. Right now AJAX is OK for adding a little spice to traditional web applications, but it won't be a revolution until we have something besides HTML to describe the UI.
Javascript+XUL is very powerful. Consider that the entire Firefox front end is written in XUL and Javascript. You can use AJAX with XUL, BTW.
-matthew
"THERE IS NO JUSTICE, THERE IS ONLY ME." -Death
For those of you complaining about how JS suffers from various browsers inconsistencies and bugs, and how it should have a [hard-to-build] framework that handles all this, take a look at the following:
t /user/Window_2.html
/. the other day, and was quite impressed -- even if it still has a ways to go before it hits prime time).
http://qooxdoo.oss.schlund.de/demo/dev/public/tes
(I discovered this through
I'm just finishing a project where QooxDoo (when its a bit more finished) would have been the cat's ass.
What! The mighty Ajax is all of the following:
1. A couple of guys from "The Iliad".
2. The name of a bunch of cars from the early part of the 20th century.
3. A major Dutch soccer team.
4. A toilet and bath cleaner.
5. A town in Ontario.
6. A character from the movie "Flash Gordon".
7. A "web technology" whose component parts have existed for ages, but marketing people believe makes them sound smart and "cutting edge".
8. Many other things.
It is NOT, and has NEVER BEEN, a mere "window cleaner"! Good god, man!
I agree that both models are necessary. You wouldn't want to lay out text with a box model, but you wouldn't typically want to lay out a form or list with a freeform layout, either. The element was a decent compromise, for a while, but its limitations are many, and it confuses programs that expect tables be used for data rather than layout. CSS is the recommended replacement, but omits the most useful part of the element, arranging rows and columns of arbitrary elements, while failing to add the metainformation that would allow screen-readers and the like to quickly find the content of the page.
You say that we're "trying to force documents to be applications", and I agree. However, with HTML we're also trying to force applications to become documents. We need access to both layout models, because the Web contains both documents and applications. XUL provides this. For example, the XUL menus in the FireFox "chrome" are freeform, and the main part of the box layout is a container for freeform HTML, while the rest of the chrome follows a box model.
Even "document" pages usually contain some "application" elements; navigation buttons, or a search box, for example. The page should be treated as an application containing content, and not forced to hold both the framework and the content in one file, with the same layout model.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
Actually, my biggest problem with Javascript was (is?) trying to understand all the little (or sometimes not-so-little) implementation differences, and write cross-browser script that didn't turn into zillions of checks:
That becomes a maintenance nightmare. Every few months a new browser version becomes available and must be tested and it's niggling quirks discovered and handled. This is not an insignificant task. Personally, I would rather be a content creator, not a browser beta tester for MS and Mozilla.The Russians have won. They have made the world a cesspool of distrust, greed, fear and hate.