Software Development optimize

Can presentation layer abstraction ever replace desktop and Web apps?

What it will take to get developers to stop trying to replicate desktop functionality in Web apps and start using presentation layer abstraction systems?

Persistent "Holy Grails" in the world of computing are the various methods of abstracting the presentation layer of applications. The current incarnation of this tendency has the HTTP network protocol as the common theme. Let's take a look at this history and see what the chances are that the current generation will have to replace current Web application and native application development.

When HTTP and HTML were developed, it was never envisioned that either would be used as a mechanism for providing application functionality. At best, it was acknowledged that someone might download a compiled application or some source code using the HTTP protocol that was linked to in an HTML document. A few years later, the CGI system showed that some read/write functionality was possible with HTML and HTTP, and the first generations of Web apps (rudimentary Web mail, forums, shopping carts, search engines, etc.) came about. For the most part, these Web apps were not created to replace desktop apps or even act as presentation abstraction -- they were about leveraging the connectivity that the Web had.

But in the mid 1990s, someone had the bright idea of writing small applications in the Java language and embedding these applets into Web pages. This gave Web developers the ability to put desktop-style functionality into Web pages. Microsoft quickly followed suit with its "me-too technology" of ActiveX. ActiveX was stillborn due to security issues (the only people who wrote ActiveX components and put them in Web pages were hackers looking to take over systems). Java applets gained a little bit of traction but not much. Applets primarily seem to crop up in intranets (so do ActiveX objects for that matter). Around the same time, Macromedia introduced Shockwave and Flash, but back then, people only used them to make goofy animations and cute little games.

Despite these various systems that were capable of providing desktop-style functionality, Web developers turned to using JavaScript to manipulate the HTML DOM to provide more interactive, traditional functionality. AJAX was being used as a technique long before it had a name, and it was so common that no one even called it anything special for a long time. It was assumed to be the best way of doing things, but until the rise of free AJAX frameworks, most programmers could not really make good use of it to do too much.

Microsoft and Macromedia (since bought by Adobe) are back in the game with Silverlight and AIR, respectively. What is interesting about both of these applications is that, while they can be embedded into Web pages, they look to break free of the applet paradigm. Instead, they are trying to be runtime environments of their own accord, replacing both desktop applications and Web applications. Both applications work to communicate directly with the application server and the local system at the same time and bypass the Web browser. "Applications" are delivered as documents to be loaded into the runtime, which is effectively the application at the OS level. Because the "application" is targeting this runtime, not an operating system, cross-platform issues such as widgets are not supposed to be a problem.

I actually believe these claims at a technical level (more or less), and yet they will most likely fail to gain significant market share despite the wide publicity. Why? Let's take the technical issues out of the way for a moment and pretend that Silverlight will be perfectly cross-platform capable (it's not, but it's a lot better than you would expect from Microsoft). Let's further extend this fantasy by imagining that it won't cost developers a cent to get the tools to develop for these platforms, and that they can be deployed with no software to be bought for the server (again, not happening; Adobe and Microsoft like to make money selling pickaxes and not by finding gold nuggets). Take this "just-so-story" back in time about 10 years, and you get... Java applications.

That's right, Java applications. Not applets to be run in the browser, but the plain old, desktop application running within the JVM and using Swing/AWT. When was the last time you saw one of these outside of the Oracle installer? It's been a while, hasn't it? It is not like they are hard to miss either, since they use non-standard GUI widgets; you would know it if you used one. Overall, except for a few select purposes (such as internally written and deployed applications and small utility applications), they don't really exist in the wild. Java applications have the technical ability to do what Silverlight and AIR claim to do and have mature, free development tools available (Eclipse, for example). And most of the cross platform, performance, and stability kinks have been worked out.

Nevertheless, Java applications are not a "has been" -- they are staunchly a "never was." If Java couldn't make it and still can't make it, I see little reason to think that either Silverlight or AIR will make it either. Unfortunately, the goal is a good one. Developers need to be able to deploy their applications to a variety of targets without a recompile. And Web applications will always be way too much effort to get to reliably handle common business problems like data concurrency unless HTTP suddenly becomes a stateful protocol that maintains a persistent connection when idle, and HTML suddenly morphs into a great UI specification language.

Since neither of those pre-conditions will occur in my lifetime, the only legitimate route is something like Java + Swing/AWT, Silverlight, or AIR. None of them seem to be big-time successes, so I am quite curious about what it will take to get developers to stop trying to replicate desktop functionality in Web apps and start using presentation layer abstraction systems instead.

J.Ja

Disclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine.

About

Justin James is the Lead Architect for Conigent.

17 comments
mschmitz
mschmitz

We develop business applications with a very long deployment life. So for us an abstraction layer both from the presentation technology (Desktop, Web, text, ...) as also from the OS. Actually the big ERP vendors showed, that this is possible. Products like SAP and BAAN showed, that with the right architecture you can develop a SW (actually in the 80'ies), make it run initially in ascii based interface, and migrate it with ease to windows and web based platforms. So if the holy grail is clear and if companies proofed, it can be done, where are the developer tools for small companies to repeat the miracle? In other words: Which abstraction layers do you know/recommend for Presentation, Database etc. Eager top hear your ideas, Markus

Justin James
Justin James

Markus - My apologoes for the late response. I really don't have a particular recommendation at the moment. A lot of it has to do with your needs and circumstances. If you are doing something where you can guarantee that everyone is using Windows, Silverlight looks decent at the moment, but I haven't worked it it personally. I think Flash is a surprisingly good choice, particularly with the platform independence, and the vector graphics take up little bandwidth to transmit. I think that HTML is not a good choice most of the time, mainly because of the HTTP protocol, but it is often the only choice. J.Ja

mschmitz
mschmitz

OK, now Java might have solved some of it's performance problems and is as slow/fast as silverlight. OK, also plenty of programmers know the language and the API. But why it failed is clear: A web app (rich or not) is supposed to be sexy. And you can do this perfectly with flash and silverlight, while any java app looks definitely 80'ies style. Just my two bits though! Markus

steven.randolph
steven.randolph

You say "Java + Swing/AWT, Silverlight, or AIR...none of them seem to be big-time successes..." But in the case of the latter two, it is much too soon to make a determination of success.

Justin James
Justin James

You are right that it is too soon to say for sure about Silverlight or AIR. But I hear a lot of people saying, "I'll give 'em a try when I get some time", which is a far cry from, "the boss is sending me to training next week on this, since we're starting a project with it in a month." So yeah, while the metric of "traction" is definitely different, I am still seeing little evidence of it. :( J.Ja

bnetguy
bnetguy

i can write a book about the subject, so i'll get to the point: the success and widespread of a platform (silverlight, flash etc...) is a direct result of a major success in terms of $$$. Web applications rose beacuse of individulas like Amazon.com who made ridiculous amount of money, thus, creating a massive wave of followers (followers that wanted to capitalize the same way). it is the same as Reality TV: it existed for ever as game shows and others but it took "Survivor" to create a mass widespread of the format. IN the END Technolgy becomes widespread if you have a croud of followers (follwing a massive success). SO, if i were Microsoft (or Adobe..) i would have to create a cross platform enterprise who created ridiculous amount of money (in a Dummy Sub Start-up)!!! you can't just wait for it to happen on it's own...

Justin James
Justin James

You make a great point there. No one is showing that these systems can be provably (or even aguably)better than Web apps, let alone show that there is a business model to follow or that money can be made. Until that happens, they will be perceived as a big risk. J.Ja

Tony Hopkinson
Tony Hopkinson

Presentation abstraction layering will never happen until developers take on the idea of it being a layer. To me one layer for presentation is exactly the wrong way to go to achieve the abstraction, especially if it's seriously entangled with a certain 'way' of doing things. It shouldn't matter to the functionality how it's presented is the real abstraction, not whether it gets hosted in IE, VMS or a 'nix shell. The best model is the basic one in linux, not because it's not windows, but because designing for command line and gui and maybe web based means you gain from separation of concerns. Turning a non-trivial app that was designed for only one sort of interface into another is fraught with difficulty. Indeed it's why a lot of past attempts have been so f'ing awful. As soon as you design an application from it's front end, you put all sorts of contraints on it, divorcing what it needs to do and what it needs to do it, from how you tell it to do those things is seriously difficult unless you make the choice right from the get go that you are going to tell it to do the 'same' things in several different ways.

Jaqui
Jaqui

Most applications on the linux platform are written for the command line interface. With the output for user interaction just being sent to stdout. This means that the application can easily be given a GUI front end any time, which is what created most GUI based applications for linux. OR, you can put it into the cgi area and use it as a web app with just a wrapper to add the headers and links needed. While the Common Gateway Interface is currently out of vogue for perceived security risks, it is still one of the better ways to gain a stateful connection within the http environment, without the additional security risks of active clientside scripting. Thinking about the idea of the blog entry, I will hazard a prediction, that we will see significant improvements in web app design for the thin client model that is behind the entry from the open source community long before we see such from any proprietary software house. It is an easier step from any of the open source operating systems with their excellent cli environments to move into the thin client distributed applications market than from the commercial / proprietary systems obese client environment. [ caveat: though getting the open source community to see the need is required before this will happen ]

Justin James
Justin James

The *Nix model does make sense, and it does lend itself well to modularization. The biggest problem is that historically, the decisions behind the format of that input/output have stunk. Someone will write "garbage app 0.01a" and release it as open source. ga0.01a will be filled with dumb quirks, since it was a personal use app that happened to be open sourced. Six seconds later, 5 other developers start building off of ga0.01a since it fills a need they have. Now, ga0.01a's I/O patterns just became the de facto standard for data interchange for that purpose. The author of ga0.01a is working on ga0.02f, and wants to fix the quirks, but they can't, because all of these other tools are depending on the quirks. So instead, the default behavior is still "quirk mode" with a command line flag for "new I/O", which no one uses since it is not the default and everything relies upon "quirk mode" anyways. By the time ga0.03j is being developed, Richard Stallman is releasing "gga" (GNU Garbage Application), djb has come out with french-kiss, which has all of ga's functionality, but works totally differently, but installs a link to itself in /usr/local/bin (ga's default install location) named "ga" which really calls "french-kiss" with a flag to turn on "ga compatability mode", and some kid has made $10 million selling a 2 month old startup to Google that does nothing more than run some standard database data through ga and then map the result with Google Maps on the IntarWeb. Meanwhile, ga's rediculous quirks will live on for another 30 years, despite having been corrected within 2 months by the application author.* Bleh. Yes, the *Nix modularization is good in a great many ways, but that good comes at a price, which is that the barrier to entry for really bad decisions is very, very low. J.Ja * See also: sendmail

Jaqui
Jaqui

said every app was useful, only that the developers for the open source operating systems have the mindset that will enable them to implement a good system, if they perceive the need. it's the anti-bloat stance most take that will help, rather than the bloated app stand of most proprietary development houses.

Tony Hopkinson
Tony Hopkinson

You have to think forward, that of course can be difficult. :p Locking yourself in a particular path too early is a mistake so common, I'm almost immune to it. The one that makes me howl still, is nix developers ongoing love affair with terseness. I know they were all two fingered typists, but please 26 one letter parameters only four of which any person new to the interface could guess at by context... Course you can always fall back on ? h -h --h --help ....... :p There again that's not the mechanism but the content, you can always configure it out by piping in your own command pre-processor.

Justin James
Justin James

Yup, too many developers are *still* not thinking in terms of layer separation. Heck, it doesn't even need to be three tiered (or N-tiered), just, "stop putting the text to output in the statement itself!" and "put the DB work in a separate library!" But too many people have too few reasons to do this, plus time constraints, plus the, "but the manager swore this would never need to change, so why should I separate it!" routine, so of course it never happens. J.Ja

smdelfin
smdelfin

Current version of Lotus Notes and Lotus Symphony are based on Java + Eclipse/SWT. Future version of the programmers' IDE for Notes (Domino Designer) will also be based on this. As corporate users upgrade to the new version of Notes, and as they deploy the Symphony office suite for basic users, Java + Eclipse/SWT will be used by millions of corporate users world-wide, even if they don't know it.

monsonhaefel
monsonhaefel

Hi, This is Richard Monson-Haefel of Curl Inc. We also offer a "presentation layer abstraction". In fact, Curl came out in 1998 so it predates Adobe flex and silverlight. We've been offering a platform that provides both RIA and desktop runtime since 2004. I think you missed a few things in your analysis. First, when Java applets came into vogue (I was there writing them) consistency among implementations of the JVM was horrible across browsers. This is why its failed. The same was true of DHTML which is today called Ajax. The pore portability story around Java was solved for the most part when Sun took charge and offered their own browser plug-ins, rather than trusting vendors to implement the JVM properly. Sadly (for Sun), however, Java already had a stink about that they just can't shake on the desktop. Java was/is also a bit of pig in terms of performance on the desktop - that too has stymied its growth as "presentation abstraction" The same cannot be said for Silverlight, Adobe Flex/AIR or Curl. These technology do not have a lingering stink about them - they are, from the perspective of developers, fresh. In addition, they also leverage existing developers skills in web presentation (Adobe) and .NET knowledge (Silverlight). Curl is the least familiar of the RIA platforms but its been in production use in Asia for five years, its much faster, and more secure. So Curl has its own strengths. Anyway, you need to look at the whole picture. The truth is that in the future desktop abstractions will prevail. Of course, since my company offers such a thing I'm biased, but I'm also right. All the best, Richard

Justin James
Justin James

Richard - Thanks for the response! Yes, I am passingly familiar with Curl, but I admit that I omitted mention of it from my post due to failure to remember about it. :( You are right about the JVM consistency issue, and the performance issues (I was there too, it was not so great). And yes, Sun didn't get the issues sorted out until Java's repuation had been battered pretty badly. But those issues have been straightened out for a number of years now, and Java enjoys a huge base of existing developers who know the language and APIs; they would just need to learn the appropriate presentation controls. But Java is still going nowhere as a presentation abstraction system. Now, that being said, I'd love to learn more about Curl and what you guys are doing, and maybe discuss it either here or in another space that I am writing for! J.Ja