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?"

Comments

Slow pain

[Apreche]

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.

Re:Slow pain

[strider44]

I doubt it. AJAX is good for applications that *need* the internet (Google Maps -> streaming map data. GMail -> email). In my opinion they will never really replace pure binaries.

Re:Slow pain

[bigman2003]

I will admit it, I am a bad programmer.

One of the main reasons I am a bad programmer, is that I have been one of the people with a 'tool' (standard desktop apps) who has been looking for a place to use it...instead of having a project, and then looking for the tool. I have searched high and low throughout the place where I work for projects to fit what I wanted to do.

I got tired of writing web apps a few years ago, and I decided that I was going to start writing some desktop apps, and distribute them in the traditional way. I was thrilled with the idea of having 'versions' of my programs. Yes, that was actually exciting, rather than just doing a million incremental upgrades.

But alas, it was not to be. In the last 5 years we have not had need for a single program that would not run on all platforms. Or anything that did not retrieve real-time data, or anything that we wanted to use an new and different (non-web) interface.

Oh well, I finally gave up a few weeks ago. For me, in my position, non web-based programming is very, very dead.

Re:Slow pain

[tricorn]

The ONLY advantage that something like AJAX has is that most people now have browsers that can support it. Other than that, it is an extremely poor "cross platform" virtual windowing/execution environment - it substitutes one type of incompatible platform (CPU, OS) for another (Web browser). Sure, supposedly Web browsers are supposed to all be conforming to a standard that can be used, but we all know they aren't.

Web development, especially when doing something like this, is no less expensive, and can easily be much more expensive, than creating a classical application. If you want cross platform, it would make much more sense to do such development to another platform which most people have, which is Java. Web browser or JVM, in either case you need to do an installation of the platform once (or it can be pre-loaded on your machine, of course). Different JVMs should be more compatible than different Web browsers currently are. People who complained that Java was too slow should be absolutely aghast at the speed of AJAX.

With something like Java Web Start, all of the convenience of just going to a Web page to start your application is there, along with the ability to cache and update applications. You can certainly do anything in Java that you could do in a Web browser, and you can do it a lot faster.

Re:Slow pain

[wilsoniya]

AJAX is also good for intranet applications that need to access the companys database for example.

So true. I was charged with writing a seemingly simple call-center manager for smallish market research op, but like so many things, the powers that be liked it so much, they went wild with expansion ideas. Luckily I opted for a LAMP solution and implemented AJAX, thus upgrades meant only one time script modifications, not an upgrade to dozens of machines.

AJAX can really streamline some traditional tasks like user-authentication. Go out and build yourself an AJAX function (w/ callback functionality) and you'll find so many uses for it.

Re:Slow pain

[Anonymous Coward]

Look for the article a while back on how google maps does searches.

It uses an hidden IFRAME to load the search data. That creates an entry in the browsers history, so it affects the behavior of the back button. It loads the data as XML, but it could just as easily load and eval javascript like google suggest (there was also an article disecting that).

Wrap it in a decent library, think your way through the way things work, and it's only slightly more complicated than using xmlHTTPRequest.

Hidden input elements are useful because the browser will restore them to thier previous values when it returns to the page (well, there are probably cache expiring issues). Store your state in onunload, restore it in onload.



NOTE: The following is untested, I came up with the idea one day at work, but haven't come across a reason to use it yet.



One interesting thing to try is to combine the two:

Make a plain vanila HTML file with only a form with a hidden input element. Whenever you want to create a "save" point, store your state in the input element, then reload the page to create a history entry. If you set your caching directives properly, the browser will probably load it from cache saving trips to the server.



Finally, this isn't really an AJAX issue, but split all traditional form POST submits into two request. A POST request that does the work, and redirects to the second. The second is a GET request to display the results. The browser will replace the POST with the get in the history, that way the user wont get a nasty warning when they try to go back, and possibly end up resending a request that could do bad things. Instead the browser will either serve it from the cache or resend the request for the results back to the server.

Attention: AJAX developers

[Anonymous Coward]

People shouldn't be running scripts of random websites, the web is for serving documents. If something requires more functionality than a web app, write client code.

Ajax == hyperbole

That is all.

In the enterprise: Yes, but slowly

[platypus]

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.

Re:Didn't we go over this before?

[cnettel]

Well, pipes are wider and CPUs faster. This enlarges the domain of "stuff you can do in really stupid ways" (that is, relatively thin client for a rich UI).

Another thing to note is that a full trend towards this, with the logical loss of not only a proprietary operating system, but a general-purpose OS of any kind on the client, could be a far more severe threat to user freedom than any "trusted computing by limiting access to ring 0" scheme...

Windows? What about the PC!

[Freexe]

Maybe Thomas Watson's quote about there only being a market for 5 computers isn't so far off the ball.

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

Re:Windows? What about the PC!

[cnettel]

So, are you going to pipe video uncompressed over these lines? With HD we actually need the same magnitude of computing power that's provided by current CPUs, or custom chips. If we continue to desire higher quality or the same quality with lower bitrates, CPUs are still needed. And, possibly, storage.

My real reason to be weary of this is another matter -- I want to be able to control and store my own data. If all I have is a browser and any real app requires a server, which I'm not able to run, then that's not a very appealing scenario. Will enough non-geeks appreciate this?

Java

[scrotch]

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.

What about the Intranet?

[PIPBoy3000]

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.

Layers and layers

[goombah99]

When I first started programming mincro computers (as they were called then) the program was entered with dip switches, then a bit later there was a computer specific rom that had enough information to operate a front panel and read a tape.

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.

AJAX is no threat to desktops.

[team99parody]

Ajax = sucks.

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.

"Any browser"?

[Anonymous Coward]

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.

Re:No.

[ultranova]

After all, why use a web based program when a binary runs several thousand times faster, you can save data on your hard drive a lot easier and there's no lag in downloading or streaming new data for the next web page.

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 ;(.

Heavy Web

[Doc Ruby]

It's about time Web "programmers" (too long a title swiped by HTML formatters) realized that URLs are just pointers. To (MIME) typed data, with varied fetch protocols. It's a measure of how badly designed was HTML: *cough*Andreesen*cough*.

His "circular reference oops" was a terrible reason not to use Berners-Lee's advice to use URLs as generic pointers to any embeddable data object. Any good programmer could have cut the recursion, merely by allowing only a (configurable) depth in the renderer, terminating in a hyperlink, rather than a fetch. The disease can be easily detected in the blowjobbing comment by Giza, the "Instructor": because Andreesen got lucky with Mosaic taking off enough for Jim Clark to pick it as "the next big thing", his design travesty was good, even though it was totally broken.

It's 12 years, and millions of hacks, later, and we're finally talking about "AJAX" apps that can get any data, any type, and insert them anywhere in a single document. Calling graphic artists "web designers" gave us a generation of deeper bad designs like half-assed IFRAMEs. How long will it take before we push AJAX JavaScripts back inside the app frame engine, so only a little bit of presentation tag code can lay out a GUI with dynamic data, accessed from and processed by distributed hosts? That was Berners-Lee's design for HTML/URL/CGI, back in 1990. Which is why Berners-Lee got knighted, and Andreesen only got rich.

Flaming Andreesen aside, we've now got "thin" browser clients that are as fat, in their way, as were the dedicated clients to proprietary client/server protocols before the Web. Sure, they do quite a lot, opening up the vast array of content, services and people now more easily connected to the Internet. But we're still trapped in the "browser". Imagine if all Windows apps ran in the context, and GUI, of Windows Explorer. Or all Linux apps in, say, Nautilus. Or every app ran in a panel in the Desktop itself. Using only the simple, static GUI of the enclosing app. Isolated from other apps, other data, any real configurability, integration or further programming by the app "consumer".

"Web services" should be the default for any process on the Web. It needs extra features, like per-call authentication (like htauth/SSL). Their APIs should be versioned and signed for reciprocal authentication of the service by the client. The data should be easily embeddable in any app, a generic remote procedure call. The services should be associated with default logic ojbects for further processing or rendering, keyed either to objects bundled with the local client app, residing in keyed repositories distributed around the Net, or downloadable from the service server. URIs should merely associated with URLs, not merely identical to them, so services/content can be retrieved by name or criteria, rather than by static location (a URI handle, rather than a merely dereferenceable URL pointer).

We've got more "computer science" students and teachers now than ever before. We've got more programmers, designers, architects, IT professionals, infosystem pundits. More depends on this system than ever before, and the stakes of getting more into it, and more people using it, are extremely high. Yet we're spiraling down the same drain that we flushed a generation ago, when we kicked off the fundamental Web architecture (really the ground floor, as per Andreesen's half-blind email to Berners-Lee) with a hack that was never fixed to work beyond its immediate deadline requirement.

Is there any hope that AJAX will become the norm, pushed under an API as simple as HTML 1.0? The Windows apps (and equally mediocre frameworks on all the other platforms) are stuck with their own cultural and legacy requirements baggage. After 15 years of spinning our Web wheels, have we merely moved our architectural tangles onto the Web? Is all of our development, local or networked, doomed to consume 80

It's getting there...

[arturs]

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.

Re:well, it's complicated...

[Geof]

This is getting at the real reasons why AJAX is up-and-coming. The technical details (performance, GUI widgets, even portability) are relatively unimportant. AJAX is about network effects.

Web developers can innovate faster because they can iterate faster. If there's a bug, it can be fixed over night. Similarly for suggestions from users, so experimentation is easy. AJAX helps change users into collaborators in software development. These are the thousand eyeballs that made open source successful, only more so.

There are more of those eyeballs because the barrier to entry is lower. Users can try your software casually because they don't need to install anything. (I use Google maps all the time, but I've never downloaded any of their apps. It doesn't matter how good they are because I've never seen them.) Copying is 100% free when there's nothing to install.

One poster dismissed AJAX as only useful for Web applications. But that's critical, because most new software is about communication, which is easier to develop with Web technologies.

Finally, the software business is changing from a focus on software to a focus on services. Amazon and eBay are the two most obvious examples of software companies that aren't about the software. Even Microsoft has been trying to move to a service model; they're trying to cope with the fact that the best technology to enable that threatens their core business.

In short, the value in software increasingly comes from communities - from the network. AJAX leverages that. Somehow when we start talking about AJAX we think it's about programming and technical details. It's not. AJAX isn't about the software, it's about the Web.