AJAX vs. desktop development
Summary: AJAX development techniques create more interactive web applications that will put pressure on traditional desktop development. Desktop development, however, isn't standing still, and may leverage the expectations created by AJAX-style applications to popularize new innovations in desktop development technology.
AJAX is the web development buzzword du mois. AJAX programming isn't really anything revolutionary. It is simply a means of combining a bunch of web-oriented technologies in a way that enables highly-interactive browser-based applications. There are a variety of AJAX definitions floating around, but I think this article outlines the essential elements:
- standards-based presentation using XHTML and CSS;
- dynamic display and interaction using the Document Object Model;
- data interchange and manipulation using XML and XSLT;
- asynchronous data retrieval using XMLHttpRequest;
- and JavaScript binding everything together.
Of course, that's the way a developer would define AJAX. From a user perspective, though, AJAX applications - such as Google Maps or Microsoft's Consumers are no longer willing to put up with the traditional 'good enough' web interface.Web Exchange client - are simply web applications that more closely approximate features normally associated with traditional, standalone desktop applications.
Historically, web pages haven't been as interactive as traditional desktop applications. The web environment has limits, but the ease with which colorful "eye-pleasing" user interfaces can be developed combined with the automatically updated nature of a web application (you download the user interface each time you access it) outweigh these limitations. The user interfaces was "good enough," and the other benefits outweighed the costs.
With the growing popularity of AJAX-style interfaces, what was "good enough" has gotten souped up to compete more fully with desktop applications (though not completely...there ARE differences). Web development is already the most popular form of application development. Will AJAX programming techniques further that trend?
Maybe, assuming desktop development stood still and didn't try learn from its web competition. Fortunately, standing still isn't in the nature of competition, and desktop application development certainly isn't standing still.
First, though, consider what the shift towards more interactive, AJAX-style web sites means for web development. It signifies that consumers are no longer willing to put up with the traditional "good enough" web interface. They want something that FEELS like a desktop application, and that means the bar has been raised on web development, making it that much more complicated to develop.
With this raised bar, web development starts to become less elegant. HTML and CSS as a layout scheme is great, and a vast improvement over the limited functionality programming widgets that exist in traditional desktop development. Interactivity, however, demands programming, and unfortunately, Javascript doesn't scale up to the AJAX level cleanly.
Don't get me wrong...I use Javascript all the time. I used to annoy people at Nortel with my Javascript wizardry (back in 1997, there was a movement afoot to BAN JavaScript at Nortel, and I was, shall we say, resistant to that). I built tree views, calendar controls, animated menus, etc. using Javascript, and thought it was great that I could do all these interactive things that I had assumed were no longer possible in the HTML world.
The fact that you can write interactive web sites in Javascript, though, doesn't make Javascript a great programming language for complex site development. Javascript isn't merely a procedural language, and it does support objects, as well as the creation in script of new ones. The interface for doing this is hardly clean, though. It's like defining objects in C, where you manually set the function pointers on your object. Since the object is dynamically defined, however, you can easily create hard to find bugs by mistyping a variable name elsewhere in your code, a name it happily accepts because the definition of custom objects is dynamic. Last, Javascript is not a strongly typed language...at least not in the form used in most web browsers.
Anyone who has had to cull through several thousands lines of Javascript to figure out what a site is doing knows what I mean. Stacks of functions that manage the interactivity of an application might work, but it doesn't make the programming model elegant. Just for context, I could write an entire application using Office VBA (Visual Basic for Applications, the scripting language used for macros in Microsoft's Office suite). That doesn't make it an elegant way to write large, complex applications.
Traditional programming languages, with strong typing and rigorous object orientation, are a better option for such applications. That adds some complexity, but then again, AJAX-style web apps are harder to develop, making the productivity difference between desktop development and web development smaller. If desktop development could just fix its deficiencies, desktop development could start to seem a lot more compelling an alternative, particularly now that consumers have demonstrated a preference for highly-interactive applications.
That seems to be occurring.
The first example is Flash. Flash is normally associated with animated web sites that annoy the surfing programmer stuck in a typical "Joe Friday 'Just the Facts'" mode. Flash, however, also makes an interesting application development environment, enabling visually appealing user interfaces with less effort. Flash applications can also be turned into desktop applications, enabling the productivity benefits of the Flash environment to intersect with desktop applications to create something better than old-school desktop applications.
Microsoft, likewise, is turning the standard Windows development model upside down with its Windows Presentation Framework, slated for inclusion with Windows Vista and released as a separate library for Windows XP. Using the new vector-based rendering engine of Windows Vista, the old-style block rendering model is replaced with something more flexible. Furthermore, applications can be laid out, and effects tailored in an XML file (the specific grammar of which is defined in Microsoft's XAML schema). This XML layout capability makes desktop development more like web development (the layout portions of which are a vast improvement over the traditional desktop model), and combined with the auto-update feature of desktop applications in Windows Vista, could provide interactive capabilities far in excess of web applications while offering the productivity advantages of web-style development.
XUL is another option for highly-interactive desktop applications. Built as more of a hybrid of web programming and desktop application development (it was designed to create the user interface for Mozilla), it supports all the standard web technologies (CSS, Javascript, HTML), while enabling richer user interfaces than possible with standard browser applications.
Web development is probably the dominant model for application development. The fact that the commanding heights are still held by desktop applications, however, shows that there are features in standalone applications that still trump web applications. Those features may grow in importance as AJAX habituates people to highly interactive applications, and as desktop development ditches old development paradigms and embraces the innovations of the web environment.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
Mistake
I've been involved in some Flash development
AJAX, however, will have another year to entrench itself, but on that note, web development and web apps are already entrenched, and they aren't going to fix the issues of taping complex web sites together using Javascript in a year. A year from now, AJAX development will still have its limitations, IMO, barring some bold new path in web development that isn't built on existing web technology.
So it's more than mois and less than tout, eh?
You wrote:
AJAX, however, will have another year to entrench itself...
and mois was in your first line.
A double pun... Tells me I'd better get up for a while.
One small thing
If I've got a choice, write once, use everywhere or have multiple programs to write, I know what my choice will be ;)
Write once, use everywhere...
...and there's that little fact that Windows owns 95% of the market. So, you write to Windows, and you get 95% of the market in one fell swoop. Nice trick, and it's ALMOST write once, use everywhere.
At least WPF is (mostly) a .NET api, which means most of the apps will be written in .NET. That means that, in theory, other platforms could work on creating the support libraries enabling them to run. Or, Microsoft could decide to make a few extra bucks by selling the runtime libraries for other platforms.
I like WPF better than Flash, and consider AJAX the solution for the current web state of affairs. But then again, there are REASONS why I work for Microsoft.
use everywhere.....
hmm, if browsers would follow standards maybe than it would be easier, but alas, Flash relieves you of that burden, but then again, you work for the companie notorius for not using standards, but creating it's own "standards"
[i]...and there's that little fact that Windows owns 95% of the market. So, you write to Windows, and you get 95% of the market in one fell swoop. Nice trick, and it's ALMOST write once, use everywhere[/i]
Nice trick, but then again, i need to have access to windows whenever i want to use it, instead of having access to a browser (which is available for most devices) and a network connection at least in europe is almost everywhere available via GPRS, UMTS and WIFI ;).
WPF is as far as i know only available in Vista, so it will take some time before 95% of the market is using Vista so i can make use of WPF. It's true that MS has a large marketshare, but than again, that's divided up into W98, W2K and WXP (i actually assume that no one is using ME anymore because of it's wonderfull stability). I know that using WPF you can create web browser applications, but if that means that i have to start using IIS, no thanks. So unless MS gets the Apache foundation to play along, I won't be writing software for the WPF.
Maybe WPF can become part of web3.0, but we will see when that time comes.
Didn't I say something about being pathological?
If you didn't have such a blatant bias, you might just see the forest for the trees . . .
95% nonsense again
There are probably at least 5 million Linux machines as well.
If Sony release a browser for the PS2, then suddenly Windows might not be the major platform anymore.
I certainly think the 95% will take some proving.
In my opinion, it's probably 80% and falling.
I wonder if the figures are skewed by the fact that Americans spend 2 hours per day of work time surfing the internet in non-work related activities (according to recent report).
You aren't going to spend that long on an internet tv surfing the web I'd imagine.
Don't Go to The Internet, Bring the Internet To You
MS could provide a very easy-to-use development system, that allows different types of web site hosts (e.g. news vendors, bloggers) to produce, distribute, and maintain one of these smart applications for itself. MS could then provide an application that hosts and aggregates these smart client applications. The application could allow searches to be conducted on all data contained in all such applications available on the Internet, as well as data in traditional web sites. When a user clicks on a search result, the application could pull up the relevant smart client app - if it resides on the user?s computer - and take the user to the appropriate page in that application; or the host application could render the page in a generic ebook reader type of application, if it comes from a smart client application that is not on the user?s computer, or if it comes from a traditional web page. The host application could further have a Favorites menu that would allow users to navigate among the smart client applications ? much like the Favorites menu in IE allows users to navigate among their favorite web sites.
What would users get out of this? A vastly richer, more responsive experience when navigating Internet based data. What would vendors (e.g. Zdnet) get out of this? More satisfied users that tend to be more hooked into their services. Also, vendors would gain the opportunity to make more revenue from ads that could become very sophisticated and stable, since they would be able to take advantage of the rich graphic services of the OS, and because much of the ad data would be stored locally, making ad behaviors less vulnerable to network/Internet glitches.
Good points
The problem, however, lies in making desktop applications as easy to develop as web applications and making them updateable like web applications. That all seems to be happening.
I even remember Microsoft talking about making WPF applications runnable in a web browser (sandboxed), or even desktop sandboxing, though I haven't investigated that completely. That would, however, make desktop applications have many of the security features of internet applications. No, they are not perfectly secure, but they are much more constrained in their operation than desktop applications.
Desktop development has been waiting for improvements to match those found in the web environment, and I think they are finally over the horizon. At least, that's what I'm arguing in this blog post.
Vista Really Can Make Smart Client Apps Compete With The Browser
I agree with you. Smart client applications that you download from an unfamiliar company could be treated with the same precautions as a web browser. On the other hand smart client applications that you download from a trusted company, could be treated like most other smart client applications you get on a CD.
I think running WPF apps in the browser would be nice, but I also believe running a vendor?s smart client application would be better for a number of reasons. Mobile users would be able to look at Internet based data with a lot more flexibility. Someone e.g. could have Zdnet data pushed asynchronously into his smart client application that looks largely like a magazine ebook. The smart client app could store a month ? maybe up to a year?s worth of content onto the user?s hard drive. The user could then read the electronic magazine?s content on the go ? whether or not he is connected to the Internet. The user could even specify (based on certain rules) that certain videos be archived to his hard drive, so that he can see them while disconnected. Ads in the application could rival the slickness of ads seen on TV, and draw users into seeing ads in a much more compelling way than can be offered on a web page ? or even on TV! Even while disconnected from the Internet, ads could take the user through an ordering process, which finally goes through once the user reconnects to the Internet.
MS could encourage vendors to offer smart client apps alongside with their web sites initially, and let market forces determine which model is the winner. (Maybe vendors will stick with both models.) I know if MSNBC, Zdnet, and my other favorite web sites were to offer smart client apps like the ones I described, I would grab them in a second. Why? Because they are a lot closer to the ?data anywhere, anytime? paradigm that everyone keeps talking about, and they present information in a much richer way that can be provided by a browser.
[i]Desktop development has been waiting for improvements to match those found in the web environment, and I think they are finally over the horizon. At least, that's what I'm arguing in this blog post.[/i]
MS separating interface creation from the creation of underlying code is very significant I believe. This should make Windows desktop apps sleeker on average. Hopefully there will be vendors with products that will allow programmers to crank out very slick looking interfaces for their applications, almost as easily as Powerpoint allows ordinary users to create slick looking presentations.
I agree, again
Yes, and WPF makes possible whole new categories of smart applications. I gushed enthusiastic about it back in 2003 in my article about the PDC, and I'm still enthusiastic about it. I don't really see anything out there on the market that matches what WPF is trying to do, from a big picture standpoint, at least as cleanly. Flash does some of it, but the Flash development model isn't perfect, and has lots of grungy elements to it. Their scripting language, for instance, could be vastly improved, and it would even be better if they gave you a choice of language (Flash experts out there: if that's already possible, do feel free to tell me).
[i]I know if MSNBC, Zdnet, and my other favorite web sites were to offer smart client apps like the ones I described, I would grab them in a second. Why? Because they are a lot closer to the ?data anywhere, anytime? paradigm that everyone keeps talking about, and they present information in a much richer way that can be provided by a browser.[/i]
It certainly makes possible levels of interactivity not possible within the constraints of a browser. Use and acquisition, however, needs to be as simple and seamless as accessing a URL in a web browser. It sounds like Microsoft is trying to do that.
[i]Hopefully there will be vendors with products that will allow programmers to crank out very slick looking interfaces for their applications, almost as easily as Powerpoint allows ordinary users to create slick looking presentations.[/i]
You can write hand HTML, but there are tools that make the job easier. I bet the same will go for XAML, and other features of the WPF framework.
An interesting idea, but will it standardize or proliferate?
If that is the goal, then it seems that there are two relevant points.
First, there are already a number of things out there which are directed toward this end, as the article alludes to. all of the necessary tools exist. The problem is how the industry has used them, which has largely ignored possible standardization.
Secondly, by giving each vendor the ability to distribute their own customized interface for their own format, presumably not required to correspond to anyone else's format, you arrive where we have already been. There are plenty of attempts to deliver a hopped-up presenation layer for content, such as Zinio, which is already used by ZDNet for their electronic editions. But their are thousands of these little silos of 'standard' mini-apps, each one pointing at all the others and labeling them as 'non-standard'.
Worse yet, from a market share point of view most vendors want to lock their customers into only their product (content, in this case), and make life more difficult for their competitors (not that we've ever actually seen a vendor do that deliberately, right? ;-) to deliver. This pushes everyone to have their own anything-but-standardized interface, all the while claiming to be THE standard.
The genius of the web was originally that it was a very simple, elegant interface which was defined to compel web authors to write in a way which any browser could render. The more we go to customized applications required for each web site's content, the more thouroughly we trash that whole idea. Where the myriad of products currently stands is literally like every manufacturer using their own measurement system for parts, neither English nor Metric, so that everyone who wanted to repair or maintain a product would have to purchase a new set of tools for each brand...and for each time that brand decided to change their 'standard' measurement system again.
Bottom line, we don't necessarily need to give better tools to developers to customize their delivery. We need to develop a consensus among consumers that they won't put up with continual fractionalization of the web by vendors trying top lock them into niche technologies.
I Believe It Will
Secondly, by giving each vendor the ability to distribute their own customized interface for their own format, presumably not required to correspond to anyone else's format, you arrive where we have already been. There are plenty of attempts to deliver a hopped-up presenation layer for content, such as Zinio, which is already used by ZDNet for their electronic editions. But their are thousands of these little silos of 'standard' mini-apps, each one pointing at all the others and labeling them as 'non-standard'.[/i]
What I?m talking about are smart client applications that essentially store locally, portions of vendors? web sites (to support disconnected states and improved performance), and render the contents more richly than can be done in today?s web browser. The smart client applications would each be an enhancement of today?s web browser, and would support links and rich standard formats such as MS? upcoming Office 12 open XML format. The contents in the smart client application would be updated continually ? the same as what occurs on a web site.
The smart client applications would have a decidedly document centric architecture, and would support sophisticated functions including search, online purchases, video viewing, etc. Amazon.com e.g. could distribute such an application that would allows users to browse through its content with magazine quality layout, having better and more responsive search features, having better audio and video sampling features, having better ads that make people actually want to see them, having better purchasing features, etc.
The above is a far cry from Zinio, which is, from what I understand, largely an electronic form of magazines. The smart client applications I?m talking about would be highly interactive document centric applications, that not only display content via links, but also provide diverse application functionality such as active 3D charts, word processing, etc.
C-S by another name?
The main advantage of web-based applications (be they AJAX or plain ol' HTML) is that the updates happen at the server and the browser just sees the new page.
Also, any new MS experience would be predicated on everyone installing the new software to run it which at this point would include an OS upgrade.
It's about time!
You used a soccer/Quidditch anology. Here's one of my own: writing a desktop application is like getting in my car and following an extremely complicated set of directions to get from one end of New York City to the other. Writing a web application is like having to build a kit car to drive 2 miles down a straight road to get to the food store.
I don't even want to get into JavaScript, but I find it amazing how so many of the websites I visit throw off JavaScript errors. Each browser, each version of each browser, contains a slightly different implementation. For example, there was a long time where Netscape and Internet Explorer handled "true" and "false" compeltely differently when evaluating a scalar. One would accept any non-zero value as "true", the other would only accept one as "true". This came as a real surprise to me when evaluating statements like "if (strInputString.Length) {" suddenly started behaving erratically in one browser, even though this statement is perfectly valid in every C-style language I have ever encountered.
JavaScript is a miserable dog to work with. XHTML and DOM are even worse. Too many sites have fancy drop-down windows and graphics and what-not that simply do not work right. I'm using Internet Explorer 6, and yes, it isn't 100% standards compliant, but until Firefox came along, it was a de facto standard. Even now, IE6 is 75%+ of the browser share, so an AJAXed app had *better* work right in it.
HTTP was never designed to have applications running over it. Just read the RFC and anyone can understand that. It is a STATELESS protocol. Applications need to be stateful. Additionally, web servers are designed for handling burts of medium sized data, in the 20kb - 100kb range. This is why FTP is better for large files, and this is why the short burts of data transmission that an AJAX application requires for the XML passing are miserably slow. Read that RFC. HTTP was designed for one-shot requests. "GET me_this_page_and_be_done_with_it.html". It was not designed to keep a connection open once the heavy lifting of building up a connection was finished. An application that requires constant passing of data, like an AJAX application, requires that connection buildup and tear down to occur with nearly every mouse click, it seems like. Think about what the web server needs to do for each of those new connection requests, according to the HTTP RFC, and the logic of what a webserver does. Most of the CPU use on a web request is connection building. So why write an application that requires that to happen nearly constantly? I have no idea.
AJAX is a nifty idea, in it's own way. But I have no desire to write the code, and I have not been impressed with what I have seen. I agree, Flash is a much better choice, and has had the same capabilities that AJAX is trying to do today, for many, many years.
J.Ja
Why HTTP
With one exception: it can get through corporate firewalls that block everything else.
That, and that alone, is why everyone (Microsoft especially) is loading insanity like RPC (SOAP) on top of HTTP. It's an attempt to overcome HTTP's limitations. The fact that those firewalls [i]count[/i] on those limitations for security [1] is beside the point.
What we have here is an arms race. HTTP takes on all of the roles that other protocols have in the past, so that all but two out of 65000+ TCP ports become historical curiosities. In response, proxies have to become increasingly content-aware, watching out for illicit RPC connections and so forth.
It sucks -- unless, of course, you're selling "arms" to all sides in the war, in which case you can cry all the way to the bank.
[1] Not so much "security" as techies understand it as "security" as suits do: making sure that nothing is going over the wires that isn't under their control.
Feel Better?
Ahhooooga. Ahooooga.
DIVE! DIVE! DIVE!
Frameworks like Ruby on Rails will ease the burden on programmers wrestling with AJAX, just to name one.
Bill Gates characterized the changes in one of his recent memos--you know the one--vis a vis competing markets as 'disruptive'--that might not bode well for you and your bretheren at MS--given the frenetic pace of changes occurring around MS--VISTA is only a lick and a promise not due out until late 2006 and Live is, well, Dead.
But, I do hope that you found writing about 'AJAX vs. desktop development' therapeudic. ;)
I always feel better after I write...
Ewwwwww!