Hey... Are you sure that these screenshots are a good idea? Now everybody knows, which files you're loading... And I can imagine some people not being too happy about 'em ;)

While I like web based applications they do not perform well enough for me to want to use them over a client side app. a great example of this is FeedDemon and NewsGator. I really like the NewsGator web interface (the new AJAX system currently in beta is excellent) however FeedDemon does more and is much faster so other than checking my rss feeds when i am away from my machine I never use the web interface.

It is a shame a lot of people dislike writing true Win32 applications. uTorrent is an excellent example of a well written Win32 application. It is solid as a rock, performs great and looks good. While the web interface also looks good it is no where near as nice as the real thing.

You beat me to it BlaM!

Although I was just going to mention Jeff's good taste in TV and poor taste in films!

The future is spelled XAML.

In a few years when the Net 3.0 installed percentage reaches critical mass, you will have browser based apps that have all of the UI features of desktop apps.

Funny, I wonder why they didn't use the same graphics for the buttons in the web version?

Funny that "the future" has been the same future since 1996, whether it will be flash, html, interactive pdf, depending on their bias. At least no one talks about vrml anymore, at least until someone finds a way to applify second life. (Oh god, did I just use 'applify'?)

Are there user-interface oriented AJAX toolkits? Ones that make alt-shortcuts, right clicking, and scroll wheels as easy to use as newer platform UI toolkits? Ones that keep you from having to reinvent the presentation layer every time?

flash is great, except that it follows the old adage, absolute power corrupts absolutely. The absense of firm UI standards makes most people think of it as more of a toy language.

Doug - It would be nice if that was the case. But as much as I love .NET a lot of people don't, and I don't think it will be adopted enough. Someone is likely to mimick it though, and then we'll see.

I'm wrestling with this issue at the moment. We very nearly plumped for a web app, but as our UI is what separates us from our competitors, client/server is still the only way forward.

Maybe we'll do it on the next iteration.

flash will succeed if it becomes as open as ecmascript, css, and html.

Are people stupid enough to give a company a monopoly like Microsoft had with windows? I certainly hope not.

I hope that xaml succeeds under one condition, that it does so without locking you into using windows. I really hope that people arent ignorant enough to continue locking themselves into a single vertical of software products.

Ahem,

thanks for giving the RIAA enough evidence to lock you up for good ;)

Funny random fact: did you know that µTorrent's UI was written in Visual Cobol? I shit you not, check the FAQ on the site.

Visual Cobol? WTF?!!

I'm pretty sure that for many applications, a JavaScript + declarative markup approach works. For what I'm currently working on, I use XULRunner, which is the platform the next generation of Firefox will be built on. Mostly it's very good - you can use FF2 and Firebug to debug, but not having the capability to get down into the bits on some of more complicated parts is a bit of a pain. The Mozilla JavaScript implementation is being rewritten to share the Flash 9 runtime's JIT engine, which should give a significant performance boost. Choosing between Flash and XUL is partly a matter of whether you want a DOM rather than a display list, and partly whether you want to distribute the runtime for a standalone product, which you can't do with Flash - though you probably will be able to with Adobe Apollo, which is there contender in the rich-non-internet-app-based-on-internet-languages space.

If you don't want to be locked into using Windows, currently use XUL rather than XAML.

Can't wait to here about the court case on your blog, but in the mean time the link at the bottom of the article appears to be broken.

I think it is sad that people are so slow adopting the mozilla technology, mostly due to the lack of a serious IDE and documentation I guess. But it is really nice to see that Joost like Songbird is using the technology of SVG, XUL, XForm etc. http://newteevee.com/2007/01/11/venice-project-mozilla/. Wish I had more time to mess with XUL, but the .Net development seems to take all my time, so I probably have to wait like the rest of the world for the Microsoft version of the technology.

Link works fine for me.

Have you tried Flex? It's an Adobe product, basically a library, compiler and IDE on top of Flash, that makes it an applcation developer tool. It's been quite impressive in my brief proofs of concept. Flex 2 really seems to have come into its own.

It has a GUI component model, it comes with a large number of components built-in, it has a "real" language (actionscript 3 is javascript but with a more robust object model added), and you can compile your Flex files to a .swf file with the free SDK (you don't need to buy the IDE if you're a language maven).

http://www.quietlyscheming.com/blog/ -- blog by a Flex developer
http://examples.adobe.com/flex2/inproduct/sdk/explorer/explorer.html -- Flex app that lets you explore the built-in Flex components
http://flexbox.mrinalwadhwa.com/ -- Flex app that lists all non-Adobe components floating around in the net
http://www.adobe.com/products/flex/ -- official site

web based user interfaces are, as their name implies, only user interfaces.

actually, it is possible to define a new language (or whatever else) that could standardize web-based UI accross web browsers: all that is needed is the effort to really standardize it and push for a wide-spread adoption. it seems nobody really wants to start such an effort these days.

but a web based UI can be compared to a remote desktop. we are observing the return of time-sharing mainframes and dumb terminals.
the only difference is that the dumb terminal is less and less dumb.

Remote Desktops are alive and well. I use them everyday.

I use two computers at work. I sit in front of a Windows machine, and I use VNC to connect to a Linux machine. It's a sweet setup, since I can use Windows when I want and use Linux when I want. Cut and paste is a little unreliable, but that's life -- it would be worse with a KVM switch.

I have to admit that it's been a decade or so that I've used remote X Windows -- there's just never any reason. On UNIX you've got a choice between (1) command-line apps that "just work" and let you get the job done and (2) GUI apps that almost work and mostly waste your time. If I need to do something remotely, I could finish the job with a type 1 app in the time it would take to get the remote desktop connection working right.

"Thin clients" for protocols like X and RDP have always been a nonstarter. The problem you've got is that a "thin client" has to be cheap, otherwise people aren't going to buy it. Even if a weirdo machine has a price point a little more than a PC, it will probably have 1/4 the RAM and 1/10 the CPU power because the components aren't produced in the volume PC components are. In 1999 I had a 'thin client' on my desk; the damn thing had barely enough RAM for a video buffer and it was painful to use.

"None of this bodes well for Microsoft and the profits it enjoyed thanks to its API power. The new API is HTML, and the new winners in the application development marketplace will be the people who can make HTML sing."

I think Joel is forgetting that a great way to make html "sing" is to use ASP.NET, which is still MS. I think they'll be fine. ;)

Our call tracking software is completely web based, and works quite well. Granted the UI sucks, but that's the designer's fault... not the technology's. Almost everything I write at work is also web based, it's just so much easier to distribute everything when all I have to do is send a url to anyone who needs it.

Like someone else mentioned though, I definately wouldn't want to use a web interface for "real programs" like Visual Studio or even Word. They are fine for some things, but the load times between screens and losing certain keyboard commands would drive me nuts!

I hope XUL becomes popular, it's the thing that web UI's need.

If you don't believe me check this out (must use a browser that can handle XUL):
http://faser.net/mab/chrome/content/mab.xul

ICR - Every computer with Vista also has Net 3.0.

Look at the lag time between when MS invented the XML request technology behind AJAX. It wasn't called AJAX then but later became the hot thing. I have wondered why ASP.NET wasn't built to take advantage of these features from the beginning.

Sooner or later most people will have Net 3.0. (Unless Apple makes a miraculous comeback.)

Who says the screenshots are from his machine? Could be grabbed off the web and ... hey, that's a copyright violation, too! Someone call the police!!! ;)

As I look at the two example screenshots of torrent, I wonder what would be so hard about adding a few of the missing nuggets to the web interface? I may be ignorant here since I don't really use torrent that much, but it seems like the web app took a few short cuts. With a little work, it could be close to 95% there. What's missing? The main things that jump out are a few tiny icons on the left next and some ajax functionality to display the percent downloaded. Granted we can't see everything from the screen shot since some of the interface is missing and I do see some of the icons are missing at the top. I think a major part of the issue is the web apps are not polished since they are so easy to code.

I just wanted to echo the comments of the poster who points out that selling your soul to Adobe is no better than selling your soul to Microsoft. AJAX may be a hack (and maybe not), but is LAMP any better? Isn't the core concept behind Linux/Unix/Pic-a-nix (sorry) that small modular tools be combined to produce larger tools, often in an adhoc manner? AJAX is a very good example of the MVC pattern of application design, and Flash somewhat less slow (in addition to being an egregious CPU hog).

Meanwhile, Bruce Eckel can kiss my pale white behind.

"The second problem is that you are relying on Ajax libraries to handle cross-browser issues. If you want to write your own code, you must become an expert on those issues, and at that point much of the leverage of Ajax goes away."

That's as idiotic a statement as ever I've seen (lately), because it's *not* *really* *that* *hard*. If you think it is, you're, well, slow. The libraries keep you from having to write it yourself, true enough, but there's nothing wrong with that. Isn't that what the STL does for C++? Doesn't Java supply 42,398 mostly-unneeded classes to keep you from "writing your own code?"

On the other hand, what's wrong about becoming an expert on something? What's wrong with continuing to learn, so that newly-acquired skills can be applied to current issues in other areas?

Ack. That's "...and Flash somewhat less SO...."

I shouldn't try to write so much pre-caffeine.

Of course, Flash CAN be slow. Maybe my fingers are smarter than my head right now.

"I suspect we’ve already seen most of the tricks that Ajax is going to offer."

That quote from the article reminds me of another quote:

"Everything that can be invented has been invented."
Charles H. Duell, Commissioner, U.S. patent office, 1899

Let's face it the future is........

OK, we don't really know what the future is. As somebody wrote previously, the future has been a lot of things when it comes to "multi-platform, easy to write and maintain, highly performant and responsive, simple to deploy UI layers". Flash? Maybe. AJAX (in all it's variety)...the current leader in club house. XUL/XAML/XSWT/Xwhatever...perhaps. Flex....it goes on and on.

The point that you made Jeff was dead on: the path of least resistance is usually the one that wins. Today, that's IE based web applications. Sure people don't like evil old Microsoft. But most corporations are predominantly MS based in the workstation environment. And there is still a ton, ton, ton of Windows out in the wild last I checked. Sure, alot of people have switched to Firefox in the wild. And that's why AJAXish (I prefer the term "chubby clients") are succeeding. They are easy to deploy, typically pretty performant and responsive, multiplatform and with some of the new libraries, they are getting easier to develop. And they are about 85% as good as their equivalent heavy client twins.

And to a lot of people, that is good enough. To us nerdy types, we marvel in our ingenuity in how we created a chubby client out of HTML, CSS and some Javascript...aren't we awesome? To most users, they are not really impressed, but rather they're just glad they can get their job done. But to some people, more than we'd care to admit exist, they focus on the 15% that we didn't get right. We constantly hear "How come the menus aren't quite like Excel's?" or "in Application XYZ we did it this way...". And where I'm coming from is some of the most sophisticated and hard core (IMHO) DHTML clients ever produced.

Traditional wisdom has been that writing true heavy clients is hard. MFC is tough. .Net Winforms etc.. is easier but it's Microsoft. Cocoa is Mac only. Swing is lame, SWT is hard... But if you are truly interested in the absolute best experience for your user, this is the only way to go. You want to get nearly as good? Chubby clients will get you there, but somewhere you'll make a concession. It's inevitable and that might not be bad, because perhaps 85% is truly good enough (and you don't possess the skills or desire to create something in another technology)

What is the future? I predict in 2 years we'll be having this same debate. In 5 years, it will be the same, but some of the acronyms will be different. And so on. We'll never escape it, because what solves the problem today is always less cool than some up and coming technology...and rare is the company or the individual that says "let's wait a while to address that market need, so we can use that really cool new technology"....

Hmmm. Well, while I can appreciate why it seems like native Win32 apps are dead, they're simply *not*, and the death of the desktop-hosted binary exe isn't going to happen anytime soon either. While us developers are mostly using always-on broadband, each with our own super-fast machine and large clear display, that's not true of the rest of the world by a long shot. I'm not just talking about the difference between US/Europe and some of the developing countries - I'm talking about it not being true even here in the UK.

Many of my own clients (vertical-market application software) have small, standalone systems or half-dozen peer-to-peer networks on which they share client-server applications. There is no need, nor any desire on their part, to go to any kind of web-based paradigm. It doesn't matter what you can do with AJAX, or Google office, or Flash; these technologies are not solving any problems that these people currently have and they don't really offer up any exciting new business advantages that these people would make use of. When they need a new feature for their systems, they pay to have it added to their existing system - they're not going to go to the expense (time/cost/training etc) of having the app replaced with some clever Web 2.0 system just because that's what most software developers are into doing these days. In many ways they would lose, or compromise, some aspects of functionality in order to become 'web-enabled'. So why do it?

It's easy for people in IT to look around at 'our' environment and project it onto the rest of the world (in fact, it's often the case that it's the result of our wishful thinking as opposed to any hard and fast reality). We always get the fast machines, the latest OSes, the most modern peripherals and we often lose sight of what everyone is making do with. The truth is, the real world I see when I'm out and about during the day includes large companies who actively want a locked-down internal desktop app rather than something that they have to police. It includes smaller companies who are either have no use for remote working, or are fearful/mistrustful of being online all the time, or who are simply looking for a bit of extra functionality in the apps they already have. And it includes companies who work with machinery in such a way that their desktop applications control external devices in their workplace.

I still see, on a regular basis, 20+ year old dBase MSDOS installations. 15 year old Paradox applications, decade-old Access systems. Even given that these are often a pain to support in their own way, most of the time the people that are using these systems are reluctant to change and see no compelling reason to do so. There's a whole world out there where you probably only get the chance to rewrite/restructure things about once a decade.

While I'm not trying to suggest, Canute-like, that we can resist the relentless progress towards an all-online world, it's not happening *everywhere* by any means, and in my experience we're still a long way from consigning desktop applications (and desktop software development) to the history books.

It all makes for great blogs posts though, Jeff!

In a distant future, we will have a real standard for Web-based Applications (without borrowing HTML), and all the developers will live happily in a chocolate factory.

But if you happen to work now, we have XUL, XAML, XForm, Flex, OpenLaszlo, Html5, and God knows what else... lots of different markups/technologies all based on "slightly different" schemas (mmmh, yes, everybody had a "Panel" and a "Canvas", so I will just add a "HPanel" and "VPanel" to MY language, to make it better) and "little" parser-specific problems:
- for XUL you must install Firefox and pray
- for Html5 you have to install Opera9
- with Flash you can kiss right-click goodbye
- with XForm you... you... you... ok, XForm is not really option :-)

I see dark times...

What about Java web start?

http://en.wikipedia.org/wiki/Java_Web_Start

Able to launch a client UI through a web based interface on any platform.

People always mention Java Web Start, and, in theory, it should be a better experience than DHTML UIs. Nevertheless, in reality, web designers do a better job than Sun engineers at making a polished interface.

Have to agree with much of what Joel said. Great desktop apps are what web apps try to be. Due to statelessness, HTML, js, etc., lots of almost hacks have to be used. The collective framework requires these to make things work.

But the glory and the money are in the web.

Will we indeed still be having the same conversation in 5 years? I hope not. Why is the desktop experience so much better now, and will the gap narrow in the coming years? A few ideas:

- Responsiveness: going to the network for many operations is inherently so much slower than executing local instructions. Bandwidth isn't likely to solve the problem, just alleviate it up to a point.

- Awareness of local environment: being able to open, save, cut, paste, etc. as usual; not having to "log in" to every separate app, etc. These things seem to be fairly well handled by existing Java, XUL, XAML approaches; what is needed is a standard that works everywhere.

- Native look and feel: most people are using Windows now, but there's no question that Linux and even Mac OS X are on the rise. Even just assuming most apps will be built with a Windows look-and-feel only, what will give us this? Again, Java (SWT), XUL, XAML--they're working today, for the most part, but again, no standard.

- Error handling: probably needs to improve a lot for AJAX calls to be as good as a desktop app. Not sure about prospects for this.

The biggest issue by far, I think, is responsiveness. One of the big reasons people build web-based apps is to cut down or eliminate software distribution and installation problems. To really improve responsiveness, there will need to be better ways to download and run more of the app locally, updating various pieces only when needed, in order to make fewer requests across the network.

This thing about most people using just a small precentage of a big app does not really help you very much, since they always seem to use a different small percentage. When building lightweight web-apps to replace heavyweight thick clients, no matter what obscure feature you remove, someone are going to miss it. (This of course applies to non-web-apps too.)

And Foxyshadis, the guys over at IBM are talking quite a lot about Web 3.0 these days, which is supposed to be some kind of 3D/VR-web. Which, if you ask me, sounds pretty evil. Reminds of the home computers they sold in the end of the nineties, where an icon on the desktop would spin around a few times before the folder opened. All bells and whistles getting in the users way. So it seems we're not quite rid of VRML-ish stuff yet.

I'm gonna bet that one big part will move to XAML and XBAP apps for the web.

I just can't wait the time to leave the CSS, javascript, HTML world. It's amazing that in 2007 you can have the same markup, but different outputs in FF and IE (even both in Windows).

Yes there's a better way, it is called "Smart Clients", with all the benefits of Web apps and none of their inherent faults. You can build a smart client app in way less than the time required for a Web app, so it should be cheaper given the same scenario for both.

I am an AJAX developer and a .Net Win32 developer. AJAX is a hack, difficult to work with, and doesn't give enough control over the client system. I liked the way UNIX/X11 would allow you to remotely execute an application and display the UI locally. That rocked. One day Microsoft will probably implement such technology. Java web start looks promising as well.

here's another argument .. even if I use 90% of the features of Excel 1% of time, I feel snug knowing that the rest is there when I need it. Akin to getting a 500HP car. You get the idea.

And pretty glad that Bill Gates et al , did not believe too much in the "path of least resistence" argument , otherwise we all would be happily chugging along logging into our *nix terminals. The point being , that many great innovations in computing have come about because somebody refused to take the "least resistence" path , built it and then they all came. 2 cents.

Doesn't anyone see the problem that internet transfer speeds will NEVER be the same as system bus speeds... and thus, as fancy and 'interactive' as web apps get, they won't be able to be as responsive as desktop apps. People will always have to wait: for the site to load, for the next 'page' (or in-page widget) to load etc.

I personally hate waiting... that's why I spent thousands of dollars on a high end system. Otherwise a P2 would be enough. In software 'good enough' is usually never good enough.

Let's not forget the cross-platform issue as well. I just got done going 1.0 with a .NET WinForms app for a trading card game. The end user feedback has been good, but of course I get a lot of "Where's the MAC version?" for this? I initially looked into updating the code to make it Mono compatible to target the Mac/*NIX users. But when given the choice, most of them said make it a web based app.

So that's the route I'm taking. Sure this is no Visual Studio type app, and I'm sure that there will always be a group of apps that need to remain desktop based, but with the power our machines have nowadays and the minimal processing actually needed, the convenience of web based apps becomes apparent.

Steve: The whole point of AJAX is to move more of the processing to the client side. Theoretically you could have the whole application load over the web, then through client side scripting it would run just as fast as a native app.

Of course, loading it over the web would be slower...

Some things you can't do through the web UI, and their lack can be very conspicuous if you're used to them.

A MAJOR one is that you can't drag and drop files into your "application form" (to upload them, for example).

Another one is that you can't load local icons from your desktop. Sure, the server can guess at your icons based on your operating system, but that's about it.

You can overcome these with Java, but that's a little not in line with AJAX, is it?

ON A RELATED NOTE, I WOULD ACTUALLY LIKE TO ASK THIS QUESTION:

We have, on the one hand, a standardized virtual machine platform such as .NET CLR or the Java VM. It has lots of classes already that you can work with, and it's JIT-compiled to native code. Seems like a good solution for platform-independent applications! One thing that's missing perhaps is wide deployment and a standardized front-end. If you want a less full-featured version of this, you can use Flash, which is VERY widely deployed.

On the other hand, we have HTML, Javascript, and a bunch of stuff to create and manipulate WEB DOCUMENTS. We are trying to make DOCUMENTS behave like APPLICATIONS! It's kind of pathetic compared to everything you can do with the Mac OS or Windows or Linux. I mean, these OSes have had their APIs mature and become powerful tools for using the GUI and file system, and so forth. The base platform for your apps written in .NET or Java is a VM with JIT, which has a consistent spec across platforms. The base platform for modern WEB APPS is javascript running inside a DOCUMENT RENDERING ENGINE, i.e. a BROWSER... and these days, with the web being what it is, WHAT IS THE SENSE IN HAVING DIFFERENT BROWSERS AT ALL, IF THEY ARE ALL SUPPOSED TO DO THE SAME THING AND FOLLOW W3C SPECS?

I mean, isn't it kind of silly that instead of having a base VM and a standard graphical subsystem, we have javascript which is interpreted slightly differently by each browser, and a document model that is interpreted slightly differently by each model, and our interfaces are literally documents hacked to be front ends to applications?

But imagine if web apps were written in MONO and ran on your system, instead of in your browser. If the internet was designed now instead of in the 1990s, I believe there would be documents on the one hand, and applications on the other. And applications would run in a standard VM with a standard GUI, have GUI standards, and not all look different on different browsers.

THOUGHTS?

I've thought about this for quite a while, you see.

Telos: I've only done limited development for the web, so I only know the theory behind how AJAX is supposed to work... but how would that be any different from a thin client, except that it's loaded in a browser? And if that's the case, then why bother with all of the cross-platform issues, and just make a thin client that has tried-tested-and true UI controls from the OS?

Isn't it about time Web 3.0 replaced browsers with consistent renderers? But how to deploy to all the desktops? Ah, that's flash, and perhaps java.

So flash sounds like the future. Maybe I'll be investing in adobe :)

Most of the technology for pretty good desktop/web clients is now ready, if a bit fragmented in the various offerings (XUL, XAML/WPFE, Flash/Flex/OpenLazlo, Java WebStart, etc.). What's needed are some kind of common, simple industry standards, a la Web Standards (HTML, CSS, ECMAScript).

I don't expect people who have a lot of .NET code will want to re-code in Java, nor vice-versa. But without some emerging standards, developers and users will be subject to endless struggle and flailing while the "war" is fought. To get standards going, I think participation would be needed all the major players: W3C, the Web Standards movement folks (Zeldman et. al.), Microsoft, Sun, Adobe, Apple, GNOME, KDE. (Ha! I just realized what a ridiculous Holy-Grail pipe dream that last sentence was.)

> We are trying to make DOCUMENTS behave like APPLICATIONS!

This comment from GregMagarshak sums up in a few words the nebulous discomfort and vague dread that I experience whenever I work on a web app.

I always get one of two feelings.

Either I'm rigging things together with bailing wire and twine...

Or I'm trying to get a square peg through a round hole, without changing the it to the point where it disappoints all the people on the other side of that hole that are expecting a square peg with clean, sharp edges.

To put it bluntly, applications are square pegs. Web browsers are round holes. Something _has_ to give.

WPF/XAML will end up being the replacement for flash and html. The fact that it will be easily remotable is also a big plus so you can have your cake and eat it to. Instead of sending raw screen data across the wire you will be receiving XAML commands and having them rendered locally. And Microsoft already has WPF/E which runs on Windows and OSX. In about two years we will hit the infamous "SP2" stage for WPF and it will be a viable technology for both web and desktop apps. And why shouldn't it be? Why have desktop apps taken so long to catch up with what the web can do as far as content and layout are concerned?

I'm a Microsoft fanboy and this is how I see the future through my rose colored glasses.

Steve: Sure you could use a thin client, however what do we do? Have everyone create their own thin client to host their server based app, then have each user download it? It kind of defeats the biggest benefit of a web based app then, which is that all upgrades/deployment can stay on the server and all users get it instantaneously next time they use the application.

Besides which, essentially what we are doing now is using the web browser as the thin client. It may not be ideal from our perspective, but _everyone_ has IE on their machine. (Everyone who counts, sorry Mac/Linux people. :P )

I guess it goes back to least resistance again. Maybe someone will develop a standard thin client someday, and everyone will use it. Until then IE serves that purpose well enough.

Don't forget that Steve Yegge has (in my opinion) stated that Adobe's Flex/Apollo framework will take over. See:
http://steve-yegge.blogspot.com/2007/02/next-big-language.html

I like Microsoft's WPF/E, but the fact of the matter is, WPF/E has 0% market penetration and Adobe's Flash has, what, 97%? More?

I love that the screenshot includes a download of 'The Chronicles of Riddick'. (Decent flick).

:-)

The better way is stop using HTTP to build applications with. HTTP was never intended as an application protocol, its a document protocol. I beleive others have pointed this out. Web *Browser*. Browse for documents, information. Browsers not applications, merely render content.

But when web exploded people wanted to do more, so addons were added to browsers, server side scripts, and client side script or a mix of both: Netscape Javascript, Micrsoft ASP, ASP.NET, AJAX, etc.

All previous and new solutions WORK AROUND this problem. ASP, AJAX, Javascipt, etc. are bandaids to this issue.

Now its a big pile of dodo rolling down a hill. Can't stop it, just jump in and go with the flow and do your best.

I agree with Jon Raynor. Why is there a push to build desktop apps in a web browser? If you want a fat app, build a fat app. Too much web "functionality" relies on hacks, workarounds, and flat out sloppy software design in order to emulate a desktop environment.

I've always preferred a mix of flash and php over javascript, but there are times when people try to get too much from flash. Theres this annoying School Yearbook software run by johstons which is an interesting exploit of Flash, but is poorly designed. There would have been much better ways of making it on the web. There have also (oddly enough) been offline typing applications made in flash...which fail miserably and are annoying. Flash has many applications, and when properly used, it can be pushed hard, but when you start doing something complex as online programs that imitate offline ones - your better off with CGI, PHP or Javascript.

HI;

I'm an idiot; where can I see where XAML differs (abstractly and concretely) from being an XML-markup of an XServer C/S stream?

(Help) Teach me Obi-wan, you're my only hope... I want to be on this bandwagon before the crowd discovers how cool the coffee is over there.

Jeff,
The µTorrent browser-based UI provides you with the ability to remotely administer your torrent system. You are willing to give up the rich UI for the benefit of remote administration (thus not needing to remote-desktop into the client).

What if in addition to providing a web UI, µTorrent allowed you to administer any µTorrent system from the rich UI? Would you still use the web UI?

One barrier to rich clients that browser based clients don't have is installation. Imagine upgrading a critical client/server corporate application with rich clients installed with a setup.exe. Imagine trying to ensure that all 2,000 workstations are simultaneously upgraded. That is enough to give any IT admin nightmares.

Technologies like Java Web Start and Click Once are endeavoring to eliminate the installation issue. Once the corporate application server was upgraded, the users would download an upgraded rich client the next time they start the application. When these deployment technologies are mature, you the user will likely be oblivious to the download, just as they are oblivious to the download all the html, css, and js files that make up a web application.

Take a look an any of the XAML based XBAP applications. Surprise! XBAP applications are deployed via Click Once.

Many of the "applications" we use today are really services. Email is a service. Chat is a service. iTunes is a service. The service just happens to be hosted on my computer, which means I get the pleasure of maintaining it, backing up files and what-not.

Let's see, what else do I have open? SQL client. Service. Command shell. Service. Windows Explorer, but only so I can use TortoiseSVN, which is a service.

I have Google Calendar open. The UI sucks, but I value being able to access it anywhere over being able to view and make changes easily.

And I'm listening to Pandora. And replying to your blog, through a web browser. I got to your blog via Google Reader. All services.

BitTorrent, of course, is a service. I've never used it, but I don't know why it has to have a fancy GUI. Other than detailed monitoring (because you're a geek), it's just search and download right? Just like the web.

On the other hand, my IDE is a desktop app, and should be. And of course you can't have a web based web browser. Desktop apps will never go away completely, and that's okay with me. But the ones that are nothing more than specialized clients are starting to disappear from my hard drive.

Hi Jeff, thanks for the write-up!

One of my goals with InstaCalc was to make numbers much easier to use and share (no login or attachment headaches), and I'm glad that point came through.

It's going to be SVG + Javascript - you get a full graphical interface, plus JavaScript manipulation of the image, just like you currently do DHTML. And it's going to suck at first, like these things do, but it's equally the right answer.

I love reading about the future of web development. And I'm still waiting for my flying car...

GregMagarshak, WaterBreath, Jon Raynor and everyone who get's their point of view: right on! I have spent the last 5 or so years trying to get anyone who will listen to understand the difference between a web "application" and a desktop app. The browser, while being a wonderfully cool idea, is not an application container. It works for trivial types of interaction (even large scaled ones like Amazon or Netflix) but it becomes a smoldering mountain of hacks when you begin to add in the basic things that a desktop app has. Local file system access? Not going to happen. Stateful operations? Loosen up your fingers for some serious hacking. All of the things that you need and take for granted in a "real" desktop app become harder and harder. But the web app dominates because that's where everybody is and there are a lot of very clever people willing to develop in this environment, having cut their teeth on the old school web applications (like classic ASP). I'm just ranting now, but I'm glad this spurred on a good discussion. Three cheers for Atwood!

I've sent the links of these screenshots to MPAA. Their lawyers will take care of you.

I don't know why the trouble.

I use only HTML and NO JavaScript. Works just fine for me. My apps work on all browsers and I don't have the need to fiddle with JavaScript discrepancies amongst browsers. Much easier. My apps are everywhere.

Rome rocks! ;)

There's no reason any of uTorrent's displays couldn't be done on the web today without plugins, even in IE. They just happened to not get around to implementing them.

IMO, Web Interfaces are not "good enough" because you have to know what you're doing when you implement one. They'll become good enough. Ref. Shirky's Permanet vs Nearlynet.

That article by Joel Spolsky is just about the most intelligent thing I've read in a long time.

Disagree that X11 remoting has never really caught on... in environments where Linux/Unix workstations are widely used, it's an invaluable feature. I frequently use it to access applications on my personal desktop machine from whatever computer happens to be handy...

I'm agreeing with Karl G here, especially since it is most likely a rich client (non web) creating the backing data for the app. Theres sort of no reason other than the amount of time and need to implement the display of the missing information on the web. Now if we are talking about creating an entirely web based torrent application that just runs on a web server then that might be a different story but I am not an expert on torrent protocol or network programming but if there is a PHP library that could initiate a transfer with the tracker and then recieve an address it could bind to and pull data from theres sort of no reason that couldn't be implemented either.

Applications vs User Interfaces:

Many people here are confusing UI with Applications. UI is only part of an application, not the entire application. Even the author seems to blur this definition a little too much IMHO. My guess is that, from a functionality perspective, the two applications are very similar. The fact that the web application is accessible remotely gives it an edge if you ask me.

Some might say that standalone applications have the advantages of working offline and access to stateful storage. These issues are being addressed by libraries (DOJO) and browser technology improvements. I suspect that if there is a will, there is a way. These issues will eventually be resolved, like many others.

Flash vs Javascript:

Flash has been around for quite some time. Yet in this time, another language/platform has come out on top as THE language for this generation of web based applications. Why is that? Flash is certainly capable of producing amazing *applications* (UI and functionality). So, why hasn't it gone 'mainstream'... Why hasn't Google made a flash version of Google Maps? There are applications around, but why aren't the big boys using it?

Some people might say, accessibility is the stumbling block. Frankly, I think it just comes down to a matter of money and ease of development. I can develop in Javascript, free of charge. I don't have to purchase a copy of Flash from Adobe to create applications. Some one is going to yell, what about "MTASC" or OSFlash related technologies? Fair enough, but why bother when I and everybody else already have a browser+texteditor capable of producing applications RIGHT NOW.

Flash certainly has its advantages, particularly in the graphics department. But these advantages will diminish as new open technologies become more readily available (SVG and Canvas for instance) Also, Flash doesn't have to worry about the underlying browser as much. This is still the case, even with the latest fancy framework or library... Things have become much better than they were, and that alone has been major contributing factor behind web 2.0. As libraries and frameworks have matured, hopefully browser vendors will start to adopt standards better *cough* Microsoft *cough*... That could be a big ask though, it might not be in their best interest after all...

I think if any flash developer has doubts about the capabilities of a complete javascript framework, including IDE and decent component library, check out Tibco General Interface. It is truely amazing. For Java programmers, check out GWT...

Authors Comments:

"As useful and as clever as µTorrent's web UI is, I'm still deeply disappointed. I'm disappointed that, with all the technology at our disposal, we can't come up with some way to deliver a full-fidelity user interface over the wire for an application as nifty as µTorrent."

You are making the assumption that the interface will not improve over time. You are also making an assumption that the platform upon which the web client exists will also not improve. These things will come, and soon, it will be impossible to tell the difference between the two. In fact, there will probably only be the one web application.

As a side point, I would have to say that the interface in mutorrent is pretty horrible. A better example of good user interface design for a torrent program might be found in say Transmission for OSX. Perhaps this is just something to do with Windows application UI's, they always seem so complicated to me... But, lets not go there.

http://transmission.m0k.org/screenshots.php

> Flash has been around for quite some time. Yet in this time, another language/platform has come out on top as THE language for this generation of web based applications.

Agree. Kind of odd that Flash has been around so long, and yet uptake for developing full blown applications in the browser is pretty dismal. It's sort of like Linux and Desktop UI: if it hasn't happened by now, will it ever?

Actually, though Flash has been around for a long time, it hasn't been suitable for more advanced web applications until fairly recently due to the lack of a powerful scripting language. ActionScript 2 essentially made Flash based web apps possible. ActionScript 3 (Flex 2, Flash CS3), an implementation of the latest ECMA spec, will go a long way in extending these capabilities.

Jeff Atwood: "The web browser is the giant black hole of the computing universe, and like it or not, your application is caught in its immense gravitational pull along with the rest of us."

Zawinski's Law of Software Envelopment: "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

It is my pleasure to propose the following:

Atwood's Law of Platform Contraction: "All end-user applications which do not support the function of a web browser will eventually incorporate a browser-based interface. Those that do not which do not are replaced by those that do."

"I suspect we’ve already seen most of the tricks that Ajax is going to offer."

Lol, not if I have anything to do with it. Some of the projects I've helped put together to force contemporary web browsers forward, teaching them new tricks:

Dojo Offline (creating with SitePen): True offline access for web applications

Dojo Storage: Store hundreds or megabytes of client-side data for persistent access -- works across 97% of the existing installed base -- Safari, IE 6+, Firefox 1.5+

Really Simple History: First available open source library that solved bookmarking and back button issues in Ajax applications

HyperScope (with Eugene Kim and Douglas Engelbart): Layers supercharged hypertext on top of existing web without needing new plugins

Of course I'd love to blow up the browser and try something new (see Paper Airplane for a thought experiment I did a few years ago on this matter: http://codinginparadise.org/paperairplane ). In fact, I think that is a valid thing to try, but I think existing approaches are trying to solve yesterdays problems -- they aren't the ten times better or ten times cheaper that is required of new solutions to displace deeply entrenched ones. The best way to displace an entrenched solution is to actually move to new ground.... that new ground then turns out to be bigger than the original market, 'enveloping' it (see: the Personal Computer versus Mainframes/Minis, the Web versus proprietary online services, etc.)

Best,
Brad Neuberg

Yeah guys very good points.

Question: can someone explain why we need different browsers competing against each other, if the W3C RECOMMENDATIONS seem to pretty much dictate everything that happens. All this competition, and for what? Power for the browser makers, I guess.

And so my fellow Coding Horridians, ask not what your desktop can do on the internet — ask what the internet can do on your desktop!

Stop reinventing the desktop using Ajax. There is a usability revolution out there, waiting for you to grab and make yours. You have to look beyond the metaphors of the desktop and see what is truly possible.

Stop thinking outlook and start thinking gmail.

A desktop app on the web will always pale in comparison to the same app on the desktop. Don't make the desktop app on the web. Don't set yourself up for failure.

Greg: "can someone explain why we need different browsers competing against each other"

Because IE sucks, basically. If IE were any good whatsoever, rather than a giant crappy security breach waiting to happen, I doubt anyone would bother with Firefox or Opera.

Though I still like Opera's interface a lot better than the others.

The CRM application I use has been doing AJAX like stuff since it was released serveral years ago. However, due to the amount of data that needs to be pushed in the application, they have determinited that HTML (web) is not the best option for them going forward. They are totally rewriting their application using .NET 3.0 and Smart Forms.

https://www.youos.com/ click on the Try A Demo link to give it a spin.

Amazing what you can do in just JavaScript...

The World's Most Misunderstood Programming Language http://www.crockford.com/javascript/javascript.html

Worse is better.

The thing I struggle with when it come to more desktop-like web user experiences is how to serve all the masses. If you pin your hopes on Javascript, you alienate at least 10% of the browser market based on the W3C estimates on the number of people who turn it off. Then there's the browser compatibility and accessibility issues to deal with.

Flash, as several people have pointed out, is a good cross-browser environment, but it can be slow and you sell your soul to Adobe. <a href="http://disney.com">Disney</a> recently went almost all-Flash and their implementation looks really slick, unless you don't speak English or if you are accessing it over a handheld device.

And that's the other thing to consider. Depending upon where your market is, handheld can be huge. In places like Korea, there are more handheld users than wired users, so how do you have a great user experience for both browser and handheld without alienating either one or having to build your stuff twice?

Maybe you can't have it all. Gmail went the route of going huge on AJAX for the browser experience and built a completely separate client for handheld. The didn't tackle the acessibility issues, but maybe they are leading the way with this too.

---Pete
<a href="http://nerdguru.net">http://nerdguru.net</a>

I use X11 tunneling with SSH a few times a week to remotely run KATE from my universities server.

It's a bit sluggish at times, but usually its pure KDE UI goodness!

X11 was made for that sort of thing from the ground up... Hence its client-server architecture. Pure X11 goodness is what you probably should be saying :)

"Agree. Kind of odd that Flash has been around so long, and yet uptake for developing full blown applications in the browser is pretty dismal. It's sort of like Linux and Desktop UI: if it hasn't happened by now, will it ever?"

Yeah, it strikes me as really strange too. Like others are saying, there really hasn't been much of a consistent and powerful framework for Flash programmers to take advantage of. Its only since the likes of Flex and the upcoming Apollo work that things will get interesting in this space. Perhaps thats the reason.

What do others think?

I think that there is definitely a place for Flash, particularly as components within a web application. Im just unsure as to how much I need to invest in flash to create full blown apps. If Flash doesn't really offer me anything useful that I cannot achieve without it, doesn't that make sense?

I particularly like some of the comments on how people should be avoiding the mistakes of the desktop and developing new types of interfaces. Thats a good argument and I would like to think people are starting to think outside the confines of desktop apps ON TOP OF their thinking outside of standard HTML. However, the other side of that story is that a desktop-like interface is consistent. The metaphor is a well known one, so we can generally rely on people knowing how to use the interface to access the functionality of the app.

Sidenote: I think the linux desktop is a reality. I just think it offers people another option and another style of computing. Its still got its problems - even now.

Yes, we know that Bruce Eckel used to think in Java but now he thinks in Flash. Flash on the web reminds me very much of those old Applet days. I thought Applets were great. They certainly had many limitations but didn't try to take a document -> rich app like HTML/AJAX/etc.

Jobs is right though - applets are dead. We recently ported a customers system from Applets to plain Servlets.

Pity; If applets had had the same attention from Sun that Adobe gives Flash, who know where they might be know?

I hope the future af all application won't be web based.
We all expericed that the most powerfull server in the world can be easily saturated when many users connect to it for some reason.. like and important news, a global event. In those circumstances everything become unusable.

What you can do now is writing a program, and maybe get an high number of users in short time, maybe millions. All you need is a very thiny laptop to write your software, and a very simple web page to let people download it.
What if I want to do the same with a web aplication? I need a powerfull web server becuase millions of people will connect everyday to use it... maybe a cluster of servers, or servers localized around the world to split the network traffic.

Think also this, you are working on thread secret information on a web based application... It needs to be connected to the internet even if you don't need anything from the web. Are you really sure you secrets are safe??

An other question: if the future is completely web based, what if you can't connect? Laptop is beyond the idea of freedom. Just pick your long lasting battery laptop, or maybe a solar chanrger and go to the top of the montain to work there, and come back at the end of the day.
The idea ow wireless is to be free and unplugged, but at many levels! web based applications are an invisible wire that prevent you to use them with the same freedom you have with standard applications.
Many time I bring my laptop at work to write some code, but I don't have rights to plug it to the network. So I couldn't use it anymore. Since I do two jobs at the same time, I couldn't do thesecond job anymore.

You can just buy many software, then use them for 5 years wihtout any upgrade because they just do what you need.
I suppose web based application will be just a good way to keep us paying expensive maintenances, even if we don't need them at all.

Max

BB if you think "web designers do a better job than Sun engineers at making a polished interface" I suggest you look again. Especially at Java 6 & 7 and SwingLabs(ie Painters) and java.net(ie Timing Framework) and ... .

But the great thing about Java - we don't have to wait for Sun. (Is there still a lot of work? Sure.)

MaxL - I think you are assuming too much about the model which web applications will work.

For instance, I think it is wrong to assume that web apps will be all served globally/externally to your organization. I would even go as far as saying its wrong to assume all web apps will be served externally from your computer. Offline web apps are here today, some don't even require web servers to run and offer amazing functionality without the need to be connected to the Internet or even other computers.

There is really no reason that I couldn't run Google Docs from within a corporate network. Heck, that would be a 5hit load easier than buying hundreds of copies of Office and running the gauntlet of updating upon yet another software release... (or should that be a visit from the M$ tax man?) I guess if Google released the code for their apps, that would an option for people. If they don't, theres no reason why someone else won't venture down that path eventually - maybe thats what Microsoft might do with their productivity suite... Hope not! :)

The thing about AJAX development is that it is rapidly becoming a lot easier. Morfik, for instance is about to go 1.0, which means that all those v.net and Delphi folks are going to have a way to build AJAX apps without having to learn all the crap that you have to know now. I can't freaking wait.

Karl: "I think you are assuming too much about the model which web applications will work."

I really hope I'm wrong :)
I was describing the worst scenario this path could bring.

Max

naughty, naughty - downloading movies and music ;)

I'm a web developer, working with PHP as my primary server-side language. Coming from a web development background, I can tell you it IS possible to make pretty, working code that performs many functions of a desktop app--especially with AJAX.

For instance, take a look at http://www.thephppro.com --look at some of his product demos and their source code. I work for this guy and have used his AJAX system before, and let me tell you it works like a dream. Two simple function calls on a PHP page will produce all necessary XML formatting, return data to the page, and overwrite any necessary element in the page. One of two different function calls can be used to request this data.

Using this technique I created--with relatively minimal effort, good OOP standards, and clean, efficient code--an application that can update large or segments of a page with information from a server-side database as necessary, modify the database and return results based on the modification in less than 100ms (depending on the client's connection speed).

Again, take as an example Google's Docs and Spreadsheets web application. Though I can't speak for its code, having never seen it, their interface and abilities are nothing short of fantastic for a web app. Sure, it's different than a desktop application--I won't say worse, for though it does lack a few features such as default font selection, it has a whole range of features, many of which are inherent to web apps--such as being able to access your saved documents from any computer, anywhere in the world. Google Docs and Spreadsheets goes so far as to offer you the ability to save in formats including HTML, Word/Excel's .doc/.xls, and several other formats not supported even by Office.

I won't continue listing examples, but there are many, many of them out there--it's mostly a matter of A. finding them, and B. finding people capable of making them. :)

One my better college professors told me once that knowing what is "good enough" is the hardest lesson a programmer can learn, because it's never perfect unless you do infinite improvement iterations, and you don't have that much time.

Yeah Morfik sounds like a great solution, but how does it execute on the server side? It looks like you have to use their proprietary Apache plugin, right? And you are able to use databases but all your computation is on the client side in obfuscated javascript, not on the server side -- am I right?

Greg

Jeff,

You mention that web is the path of least resistance. I agree, but only for apps that are for use by the general public and/or which require venture capital or similar funding (and which must, therefore, use trendy technology).

However, for corporate apps (custom-built for use in one company) rich clients can be the path of least resistance. Some reasons why:

1. More cost effective (either more functionality, lower cost, or both)

2. Better use experience. While it's often assumed that corporate apps are adopted according to a decree from the top, in my experience the really successful ones are actually _popular_ with their users, and to be popular the user experience must be pleasant.

3. Less demanding on server hardware. Since each user of a rich client brings their own hardware (their desktop PC) to the party, the server only has to serve data not UI as well.

I wrote this last year :
http://buzzsort.wordpress.com/2006/09/07/on-desktop-webification-and-web-desktopification/

I prefer the path that takes us to web enabled desktop apps like iTunes. I think Microsoft if heading down this route, whilst they have their Live platform if you look at Office 2007 you can already embed live data from the web in documents, its even easier if you are using Sharepoint based solutions for intranets etc.

However the whole WPF/E thing is most interesting, the ability to design an UI for a desktop based app, browser based app and mobile app usinng the same XAML is great. In my line of work I build intranets, so have a differet set of issues to building websites, however people expect intranets to be more applicationified, WPF/E is where I'll be heading in future for user controls and web parts, meaning I can deploy them as web forms, application/windows forms, Sharepoint webparts or on a moblie device. All things that over the next year I'll be needing to do.

The fact that WPF/E and XAML allows me to run applications in both on and offline modes makes life even easier.

Also as an aside, those people that describe HTML as a document language and cite the term browser to back this up are mistaking semantics for facts. HTML stopped being about documents the day the Form element was added in, some time 1994-5 I think..

The "path of least resistance" changes depending on what you need to accomplish and the tools you have to reach that goal. I've built several web apps that leverage JavaScript to add some nice functionality to the UI, but it takes time.

There are certain situations where technologies like Flex can give you that very usable UI with a lot less time and a lot less effort. While Flex is based on Flash technology, it is a TOTALLY DIFFERENT development experience: do not make the mistake of thinking that if you've dabbled in traditional Flash you have some idea of what developing in Flex is like.

I saw someone posted some links to Flex resources. If you want just a taste of what Flex can offer (either as a stand-alone web application or just a widget on an HTML page), just take 5 minutes of your time and do the following:

1. Go to the Flex Online Compiler at http://try.flex.org/index.cfm
2. Select "Sample Apps" from the Category drop-down and "Blog Reader" from the Entries drop-down.
3. Click on the "Try It" button under the code window.
4. When the page reloads, scroll down to the bottom of the screen and try it out...click on the Get Entries button to retreive the data. Click on the column headers to sort the entries. Click an entry to read it.
5. Scroll up to the code window and check out how many lines of code it took to make that widget (if you doubt that code is responsible for what you're seeing, change parts of the code--like the label for the Get Entries button--and click Try It again).

There is room on the web for all of these different technologies.

I can't see how you can reconcile this with your "Non-Native UI sucks" article, which I agreed fully with. Given a choice between a Web interface and a native app, I'll go native 100% of the time.

What bothers me about the Flash based approach (Apollo, OpenLaszlo etc.) is that they always break keyboard shortcuts like Ctrl-C, Ctrl-X, Ctrl-V etc. To copy and paste you *have* to use the mouse. I'm not even going to go into the fact that you cannot select all parts of the app...

I agree with the comment about "never bet against the path of least resistance." The real question is: which has more resistance, flash or AJAX? Flash actually works on more browsers than Ajax (97% vs 92%) (supposedly 8% of users have javascript turned off). I would argue Flash is easier to code than AJAX. yeah, there are a bunch of JS libraries, but you're still dealing with Javascript to use it... and JS dev is an error-prone PITA IMO. I could do stuff 10 years ago in Delphi 20x faster than it takes now with JS.

It **really** depends on the app.

I'd be almost be happy to use Yahoo mail instead of my desktop mail app except for responsiveness on large lists. I mostly don't have a problems with Google Spreadsheets over Excel for my needs although responsiveness is still an issue.

But somethings are going to require new standards I think. For example, photo editing, illustrator type editing, video editing, I think are a ways off over the net.

Then there are subtler things like there is no copy and paste of anything but text in HTMLland. Uploading my non text content a few files at a time and referencing it later is a huge step backward in productivity. People appear to be living with that issue but I have a feeling they are actually just not using nearly as much non-text media as they would in a local app.

Imagine trying to write docs for an app and needing to insert a few hundred screenshots. In a local app that's Alt-Printscreen then Paste. On the web it's just so much work as to make people just not do it. Flash doesn't solve that issue either.

Still, probably 95% or more of the people out there only need email, web browsing, maybe a blog and photo albums. Clearly they don't need any desktop apps for that. In fact arguably they don't even need a PC. A cell phone with a better keyboard and larger screen docking station has enough power to cover the needs of 95% of the world

> A cell phone with a better keyboard and larger screen docking station has enough power to cover the needs of 95% of the world

I suppose it's possible if you factor in a docking station with a monitor and keyboard. But I think this will take a LONG time to happen, even by manic computer evolution standards (eg, 15-20 years from now). I want my cell phone to be as tiny and light as possible, with maximum battery life. Those requirements are diametrically opposed to what a computer does. Even the tiny Mac Mini is a colossal behemoth compared to my Samsung Blackjack.

That's alot of comments, its hard to imagine with such smart people posting how little I learned from all of that, the comments basically went back and forth and said the same again and again as the article

I'm surprised people didn't bring up current problems with web apps, they are already starting to use alot of the cpu, there are alot of cpu intensive flash games these days that cite high end specs to play and javascript is worse if your not careful

sadly the most responsive things I have used in browsers are ones made in activeX, the activeX version of the remotelyanywhere client is far superior then the java version

Yes Morfik an GWT and Echo2 and ZK and Wt and Tibco GI are all going to make writing rich interaction Ajax apps easier. There are a few things to watch out for as we move from the painful three environment development of current web apps to the component GUI model of these emerging frameworks. See <a href="http://blogs.pathf.com/agileajax/2007/03/so_you_want_to_.html">So You Want to Convert Your Desktop App to Ajax</a> for some specifics. For an example of where Ajax developers stumble, see Yahoo! Mail beta. To delete a few thousand email messages, you have to scroll through all of the messages so that they fully load, otherwise if you do a "select all" or a shift-click and try to delete unloaded messages, you get an error message.

Yes, all those frameworks -- Morfik, GWT, Echo2, ZK, Tibco GI, etc. -- will make developing RIA apps easier. But while hiding the messy underbelly of web development is useful and productive, it also has it's downsides.

So You Want to Convert Your Desktop App to Ajax (http://blogs.pathf.com/agileajax/2007/03/so_you_want_to_.html)

For an example, see the Yahoo! Mail beta. Because the network bandwidth between browser and server is a lot smaller than between disk, memory and video card, the Yahoo! Mail beta make the list of emails lazy load. Now if I have a few thousand emails I want to delete, I have to scroll through all of the emails so they load, otherwise a shift-click select of a range of unloaded emails will give me an error. As a result, something that would be a trivial and natural opperation in a desktop app becomes unusable in an equivalent web app.

It's a shame that you removed the links from your quotes. Just in case anyone's wondering what Bruce Eckel was referring to with "someone did an imitation of the much simpler Microsoft Paint using HTML, CSS and JavaScript": http://canvaspaint.org

Venture capitalists won't invest in Windows applications because of fear of competition from Microsoft?

But, um, er, a "web app" running on IIS written in ASP.NET and requiring the latest Internet Explorer with all patches is actually a Windows application. (Unless somehow there actually is a lowest common denominator across many browsers and web servers - but that means that no web browser is allowed to implement anything that the others don't have.)

In the meantime, either Vista will be the biggest flop in computing history, or *something* will be running on the desktop.

On the other hand, Joel did say something else that is still true: abstractions leak. The web-app SOA abstraction does leak, and no matter how well you plug your leaks, there's always one more leak needing plugged.

Still, it's nice to see the Sun slogan "the network is the computer" ws just ahead of its time, and they wern't as mad as everyone said. ;)

As far as my near-religious opinion about remote use of torrent clients is concerned: i prefer the combination of OpenSSH, screen and rtorrent (http://libtorrent.rakshasa.no). Perfect for those running *nix boxen at home.

Why you always put the word "orange" in your Captcha Control? Is there no other word you can think of for the captcha image. I mean if there is only 1 word coming again and again then there is no use of the captcha control! It should have random words and not 1 word. 1 could easily write a program which will fill the word "orange" without even bothering to read the captcha.

Regards,
Mahernoz

Well, did you heard about NeoSwiff ? <a href="http://www.globfx.com/products/neoswiff/">http://www.globfx.com/products/neoswiff/</a>
Writing Flash applications in C# solves many problems in my opinion

How many of the supposed 8 per cent of users who have disabled JS have also disabled Flash?

SEO can't do much with Flash. Administrators want their websites ranking high in searches. In house Flash/Web stuff doesn't need this, but then again, "inhouse", doesn't need Flash, it can use the bigger stuff.

It is kinda nice when you just tell the user, "close your browser and then open it again", to fix most problems.

You seem to have misunderstood what Bruce Eckel was getting at. With Flex 2, your rich (i.e. thick) client RUNS IN YOUR WEB BROWSER. It leverages the capabilities of the Flash plugin, which something like 97% of current internet users already have installed, in order to provide all the benefits of a true thick client combined with the ease of deployment of a web application.

The last part of your post laments the fact that "we can't come up with some way to deliver a full-fidelity user interface over the wire for an application as nifty as µTorrent". Ummmm - in fact, we can. With Flex 2... which is what Bruce Eckel was talking about, and you did not seem to comprehend. You might want to look into Flex 2 sometime soon.

Do you know why Flash sucks and will suck forever?

Flash is inconsistent and unintegrable by design:
- web pages (what user gets) have open code, while flash does not
- flash plugins cannot act like other native elements in browser, e.g. images, to catch right clicks and mouse gestures - they are alien to browser
- flash cannot be disabled or saved separately with standard (default) means - such inconveniences with images killed Netscape!
- flash takes most of CPU time on huge objects
- flash is used 90% for ads
- the rest 9.9% of wholeflash sites have no integration with standard browser tools - bookmarks, navigation, copying, saving etc; users hate this
- 0.1% of flash use are separate content instances (games, etc) which can be loaded into a separate flash player as well.

That's why flash must die.

And as for web apps they suck for similar reason:
- they not always cope with standard browser tools
- in 99.99% cases you cannot save a web app in its current state
- they are inpredictable - nobody knows when they choose to update or to insert ads; as for my The Bat!, it will run and looks the same yet even in 2099, as well as i don't update it
- they are too server-dependent (not 100% reliability and privacy)

So, while there will satisfy 90% users, there will always be a niche for the rest 10% or more, who now use Linux/2003 Server as a workstation, Firefox/Opera as a browser, Greasemonkey or other user script tools, ad blockers etc. And it is a huge potential market for all kind of customizers. All browsers suck by design.

I agree that web technologies fail to provide that last 10% that we expect out of windows apps. And microsoft recognizes this and has created WPF/E, which in my observations is essentially a flash application foundation.

Something to look at.

> It's the YouTube of spreadsheets.

Don't you mean YouTube is the Instacalc of video? :-)

What sad is that Rich internet application slowly start to solve problems we already soved for desktop systems and on the other side of the equation we managed to solve the deployment problem of desktop applications which is probably the main motivation for web-based ones anyway

I blogged about it on my Dr. Dobb's blog:
http://www.ddj.com/blog/architectblog/archives/2007/02/ria_is_it_deja.html

Everybody having Vista and .NET 3.0? Not that I plan to not having the first ever, I even have no stinking .NET 1.0 at all. If you want to do browser based stuff using widgets, XUL is the way to go, not that .NET crap. For the rest, let's see where Flex will get.

Oh, and yes, Flash does suck hard on the whole "open" issue.

Hi Folks,

This is a great discussion. I wanted to point out that with the release of OpenLaszlo 4.0, there is now a 100% open-source framework that allows you to take advantage of Flash's strengths when you need it (video and audio playback for example), and have the _same_ source code compiled into a DHTML application. The DHTML kernel is quite good, with cross-browser support for things like vector graphics, mousewheels, context menus and reliable cross-browser opacity among other things. We like to say 'we work hard so you don't have to' meaning we take care of abstracting away all the browser and Flash player warts. Instead of worrying about runtime issues (or even which runtime you want to use - Flash or DHTML), you can concentrate on building great UIs.

I don't know if you can build an adequate replacement to a native desktop Bittorrent client, but it certainly won't hurt to try again! As browsers improve, I expect the line between native and web applications to disappear.

I don't think you missed Bruce's point at all - and I must say I find it somewhat amusing he cites an OpenLaszlo app as an example of why you should use Flex 2/Flash! Where are all the Flex deployments on the open web? I don't see a lot of them. Certainly, there's a ton more AJAX out there, with more showing up every day. And, there are many more OpenLaszlo apps on the open web, at places like pandora.com, walmart.com and monster.com.

Part of my mission in developing the DHTML runtime was to see how far we could get without Flash, while still giving developers a rational development model that scales better than hand-coded JavaScript. A good friend of mine recently remarked 'JavaScript is the new assembly language' and I couldn't agree more. Sure, there are still folks hand-coding x86 assembly but the point of diminishing returns (and Moore's Law) means that most people don't bother.

The other part of the mission was to make it easy to add new runtimes. In the coming months, you can expect to see support expand beyond Flash and Ajax into places like the mobile space. In fact, if you're going to be at JavaOne, come by for a visit - I'll be co-presenting Project Orbit, Sun's new Java mobile runtime for OpenLaszlo.

What runtime would you like to see added next?

Regards,
Max Carlson
OpenLaszlo.org

I'm glad Max came in with "take advantage of Flash's strengths when you need it (video and audio playback for example), and have the _same_ source code compiled into a DHTML application". I think Eckel's points are good, but I'm not so sure about his conclusion.

Perhaps OpenLaszlo's fate will be a strong indicator of how this is going to pan out.

i'll be thankful if u help me getting a horror interface of my forum

I sure hope those screen-shots weren't made by you or that you paid for the movies :)

I DON'T WANT my web apps to look like my desktop apps.

What few bits and pieces are you missing in the WebUI exactly? The "Done %" bar and the "Pieces" graph? I see no obvious reason why these can't be implemented using Ajax if one wanted to. The tiny icons on the 'folders' and the shaded tabs? Ditto.

It's not a question if it can be done, it's rather a question if it was worth the extra overhead in the first place. There is a reason why today's MS Office measures in gigabytes rather than floppy disks.

Average Joe just wants to write a letter and download a .torrent, like you said, via the path of least resistance.