|
A key premise behind Microsoft's "smart client" pitch is that Web apps are not as good as fat/rich/locally based ones.
Microsoft defines smart clients as software that combines the best of Web apps with the best of locally hosted ones.
Microsoft's smart client elevator pitch: Web apps can't handle all the complex tasks that smart-client apps can. They can't gracefully switch between connected and disconnected states. And they can't take advantage of all the rich graphics and processing power that smart-client apps can.
Microsoft has been pushing the virtues of smart clients for at least two years. But this year, the company is intent on getting that message to stick.
But not everyone thinks you need Microsoft's .Net, Visual Studio and Windows environment to write powerful, savvy apps. There's an alternative camp that's gaining some mind share. They are backing a programming model known as "Ajax," which translates roughly to "asynchronous JavaScript and XML."
Adaptive Path, a consultancy that does Web design work for companies large and small, is the firm that coined the Ajax moniker.
As is true of Microsoft's smart client model, Ajax isn't a technology. Instead, Ajax is "really several technologies, each flourishing in its own right, coming together in powerful new ways," Adaptive Path says. Among the technologies included are:
standards-based presentation using XHTML and Cascading Style Sheets (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.
Adaptive Path points to Google Maps (the poster child for Ajax) and Google Suggest as examples of the kinds of applications that can and have been developed using Ajax principles and technologies. And Ajax isn't meant to replace Flash, as some industry watchers have speculated. Instead, Ajax can coexist with Flash, as the Flickr online-photo-sharing app from Ludicorp demonstrates.
"Ajax has platform independence," one of Adaptive's founders, Jeffrey Veen, told Microsoft Watch earlier this month. "It doesn't make sense to just develop for IE (Internet Explorer) any more. The Web is an open platform."
It seems like the Ajax camp is gaining some momentum as of late. Even some Microsoft folks are blogging about it.
But Microsoft has an awful lot of developer momentum. And it's planning to spend lots of evangelism dollars on extolling the virtues of its smart-client strategy in 2005 and beyond.
Is the Java vs. .Net battle giving way to an Ajax vs. smart client one? Will we see a dev world divided along Ajax/smart client lines? Or is there room for both programming platforms to coexist and (shudder) maybe even interoperate?
Send me your two cents. Talk back in the forum below, or write me at mswatch@ziffdavis.com and
let me know what you think.
|
Comments (9)
I've been developing "AJAX" applications for more than 5 years, and one of the first technical decisions that always gets made on these types of projects, is to stick with IE. IE has ActiveX support, includes MSXML, which includes XMLHTTP. Without those technologies, AJAX would not even come close to being able to offer the power that users require.
Smart Client applications are the future. Why waste time working under second class development conditions, like inside of browsers, when I can write real applications, which run on real machines, and do it much more quickly and cheaply.
Web applications have always been about deployment. If Microsoft keeps it's promise to fix the deployment story for smart forms, AJAX will be a distant bad memory for me and alot of other developers.
Posted by Chris Bilson | March 24, 2005 11:34 PM
People no longer want to be tied down to IE, especially after the way MS just pulled the plug on IE. I mean who would want to develop apps for an end of line product.
No doubt MS has announced IE 7.0, but thats more of a knee jerk response to Mozilla.
If i were to write a platform independant, browser hosted pseudo - rich client I would rather trust Mozilla (Check out www.faser.net/mab and http://mab.mozdev.org/) or wait for GBrowse.
Posted by Raghupathy Srinivasan | April 2, 2005 11:01 PM
The reality is that smart clients are no different from Ajax if MS truly wants to see this survive and get adopted.
The interesting piece is that it is not an either/or situation - smart clients will need to have common foundations, and perhaps the only way they will deviate is in the usage of Flash.
There's a company called Xamlon that integrates Ajax and Flash( you can also read the news article) at my blog http:// prodman.blogspot.com.
-Raj
Posted by Raj B | April 6, 2005 5:43 PM
I think there is definitely a place for the ajax model - especially where you're looking for "no touch" deployment of a web-centric application that needs the broadest compatibility (of operating systems, browsers, etc). I also think that the script-postback support in ASP.NET 2.0 (and backported to 1.x) is an acknowledgement by MSFT that web-apps are moving this way.
But - for corporate apps that do a lot of complex data-sorting, editing, and manipulation that is cpu-intensive, I think compiled, web-enabled fat "smart clients" (as opposed to stupid ones?) are going to continue to reign, especially where the IT dept knows (or can dictate) the user platform. Plus, I think the nature of compiled applications written in either .NET or Java lend themselves more to modular development by teams than the mix of script, xml, XHTML and CSS that the ajax model calls for.
So for us (and lots of companies) that have teams of developers working on a project that does a lot of CRUD (of info pulled from a web-service, in our case), and that is going to be deployed internally only, a relatively light-weight .NET windows-form application is the better choice. Good performance vs scripting, a great IDE (VS.NET 2k3) and relatively easy deployment (choice of XCopy, assemblies-on-network, or a simple MSI installation by VS.NET).
The more choices the better of course ;-)
Posted by Kirk Davis | April 7, 2005 8:56 AM
Wether you develop JAVA/.NET or make some scripts in ASP/PHP AJAX PRODUCTS promise to give you a way out of procedural programming to manage user interface/ interaction.
Its not the technology but the products that get out there to make it work.
JJG (Adaptive Path) states that the clientside engine takes care of the rendering (and believe me engines can do many more) and roundtrips the server for datarequests/ update.
So would it not be nice to everybody to get rid of managing (and sure its hacking) the GUI and browser (in)compatibilities.
At the end its about consistent user experience and developer productivity.
Backbase delivers AJAX based RIA products already for 2 years now and we never had anybody showing the product (both JAVA and MS community) who was not enthousiastic.
Sometimes things happen disrupting what we are doing now. Key is to change the current development paradigm.
Getting unlimited resource available (network, memory, processor) what will this mean for the client ?
http://www.backbase.com
Posted by Roy Wietmarschen | May 13, 2005 12:06 PM
Amusing to read these posts just 18 months on when Microsoft have just released RC1 of their ASP.NET AJAX product. And hats off to them for recognising that this is the way web apps are going.
For me, this makes ASP.NET finally a viable choice for web app development as previous versions only addressed the developer productivity whilst leaving the user experience severely lacking in most scenarios. Put up any ASP.NET app next to a hand coded one, using Ajax and "tricks" and, to a user (the important person!), the hand coded app was always much, much slicker.
It seems clear now that the fat client solution is only viable when the audience is a known quantity, such as an intranet environment or possibly a public web app with "System specs" attached. This goes for .NET or Java based solutions. Even Flash but to a slightly lesser extent. If you go that route then you'll just have to accept that some users won't be able to use your app, or will choose not to allow it to run / install the runtimes needed.
If you go that route then be prepared for when your boss, or the client, questions your decision on the technology. If your answer is merely, "But fat client is easier for me to program in" and the spec says "must reach as wide an audience as possible" then you may be in trouble. On the other hand, if you answer "But the application required high speed 3D graphics" then you are probably safe :)
The decision to use Ajax or a fat client is one we can make as software designers based on an informed decision, who our target audience is, application scope etc etc. One is not "better" than the other, only more applicable to certain scenarios.
However, if you decide that your fat client doesn't need high speed graphics or intensive computations, then, by using Ajax, you can leverage the Browser as a platform in it's own right, the Browser becomes the OS and Javascript becomes the language of choice. It doesn't matter if your user has Linux, Windows or Mac, they can still run your app, using nothing but default Internet security settings.
Since Javascript can be coaxed into acting very similarly to a classical inheritance language, such as C#, Java or C++ then large scale, well designed applications can be created, even by large (but well managed) teams. The current (and future) crops of Development tools, such as the Free Visual Web Developer and its integrated Javascript debugger can only help this situation.
Still not nearly as easy as Java or C# but a great leap forward all the same.
Lazy loading of Javascript classes can render any arguments about application size, framework size or download and installation virtually null as program components dynamically load as and when required (JIT on the wire). I only know of one Ajax framework that fully supports this currently but its a proven concept all the same.
However Javascript is hellishly slow to execute compared to Java and .NET code meaning that high speed graphics and intensive computation are complete no-no's. The "Canvas Tag" will not do much to help either. To give an idea, a "3D spinning cube" can be calculated and rendered in a 640 X 480 Java applet many, many 100s of times a second on any reasonable spec PC. A similar port to javascript (even using an applet for actually drawing) would be very lucky to achieve 30 frames per second. 2 cubes would be 15 and 3 would be 7 or 8 (based on my observations).
Also, client data storage in a Javascript client is extremely limited.
But that still leaves a great deal of scope for the Ajax application to work in.
Microsoft now seem to have covered all the bases, from traditional client apps, Smart/Fat clients and now ASP.NET with AJAX. Their AJAX library will now form part of the full .NET framework for Version 3, validating Ajax as a standard model to produce Web Applications. The next verion of Visual Studio will likely support Javacript Intellisense of the client Ajax library.
This kind of development will push Ajax more and more mainstream (if it isn't already) and will further marginalise the fat client back towards the Intranet arena. Microsoft have not only done a "U" turn on their fat client focus, but have also done a "U" turn on the purley postback architecture of their flagship web app framework. I'm stunned by this but am also delighted. Who would have thought this would be the case just 18 moths ago? Judging by the previous posts, virtually no-one!
Moving forward, with ever improving tools, lil' ol' Javascript may well pick up the mantle that Java set out to achieve, that of true platform independance and "write once run anywhere" for the developer. And since it's "runtime" is the common Web Browser(a concept of using the web which isn't going away any time soon) then there are no installation considerations or security restrictions to get bogged down with.
Put simply, Ajax gives the most, for the least.
Javascript eh? Who knew?
Posted by Kavin Robinson | December 15, 2006 8:35 PM
Well Said About the Smart Clients vs Ajax.
But could any one help me to study systematically
1) Smart Clients
2) Smart Client Software factory and CABs
By sending some tutorials or videos or labs . before learning Smart client Software factory I really need to have a strong base of Smart clients.
How to build a sample smart Client Applications using normal .NET . Thanks
Posted by positive | July 30, 2007 8:15 AM
Both (smart client and ajax) are irrelevant now with the introduction of WPF/Xaml/Silverlight. Who would've thought we would be saying that 2 years ago :-)
Posted by Bo | October 31, 2007 3:36 PM
Over the last several years, I've been fortunate enough to work on asp.net/ajax applications, as well as standard vb/c# windows applications. The thing that I've noticed, personally, is that the web is not a Rapid Development platform. Things that take only a few minutes in a windows application, can take hours and even days in a web application. There are a lot of technical details that can "hang" you up and kill your productivity while creating web apps. This is especially true when your application has a complex UI, with lots of controls. While I used to be a champion for web development, lately I've fallen in love with windows development all over again. While it's certainly fun and challenging to build solutions with asp.net and ajax, my windows applications simply crush anything I've built for the web. In addition, since I'm building applications strictly for use inside a company (and not public web sites), the browser/platform independence argument is moot. I also predict that the trends in virtualization will further dampen the benefits of a browser app. When my users can terminal in from practically anywhere and run my windows apps, then who needs a browser? Do you agree? Am I way off here?
Posted by bonetap | February 5, 2009 10:56 AM