March 14, 2007
Torrent, my favorite BitTorrent client, now offers a web UI. See if you can spot the differences between the Web UI and the Windows UI:
After spending about a year interacting with Torrent exclusively through Remote Desktop, I was pleasantly surprised to discover how good the web UI is. It aggressively exploits the latest Ajax techniques to replicate most of the rich GUI functionality of Torrent in a browser. But the web UI is still a pale shadow of the full-blown Windows UI. There are small but important details missing throughout, and part of the pleasure of using Torrent was luxuriating in its intense attention to detail, its wealth of well-designed data readouts. Using the web UI is like drinking watered-down beer. It doesn't satisfy.
But does it matter? Despite my nitpicking, I can do everything I need to do remotely through the web UI.
I do sometimes miss the fit and finish of the complete Windows UI. But if the only way to achieve full fidelity is to log in to the machine as a user via Remote Desktop, it's hardly worth the effort. Remote GUI technology has never caught on, either in Windows (RDP), in UNIX (X11), or even on the Mac (ARD). This approach has always felt like overkill, and it doesn't seem workable based on the historical evidence.
So the Web user interface is about 80% there, and even without new web browsers we can probably get 95% there. This is Good Enough for most people and it's certainly good enough for developers, who have voted to develop almost every significant new application as a web application.
I'm actually a little bit sad about this, myself. To me the Web is great but Web-based applications with their sucky, high-latency, inconsistent user interfaces are a huge step backwards in daily usability. I love my rich client applications and would go nuts if I had to use web versions of the applications I use daily: Visual Studio, CityDesk, Outlook, Corel PhotoPaint, QuickBooks. But that's what developers are going to give us. Nobody (by which, again, I mean "fewer than 10,000,000 people") wants to develop for the Windows API any more. Venture Capitalists won't invest in Windows applications because they're so afraid of competition from Microsoft. And most users don't seem to care about crappy Web UIs as much as I do.
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.
Bruce Eckel read the same tea leaves as Joel Spolsky, and concludes that the future of rich web applications lies not in HTML, but in Flash:
- The typical user only touches a fraction of the functionality in most applications. Switching to an online spreadsheet like EditGrid or WikiCalc is hardly a catastrophic loss when you only used 1 percent of Excel's functionality to begin with.
- Online applications may be awkward, but they do one key thing that local applications can never do: embed snippets of live content in a web page. Instacalc may never be Excel, but so what? It's a completely different use case. Instacalc is ideal for embedding bite-sized, interactive nuggets of calculation next to a paragraph of text on a web page. It's the YouTube of spreadsheets.
Like Joel, I think the future of many-- but not all-- applications is in the browser. Web apps are good enough today for most tasks, and they're getting better every year. 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.
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. I'll belatedly agree that web interfaces are "good enough"-- but after all these years of progress, why should we have to settle for something that's merely "good enough"? There has to be a better way out there somewhere.
Posted by Jeff Atwood
That article by Joel Spolsky is just about the most intelligent thing I've read in a long time.
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 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?
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...
"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.
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."
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 ;)
"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.)
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.
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!
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.
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?
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.
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.
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.
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.
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.
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.
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
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.
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 :)
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.
"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.
"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!
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.)
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.
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.)
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!!! ;)
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.
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.
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!
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.
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...
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.
naughty, naughty - downloading movies and music ;)
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.
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.
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. :)
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.
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.
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.
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.
I love that the screenshot includes a download of 'The Chronicles of Riddick'. (Decent flick).
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.
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.
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.
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.
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.
I wrote this last year :
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..
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
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.
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.
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...
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.
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
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.