Slashdot Mirror
Will AJAX Threaten Windows Desktop?
prostoalex writes "They are not your father's HTML pages anymore. AJAX interfaces are getting more complex and versatile, relieving the user of the necessity to reload the page, and thus are becoming more like your average desktop apps. The catch? AJAX apps work in any browser out there, making the OS layer a bit irrelevant. Will the trend threaten Microsoft desktop near-monopoly? Or are we hearing the story of poorly debugged device drivers again?"
I was under the impression that the answer was a pretty resounding "no". Some things have to be done locally. We had the same discussion about Java, which at least was a general-purpose programming language.
Indeed, There has been talk of the Doom of the Desktop for years, and sure enough there are increasingly many apps that don't require it, but that there will be some big avalanche of abandonment is unlikely.
Facts do not cease to exist because they are ignored.
I know I'll get marked up +5 troll for this, but this has to be the lamest thing I've seen posted on slashdot.
As a web developer who has done work with AJAX (as people like to call it these days since google started using the 4 year old technology) and has built numerous applications with it, it's never going to replace desktop applications.
Never, never, ever. PERIOD. (of course, this is slashdot though... we need to find every possible way to topple that devilish windows!)
...it might make Microsoft's offerings less relevant. if most tasks people need to do can be done with online office apps at (say) OpenOffice.org, and other online apps from Google and other companies, that could make standalone applications irrelevant if their browser-based replacements are sufficiently compelling.
Once you can do everything you need to do on your PC without Microsoft, the same way you would with Microsoft (eg, in Safari or Firefox rather than IE, but the same links and buttons), it's much easier to convince people to try out something new, like a mac or a linux desktop.
That's the threat here.
Stasis is death. Embrace change.
The web applications that benefit from AJAX benefit because the experience is snappier, and because it can behave a little more like a desktop application. That's all.
Making web applications look, feel and work like desktop applications take time and require hard work, and it's mostly useless because the tasks that wouldn't be hurt by being transferred from a desktop application to a web application are few. Programs like The GIMP and Photoshop are near impossible to do as web applications, and that's not because HTML wasn't build for web applications, but because they shouldn't be web applications in the first place.
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.
Open Source Java Web Forum with LDAP authentication
All that because each of the applications just offers a dumb fat client to access it per default.
All that you are doing with AJAX is writing the dumb fat client using a different, less capable programming environment than what is used today.
Because it works on any platform that has a web browser
Like Gmail did so easily?
, without requiring the user to "install" anything
Like Google Earth?
No. It doesn't matter if something is better or not. What matters is who has the most marketting muscle. We know who, at present, this is. There might be an MS AJAX, but I'm doubting that unless it's successfully patented by them somehow since we see that the whole idea is that it runs anywhere.
No, we've seen countless "better things" not accepted. I don't think this will be any different.
Wow, you guys must be really enjoying your high out there. Sure, AJAX is nice, but it's not going to replace desktop apps anytime soon. Note that Flash and Java applets have been available for a long time, and they are actually more flexible than AJAX. Also note that AJAX, contrary to what you may think, does NOT work in all browsers. In many browsers, your experience will still be limited to some text on some page, at best. And people actually _do_ use these browsers.
As for the people who think that Microsoft is going to get into losses because of this, you should _really_ cut down on your dope. In case you had forgotten, Microsoft has not traditionally been defeated by superior products, and they are actually working on a system of their own for providing a rich user experience through the web (XAML).
As long as web standards insist on the heavyweight request-response model, they will never achieve the snappiness, responsiveness, and flexibility that can be achieved with proper applications.
Here's some food for thought: imagine a simple instant messaging program, written in your favorite programming languages. One the connection to your chat party is established, all you need to do is send the text the user types, and wait for incoming text and display it. Now, imagine implementing the same sort of application in an environment where the only possible communication is you making an HTTP request and receiving an XML response.
Please correct me if I got my facts wrong.
Remind me again which business application needs to run several thousand times faster, needs to have data stored on your local unbacked-up-hard drive, and has so much information that streaming data to the client over 100Mbit causes any appreciable delay?
You win if you say any graphics design/layout program. You lose if you say almost anything else commonly in use by businesses today.
AJAX is also good for intranet applications that need to access the companys database for example.
It much easier to upgrade an AJAX application than a traditional application for 2000 employee computers.
The IT staff probably loves this trend!
It's not Photoshop or heavy-media type applications you should be thinking of, it's the simple end-user-interacts-with-database type applications - where you don't need to have lightning-fast feedback. It's the sort of applications that can work fairly well even as "traditional" web applications - eg. webmail, usenet, flickr, etc.
Using AJAX-like techniques just opens the gate a bit further and makes it possible for quite a few more types of applications to exist and run on the "web" platform.
And the thing is that lots of non-computer-geek people really like web applications - they tend to be simpler and easier to use, there are no download/install issues, you can in theory access them from any computer with a network connection and a web browser (ie. just about anywhere), you don't have to worry about managing or backing up your data because it's being looked after by professionals (for what that's worth *grin*)...
No, webapps in general (and AJAX-type web apps specifically) can't do everything. But they can do a hell of a lot more than you might think.
I know many people here won;t like to hear it, but the answer is to use IE only. So many companies have your problems that, in the end, they said "sod it, as long as it works on IE, it'll be fine".
You can blame MS as much as you like for any shortcomings in standards (though much of it lies at the door of Netscape in the first place - MS had to break standards to compete with the broken bits in netscape IIRC) but it doesn;t matter 1 fig - in the world of business my manager doesn't care or know the difference between IE and and other browser, he just wants results. Same with so many other managers, and the net effect of this - IE only policies.
That way, your apps work on the majority of desktops, especially those that your company will be using.
Now, if Ajax really is the new 'single target' to write for, then the world of webapps might well have finally matured. Bring it on!
AJAX apps will replace numerous desktop apps, but not because they're better. Vendors distribute products as Web apps because of a distaste for installing things by IT departments. Not requiring an install on every desktop can mean the difference between getting a sale and not. AJAX allows this to be less of a compromise in user experience, which in turn translates to competitive advantage.
f rame.html) as well as a library called JSRS that works in v4.0 browsers (http://www.ashleyit.com/rs/jsrs/test.htm).
Even in the Web space, AJAX isn't actually better than anything: Flash is arguably a more appropriate rich application platform and can do everything AJAX can. Java is an even better application platform. But I think people got burned by client-side Java when it first appeared and are wary of it now. In addition, turning your Web app into a Flash or Java app requires significant retraining and recoding, while adding some AJAX does not. Thus AJAX is an easier path to a better product in many cases.
AJAX is also not a silver bullet for application functionality on the Web. For example, an AJAX-based word processor can't directly open and close documents on the user's hard drive. While the solution doesn't have to be local file access, the current state of affairs isn't enough I don't think. Also, Web apps are stuck inside a Web browser, which means limited acces to OS-wide features and unfortunate ties to a UI designed for pages, not apps. These aren't limitations to AJAX only, but to anything confined to a browser window.
For the promise of AJAX to be realized on a large scale, some things need to happen. Web app frameworks need to incorporate it more. This has already started to happen with Rails, JPSpan, and others, but the integration needs to be tighter and the standard enterprise development environments need to incorporate it. In addition, AJAX permits much more application-like functionality but the Web only natively supports some very basic user interface elements. A standard set of elements, available to everyone with a consistent look and feel, will both make building AJAX apps easier and make for a more consistent, predictable user experience Web-wide.
Last, it's worth noting that you can do AJAX in earlier browsers than those that support XMLHTTPRequest. It used to be called Remote Scripting, and there's an excellent article on the Apple developer site describing the technique (http://developer.apple.com/internet/webcontent/i
Most of the web references to AJAX that I've seen correctly point out the importance of checking the browser version, the necessity of testing on many different browsers and versions, and the difficulty of fallback coding if XMLHttpRequest isn't supported. For example, see the AJAX page at http://en.wikipedia.org/wiki/AJAX.
This is not to say that AJAX isn't terrific, and a major breakthrough in building more responsive web apps. But it's often important for the application to work for all users, many of whom are still running Windows 98 (with an old IE), Mac OS 8 (or earlier), Palm OS, and other systems that don't support AJAX. Sometimes these users can be ignored, and sometimes they can't. If they can't, the developer who wants to use AJAX may have to program (and document, test, maintain, etc.) a second, non-AJAX interface.
No, but the interface is vastly superior to Google Maps, which is its AJAX equivalent. So, the answer to the story is a resounding no. AJAX apps will not threaten Windows (or any) desktop.
Had the question been "Will AJAX enhance the Windows desktop?", the answer would have been yes. Of course, AJAX will enhance Mac, linux, bsd, whatever desktops, but that's not 'news'. Sadly, "X threatens Microsoft" is seen as news round these parts.
AJAX has about as much chance of replacing/supplanting the desktop OS as software patents proving to be worthwhile. It does answer to a lot of the problems of client-side apps, but is hardly the end-all and be-all of browser compatibility. The *only* way to do that is to have the application run inside of an independent player/interface like Java or Flash.
Javascript/AJAX is tied to stock HTML controls, has no real persistence (and don't say 'cookie' unless you want to be glared at), is most definitely not browser-generic, and can (and will) break as new Browser versions are released with 'fixes' that break the numerous workarounds that AJAX has to rely upon.
Now, I realize Flash has never been taken seriously as an application tool, mostly because the entry level for using it has left every tool with a mouse and too much free time the ability to annoy us with pointless splash screens, unusable interfaces and incomprehensible navigation systems, and also because it was hair-rippingly slow, had poor text rendering, and lacked good UI components.
But this is changing. With their new product, the vapidly over-priced Flex, Macromedia has introduced the world to a workable, streamlined and semi-intelligent IDE/framework for developing decent browser applications. More importantly, it has shown more industrious developers that they can use it to develop their own frameworks, and both together promise to make Flash a much stronger (but still very, very unlikely) desktop killer. As to the other problems, between Flex and the forthcoming Maelstrom product is much faster thanks to bit-caching, text rendering is very good, and the UI component set has become very solid and much more comprehensive.
The most important note here, however, is that until a browser app has access to system-level resources, it will never perform as well or be as powerful as a desktop application except in the certain roles like data management/manipulation or user interaction.
Just as a footnote, the reason I wouldn't put Java up front is because the development time for Java apps is way too long for the type of application that belongs in the browser as opposed as to a desktop application (not troll-bait, just my opinion).
------------
Look, over there, another for-cristsakes menu!
Good points, but none of them countered my argument. Most things are possible given the right browser plugins or built-in browser support (as XMLHTTPRequest and Javascript themselves are examples of) - I never debated that. I just think that it's insanely stupid to build certain kinds of apps as web applications because their implementation could be better off being built as a desktop application.
) Desktop applications are neat. Moving certain desktop applications to web applications (or vice versa) to gain certain benefits is very neat. I never once contested this. But to *cram* all of one class into the other class for no particular reason, that's just not neat, beneficial or useful.
There's another side of this, too. If you have Photoshop or The GIMP or Paint Shop Pro installed, you can, with very few exceptions, snag an image from anywhere, get it into your program, edit it in a familiar environment (including usage of your own filters, shortcuts and what have you), and get it out of there. That's the whole point of desktop applications.
Web applications work just fine with text and to a lesser degree with file attachments, but making it work gracefully with other kinds of media, including rich text (yes, I know about contentEditable HTML and so on), video, sound and pictures (vector- and pixel-based) *built in* would require a major reworking of the way web developers work with HTML and Javascript. And what are we left with? A sub-optimal clone of desktop applications.
You say that I could have my drawing app as a web application. I don't *want* my drawing app as a web application. Making everything into a web application is a text book example of having a hammer and everything looking like nails.
Web applications are neat. (I would recommend everyone and anyone to read http://daringfireball.net/2004/06/location_field.
Do not do this; it is broken.
If you want to use the XMLHttpRequest object, then the correct thing to do is to see if the XMLHttpRequest object is available. The browser version has nothing to do with that.
If you see me using Internet Explorer 6.0 and say to yourself "oh, I can use XMLHttpRequest because Internet Explorer is on my list of web browsers that support XMLHttpRequest", then your code is going to break when I have ActiveX switched off.
If you see me using FooBar 1.2.3 and say to yourself "oh, I can't use XMLHttpRequest because FooBar 1.2.3 isn't on my list of web browsers that support XMLHttpRequest because I've never heard of it", then your code isn't going to use XMLHttpRequest, even though it might be a simple shell on top of Gecko.
In both cases, you've done the wrong thing. The correct approach is to check to see if the object is available ("object detection" instead of "browser detection"), because that's what really matters. Browser detection is a fragile, archaic practice that competent developers stopped using back in the 90s. If you see it in a tutorial, then it's a good way of knowing that the tutorial is shit and you need to find a better one.
AJAX wasn't invented how long ago? AJAX has been around for several years, but with a less than sexy name. It was, and is stil in some circles, known as remote scripting. Yes, it's improved upon the original remote scripting, but the concepts are essentially the same. Remote scripting was just a little ahead of its time and now it's got an acronym to help it sound glamorous.
Google maps may only be a "hack" in your terms, but perhaps that is a more logical direction for enterprise apps. I work for an enterprise application software vendor and see the challenges of implementing these all-inclusive apps at a customer site on a daily basis.
From the common business user perspective, a whole set of these clever hacks could contain most, if not all, of the basic functionality that each user needs. Build an architecture that supports such hacks and deploy the functionality based on a hack-to-role responsibility matrix. The more I see our own enterprise app growing in number of forms and tables, the more I shake my head as the deployment of the application grows in what seems to be exponential rate.
Well as long as they're tied to a web browser, there are a lot of usage considerations to worry about. Users expect a web browser to behave in a certain way. AJAX breaks that model -- back buttons become non-functional, or function differently than expected. Reload may or may not get you anywhere -- there's a host of problems.
For AJAX to replace the desktop binary, it's going to need a new generation of browsers. Either that, or we're going to have to train a lot of users -- and we all know how that works out.
Killfile(TGK)
No trees were killed in the creation of this post. However, many electrons were inconvenienced.
It's not really correct to state that AJAX is good for Internet or database (meaning network information) access apps. A better model is that AJAX is good for apps that DON'T require X, Y, or Z, for appropriate values of X,Y,Z.
Plain old executable client side apps written in C can access network information as well as any AJAX app. But they can also do anything else your client OS allows an app to do. You can have a full-featured, fully interactive user interface, local data storage, high performance, inter-app communication, etc., in addition to your network info access if you write your app in C (or some traditional equivalent.)
The only advantage an AJAX app has over a traditional app is in installation, which can be considered an almost instantaneous, just-in-time network install. ("Cross platform" is not an advantage since writing different code for different browsers, which we still have to do, is just like IFDEF'ing your C code for different OSes.)
I say installation is the only AJAX advantage, but it is a HUGE advantage, so much so that most app developers would love to have it. Well, they can have it with AJAX, but only only if their apps DON'T require X, Y, or Z.
What I'd like to hear from an AJAX expert is a list of what you CAN'T do well or *reliably* with an AJAX app--based on experience, not guesses. It seems that all of the successful AJAX apps I've seen have had UIs that were so simple that they were just marginally more than a static HTML page.
"Those who have never entered upon scientific pursuits know not a tithe of the poetry by which they are surrounded."
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz