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?"
It wont be any enormous instant change. But it will be a very slow methodical one. I notice that many companies are developing more and more web applications rather than buying expensive proprietary software. As companies break free of the proprietary software on their own, they will be more open to alternative OS and hardware solutions. All it takes is one salesman to go in to such a company and win them over.
AJAX helps because there was a set of desktop applications that could not formerly be made into equivalent web applications, but they now can be. You'll see MS take some losses over the years if the trend continues.
The GeekNights podcast is going strong. Listen!
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.
Many enterprises are plagued with too many proprietary, non-modular fat clients needed for Customer Care, Service Management, Billing, HR, etc. etc.
The people on this sometimes have to work with 1-5 apps for one transaction (e.g. Cable Service Customer calls Customer Care about a billing problem for a PPV event, CC maybe agent has to look in one app details of the Customer, in another if there was a know outage, in a third if the money was transfered from the customer, and then maybe open a ticket in a 4th, etc., all while copying&pasting data from one app to the next)
All that because each of the applications just offers a dumb fat client to access it per default.
If vendors - which should have no interest in that kind of lock-in - started to offer modern Web GUIs, that would be a step in the right direction.
Though expect that these Web interface will pop up, and have already, I also know that the underlying interfaces often doesn't lend itself for easy integration with others.
Will the trend threaten Microsoft desktop near-monopoly?
No, it will strengthen it. According to the article, Microsoft is already creating a proprietary toolkit for AJAX.
Perhaps they hope their toolkit will become the standard.
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.
If moving CPU cycles and storage on-line to big company's (compare how fast it takes to search all your emails in gmail and Microsoft outlook, and how much space is available and backed up), then i can see the demand for new, faster PCs for a lot of people to decline.
When that starts to happen, who needs the newest and latest OS, or even a PC anymore when you can do it on your WiMax enabled pda and opera.
Things like Ajax only help move this data off the PC on-line and reduce the need for both a OS and PC
"In a time of universal deceit - telling the truth is a revolutionary act." - George Orwell
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
They said the same thing about Java, right? Which is faster than web apps (even if you think it's slow compared to C) and has more access to the file system and it's resources.
The way to make the Desktop unimportant is to have cross-platform applications become the norm. Word processors especially, but also browsers, mail programs, etc. Only when the apps that average folks use every day can be found on every platform will the platform cease to be so crucial.
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?
I would like to pour some AJAX on my Windows installations... maybe scrub off some of that OS...
Think AJAX is too harsh to be an effective fdisk?
"why don't you just slip into something more comfortable...like a coma!"
Okay, I'll feed the troll.
As a web developer, I'm currently focusing my AJAX development on our Intranet. It's safer in the sense that we have more control over the browser and it's less likely that people with odd browsers will complain. That's where most of the interest is at the moment. For example, a form builder that lets people drag and drop controls, update properties, and so on.
There's a reason why Google maps is so popular while Google Earth (a client/server app) isn't as much. Anyone with a modern browser can use Google maps, while Google Earth requires an install, the right OS, and more.
NO, this isn't going to happen anytime soon. My wife just asked me why someone would want to mix cleaning products and computing, so what do you think ole PHB is gonna say?
My humor is probably your flamebait
The along came things like microsoft Basic. The computer would boot into an interactive language environment. If you wanted an operating system, you wrote a program in the language that could do primitive reads of some storage device (paper tape, cassette and later 8" floppy), on that was a larger basic program that would do operating system commands like list the files on the tape/floppy and allow you to copy them.
then along came DOS. While mini computers (like vax and prime and wang) had had OS's for years these were new to Mini computers. now the computer booted to the OS and if you wanted to program you had to load BASIC or fortran to create a programming environment.
Then along came the PC. suddenly there was this thing call the BIOS that normalized a lot of hardware kinds to a more uniform hardware API. And there were these device drivers that patched the OS.
THe OS slowly became more layered in design but that was transparent to the user.
the next big leap were browsers and quickly JAVA, which were touted as a normalizing layer over the OS to make machines more common at a higher level of abstraction above the OS.
Everyone thought webapps would rule. Never happened.
Maybe it was just too soon. Or maybe it's because MS torpedoed JAVA's cross platform success.
Now were seeing the rise of Javascript and XML. A few years back that would have been a joke. But I guess computers hand interpreters and high speed internet have gotten fast enough now that you can do slick things Google maps. Fast enough for simple common operations like Calendars, editors, spreadsheets and what-not.
my own feeling is the interface itself is still pretty crude. I'd rather run local apps. On the other hand if I were a corporation I'd probably tell my employees they dont need a faincy calendar or editor they need a siimple one we can maintain on a server.
So my feeling is that for the most part this is just another layer on a rather large stack of layers. and probably the slowest one yet. It offers little improvement to the user but does simplify maintainence and offers attractive corporate benefits.
Some drink at the fountain of knowledge. Others just gargle.
The main reason the internet caught on is because it had a consistant UI that everyone, even non-computers users, could use.
- All links worked the same way and had the same right click menu.
- The back button could get you back if you get lost
- You could bookmark what you're interested in.
With showcase AJAX applications from leading software vendors all of this is broken. I can't bookmark. I can't use the back button (I remember when only porn sites used to do this - and now Microsoft sinks so low?). I can't use my right-click menus that I know.AJAX combines all the inconsistancies and learning curves of desktop applications with all the limitations (bandwidth, limited access to local storage) of the web.
Please make it stop.
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.
Have you actually developed something using AJAX? I'm going to guess not if you think it works in "any browser." It probably works in Firefox/Mozilla, good chance it works in IE6, Opera and Safari if you say a few prayers, and anything else is pretty unlikely. Now, you msy say that's most browsers, and it is, but it is not "any browser." There are still people using Netscape 4 for some unknown reason.
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.
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.
Just to see what the fuzz is all about I created a small AJAX "app" using SAJAX, a small AJAX toolkit for an assortment of languages. Here it is: SAJAX + Google Define-test. Kinda fun and very simple to write. I don't see any obvious use for it though except for larger applications such as Google Maps. Most "interactive" contents over HTTP is message boards and such and they don't really benefit from AJAX directly.
I always keep all Javascript and other active scripting turned off, and have been happily surfing the Web problem-free for years. I have no desire or interest in enabling Javascript.
Sure. And I happily use my PC with the ethernet cable unplugged. I've been virus-free for years.
I don't respond to AC's.
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!
You're making the assumption that the bulk of data handling is going to happen in the web browser (which may be the case in AJAX, I don't know anything about it). This is simply not true.
For an example, take a look at mldonkey. The engine runs as a separate process, and lets the user access it through either a very primitive telnet interface or a web browser. If you use the latter, you get a graphical user interface without having to depend on GTK, QT or Windows (and can start the core from crontab as soon as the machine starts, without having to wait for the user to log in and start it from X-Windows).
Or take the program I'm writing. I regularly read binary newsgroups, and have accumulated thousands of image files (from fantasy-sci-fi -group, so save the jokes about porn collection), and must manage them somehow. As a solution I wrote a python script that downloads the images from desired newsgroups, decodes them, and inserts them into a PostgreSQL database together with all the headers and other data that could be collected from the message (and even checks fro dublicate posts and simply links to the old image in case one is found). The database uses a web browser (through Apache and PHP) as its user interface, but the actual data processing is done in Python, PHP, ImageMagick and PostgreSQL. This frees me from having to worry about the interface into wondering how my Python script actually works, since I forgot to comment it and can't make heads or tails out of the 3-page listing ;(.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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.
Flash can be really horrible for a great many things. As a Mac user, I'm unfortunately familiar with its occasionally lagging performance. But it can fit the bill for some things, and I think Macromedia - before they became Adobemedia, of course - were really trying to promote Flash as an application creation tool, rather than just some fancy rich media web plugin. Think about it.
Oh. And Flash had remoting with XML while the term AJAX was still a gleam in the eye of those folks at Adaptive Path.
concrete5: a cms made for marketing, but strong enough for geeks.
AJAX is overhyped. This technology was available for years, and nothing revolutionary has happened. It recently just got a cool name...
1. Closing browser window (or navigating away from page in something else than Opera or DeerPark) kills state of application.
2. It still needs roundtrip to server
3. Still needs HTML+CSS gui, server backend...
Web apps are web apps. AJAX web apps are still web apps, but a little faster, duh.
Google maps etc. aren't really striking examples. If you want to see something really cool, go to http://demo.atmail.com/. The web interface of their online e-mail client is, I dare say, superior to many traditional ones. It's an incredible example of what a modern Web browser (both IE and Mozilla-based) is capable of.
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.
XAML is more about the (inherent) problems in defining UIs in HTML than how to drive those UIs to actually do stuff. Any UI done in Avalon is or could be represented in XAML, but it isn't any more sexy than a total upgrade to the old and almost-forgotten Windows resource files with their "dialog templates". It COULD be used in a browser, just like Swing in Java can be used in a browser, but it's simply a declarative way to define UIs with some similarity to the web paradigm, but some real differences, too. Think "HTML + SVG + VRML" and then throw in a Not Invented Here to change it somewhat and adapt it to the Win32 legacy. Voilà... XAML!
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."