Domain: adaptivepath.com
Stories and comments across the archive that link to adaptivepath.com.
Comments · 62
-
Re:namingFor example, the communications do not have to be asynchronous and doesn't actually need to have anything to do with XML.
Uh... the core part of AJAX is the XMLhttpRequest function, therefore the XML in AJAX. Also the link defines XMLhttpRequest as being asynchronous, I have no idea if that is necessarily the case... but if it were, then the (A)synchronous would make sense.
From your definition JASC is somewhat different from AJAX, in the implication that you don't need to use Javascript or XMLhttpRequest. I think that those two are used solely due to installed support for the two (instead of relying on a JRE or other method).
-
Ajax
another cool use for Ajax (or whatever you want to call it)
Thank you, Jesse James Garrett, you ugly slag, for coining the most irritating term yet devised for Javascript. -
Re:Ajax?
-
Re:Needs ActiveX
Does NOT require ActiveX. It does require one of the following:
IE 5.5+ (Windows)
Firefox 0.8+ (Windows, Mac, Linux)
Netscape 7.1+ (Windows, Mac, Linux)
Mozilla 1.4+ (Windows, Mac, Linux)
Probably because the code makes extensive use of the XMLHttpRequest feature (""Ajax" to some), though that doesn't explain why it doesn't work with Safari outright. Through a quick view source, I can detect they're using XSLT, and that's probably why Safari can't. But none of this matters, as Tiger's coming out very soon and we can expect Safari 2.0 to support a lot that it couldn't before. -
Re:Web applicationsThe web application of 5 years ago didn't have ajax, or anything similar. You had to wait for a full page to load, which is slow. It makes the whole app seem a lot slower. Now, your GUI can recieve updates as it is processing other stuff. The heavy processing can be done on the server, your client can do the light processing of displaying whatever you're working with.
I wrote a few simple apps that use XMLHTTPRequest. This has been a new buzz word in the JavaScript community since some live search demos (and later Google suggest) came around. I made a live blog randomizer that downloads the blog summary from my website, and only downloads the actual content that is new.
Most web apps we are used to are more monolithic. On slashdot, for example, every time you click on something, you have to doadload all the same formatting code all over again. CSS reduces a lot of overhead of extra formatting, but it does not know when the content has changed. Thus, a monolithic web application will tend to retransmit the same content over and over. This adds a lot of latency to everything, and the user perceives that it is much slower.
http://www.adaptivepath.com/publications/essays/ar chives/000385.php
Q. Is Ajax just another name for XMLHttpRequest?
A. No. XMLHttpRequest is only part of the Ajax equation. XMLHttpRequest is the technical component that makes the asynchronous server communication possible; Ajax is our name for the overall approach described in the article, which relies not only on XMLHttpRequest, but on CSS, DOM, and other technologies.
Ajax not only fetches only the data it needs, it also does additional processing to display the data for your particular setup. Think of Google as a public supercomputer you can use to speed up your desktop applications.
Lets say Google made a spreadsheet application. It could potentially be faster than a desktop spreadsheet for many operations. Imagine you have a million rows of data, and you want to sort it all. Google could perform the sort, and send back the order of the data. The local client would just have to display the data it has in a different order. The client would not even need to store a cache of all the data. It could cache the rows in your viewable area, maybe some above and below it, and stream data from the server as you are scrolling the window.
You can probably turn all of an office suite into a fast web office suite if it is cleverly designed. I wouldn't be suprised to see a Google Office in a little while. -
Re:Speaking of Ajax
Oh right on! It's like ajax meets ethnoclassification. See: this article. I think the best example on this site is here: GenieLab Most Popular Artists. Click on "more options" then use the checkboxes to filter based on tags/keywords. It all happens in real-time, no trips back to the server.
Check out the source too, it's pretty wild. -
web content developer toting new web design?" "Ajax: A New Approach to Web Applications" (from Adaptive Path..."
Adaptive Path Services: "We evaluate your site and offer detailed recommendations."
wait wait, this is rich, let me get this straight: a web design company wrote a article saying what you're using now is the "old" sucky way and their new stuff is the way to go??
hold on! this is revolutionary!
;)Not that AJAX isn't great, i'm sure it is, but this is like reading a article on how great a new car is that was written by the manufacture. Perhaps a more unbiased article needs to be submitted before I believe it.
oh and mod me +5 flamebait cuz i have so much karma i'm sniffing clouds.
-
Re:If only the boss could understand the virtues
If you really want your boss to understand the virtues, have him read this article, which gives an excellent breakdown.
-
Chicken and egg situation
The XHTML support in these phones is great! As a bit of an XHTML/CSS advocate myself, however, I think browsing the Web from such space-limited devices could become a chicken and egg situation.
A LOT of pages out there are poorly coded FrontPage (or even MS Publisher) not-even-HTML 3.2-compliant junk. There are a lot of amazingly beautiful XHTML/CSS coded pages out there, and they all display well on the small screens.
How many people will buy these phones, surf to their favorite page, and then discover they can't get anywhere fast? Will devices like smartphones and portable computers, with and 3G's ability to access the Internet at speed, force more Web designers to follow the chosen path and design in a fully backwards, and forwards, compatable way with XHTML and CSS? Or will we have a chicken and egg situation where people are turned off from using the devices because the content and pages available to them are so poor.. just like with WAP. -
Re:Standards? Ok. Compulsory standards? Not ok.
And therein lies my whole problem with this. Accessibility compliant pages are damn ugly. Almost uniformly.
And so what we end up doing is take a visual medium and break it for those with different needs.
Accessible websites don't have to be ugly. What makes you think that they do?
-
Some other thoughts on the topic (mine)Last week Lane Becker and I presented some ideas about this at a tutorial we taught at the O'Reilly Open Source Convention. We tried to address what makes Open Source user interface development problematic and to present some techniques that allow software developers to research what interaction methods work for their users. You can find all of the materials on our site and we welcome feedback from the Open Source community.
(and yes, we realize that most of our materials are in MS Office formats or in PDF, but--with the exception of Visio--we tried to make documents that can be opened by Open Office or Ghostscript)
-
Some other thoughts on the topic (mine)Last week Lane Becker and I presented some ideas about this at a tutorial we taught at the O'Reilly Open Source Convention. We tried to address what makes Open Source user interface development problematic and to present some techniques that allow software developers to research what interaction methods work for their users. You can find all of the materials on our site and we welcome feedback from the Open Source community.
(and yes, we realize that most of our materials are in MS Office formats or in PDF, but--with the exception of Visio--we tried to make documents that can be opened by Open Office or Ghostscript)