Slashdot Mirror
Mastering Ajax Websites
An anonymous reader writes to tell us that IBM DeveloperWorks has an interesting article introducing the uninitiated to the world of Ajax. From the article: "Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM, is an approach that helps you transform clunky Web interfaces into interactive Ajax applications. The author, an Ajax expert, demonstrates how these technologies work together. Ajax is more than just the latest fad -- it's your stepping stone to build better Web sites through efficient use of your time."
. . . how when a new fad comes along, people say it's not a fad?
I too have felt the cold finger of injustice.
Call yourself one.
Interesting post. This kind of introduction might help beginners (like me) to know more about this new mix of different technologies and avoid confusion. Just these days a friend of mine said to me that he would like to learn this new "Ajax programming language". Many people still think that way. Thumbs up for the article.
Pinesol has waaaaay more cleaning power
Only two things are infinite, the universe and human stupidity, and I'm not entirely sure about the universe - Einstein
Instead of a complex hybrid why not a new language ? Half the opinions about Ajax is that it's not worth all the effort. Too complex.
What about Python or something new just for interfaces ? Something like Macromedia Flash ?
A nice example of Ajax usage can be found at http://www.meebo.com/.
From the article:
... "Particular Way" for browser two ...
JavaScript code is the core code running Ajax applications and it helps facilitate communication with server applications.
Depending on JavaScript could be its downfall, since JavaScript has so many functional work-arounds for each browser. Even the article mentions (but dismisses) this problem.
From the article (again):
Microsoft's browser, Internet Explorer, uses the MSXML parser for handling XML (you can find out more about MSXML in Resources). So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way.
"Particular Way" for browser one
Sounds like in an inherently poor design.
AJAX isn't an end in itself; it's just a tool. It's like JavaScript. Back when the web was old, if you wanted to do data validation for a form (for example), you had to send the page to the server and wait for a new page as a response. When JavaScript became popular and well-enough supported, the webpage itself could check data before sending it to the server - although the checks couldn't be that complicated. AJAX is similar; instead of limiting yourself to either using a new page or client-side data, AJAX lets you use JS to access server-side data.
As a concrete example, play with Google Maps for a couple of minutes, then try using a map from MapQuest. It will quickly start to annoy you that you can't drag the map and that you have to click to a new page to move the map around. GMaps isn't pure AJAX, admittdly, since it deals with picture data - it can just write the image tags to the page and move them around as you drag. But the side text and the map searches are AJAX - when you click search, you don't open a new page with the search results. You can keep using the map; the client will turn your search into an XML request, Google will process it, and send the results back as XML - asynchronously.
For another example, I wrote this week a dead-simple chat program (because I needed a specific feature). It was simpler to write a web app instead of a real app, because the latter would require networking, windowing, and whatnot - the web interface made GUI easy and manual networking irrelevant. Without AJAX, I would need to have the page reload every second to check if there are new messages - very distracting. I had the system asynchronously check for messages in the background, and when one arrived, update just that part without refreshing the page.
AJAX is a tool to be used when necessary. Don't freak out over it, but realize it's there whenever you need to use a more application-like interface instead of a page-like interface.
AJAX doesn't make it easy to develop cross-platform web applications. Look at all the browser incompatibilities in the developing of Gmail and more recently MSN's start.com page.
We need to re-standarize Javascript or at least make sure all the browsers implement a 100% compatible version. And I don't think that will work since not even HTML is properly rendered by any browser at all.
From the article:
However, Ajax is far more than just a fad; it's a powerful approach to building Web sites and it's not nearly as hard to learn as an entire new language.
Interestingly enough, my current approach to building Web sites is also powerful. So, I guess I'm already all set. :)
Recalling the Simpsons: "Only suckers buy [last year's] model. You are not a sucker, are you?"
I can't wait to start padding my resume with the latest and greates technology out there that will do the same thing we've been doing for decade but with more acronyms and steeper learning curve.
"Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM, is an approach that helps you transform clunky Web interfaces into interactive Ajax applications."
DHTML is nothing more than javascript and html. And how the heck are you supposed to use javascript without using the DOM, aka Document Object Model? Talk about buzzword compliant...Somebody should break this news to Hani.
(It's not going to be me.)
Depending on JavaScript could be its downfall ... Sounds like in an inherently poor design.
While I'm not a big fan of JavaScript, the incompatibilities you talk about aren't JavaScript's fault. They are due to different levels of JavaScript support in different browsers, and the addition of non-standard features by the different browser camps. AFAIK, XMLHttpRequest is not a standard. It was invented by Microsoft, and others found it so useful that all modern browsers now support it, albeit with slightly different APIs. That is the source of the incompatibilities, not JavaScript.
You forgot "...and asynchronous updates are useful". For example, one of the major applications I work on is a course management system. We could update the display of which students have uploaded work, in real time, but it would only be of use for those courses where submission has a short window (for example, lab-based courses), and even then I'm not convinced it would be used as a feature. Much of the system is like this; rarely updated data, which isn't that helpful to watch change in realtime anyway.
On the writing to the server side, there are a few more uses (particularly backing up work in progress), but everything I can think of is best only written back when delibrately saved...
The incompatibility you are talking about is the direct result of Microsoft implementing XMLHttpRequest with ActiveX, and everybody else implementing it as a native Javascript object. Microsoft are changing their implementation in Internet Explorer 7 to be compatible with everyone else.
So no "inherently poor design", just a historical artifact that is a) easily worked around, and b) going away.
Bogtha Bogtha Bogtha
You don't need polish to keep users, you only need polish to attract users. Take Slashdot as an example. Hideous design, atrocious implementation, no polish whatsoever, full of bugs, and yet people keep coming back to it.
Once you've attracted users, they rarely go away unless you give them a push (like endlessly posting repetitive articles on Ajax, for example).
Bogtha Bogtha Bogtha
Amen to that! For most other sites, choosing either plain HTML or a real (Java Web Start or even -- horror -- .Net or native) app is much easier. Mod parent up! :)
You're almost there, but the number of users has nothing to do with it. You use it when it's appropriate to support a desktopish interaction model, and you don't want to reload the page every time.
Also, I'd clean up the terminology. You don't use it for web sites. You use it for applications.
Slashdot - where whining about luck is the new way to make the world you want.
"Particular Way" for browser one ... "Particular Way" for browser two ...
Sounds like in an inherently poor design.
Yeah, because var req; if (window.XMLHTTPRequest) req=new XMLHTTPRequest(); else req=new ActiveXObject("Microsoft.XMLHTTP"); is such poor design. (req supports the same capabilities now, regardless of method - that's why he said "create".)
The reason behind this is that XMLHTTPRequest was originally a Microsoft idea using ActiveX. When Mozilla, Opera, Safari, etc. realized it was a good idea, they needed a way to create that object even though they didn't support ActiveX (justifiably). And Microsoft just kept its original design.
Also, if you consider the popularity of the "NoScript" extension, you'll see that a lot of people turn JavaScript off. Having it permanently disabled is a part of many security policies, as well; I would estimate that at least 10% or so of people will have JavaScript disabled at least on their first visit. This is a lot more than a minority such as "Links users" or "the blind".
So... unless you disregard a significant percentage of viewers, you do need to provide an alternate version.
The article says: "Ajax is more than just the latest fad -- it's your stepping stone to build better Web sites through efficient use of your time." -- tell me how can AJAX save you time if you have to do _both_ versions of the site, multiplied by the number of differently behaving browsers?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Hmm..
I guess we should thank the people writing and using IE exploits, they will ensure no one uses an obselete IE browser in the coming years.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
Not an inherently poor design, but an inherently poor architecture. If AJAX needs to be browser-specific, it is doomed in the long term.
Think: flash in the pan.
The number of users has nothing to do with it.
I disagree. Unless you're developing for fun, you need lots of users and/or transactions to justify the extra expense required to implement AJAX.
You use it when it's appropriate to support a desktopish interaction model.
Okay, but that's nearly tautological. The problem is to determine when a "desktopish interaction model" is appropriate.
You don't want to reload the page every time.
Whether you "want" to reload the page isn't nearly as important as whether you can justify the expense of avoiding reloads. Lots of people "want" to use AJAX. That doesn't make it a good idea.
-- Brian
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Not trying to spruik it or anything, but I'm currently working on a project of making a webapp using Laszlo.
It's an open source language/server for creating flash based applications.
We've found it to be very impressive how much you can do with so little code... and it's nice to have a proper OO backend to a flash frontend... the flash frontend means we can:
a) Make our interface very pretty and like a 'normal' application
b) Means it works in pretty much any browser...
c) on pretty much all platforms...
d) without a download of any plugin in most cases (just because of the penetration of flash)
Good point. There's no point in polishing a GUI that doesn't need that kind of polish.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
Well it is ;). It assumes that XMLHttpRequest is implemented in one form or another, it throws an exception when Internet Explorer users have ActiveX disabled, and it doesn't handle Internet Explorer 5.0 (IIRC), which implements the same object, but with a slightly different name.
Bogtha Bogtha Bogtha
I disagree. Unless you're developing for fun, you need lots of users and/or transactions to justify the extra expense required to implement AJAX.
I don't find this request model (I hate the term AJAX) to be expensive to develop, or to run. Took me a week to make the necessary framework level changes and test them, and now it's a matter of setting a few attributes on my custom tags. (I'm using J2EE and a custom framework right now)
Okay, but that's nearly tautological. The problem is to determine when a "desktopish interaction model" is appropriate.
I should have stated this more clearly - it's user driven. My current project is replacing some old desktop apps into an integrated web application. The choices were made before I started, and using this architecture lets me satisfy everyone. Obviously, it's a case by case basis, but if the user is expecting things to be highly interactive, and the project is a web app, then this is the way to go.
If the project isn't customer driven, then I guess it's really just a personal decision. If the system isn't intended to be highly interactive, why bother?
Whether you "want" to reload the page isn't nearly as important as whether you can justify the expense of avoiding reloads. Lots of people "want" to use AJAX. That doesn't make it a good idea.
Again, I disagree with it being expensive. There was some upfront work in my case, but that's over now. Things are actually simpler to develop overall, because individual interactions have very few dependencies now, as opposed to traditional web development.
In the end, of course people will misapply these technologies. That will be true of everything that will ever be invented, though.
Slashdot - where whining about luck is the new way to make the world you want.
I'm bored with these paradigms. Can we invent some new ones already? I propose Flash + Ads + Porn + Paypal = FAPP.
It's not just a fad!
There's no doubt that AJAX is fundamentally more complex than traditional web development. If you've figured out a good way to abstract away this complexity using a framework, good for you -- and maybe you should share it with the rest of the world.
The most rabid believers in American Exceptionalism are the exact same people whose policies are destroying it.
I'm working on that right now - making sure I've got compatible licensing on the dependencies, and documenting. I expect to release it by the end of this month, but that may slide if my project gets hairy. The site will be in my sig when I get it done.
Slashdot - where whining about luck is the new way to make the world you want.
Well it is ;). It assumes that XMLHttpRequest is implemented in one form or another, it throws an exception when Internet Explorer users have ActiveX disabled, and it doesn't handle Internet Explorer 5.0 (IIRC), which implements the same object, but with a slightly different name
As a rule, you don't post error-checking code in programming discussions. It's assumed that everything's wrapped in a try block.
What I used in my application was copied-and-pasted from Apple's XMLHTTPRequest tutorial, part of function loadXMLdoc(), with appropriate redirects to an error/troubleshooting page if creating the object ultimately failed.
Why not use the javascript way of avoiding activeXObject calls when accessing XMlHttpRequest objects on MISE? Its been in several ajax libraries for the past 4 months! AJAX is all browsers with the XMlHttpRequest object not just MSIE junk..
Fred Grott(aka shareme) http://mobilebytes.wordpress.com
Depending on JavaScript could be its downfall, since JavaScript has so many functional work-arounds for each browser. Even the article mentions (but dismisses) this problem. From the article (again): Microsoft's browser, Internet Explorer, uses the MSXML parser for handling XML (you can find out more about MSXML in Resources). So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way. "Particular Way" for browser one ... "Particular Way" for browser two ...
Sounds like in an inherently poor design.
Im not a huge fan of AJAX, but this is one criticism you can't honestly level at it. Browser incompatibilities exist for pretty much all client-side, web-based technologies, and AJAX has only a single minor change to work around, as opposed to getting a complex CSS layout to work cross-browser. *shudder*
The simplest AJAX app relies on one piece of javascript functionality - the ability to make an http request through script. I've used this a number of times to submit data to a server when I didn't want to update the page.
Most AJAX then also relies on the ability of javascript to parse an XML document (to examine the results of the post) and some form of dynamic page-rewriting to change the current page based on the XML document (generally object.InnerHtml for content changes, or object.style for stylistic ones).
These features are fairly static - there's no need for them to change often. Simple AJAX - which is simply just offloading form submission - is good, useful, and most users don't even know it's there. As long as javascript keeps these three features, AJAX won't have major browser compatibility problems.
AJAX which rearranges the page after each XmlRequest is a bit more troublesome. It's also the flashy bit, which means its the bit every man and his dog tries to do. Using this technique, it is easy to write an entire site in one page - that is, there's one page the user visits, and the page rewrites itself based on their clicks. This is the stupidity of taking AJAX too far; you end up breaking basic functionality of the web (back buttons, refreshing, bookmarking, opening in new windows/tabs).
Just because you're paranoid doesn't mean there isn't an invisible demon about to eat your face
"Ajax is far more than just a fad" They never said it wasn't a fad. It's fad++.
Standup Comedian New York, NY
"Ajax... is an approach that helps you transform clunky Web interfaces into interactive Ajax applications."
Couldn't have said it better myself...
You don't want to know how many different versions of that object are probably listed in your registry. Hopefully the one that snagged the VersionIndependentProgID is the correct one. (Check under MSXML2.XMLHTTP as well.)
One line blog. I hear that they're called Twitters now.
"it's not nearly as hard to learn as an entire new language."
Standup Comedian New York, NY
A growing annoyance is a page that hangs during loading because its advertising site is slow. With plain HTML, page rendering isn't delayed for image loading. With AJAX, page load can be stalled while the ad server cranks. I keep seeing "Waiting for servedby.advertising.net" in the browser status line. Fortunately, I can just close the page and go to a competitor.
I just bought 40 backup tapes. First site had some problem with its dynamic stuff. Went to another site and spent money there.
Ajax is not an acronym.
From the article you did not read:
"
Ajax defined
By the way, Ajax is shorthand for Asynchronous JavaScript and XML (and DHTML, and so on). The phrase was coined by Jesse James Garrett of Adaptive Path (see the Resources section) and is, according to Jesse, not meant to be an acronym.
"
The Kruger Dunning explains most post on
I just can't decide:
1) point out that AJAX is nothing new, it's just a fancy schancy buzzword for DHTML+XMLHTTPRequest, and that I'm so cool since I've been using it since 1997 long before someone coined the term. In fact, long before XMLHttpRequest was even invented!
2) "Web 2.0" is retarded why do we need to version the web, Flickr sux, GMale sux, Google Maps sux, and anything with fancy javascript interfaces, rounded boxes, and pastel colors sux
3) obligatory overused joke regarding AJAX the cleaning supply
-tom
to do whatever General Kala says?
General Kala: "Confess and we won't hurt you anymore, we don't like doing this at all."
Man, so bad, it's great.
The Kruger Dunning explains most post on
Ok, one day Ajax is crap, next day its gold.. which is it?
For a simpler programming model for rich web applications, take a look at Tersus. Tersus uses a single visual language to create user interface, client side behavior and server side processing.
You do know that Microsoft actually invented the XMLHttpRequest object, don't you (they then completely ignored it for years until Google realized its potential)? And since COM/ActiveX is the main way things get done in the Microsoft world, it's entirely appropriate (although, you're right, the security implications are huge).
I will be really impressed if Microsoft really is changing their implementation to an in-browser object instead of a COM object, as it means that they will have changed something they invented to fit in with everyone else - the exact opposite of their usual behaviour.
I'm all for bashing M$ when they deserve it, but give them credit where it's due.
-- Dramatisation - May Not Have Happened
Actually, you have that backwards. The A in AJAX stands for Asynchronous. While AJAX is doing its thing, the rest of the page continues to load. It's when the ad is included via an object or img element that you end up having to wait for morons' ads to load.
It does not say AJAX is "not a fad," it says it is "more than just the latest fad." So he's saying it IS a fad (and the latest one), and more. I don't think that's an objectionable statement.
(%i1) factor(777353);
(%o1) 777353
All this recent talk about Ajax has me wondering, why is Slashdot essentially unchanged since 1999? Looks the basically the same and acts the same as when Rob wrote the first perl script. If AJAX is so great, why doesn't slashdot use it?
Until AJAX has a decent editable data grid widget, it will not catch on much for biz apps. It takes a while to get the kinks out of grids, so Ajax better get a start on it now.
Table-ized A.I.
I'm too lazy to search, but wasn't there a posting on /. just the other day where Jakob Nielsen claims that Ajax is teh suxx0r?
Who are we to believe?
I enjoy large posteriors and I cannot prevaricate.
If by useful you mean allowing MySpace to get pwn3ed, then yes, AJAX is useful.
Remember the Samy worm?
http://namb.la/popular/tech.html
He used html, java, dhtml, xml...
Especially XML
AJAX seems to be like Darth Vader... Powerful, yet dangerous.
[Fuck Beta]
o0t!
A web application framework, like Ruby on Rails, can isolate you from most of the JS. Here is a introduction to Rails and Ajax.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
Comparing that to the description of DHTML itself at w3schools:
DHTML also seems to involve a fair amount of DOM. So what is new about AJAX? Is it just the addition of XMLHttpRequest? And... didn't Microsoft invent that?
This article only begins to scratch the surface with AJAX. Beginners, only. One thing I'd like to add to the article - is the best way to parse XML documents. The article suggests:
function updatePage() {
if (xmlHttp.readyState == 4) {
var response = xmlHttp.responseText;
document.getElementById("zipCode").value = response;
}
}
Which is really the absolute WORST way to parse XML. It's a bear to support cross-platform. I have had the best luck for client-side-Javascript-xml-parsing using Google's XPATH library at http://sourceforge.net/projects/goog-ajaxslt/ - Sarissa is a close XPATH second, but she has trouble supporting Safari and other browsers.
Also, the article does not mention how brutal it is to work in JS at this level since there are very few savy development tools. Be careful before you invest a lot in AJAX or you will get CREAMED tring to support this code down the road.
Horns are really just a broken halo.
Yes, the generally accepted practice is to use POST whenever changing state on the server side. But I disagree with you about only using XMLHttpRequest when i would've POSTed something normally. Being able to maintain state on the client and fetch more data (a GET) from the server is a Good Thing, also. In fact, it's what i mostly use XMLHttpRequest for.
Not that that in itself helps with the bookmarking issue, though i also agree with you that providing a link where it may reasonably be useful, as google does, is also a Good Thing.
"Our interests are to see if we can't scale it up to something more exciting," he said.
You can tell this is a fad because 1) this technique has been available for years this with Java applets, iframes and dynamic script src includes 2) it's not beneficial for 99% of the websites out there 3) it requires extra work to make the process intuitive to users 4) it's more costly to develop in that it takes longer and requires more smarts, and most of the time it isn't going to pay for itself, because simply getting rid of a page reload in the age of broadband doesn't itself improve the underlying quality of the website. The success of most websites still has 99% to do with content and 1% or less with UI aspects. Look at Craig's List or this website. The reason the technique has become popular all of the sudden is because Google has been incorperating it alot and someone gave it a name. Before the name AJAX came along you would have had to describe it with a sentance and that doesn't fit in a headline. Before HTTPRequest you could have as easily done an location.replace() to a CGI in a hidden frame and had the CGI's response do a callback to a function in the calling window and it would work exactly the same way. When you use the location.replace() method you avoid the clicking sound and the history entry when calling the hidden CGI. You can even use an iframe if you want to avoid using a frameset. This technique has been available since the 90's. I might still prefer this method because it's more robust and there's no need for compatability checking.
If you had an ounce of understanding of web architecture, you'd know that AJAX would actually alleviate those problems. You know (A)synchronously loading the ads via (J)avascript with an (A)PI that calls (X)ML data about the ads.
In other words, you are a complete idiot.
Hey, I'm just your average shit and piss factory.
I'd recomend checking out the Prototype Framework. It make all of this transparent.
Jeremy Logan's Website.
I've been working on a project that provides a web-based environment for people with a medical condition to get counseling and support online. Chat has been one of the desired features, but the various methods for implementing chat were presenting a problem. Java applets and Flash applications presented problems with time to load for modem users as well as issues with having the right versions of Java/Flash player installed on client. I thought setting up a Jabber server and letting folks use a client installed on their computer would be a good solution, but many (most) found it too difficult to install and configure a chat client. (These are older folks often with little computer experience.) AJAX came to the rescue. The "chat client" is part of the web application. It is as lightweight as the typical web pages being loaded. The exchange of messages between client and server require very little bandwidth. The chat application is just part of the same environment that the users are already comfortable using. I don't see AJAX as the answer to everything and, for the moment, having web applications chock full of AJAX doesn't make sense. But, it has come in very handy in the case of chat for the project I am working on.
JavaScript has so many functional work-arounds for each browser
Such as? I'm aware of plenty of workarounds for the DOM, but that's nothing to do with Javascript. I'm also aware of the different ways to create an XMLHttpRequest object, but again that's nothing to do with Javascript (hint: it's an API you're calling, and just as the differences between KDE's libs and gnome's libs are nothing to do with C, so the different APIs the browsers implement are nothing to do with Javascript).
So when you write Ajax applications that need to work on Internet Explorer, you need to create the object in a particular way.
As others have already pointed out, that boils down to an if... then... else... construct. Big deal; if you can't handle that, then you shouldn't be coding in the first place. No, it's not ideal, but c'mon, it's not exactly rocket science either.
It's official. Most of you are morons.
Ajax, which consists of HTML, JavaScript technology, DHTML, and DOM[..]
This came out of someone from IBM? I fear for the species if this is the case. Wake up! DHTML is just Javascript and HTML - you know, another one of those silly terms thought up to describe combinations of existing things. It's not something exclusive. This 'expert' should learn to get his terms straight.
BeauHD. Worst editor since kdawson.
Might as well be X or VNC. Lets face it people. If you want a desktop in your web browser, we already know how to do that.
Deleted
Er, what are you talking about? Of course I know that Microsoft came up with the XMLHttpRequest object. I didn't think I had to explicitly give them credit every time the subject comes up though. And I didn't say anything about security.
Just to recap, my point was that Microsoft using ActiveX and everybody else using a native object is what causes this minor incompatibility, and the incompatibility is going away.
Bogtha Bogtha Bogtha
/. gets it right, for once.
The Admin and the Engineer
I'm genuinely confused. What does AJAX give you that Java applets do not? For example, people talk about Google's mapping application, and the ability to drag the map around. Isn't this something that Java was supposed to be able to do? And as far as browser incompatibilities go, isn't that what a Java applet program could circumvent?
What am I missing here? Furthermore, AJAX seems to force open source -- all of your source code is available so that malicious people can exploit its vulnerabilities.
You really think I give a darn about the hotmail address I use for messenger?
Come as you are, do what you must, be who you will.
DHTML *AND* DOM? i thought DOM was what made DHTML DHTML.
"hey, could you pass me a paper towel? er.. I mean... DEPLOY ABSORBTION PANEL!"
We've found it to be very impressive how much you can do with so little code... and it's nice to have a proper OO backend to a flash frontend... the flash frontend means we can [snip]
I block Flash and I encourage anyone I come across to do so as well. Flash means we can:
Win a $5,000 shopping spree
Get the X-Box 360 before it hits the stores
Win a dream vacation
Once in a while it does something worthwhile like batting penguins across the ice.
If I stumble upon a "Flash-only" website I leave and send the business contact for the domain an email telling them why I left and won't be a customer.
Ajax is fast -- it requests from the server only needed data -- saves downloading redundant HTML -- this has huge implications for delivering content to all kinds of clients, especially mobile/remote/latent clients.
I'm sold, Ajax is "a must".
-kgj
-kgj
-Eric
SJW: Someone who has run out of real oppression, and has to fake it.
Besides which, you should be using browser-agnostic encapsulation functions for managing your DHTML objects. It's future-proofing.
... not everyone has a speedy bandwidth? The applications (Office suites for an example) on the desktop are still heavy, even for some... desktops.
Developers try to minimize the HD/RAM used in every release. Integrating those applications on the web with a lite interface is very difficult since, I presume, "all" the byte's on the application are necessary. I think the problem "resids" on the bandwidth.
Much if not all the business logic would reside on the server and stay there. Only the presentation logic would live on the client side.
.Net client I'm working on talks to a Java backend via web services. It's still not ideal, as the client could be thinner than that. But we get some of the best benefits of both worlds. The UI richness of a traditional client with the transient connection of HTTP.
The current
I deally I'd rather see the UI defined in something like XUL or other technology that could be efficiently transported over the wire to a client that understand this. Similar to what X-Windows does but without the persistent connection.
--
Q
while (!asleep()) sheep++