Be it Resolved: VCs are Wrong About Desktop Apps

Over at Om’s site Mike Rundle says it’s understandable why VCs (and journalists) are so enthused about web-based apps:  they don’t “produce” things, so they don’t need desktop horsepower. Real people, he argues, the sorts who produce real things, will always use desktop apps. Sayeth Mike:

We’ll never see design, audio, or video professionals use web-based versions of the applications they use to PRODUCE things because that’s totally impractical and ridiculous.

True of false? I say False. Way back when there was a time when people would have said that editing text in WYSIWYG was a CPU-bound task that required a desktop application, but times have a-changed. I have no doubt that the same thing will happen, sooner rather than later, to many tasks, like audio-editing, that are currently deemed now-and-forever desktop apps.

Agree or disagree? Tell me.

[Update] There are lots of thoughtful comments on this post, including Mike
 Rundle
, who started the whole thing, plus Avi Bryant of Dabble DB.

Related posts:

  1. Desktop Ajax as Desktop.com Returned
  2. Google Desktop Uber Alles?
  3. Om [Doesn't heart] Google Desktop
  4. Google Desktop Search: Internet O/S
  5. Copernic Desktop Search vs. Blinkx

Comments

  1. cem sertoglu says:

    I agree, Paul. I think, on the editing side, the path may be paved through the personalization services. There’s bound to be tools developed so that when you add a youtube clip to your myspace page, it’s not the same as everyone else’s embedded clip.

  2. Tim Swanson says:

    I also agree. With companies like Apple pushing web services (through things like iLife), it is only a matter of time when apps like Garage Band are available in a web-based form.
    Similarly, there is already a market for off-site 3d rendering; so perhaps someone will create an AJAX version of GIMP in the near future.

  3. I agree as well. We’re building it. We’ve got a simple single track based recorder built into our service now and we’re creating a GarageBand like ‘in browser’ recorder app as you read this.

  4. Niko says:

    I feel there is a strange combo of assumptions: that we will have lightning fast network connections, capable of sustainable transfer rates above 10Mbps with near-zero latency (required for GarageBand, for example), AND we will still be using AJAX or other programming technologies currently available.
    To simplify a bit, it might be useful to split applications in three: data storage, data processing and user interface.
    A web-based application is simply something that puts the data storage online instead of the local filesystem, and processes data online (or in the locally running JavaScript engine) instead of using the desktop system’s processing resources. A web-app also stores the user interface on the web (enabling the benefit of transparent updates etc), and the user accesses the app by loading the interface in her browser.
    So, looking to the future of the super-fast network, why on earth would we be running our apps on top of the browser’s JavaScript engine? If we have the dream network, and we can load the application interface into a browser, why couldn’t we simply launch our apps from an “online drive” that looks like our local hard drive (like Apple’s iDisk), lightning-fast if I may add? It sure beats typing in urls to launch apps. And the apps could use some real technology and not that (in the future) legacy AJAX stuff.
    To finish with my point, I hope we will not see WEB-based apps for everything. But I do hope and agree that we will see NETWORK-based apps for everything.

  5. Matt W says:

    Let’s look at what advantages a desktop app has versus a web app:
    1. Data is kept locally
    2. Superior processing speed
    3. No need for reliable net connection
    It seems likely that web apps are posed to overtake web apps in all three of these advantages.
    DATA IS KEPT LOCALLY: OK, admittedly, it’s not even clear that this is an advantage. Local data requires the administrator to deal with security and backup issues. We can easily imagine that a significantly large/trusted web service provider (e.g. Google, not Kiko :) can do a better job of securing and backing up the data. Most consumers seem to trust a Yahoo or Microsoft with their email and businesses are also used to remote data management / backup.
    PROCESSING SPEED: Already GMail delivers search results faster than this internet cafe computer ever could. With massive Google-like computing grids, you should be able to get far more processing power remotely than on your desktop. Of course, there are problems with latency and whatnot which would have to be overcome for games/etc. to work flawlessly. Which is a great segue into…
    RELIABLE NET CONNECTION: So, I think this is the biggest issue. Nothing is more annoying than opening up your laptop on the way to the airport to check your flight info than to realize that you received it in GMail. You have to be pretty certain that 99.x% of the time you will be online with a fast enough connection for your app otherwise there’s no way you can rely on a web app for most serious applications. I’m still waiting for these web apps to develop the ability to have some percentage of the functionality/data available for unconnected use. I imagine that something could be done on the browser level to accomplish this in a secure way?
    OK, back to the day job…

  6. asdf says:

    Disagree. Text documents haven’t been growing in size so eventually net speeds caught up to the point where they can process them. Media generally has grown in size and therefore will remain ahead of net speeds. I’m still waiting for the day I can just pull a .wav file off my CDs without having to compress.

  7. Toni says:

    Agreed. And as these apps move to the web, they’ll get a much needed trimming down of the endless feature lists accumulated over 10 or 20 years of desktop based software development. Agile development wins.

  8. Agree: There is no page break in HTML. And yet I care about whether something will print out on page 3 or page 4.
    Disagree: the “Flash player” that powers a lot of video playing these days (YouTube etc) is a “web application”. But Adobe has the capability of adding a lot of editing and mixing power to it — that *already* exists in their “desktop application”. Adobe’s decision to copy functionality from their Flash maker into their Flash player is not likely to have much to do with desktop CPU horsepower, and much more to do with golden gooses. Could parts of the PDF/DOC/XLS/… maker be pushed from the viewer in the same way? Surely.
    You could define “web-based apps” so as to exclude the viewer plugins and include just html/javascript, but why? A lot of it seems to do with “is it already downloaded?” The penetration of the Flash Viewer is so high that people are probably willing to just consider it part of the browser. For XLS Viewers, far less so.
    As the number gets further from 100%, there is an opportunity to do an html/javascript only application. But it still won’t print out the right stuff on page 4.

  9. Barton says:

    Disagree. Web apps will augment desktop applications. But they won’t replace them.

  10. franklin stubbs says:

    How about both / and. The rise of web apps will be incremental, adopted by light users first and heavy users later if at all.
    For example, I use photoshop maybe four or five times a month, but I never do anything with it beyond what a much more basic program could handle.
    If you could plot a bell curve of feature use for fat desktop applications, I bet you would see an 80 / 20 type distribution of features used (80% of users rely on 20% of the functions), with a small minority in the high-end portion of the tail. This could be true even among professionals.
    Sticking with photoshop for an example, their profitability could die the death of a thousand cuts as simple features were incrementally added to a useful program one by one. First simple cropping and photo resizing, then basic editing, etc. etc… the rise of web apps may benefit us by splitting out the casual users from the hardcore users in a way that benefits the casuals. This would hurt the desktop app companies in the same way that the downfall of television advertising has hurt madison avenue. It used to be that you had to buy photoshop if you were at all serious and didn’t want to gimp around. Over time that will cease to be the case.
    Also, even with desktop apps, it makes more sense (from my view) to move from a one-time purchase model to a pay-as-you-go model. Even a desktop app could have some kind of usage meter, letting the user buy minutes like a cellphone plan. This would allow for lower cost (no huge pocketbook hit upfront) and continuous upgrades (no need to shell out for version 6.0, 7.0, 8.0 etc). The software industry has many dinosuar tendencies that still need to evolve, much as the book publishing industry does.

  11. Matt M says:

    Disagree. Studios and production companies are unlikely to use Web apps because of the legal implications of remote storage. On the flipside, Web app companies are unlikely to agree to indemnify studios for lost or stolen footage. Since studios and production companies will not move to the web, desktop packages will remain the industry standard. If desktop packages remain the industry standard then most amateurs aspiring to industry jobs will want to train on desktop apps. Therefore, web apps will play a minor role in the audio/video industry.

  12. franklin stubbs says:

    Why does a web app require offsite storage? You can’t save to your own server?
    Also, salesforce.com seems to be getting around the data liability problem…

  13. I don’t agree that all apps will be running on the web soon. I am a journalist and I prefer applications running locally on my PC. Processing is just faster. With web-based apps there is invariably a delay between editing and updating of the changes on the web-page. Besides slowness, a web app will often hang in the middle of carrying out a task for no obvious reason.
    Web-based applications, like the web interface to my email programs, are good if you’re on the road and have to use a public Internet terminal. But for the time being the response time is too slow to use them all the time, in my opinion.
    Cheers from Zurich
    Valerie

  14. Matt M says:

    “Why does a web app require offsite storage? You can’t save to your own server?”
    When is a Web app no longer a web app? Is Windows a Web app because of live updates?
    “Also, salesforce.com seems to be getting around the data liability problem…”
    Salesforce.com was founded in the spring of 1999. At that time it seemed that the legal protection we enjoy in the offline world would be extended to the net. Post-9/11, the legal environment for remotely stored content changed. Brad Templeton succinctly summarizes the problem as follows:
    “When you use network services, you need a contract, and that contract will be written primarily to protect the interests of the service provider. When you run software on your PC, you may agree to terms when you install software, but as far as your own data is concerned there is usually no question of contract at all. The data is on your PC, and there don’t have to be rules governing what others can do with it.
    Without the ECPA protection, your e-mail (now just a database) can be seized against Google’s will by the government with an ordinary subpoena (vastly less involved than a warrant or wiretap) or in the discovery phase of a lawsuit. With warrants, and in some rare cases even without them, your mail can be grabbed without you being informed that this has been done. Worse, Google has retained the right to hand it over in the case of a “request” from law enforcement, rather than a court order.
    Of course, these legal techniques can be applied to the data you store yourself. However, short of a secret warrant to break into your house and seize your computer, it can’t be done without your knowledge and involvement. You have the chance to fight any attempt to grab your mail. You have the power to get a lawyer and appeal any order in front of a judge. You give up some of that power when you put your e-mail database in somebody else’s hands. Google is a good company that wants to please its users, they don’t want to be subject to all these subpoenae. But they won’t fight as hard as you would.”
    (See http://www.templetons.com/brad/gmail.html)
    This is the Achilles’ heal of SaaS.

  15. Mike Rundle says:

    I think this argument comes down to what’s deemed necessary or what’s deemed additional in software. Google Spreadsheet is the web-based version of Microsoft Excel but there’s no comparison, and that’s with a crippled feature set on one of the largest computer grids in the world.
    Normal, everyday people will be using web-based apps that have a limited feature set, however for full-horsepower production work it will always be done on the desktop. Niko’s comment is essentially my point, that there are so many bottlenecks inherent with running web-based applications that it will never make sense to rely on them for production work. Moore’s law will always be ahead of broadband speeds, if a cheap processor runs desktop applications faster than a browser with the most expensive FTTH or Gigabit internet connection could ever run a web-based version of the same app, guess which one wins?
    Internet related slowdowns don’t just stop at connectivity speeds, but also in the browser’s rendering engine (how long does it take IE6 to render that HTML it just got back from an Ajax request?), JavaScript engine (as noted previously), amount of memory that browser application is running on, etc.
    Now for what it’s worth, this opinion is coming from someone who uses Photoshop, Illustrator, and various development IDEs all day long, so my world is grounded in full-horsepower, *production* applications, and so are many of the people I know. For people who don’t use applications like this, and mainly create and interact with textual data all day long (IM, email, Word documents, calendar appointments, etc.) then I agree, your world is coming online at a much faster clip than mine. Just because the three killer apps you use all day are now web-based and free doesn’t mean that all apps are going that route :)

  16. Tom George says:

    I say false.
    Moore’s law (and its equivalent is in the network sphere) often makes naysayers eat their words. It has made me eat more than my share. So, if the argument against web-based apps is technical, I believe it’s just a matter of time.
    More importantly, in a small company like ours, it becomes glaringly clear how expensive it is to install and support software and computers. I think you can hide this cost to yourself when you’re just one person, or when you have an IT department, but we can’t.
    So when I think of buying any software now, I wonder if there is an online version that we can just sign up for. If the tools we use could be procured online on a monthly per/user basis we would not buy much if any software.

  17. Joe says:

    First, nobody is clearly defining what they mean by a web application. It a program simply running inside a browser a web application? Does it have to run remotely? Can it have any locally run components (i.e. ActiveX controls)? What about an application that runs purely as a native service on a server, but has a lightweight web interface into it?
    Let us assume that a web based application is one where the bulk of the processing takes place on a remote machine and the interface is through an html/javascript based interface (which I’ll call a web interface.)
    The first problem is that web based interfaces are currently quite poor in usability. Given their limitations, designers can do a reasonable job, but I’ve yet to see a web interface that has the same level of usability as a comparable native interface (Microsoft’s Outlook web interface is a prime example of this. It’s close, but it still has a clunky feel to it that can’t be overcome without a new HTML/Web standard.)
    The second problem is performance. Web apps have two performance penalties; the speed of the network and scalability of the server. Even if the first is overcome, the economics of the second become highly impractical for many applications. To overcome this, you can distribute the application across multiple servers. Or you can distribute the horsepower back to the client itself.
    Take something as simple as editing a raw image from a digital camera. Say you want to rotate it, crop it, resample it and apply a sharpening filter. No matter how you architect the web app, it will always be vastly inferior to doing this with a desktop application (okay, with one big exception, you create a web app with a huge ActiveX control for editing images, but then this is just a desktop app with a crappy interface.)
    How about editing video? CAD? And many other applications. All will always be superior as a desktop application because the amount of processing power required. (In theory you could make every one of these work as server applications, but scalability and practicability quickly come into play.)
    There are applications that could be easily run remotely, such as personal finance or genealogy. Even there, though, the “lag” quickly becomes frustrating for most users. Even more intersesting is my own research due to working on similar project is that people really, really don’t like their personal information being stored remotely. There are a myriad of reasons for this, but the inability to work “disconnected” is much bigger than many people realize (privacy and the believe that the vendor will hold their data hostage for higher fees are others.)
    Incidentally, I’ve yet to see a web app that is superior to a comparable stand-alone app. Besides Outlook, I’ve tried the so-called online word processors and they pretty much suck. Even the Wordpad applet is more responsive and better designed than most these monstrosities. (If you give counter comparisons, make sure first that the app in question isn’t running an ActiveX control–many web app advocates turn a blind eye to this.)

  18. Joe says:

    PS. I should have made clear that while a given web application may not be as nice as a comparable stand-alone application its pros may outweigh its cons.
    I recently worked on redesigning a stand-alone application. The amount of reports and processing that needed to be done simply couldn’t be done with a web application. But, I asked myself, how many of our current and potential users really care about that stuff? It quickly became obvious to me that the vast majority of our user base only needed the basics and, therefore, it would make more financial sense to make the new application web based and to simply keep the old application on life support for the die hards.
    I also realized that we could, in time, add ActiveX controls or a “thick” client to the web application and satisfy most of the “power users.”
    This, methinks, is the future. It’s not stand-alone/desktop apps vs. web apps, it’s an amalgam of the the two. It requires a whole lot more clever thinking and skill to write such apps, but if properly done you can have something that will work stand-alone or fully online, with advantages and disadvantages to both.

  19. Avi Bryant says:

    Joe: “Say you want to rotate it, crop it, resample it and apply a sharpening filter. No matter how you architect the web app, it will always be vastly inferior to doing this with a desktop application”. I work beside Beau from http://snipshot.com, and he routinely uploads images to the server to do exactly that kind of cropping and rotating, even though he has Photoshop on his laptop. Why? Because even with the initial delay of uploading the file, the multiway Xeon server can do the processing much faster than his MacBook Pro can. Only a relatively small amount of data (a low res JPG) needs to be transferred back to the client so he can see what’s going on. All quibbling about “what is a web app anyway” aside, I think the model of powerful servers with unlimited storage that transfer tiny subsets of data back and forth to the client’s computer is going to become (“by a commodius vicus of recirculation, back to mainframe and environs”) the dominant paradigm. Depending on how much interactivity and complex display is needed, we may still need specialized clients, but like web apps these will be clients that depend on vast data storage and fast processing that’s happening in the cloud. Google Earth is a great example of this, as are WoW, Second Life, etc.

  20. Josh Wais says:

    “It’s not stand-alone/desktop apps vs. web apps, it’s an amalgam of the two.”
    Exactly. There are some factors we are forgetting here. Granted these are a bit out there, but, since we are talking about the future here, let’s be complete in our thinking.
    Are our PCs going to remain our only real point of access to our files and applications? I think not. We’re moving into the age of device shifting, Flash OFDM (think WiMax, I work at QUALCOMM) and a fully digital lifestyle. We can no longer afford to rely solely on our computers as the digital world leaks out onto the real world. We’ll want to have a centralized location for all computing needs. We could use the good ol’ local yet synced paradigm, but is that really how we want to be accessing applications on our mobile phones? And do we really want to have to sync everything? Want to email that girl whose email you got the other day at lunch? Sorry, can’t get it. Your cell’s off.
    What will our uses look like in the future? Will the average person be only using “IM, email, Word documents, calendar appointments, etc.”? If not, then what will they be doing, and if it will have “heavy demand” then will the speed and availability of necessary components (connection capabilities, servers, etc) be there? I think so. Just look at the game now. Gmail and it’s cohorts are proving it so. As web-sided computing accelerates, though, we’ll probably be facing a no contest situation soon. (I think Microsoft’s Live initiative is a big sign to us all. Oh and don’t forget Google.) Don’t get me wrong, I’m not saying that the local machine won’t be able to compete. This is the crux of all this, it’s not about competition. Now, as egregiously playgroundish as that sounds, it’s true. It’s about the amalgam. It’s about assigning to each her own and creating the best possible combination of what will be available to make our future, powerful, ubiquitous, computing world possible. Ggggo the future!!

  21. Joe says:

    Woah, time out Avi. World of Warcraft is most certainly not a Web app. It is a client/server application and the client piece requires a whole lot of processing power. This was my second point about the future being an amalgam of the two. Now, by its nature WoW does not run in a disconnected state (it would make no sense) but many other applications could (a good app with also degrade gracefully if broadband throughput declines.)
    (Incidentally, Google Earth uses an ActiveX control; it’s a genuine client/server application that uses the server largely for data store, not for processing power. What it most certainly isn’t is a web application.)
    I still disagree with the point about photo editing. Someone has to pay for the back end and the back end will not scale well even with a Xeon proccessor.
    As always, the proof is in reality. There are very few commercially successful pure web applications available. Part of this is the revenue model, but a bigger part is that people just don’t like them. Even with a big fat “pipe” there is lag–you hide some of it, but you can never escape it.
    Likewise, to suggest that stand-alone appliations are the only solution is absurd. Many applications can be “webized” without problems and where the benefits far outweight the negatives.
    The key is to think “distributed computing.” The parts that servers handle best are put on servers. The parts that clients handle well are put on clients. (Also think “disconnected”–I’ll never buy a purely web based personal finance program for this reason alone–for me the data itself is irrelevent, any spy would just bust out laughing if they saw my balances.)

  22. Tony Jones says:

    As usual, the lawyers will decide it.
    When you create Web-based apps that are mission critical or necessary to function in money making enterprise, the first “blow up” whereby a companies applications or access to the Web app is compromised, then there will be serious legal ramifications.
    Developers will then realize it is safer (from a legal perspective) to let the customer buy a desktop app and offload the liability to the customer.
    One place net apps will NEVER be used — transaction processing and algorithm processing in finance. This is not the same thing as distributed computing. These areas are top secret and really the only thing between multi billion dollar decisions and doom. Net apps will never be trusted in that environment.