Forgot your password?
typodupeerror
Programming Technology IT

People Don't Hate to Make Desktop Apps, Do They? 233

Posted by CowboyNeal
from the all-not-yet-lost dept.
Annie Peterson writes "Paul Graham has been making the argument that desktop development is dead — That's his premise for declaring Microsoft dead as well, and he claims that no one out there likes to develop for the desktop anymore. But that's not true, or is it? Desktop development is easier, faster, more productive, and infinitely more enjoyable — right? The question is, since web apps were originally built on desktop applications themselves, have the tables flipped? Or is it just wishful thinking?"
This discussion has been archived. No new comments can be posted.

People Don't Hate to Make Desktop Apps, Do They?

Comments Filter:
  • Although I have done my share of PHP web apps, my favorite application would be writing in Python using Qt.
    • Althouth there are a few interesting tools I'd still like to see, how many more desktops apps are really needed? Most people's needs and desires are more than covered by a word processor, email client and web browser. Open Office and MS Office are already overloaded with features that almost nobody will ever use.

      There will always be a need for custom software for corporates, but that is typically client/server with the client side just being a web front-end. The browser covers that.

      The real scope for target

      • Re: (Score:3, Informative)

        by fbjon (692006)
        Don't forget resource-intensive apps like Photoshop, any 3D modeling, music&audio, and so on. There's lots of people making those, and they require a personal computer.
        • by Baddas (243852)
          Ironic you should mention Photoshop, since adobe is frantically working on a web version to compete with online-image-editing startups.
          • by Dogtanian (588974) on Tuesday April 10, 2007 @05:40AM (#18672845) Homepage
            Ha ha... knew someone would mention that as soon as I heard mention of PS. I'm willing to bet that the online "Photoshop" will be extremely limited and wizard-based; at best it will use the core PS engine. I'm not saying it'll be bad, but it certainly won't compete with the full PS, nor even Elements; in fact, I doubt it'll even be as sophisticated as the now-defunct Photo Deluxe (a nice, but very limited PS-based product).
    • I've been using PyQt4 since last june. The crossed-platform RAD nature of python with qt4 is a godsend. The widgets even look native across Linux, OS X, and Windows.

      Unfortunately, the deficiencies of py2app and py2exe mar what could otherwise be one of the simplest ways to develop good cross-platform applications.
    • I like developing for the web... actually, I don't. I like developing in a non-gui environment, but I'm currently assigned to a "gui" team. Developing for the web (at least in my environment) allows me to (mostly) concentrate more on the problem itself and less on the "how thing are going to look". This is probably due to the great framework we use for web (mix of Struts and our own very extensive framework) and the lack of such framework for our (now abandoned) swing application. However, in my opinion,
  • Passe... (Score:5, Funny)

    by MarkRose (820682) on Monday April 09, 2007 @10:36PM (#18670435) Homepage
    Desktop programming is so nineties. I'm a laptop programmer!
  • by TinBromide (921574) on Monday April 09, 2007 @10:43PM (#18670497)
    Web apps are fun and all... Until my comcast tech decides to flip my interweb switch to OFF for 5 hours.

    Then i'm glad i don't rely on ajax apps or anything to get work done. While corporate customers enjoy a level of reliability that the average home user doesn't even dream of, being chained to the internet, yes, being chained to hotspots or cell towers for mobile internet is a drawback that the average user can't consider.

    While php and perl are great, people like to think they're somewhat self reliant, and relying on outside sources is good every so often, you don't hire consultants to do payroll for you.

    The web apps are like consultants, you bring them in for activities that is too expensive to implement and are only needed for on demand, but you don't have them do mundane activities that you could hire someone full time and not lose money on.
    • Re: (Score:3, Interesting)

      by tdelaney (458893)
      Unfortunately, my company (and many many other large multi-nationals) *do* hire outside consulting companies to do payroll.
    • Until my comcast tech decides to flip my interweb switch to OFF for 5 hours.
      ...and that web app will have enough fail-safes to run locally for short periods of time. The only problem that can't be mitigated is the degree to which you trust a vendor with your important data.
      • by Rakishi (759894)
        Thats assuming I'm running the app at that time. Too bad if I say turn on my computer in the morning and suddenly find that I can't do jack shit for the next three months (no, three months is not an exaggeration given past experience) cause someone jackhammered the fiber line.
    • Firefox 3.0 (Score:4, Interesting)

      by PIPBoy3000 (619296) on Monday April 09, 2007 @11:15PM (#18670765)
      Wait for Firefox 3.0 [readwriteweb.com]. Soon you'll be able to use your web apps, even if you're connected at 0 Mbps.
      • Re: (Score:2, Funny)

        by 8-bitDesigner (980672)
        Oh man, I can use GMail without a network connection now?

        SWEET!
        • Re: (Score:3, Funny)

          by RuBLed (995686)
          Haven't heard of GMail Paper yet?
        • Well theoretically yes. You will of course be limited to emails in the cache. About as useful as an IMAP client without a network connection.
      • Re:Firefox 3.0 (Score:5, Insightful)

        by tambo (310170) on Tuesday April 10, 2007 @02:12AM (#18672063)
        Wait for Firefox 3.0 [readwriteweb.com]. Soon you'll be able to use your web apps, even if you're connected at 0 Mbps.

        I'll believe it when I see it.

        Sorry, I just can't be optimistic about this. You shouldn't be, either.

        Look - today's web browsers can't even really get offline web page caching right. We're about a decade into the WWW revolution, yet browsers still can't passively save all of our web accesses and show 'em to us again when we're offline. I'd love to have my browser cache all of Slashdot's articles, and BoingBoing's, and Fark's links, for later offline browsing... yet it can't do that. The best we can get is RSS, which, frankly, is crap... it's like Gopher in HTML.

        If browsers can't tackle the very simple task of caching routine HTML for offline access... what gives you confidence that it will cache complex AJAX applets with even minimal usability?

        - David Stein

        • Re: (Score:2, Informative)

          by Anonymous Coward
          Oh really? [mozilla.org]
        • Re:Firefox 3.0 (Score:5, Informative)

          by dk.r*nger (460754) on Tuesday April 10, 2007 @09:03AM (#18673937)

          I'll believe it when I see it.
          Sorry, I just can't be optimistic about this. You shouldn't be, either.
          Look - today's web browsers can't even really get offline web page caching right.


          I'm not sure why I should adjust my expectations to technology according to your misuse of technology.

          Todays browsers don't get offline caching of Slashdot right, because Slashdot is an online application, and says so:

          HTTP/1.1 200 OK
          Date: Tue, 10 Apr 2007 12:48:30 GMT
          Server: Apache/1.3.37 (Unix) mod_perl/1.29
          SLASH_LOG_DATA: 07/04/10/011220
          X-Powered-By: Slash 2.005000152
          X-Fry: I don't regret this, but I both rue and lament it.
          Cache-Control: no-cache
          Pragma: no-cache

          Vary: User-Agent,Accept-Encoding
          Connection: close
          Transfer-Encoding: chunked
          Content-Type: text/html; charset=iso-8859-1


          In order to read Slashdot offline "right", you need to break HTTP. And we all know what happens to naughty boys who breaks standards. [greenspun.com]

          Offline webapplications will work offline because they will be designed to work offline. They will get safe caching of resources and a stateful browser-DOM-object to save data to. It's not exactly rocketscience.
          • Re: (Score:3, Interesting)

            by Myopic (18616)
            I would prefer if my web browser did what I told it to do, instead of what web page authors tell it to do. For the most part, I'm going to go with the author's decisions, but often I'll tweak and twiddle things. Specifically, the two best examples, in order of importance, are filtering of parts of pages (think, advertisements), and caching pages marked nocache. This isn't some crazy concept, the CSS specs first made the mistake of telling browser writers that webpage stylesheets took precedence over user st
        • by _iris (92554)
          Then go check it out [mozilla.org]. The difference between the FF 3.0 offline application support and web page caching is that FF simply provides a storage model. The applications are responsible for ensuring that they have the information that they need. And, btw, the browsers _can_ get offline browsing right, but you are in very small minority of people who want it. You could always fix that yourself in FF or Konqueror.
      • by Meostro (788797)
        You don't even have to wait.

        Firefox 2.x supports DOM:Storage objects [mozilla.org] that will already let you store arbitrary data client-side, and IE supports something similar with Persistence and DHTML Behaviors [microsoft.com]. If you want the same mechanism for multiple browser types you can do some crazy Flash-based stuff as well.

        Within the browser storage objects there are some limitations as to size, so that could be part of the new versions. But make no mistake: this feature is already a reality. See Ajaxian [ajaxian.com] or Dojo [dojotoolkit.org] for more
        • by CaptnMArk (9003)
          IMO, such things will not really be usable as long as people have to manually do the load/store operations either from web or the local storage.

          This needs to be solved declaratively, by making browser do all the client side work.
          • by Baddas (243852)
            I love the thinking.

            "This needs to be solved declaratively, by making other people figure out how it works and do it for me." :P
      • Re: (Score:3, Funny)

        by kalirion (728907)
        And I bet you'll be able to play online games and download movies offline too!
      • by rjshields (719665) on Tuesday April 10, 2007 @12:31PM (#18677359)
        Man, I can't wait for someone to write an AJAX version of Photoshop that I can use offline. It could be just like the real thing but fifty times slower!
    • by mr_mischief (456295) on Monday April 09, 2007 @11:28PM (#18670871) Journal
      You assume that neither PHP nor Perl are being used to do desktop apps. Perl certainly is. Ruby, Java, Python, and several other languages are being used to do web development, too.

      In particular, it seems a shame to pigeonhole Perl. Using Perl and readily available libraries, one can develop console programs, GUI programs, daemons, or web apps. With Tk, SDL, OpenGL, WxWidgets, curses, GTK, Win32::GUI, or Prima, few languages have as many options for interface libraries last I checked. Just because Perl is very useful for web development doesn't mean it's not useful in other areas.

      In a fun twist, I had to develop an app that worked the same over the web or on a Windows desktop with no net connection and no installation. It's written in PHP and Perl with a little client-side JavaScript and runs an Apache+MySQL instance from CD. So it's a web app, but it doesn't require net access.

      And BTW, ADP (American Data Processing) and similar companies makes a lot of money doing payroll for other companies.
      • In particular, it seems a shame to pigeonhole Perl. Using Perl and readily available libraries, one can develop console programs, GUI programs, daemons, or web apps. With Tk, SDL, OpenGL, WxWidgets, curses, GTK, Win32::GUI, or Prima, few languages have as many options for interface libraries last I checked. Just because Perl is very useful for web development doesn't mean it's not useful in other areas.

        You have to admit, it's pretty cringe-worthy when you discover Frozen Bubble [frozen-bubble.org] was written in Perl.

        • Frozen Bubble (Score:3, Interesting)

          by mr_mischief (456295)
          I haven't played the game. I might try it out, if only to see what's so "cringe-worthy" about it. Is it buggy? Is it just plain annoying? Those things are likely effected by the implementation language very little if at all. I doubt that for a game like Frozen Bubble, using a good dynamic language is any problem. It probably could have been done in Perl, Python, C, Pike, D, C++, or any other language with SDL bindings and been just as good (or just as bad).

          OTOH, the dynamic language Lua is used for much of
    • Re: (Score:3, Informative)

      by The Bungi (221687)
      you don't hire consultants to do payroll for you.

      Actually payroll is one of the most outsourced corporate functions, by far.

    • by tambo (310170) on Tuesday April 10, 2007 @01:34AM (#18671879)
      Then i'm glad i don't rely on ajax apps or anything to get work done. While corporate customers enjoy a level of reliability that the average home user doesn't even dream of...

      True, having your apps - and data - locally stored is very helpful. I'm sensitive to that - every time MS Office insists on using "Office Online" for my help queries, I silently curse up a storm. It's a perfect example; this is a simple function that used to execute immediately.

      But that's only one of a few really key advantages of desktop apps over web apps. I've spent a lot of time [djstein.com] designing a lot of apps (as a pro/am enthusiast), and here are just a few of the very many other reasons for preferring the desktop environment to the web environment:

      • A robust, designer-friendly GUI control set, tightly coupled to a solid visual designer. For me as a developer, this is THE reason why desktop apps kick the digital asses of web apps. Panels, splitters, checkbox lists, picture boxes, tabbed page collections, menu bars, complex ListViews, editable grids, date selections, numeric up/downs, tree view controls, progress bars - all can be installed in a desktop-based form with a single visual-designer mouse click, while AJAX programmers are still struggling to get buttons working. Plus, the desktop versions are much more consistent - there are fewer visual-style-based visibility differences with desktop apps than browser-rendering issues with web apps. Plus they're higher-performing, and much more easily customized. The ease-of-design gap here is astounding.
      • Comparatively few security issues. I am not claiming that desktop apps are more secure than web apps - not in the slightest. Rather, I mean that as a legitimate programmer, I encounter a whole lot more security obstacles in web programming than in desktop programming. I've spent a ridiculous amount of time debugging web-based security issues: code access security; application pools; file and folder permissions; authentication; impersonation; web-interface/database interface problems; web browser security settings; server- and client-based caching foibles; statefulness issues; cookie policies; code signing and security certification; firewalls; badly configured internet security apps like ZoneAlarm... I've tripped over all of 'em in web programming. It can drive you batshit crazy. Desktop programming has orders of magnitude fewer issues.
      • A much wider array of readily accessible APIs and tools. In desktop programming, if I want a hashtable, or a font dialog, or a color picker, or a high-performance timer, or a Rijndael encryption algorithm, or an MD5 has, or a bitmap converter - they're all immediately available and easy to program. Web programming... good luck.
      • Flow layout is stupid. No, seriously. What I mean is: flow layout is fine for reading - desktop publishing, embedded images, all that junk. But it's stupid for a window-based GUI. As a UI designer, I'll take the absolute positioning and "anchoring" models over browser-based flow layouts any day.
      • Easy-as-pie installers. I can add a desktop installer package to a desktop app project with, like, six mouse clicks. The resulting package is fairly small, quite robust, and has few compatibility issues.
      • Easy multithreading. Self-explanatory.
      • Performance. I've coded in DirectX, and I've coded in Java. I'll take DirectX any day.

      Again, those are just a few issues. I can come up with a whole lot more.

      Face it, people. Web programming is absolutely the future... but at present, it's still a toddler. Web 2.0 is the equivalent of a two-year-old: fussy, colicky, prone to outbursts and temper tantrums. And it's still teething, so when it misbehaves, you end up with bite marks.

      I think it'll take a solid six years or so before web programming is as easy as desktop programming. Until then, I'll keep banging out apps for my "antiquated" desktop environment... with ease and a grin.

      - David Stein

      • Coming from someone who was raised as a desktop developer, then became a web developer for 7 years, and is now starting to get back into desktop development... .NET is very cool. But I sure hate the fact that I am so friggin tied, at least in theory, to which POINT RELEASE of .NET the user has installed.

        For most stuff (most stuff I do), the web is the way to go, because I do a lot of data-driven apps. No versioning crap (other than browser, and if you stick with standards you are OK 99% of the time), and
        • by tambo (310170)
          I sure hate the fact that I am so friggin tied, at least in theory, to which POINT RELEASE of .NET the user has installed.

          Agreed. And you know what makes it worse? If your machine doesn't have the right .NET framework, the app doesn't politely tell you... it just friggin' dies. That's stupid.

          ASP.NET has the same problem. I found out the hard way that if you build an ASP.NET 2.0 app and upload it to an ASP.NET 1.1 server, you get a cryptic, misleading error message that distracts you from diagnosing the

      • by VGPowerlord (621254) on Tuesday April 10, 2007 @03:12AM (#18672269)
        Before I start nitpicking, I'm going to point out that I said "Why not just leave the web to things that require the Internet and keep applications on the PC?" in a previous comment [slashdot.org].

        while AJAX programmers are still struggling to get buttons working

        I sincerely hope you mean they're having trouble getting the code behind the button to work, because I'd be extremely worried about the state of web developers today if they can't write <input type="button" value="Text on the button face" onclick="functionCallHere()">
        or a form consisting of only a submit button (if you're making it compatible with browsers that have no scripting or have scripting disabled).

        Performance. I've coded in DirectX, and I've coded in Java. I'll take DirectX any day.

        The term web application is not often applied to Java any more. The term "web app" these days often refers to AJAX (formerly known as DHTML) apps and, less often, Flash apps.

        However, you're right, on the whole desktop apps have better performance than web apps.

        Flow layout is stupid. No, seriously. What I mean is: flow layout is fine for reading - desktop publishing, embedded images, all that junk. But it's stupid for a window-based GUI. As a UI designer, I'll take the absolute positioning and "anchoring" models over browser-based flow layouts any day.
        ...so use absolute positioning [w3.org] instead. You act like it doesn't exist, which, given that you've been using the ASP.NET web designer, doesn't surprise me. While fixed position in CSS is known to not be supported by Internet Explorer 6 and older, absolute position is.

        Which brings up another point not yet mentioned: The sad state of affairs with web application GUIs is almost entirely Microsoft's fault. IE6 and its rather poor support for CSS2 and DOM, which weren't addressed for 6 years, let alone fixed, coupled with its widespread use has made it the lowest common denominator.
        • "The term web application is not often applied to Java any more. The term "web app" these days often refers to AJAX " ...and what do you think is more often than not receiving those asynchronous XMLHttpRequests?
        • Re: (Score:3, Insightful)

          by tambo (310170)
          I'm going to point out that I said "Why not just leave the web to things that require the Internet and keep applications on the PC?" in a previous comment.

          And in response, I'll assert that there are many contexts in which internet apps are better designed as locally installed, robust, high-performance desktop apps than as remotely deployed, hinky, inefficient browser-caged apps.

          The term web application is not often applied to Java any more. The term "web app" these days often refers to AJAX (formerly k

      • Re: (Score:3, Interesting)

        by master_p (608214)
        While you are right, the need for detaching the GUI from the computer the application runs on is not limited to the web. the X-Window system was a step in this direction, and the NewS GUI was a better implementation...but since these technologies are outdated, the world needs a standard for remote UIs that cover all other aspects of GUIs.

        Since this is not gonna happen any time soon (because people don't want to agree - only want to agree to disagree), my company chose the ULC toolkit for Java web apps. It's
      • by Nurgled (63197)

        I agree wholeheartedly with your first point about the GUI control set. It took several years to reach a point where there were nice GUI control libraries and a good component architecture to make it easy to put together a big GUI application without creating a big heap of spaghetti.

        I think that where the web is right now is like where the Amiga's GUI API was in the pre-2.0 days: it had support for windows and the ability to configure regions within those windows to be "gadgets" that can recieve click even

      • by ahsile (187881)

        A much wider array of readily accessible APIs and tools.

        I'm not sure what you've used for web programming... but md5, encryption, image conversion? These are all readily available in almost any language used for web programming.

        Easy-as-pie installers.

        Last time I tried to create an installer for a windows app, it wasn't quite that easy. Especially if you had library dependencies and other necessary support. As for web apps... what's the last one you had to install instead of just navigating to http://my.webapp.com/ [webapp.com] ??

        Easy multithreading.

        To an extent, this is true, but then multithreading is never exact

    • by johnnliu (454880)
      I don't really see the main difference being price.
      I think web apps and window apps are just two different sets of tools. Depending on what you need to do, one is better than the other.

      Let me illustrate.

      I work/blog/play games from three different locations:
      My work; my old home (where my parents are, and I visit twice a week); and my new home.

      I have different computers at each of these locations - and while I do have a laptop, I don't always bring it around with me. Sometimes, I find it a real hassle to sy
  • it's the age old situation. not one tool does every job best. there are still plenty of situations where desktop apps are appropriate. as nifty as web 2.0 apps are, they still aren't as good, in certain situations.
    that there is a demand for disconnected apps is undeniable. all one has to do is look at the disparity between the number of households with computers and the number of households with dial-up or less.
    me, i prefer desktop apps in a number of areas - personal finance, my office suite, games, my
  • by 280Z28 (896335) on Monday April 09, 2007 @10:47PM (#18670531) Homepage
    I prefer desktop development. Web development gets frustrating with its nooks and crannies of brokenness. If standardized Javascript and CSS were as ubiquitous as C/C++/[anything else desktop], that might someday change... but probably not.
  • by ironwill96 (736883) on Monday April 09, 2007 @10:52PM (#18670581) Homepage Journal
    But for some reason I can't stand Web Development at all but *love* desktop applications. My coding of choice is C#.Net or Java and i've written numerous small but useful applications that are in use at my place of employment and a few former jobs. Most of these apps are networked and use client-server interactions, but only on the intranet, not out on the internet.

    I am asked quite often though, "Well why don't we just stick this on a web page and then we can get it from everywhere!" and I usually demur some and note that we dont need it to when anyone on the intranet can get to it anyway and there is no reason for some of these apps (or data) to be accessible outside of the corporate intranet.

    For some reason, I just don't like ASP.Net or PHP or JavaScript, i've written small interactive web things in them, but it takes me way longer to accomplish something useful on a website than it does doing a desktop application. I suppose this probably has to do entirely with familiarity, but I also hate how slow websites typically are when you do something overly graphical or complex, whereas it runs great on the desktop application locally.
    • by kherr (602366) <`kevin' `at' `puppethead.com'> on Monday April 09, 2007 @11:03PM (#18670693) Homepage
      This web app stuff is a fad (I hope). It was really popular in the late 1990s as well. Eventually the weight of developing in the unreliable and limiting multi-purpose browser gets to be too much, and desktop apps come back into vogue. Ajax makes things a lot nicer than ten years ago, but people expect more as well. Some things can be done really well using Ajax but it's not the solution for everything.

      iTunes is a dedicated desktop app that uses internet data intelligently, but Apple made a good choice not depending on a browser. Compare Google Maps to Google Earth, which is more responsive and flexible? And then there's the comparison of something like QuickTime or Windows Media players and the pseudo video players written in Flash with bad control responsiveness and limited functionality.
      • Re: (Score:3, Insightful)

        by Mike1024 (184871)
        Compare Google Maps to Google Earth, which is more responsive and flexible?

        I prefer online maps; they work better for me.

        For example, did you know windows live maps includes a bird's eye view [live.com] feature?

        In the world of desktop software, here's how that would have worked: I'd have turned my map view into some sort of file, found web space, uploaded it, and posted a link to it. You would have downloaded the file and been told 'unknown file type', you'd have to go to Microsoft's web page and download 'Microsoft 3
    • by The Bungi (221687) <thebungi@gmail.com> on Tuesday April 10, 2007 @12:52AM (#18671591) Homepage
      It's just a different paradigm and mindset. They both have their unique advantages and shortcomings. Get a good IDE, a good framework and some Dr. Pepper and you can probably pull it off once you "grok" the shifts.

      Having said that, a web application will never have the level of control that a forms-based one has, no matter how fancy your JavaScript is. Truth is, the browser is a crappy platform no matter how you look at it. The web illuminati proclaimed the desktop dead ten years ago and now again on the tails of GMail and the half million good and bad "rich" applications developed apparently for the specific purpose of showcasing how utterly screwed up the browser as a platform is.

      But if you work for a living you probably have to go with the flow, so "Ajax" it is until the next fad comes around. Personally I think Java/.NET/Mono and the like with a good forms front end and a really powerful matching backend infrastructure is going to be the next big thing along with XCOPY deployment and zero impact installs. CPUs and memory are catching up to managed frameworks and writing a web service (or a client) is laughably simple now (I remember hand-coding my WSDL and walking in the snow uphill both ways, etc).

      In any case, the fun part is being int he middle of it all =)

      • by tambo (310170)
        I think Java/.NET/Mono and the like with a good forms front end and a really powerful matching backend infrastructure is going to be the next big thing along with XCOPY deployment and zero impact installs.

        Completely agreed. I'm currently manning a six-person team on a moderately complex web programming task, and I'm insistent on using ASP.NET 2.0, because it's the least crappy option. (But it's still a whole lot of suckiness.)

        I firmly believe that web programming will catch up and surpass desktop progra

    • by Tadrith (557354)
      Nope, I agree with you completely.

      I started out working with the desktop, and to this day, I still despise working on web applications. Admittedly, a lot of this is because I have less experience with web applications, and so when users ask for desktop-style features on a web applications, I tend to get very frustrated. I'm not saying web development is bad, it is definitely useful and there are many skilled web developers. I just prefer to keep to the desktop.

      Most of my work lies in databases, mostly custo
    • Re: (Score:2, Insightful)

      by tambo (310170)
      I just don't like ASP.Net or PHP or JavaScript, i've written small interactive web things in them, but it takes me way longer to accomplish something useful on a website than it does doing a desktop application.

      Bingo. It's not just you, and it's not just your imagination. Programming basic web functionality is ten times harder, more time-consuming, more error-prone, and less rewarding than desktop programming. There's no comparison. I posted a few of the many reasons above.

      - David Stein

  • and I love doing both, as long as I have decent tools to do either with.

    For example, I have done desktop development for over 10 years, I am more experienced at it and easier to make a usable UI. Drawbacks: harder to build and test, but easier to step debug - unfortunately, my current employer has a MESS of a desktop app full of .NET front ends and legacy C++ backends in a mix of multiple versions of MFC and .NET - argh - which makes it unbearable at times, but only on the app I currently work on.

    Web
  • by TodMinuit (1026042) <todminuit@gPARISmail.com minus city> on Monday April 09, 2007 @11:02PM (#18670665)
    No, really, they do. They like solving problems. Having to implement the solution is the boring part, no matter how it's going to be done.
    • by bzipitidoo (647217) <bzipitidoo@yahoo.com> on Tuesday April 10, 2007 @12:17AM (#18671357) Journal

      It's not even developing apps anymore. It's assembling apps from bits of prefab code. The kicker is that only some of it is good quality and can be picked up and mastered quickly.

      These days, coding is grabbing some barely begun project that does just enough that you feel it's better to add to it than start fresh, using code generators (SWIG, yacc/lexx or Antlr, and doesn't VB have some wretched auto generated window manipulation stuff? etc.) then spending time ferreting out and fixing subtly broken bits or wondering if you missed some little detail about how to properly use the tools. Then maybe get another piece or two by running some Fortran source code thru f2c, call functions from lots of different libraries, grab some modules off cpan, try to realize the advanatages of OOP by reusing other people's classes, search Sourceforge again for yet more pieces, glue the crap together with shell scripts, and try to avoid dallying in makefile hell by dallying instead in automatic makefile generation hell. Constantly search the Internet for this and that error message.

      And that's just "development". Then there's all kinds of support stuff to figure out. Wrestle with your choice of source repository be that cvs, subversion, rcs, or whatever, figure out what to set to what in the environment on stuff like Java's CLASSPATH, muck about with this and that IDE and try to get the compiler and debugger to talk nicely to it or live with vi when you get tired of trying to figure out why you're not having any luck getting X to tunnel through ssh. Either way figure out how to twiddle the colors for the syntax highlighting or squint to make out those letters that were displayed in dark blue on a black background. Bone up on emacs to figure out how to get it to stop replacing backspace with ctrl-h, and binding ctrl-h to the help when being used remotely. Repeat "./configure;make;make install a library or 2, discover they depend on yet other libraries" until "all dependencies satisfied or you run up against some missing or broken piece and will have to search for alternatives." And still you're not done. How about Valgrind? Profiling? Maybe some kind of package to automate testing? Automated backups of the work? And you're never really done-- there are always upgrades, and there's always deciding when the tradeoff of having to redo your environment is worth the bug fixes, new features, and so on.

      Life was so much simpler when they were teaching that bubble sort in the beginning C class, wasn't it?

  • by Mongoose Disciple (722373) on Monday April 09, 2007 @11:03PM (#18670681)
    You're never going to get the performance on the web (for most things) that you can running locally. Equally, while tools and frameworks for faking it have gotten a lot better, maintaining state is a pain in the ass on the web and generally is not on the desktop.

    It's like when Java came out and some people said we'd never write C again. There are things Java is good for and has taken over, just as there are things web apps are good for and has taken over, but there is still a place for desktop apps just as there is still a place for C.

    The kind of bold, sweeping statements made by this article aren't much more than flamebait in a pretty dress.
    • Quote: "Maintaining state is a pain in the ass on the web and generally is not on the desktop."

      You must not have heard of libraries like echo2 or Wt for doing web development. They have the same API as desktop GUI libraries.
      • Re: (Score:3, Informative)

        I'm familiar. They do simplify state maintenance to a point and are appropriate for a lot of different things you could do with a web app, but I think you're kidding yourself if you don't think there isn't extra thought/work involved there and some extra performance concerns that you wouldn't need to have with an equivalent desktop app.
  • by MBCook (132727) <foobarsoft@foobarsoft.com> on Monday April 09, 2007 @11:08PM (#18670723) Homepage

    I develop two things for a living. I work on a server back-end, and on the web front-end. The back end is easy. It's all Java, it's fun to develop for (there is challenge in some things, for example).

    Then there are tons of front-end things I do. I hate them. It's developing the same code OVER and OVER (since we basically make copies of some parts to be used numerous times) and the glue code always has to go in there and is a pain. Then there is the scripting. Besides making things display right (which is a pain across numerous browsers), there is the functionality. "We want a select all checkbox." "When you update this date, it should update that date, unless this date is before than date except when...". Javascript is HIDEOUS. Can we just replace it with Python or Java even PHP?

    Our problems are all user based. The users want it to work like a desktop application, but want it to be web based. It should respond fast and do all this checking and such, but it can't be a real application. You should be able to move forward and backwards without things going weird (can be tough to do in the stateless-ness of the web) but it can't be a real application.

    We want an application, but we want it to be web based. We want it fast, but it must be made in HTML and Javascript. Blah blah blah.

    I would LOVE to do more desktop applications. I wish I could.

    I wish users would get over this stupid "lets put everything on the web" stuff. There is a fair amount of what we do that I can see being web based (like most of the reporting type stuff external users use). But all the management stuff we use in house would be a much better fit to a real application than the web applications we are using now.

    Please, PLEASE.... bring desktop applications into vogue. Java allows right-once-run-anywhere to just as high a degree as HTML/JavaScrpit, if not more. Takes less bandwidth. Can run much faster. Can do client side stuff easier.

    • by TodMinuit (1026042) <todminuit@gPARISmail.com minus city> on Monday April 09, 2007 @11:41PM (#18671021)
      (since we basically make copies of some parts to be used numerous times)

      You don't copy code: You generalize it into a function.
    • by tepples (727027)

      Please, PLEASE.... bring desktop applications into vogue. Java allows right-once-run-anywhere to just as high a degree as HTML/JavaScrpit, if not more. Takes less bandwidth. Can run much faster. Can do client side stuff easier.
      So why don't you develop your programs for the Java platform and deploy them as applets or as Java Web Start packages [sun.com]?
      • I do really wish that these methods had become more popular. Cross platform desktop applications with no installation required and automatic updatablility are nice.

        Of course Java Applets were a bit slow and bloated for the old Pentium 200MHz and the like back in the day. Even now, it is a bit heavier than what would be necessary in a browser, though some sort of standard sandboxed runtime built in would be good.

        Java Web Start would've probably taken off if client side Java were just a bit better (mostly n
    • by Jim Hall (2985) on Tuesday April 10, 2007 @11:24AM (#18676163) Homepage

      I wish users would get over this stupid "lets put everything on the web" stuff. There is a fair amount of what we do that I can see being web based (like most of the reporting type stuff external users use). But all the management stuff we use in house would be a much better fit to a real application than the web applications we are using now.

      Please, PLEASE.... bring desktop applications into vogue. Java allows right-once-run-anywhere to just as high a degree as HTML/JavaScrpit, if not more. Takes less bandwidth. Can run much faster. Can do client side stuff easier.

      Trust me, just wait a little while, and desktop applications will be all the rage again. If you've been in the computer business long enough, you've seen the shift from "timeshare" server, to the desktop, back to server (thin client), back to desktop, back to server (Java), back to desktop, back to server (web applications / ajax, web 2.0). It's only a matter of time until the pendulum swings back to desktop.

  • by VGPowerlord (621254) on Monday April 09, 2007 @11:10PM (#18670733)

    Web apps are great, except...:

    1. When the connection goes down, or even lags, it can have an impact on the speed you're working on.
    2. Implementations for CSS vary wildly.
    3. We aren't using dumb terminals. Web Apps, almost by definition, use an interpreted language embedded into the web browser. Compiled applications (or even ones that use bytecode) will perform faster than this and without the latency that the web introduces when you change pages.

    Why not just leave the web to things that require the Internet and keep applications on the PC?

    • by Baby Duck (176251) on Monday April 09, 2007 @11:54PM (#18671149) Homepage
      Why not just leave the web to things that require the Internet and keep applications on the PC?

      Because DOWNLOAD and INSTALL are two words that make too many users pass out upon hearing them uttered. If an IT Department is doing both of these tasks on their behalf, they too faint when they have 1,000+ users.

      Do you have the right OS? Right version? The right drivers? Is your antivirus interfering? Is your Registry befuddled?

      It's much easier to answer these questions once -- for the browser software -- and be done. Need to upgrade? NO PROBLEM! Upgrade on the servers only and we're off.

      Now I'm sure EVERY ONE of my above arguments can be refuted, drowned with "gotchyas", banged with exceptions, and slammed with a "not exactly" or two. But I'm not the one that needs convincing. Convince management, cuz they are brainwashed that all my above points are Irrefutable Law of Common Wisdom. It's an uphill battle to show them otherwise. They are completely sold on the Browser as Platform concept. And that's where their pocketbooks go. So that's where commercial dev shops go.

      I'm not saying webapps are without any merit, but, yes, people tend to go overboard and shove a square peg in a round hole.

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Because DOWNLOAD and INSTALL are two words that make too many users pass out upon hearing them uttered. If an IT Department is doing both of these tasks on their behalf, they too faint when they have 1,000+ users.

        And they don't faint when they get 1000+ calls asking if the network is down, and why can't they open their Power Points, and howcome they can't access their files at home even though they have installed the Internet on their hard drives...

        Do you have the right OS? Right version? The right driver

      • Do you have the right OS? Right version? The right drivers? Is your antivirus interfering? Is your Registry befuddled?

        It's funny, I've been writing software for decades, much of it "serious" desktop applications, and nothing I've written has ever broken because of any of the above. You'd almost think this was just an urban legend that had caught on with management/consultants, which can be addressed simply by writing desktop software that doesn't suck, wouldn't you?

        But you're right: as long as it has

    • Before someone else points this out, point 1 should read "When the connection goes down, or even lags, it can have an impact on the document you're working on."
  • by jackb_guppy (204733) on Monday April 09, 2007 @11:33PM (#18670931)
    Real Men code GREEN SCREEN!

    It runs faster! It is more secure!
    • Re: (Score:2, Interesting)

      by Door in Cart (940474)

      Real Men code GREEN SCREEN!

      It runs faster! It is more secure!

      Let me guess, you use Windows. You probably wouldn't find such a thought to be so laughable if you'd ever invested the time to learn some basic *nix. Not only are text-mode apps (way) faster and (way) more secure, but they tend to excel in quite a few other places where web apps fail, to name a few:

      • configurablity
      • inter-application communication
      • extensibility
      • versioning
      • standardized documentation system

      These essential features are lacking from web apps chiefly because http and html were designed for sta

    • And then it gets edited out for the final version anyway, to be replaced by computer-generated special effects! :-)

  • The question is, since web apps were originally built on desktop applications themselves

    Say what huh? That doesn't even make sense.

  • by Nedry57 (951108) on Monday April 09, 2007 @11:52PM (#18671123)
    For two primary reasons: 1) Installers. Writing installers sucks. The MSI "standard" is a bloated piece of crap, Installshield and Wise are ridiculously hard to get along with, and NSIS is a little too primitive (although by far the best installer platform I've found). You have to test the installer on every platform, ending up with stupid little quirks on Vista and x64 platforms. It's a nightmare, and patching/updating is a whole different nightmare. In the real world, there's no such thing as simple XCOPY deployment. At least for shrinkwrapped apps. 2) COM Interop. The Win32 API and COM combined is the crappiest piece of crap that ever crapped. I have nightmares about being forced to use Interop because they left out some trivial and silly thing from a WinForms control. I am speaking quite literally in saying that I have had nightmares. Seriously. I know, I know, working in Linux probably makes both of these problems more tolerable, if not completely invisible. But some of us must work in Windows. C'est la vie. I would take ASP.NET, or PHP, or Ruby, or Python, or any of those over crappy desktop Windows programming any day of the week. I'll even accept multiple-obscure-browser testing over COM Interop and installers.
    • Re: (Score:2, Insightful)

      by xero314 (722674)

      1) Installers. Writing installers sucks.

      What is this installer thing you are talking about? You mean on some OSes you can't just copy the package containing the executable into the location you want and execute it from there?

      and patching/updating is a whole different nightmare.

      Again, don't you just copy the new version over the old version and execute? Sure you could write an updater, but once that is done what is the big nightmare.

      2) COM Interop.

      Huh?

      crappy desktop Windows programming

      Oh I get it, you hate Windows Programing. You do realize you can write windows applications without the need for COM or an Installer right? Or at least you c

    • by hyfe (641811)

      It's a nightmare, and patching/updating is a whole different nightmare.

      A ridicilously cheap, easy and not to mention; stupid way to autoupdate software on windows is to just to have your programs/binaries in a subversion repository and have a seperate startup program which runs 'svn up' on the catalog before starting the real program. Include subversion in the installer and it's totally self-contained too.

      It's not the most elegant solution, but it's damn easy and it works.

    • From reading the answers, I think the true statement is that people hate developing desktop apps for Windows.

      The crufty GUI code, the horrible installers, the COM string and duct tape, the .NET version hell, all that stuff is specific to Windows development.

      Mac OS X application development is almost a pleasure in comparison. Even Java and Swing is nicer.

      Having done Windows, OS X, Java and web app development, I'd definitely pick Windows as my least favorite. But I'd take OS X or Java over web app developmen
  • Microsoft being dead is not equivalent to saying desktop apps are dead. Sure, Graham is making a case that Web 2.0 is great, but he's not saying that it is going to completely replace the desktop. What he is saying is that Microsoft is no longer the monopoly that instills fear in all other technology companies. This is true, and is a very different statement from "desktop development is dead".

    But alas, I'm not new here. I expect this kind of misleading headline. Just thought I'd clarify for all those who ha
  • by WoTG (610710) on Tuesday April 10, 2007 @12:42AM (#18671529) Homepage Journal
    If it's technically possible to choose either a web based app or a desktop app, I would pick the web every time.

    Tech support sucks big time. It's far, far, far easier to maintain, upgrade, distribute a web application than it is to manage a desktop application. A couple major web browsers and a couple major plugins pretty much covers every testing and support situation that you will face -- especially for intranet type situations.

    For desktop situations there are a million variables: installers, bugs, spyware, permissions, operating systems and versions of OSs, non-existent user backups, differing service pack and patch levels... the list goes on. Most of these really aren't your problem as a software developer or publisher, but in reality, they often become your problem. That's in addition to the nightmare of supporting different versions of your program.

    If the web can be applied to a situation, there should be no surprise that people will develop for the web.
    • Re: (Score:3, Insightful)

      So why not build the apps as client-server? You avoid the headaches of browser implementations, and you retain the maintainability of centralised apps. It's faster/more-responsive than browser-based web systems, and easier on the clients than a full desktop app. I think internet connected or distributed apps are great, but I also think "web" based desktop apps are layer upon layer of kludge to make a display medium behave like an application.

  • The truth is the desktop some real killer apps have to be released to want to give programmers inspiration IMHO. I'm sure there are many "killer apps" just waiting in the wings until computational power gets there. I have a shit tonne of ideas for great desktop programmes in my head that I've put part of the design to paper already but much of it has to wait because the time and expertise requires is a huge undertaking.

    I also have a tonne of desktop software I would love to use if it was more advanced and
  • by ddent (166525) on Tuesday April 10, 2007 @02:54AM (#18672207) Homepage
    I _greatly_ prefer doing web apps. Great things about web apps:
    • No mucking around with ugly GUI code
    • Easy to use: the interface limitations can be a good thing sometimes
    • Easy to deploy
    • Cross platform support, if you are careful, comes for free
    • Security: less data stored on often compromised desktop systems


    Perhaps it has to do with familiarity, but from my perspective, doing desktop applications (especially by the time you deal with all the extra support & deployment issues) is a real pain.

    However, I will say that many people I work with do not share my enthusiasm for web apps. There is a huge technology stack to learn when you need to deal with the chain of technologies involved from the server to the desktop. All the quirks of different browsers take some getting used to, and it requires a different mindset. It also requires you hold the belief that a website can be an application, which, amazingly, many still do not have.

    With all that said, there are still some things which are more suitably done as desktop applications. I think as things advance that list gets shorter and shorter.
  • The short version of the reason is "scripts versus compiled code".

    The long version:

    * Web applications are developed interactively. You fix a typo, you hit reload, you see the results immediately. The interactive-versus-batch debate should have been over by 1980, but we still see dektop apps written almost completely in compiled languages that require a huge clumsy IDE.

    * The part that runs in the browser is visible to the users, so when they are technically competant they can give you detailed feedback.

    * It'
  • Note: An expanded version of this reply appears as an article on my blog [paul-robinson.us] and you can also read more there. Because Slashdot only allows shorter titles, the title of the article there is "The Rumors of Microsoft's death are clearly exaggerated."

    First, on the issue of Linux vs Windows (for the title of this article): Windows sells more because Microsoft got there first, there is tremendous inertia, plus, until recently, there wasn't that much available that wasn't an application running on Microsoft softw

  • by wonkavader (605434) on Tuesday April 10, 2007 @09:51AM (#18674631)
    I'm seeing a lot of text being written here about how desktop apps are wonderful and webapps are crap, or a fad, or difficult, or slow.

    Web apps are not desktop apps. They are different. You have different reasons for writing a desktop app than you do for a web app. Web 2.0 interfaces may be a fad, may be painful to write, etc., but webapps as an entire class just don't fit that bill.

    Write once, deploy instantly over an entire organization. Write in the environment you like, and yet the whole org doesn't know you wrote it as a wrapper over a bunch of perl scripts you use as command-line apps. Write something using one database connection (where that's a legal option), and thus, write cheaply. Write using a simple interface with fairly low expectations, so that anyone can use it without training (unless you do a VERY BAD JOB INDEED), it takes minutes instead of hours to write, and can work on every single machine of any sort in the org.

    Folks, web apps are the best thing since sliced bread.

    Desktop apps are a BITCH. As a linux guy, they mean I have to work under windows. That's a showstopper, right there. As a desktop support nightmare, they're immense. They mean you have to standardize on a version of windows in the org, have to have minimum requirements, have to compete with viruses, self-destructing OS installs, etc. Meanwhile your design phase gets much longer, because expectations are higher.

    Yes, complex apps often work much better as standalone. Yes, interface design for them is much more complicated, and thus can be more rewarding. But most companies need VERY FEW of these. Web apps are a much better choice for a huge amount of what most companies do. And as programmers, they allow us to maximize our impact on the productivity of the org. Where you can use web apps, you should. For programmer productivity, LAN supportability, and speed of delivery, it's like night and day.
  • We, the developers of the world, are in a bad situation right now. The ideal application is a zero-deployment cross-platform GUI application. Writing such an application depends on an already deployed cross-platform framework. The problem is that the dominant platform for doing this is a cobbled together load of crap.

    Which of the following is the _best_ environment to develop a zero-deployment cross-platform GUI application?
    1) Java applet/Java web start
    2) .NET
    3) HTML+CSS+Javascript+HTTP+SOAP+XML+(Python|
  • middle ground (Score:3, Interesting)

    by fred fleenblat (463628) on Tuesday April 10, 2007 @02:39PM (#18679637) Homepage
    At a previous employer, we experimented with a very thin desktop GUI. It used the host OS to display widgets but was entirely under control of a server. It worked remarkably well and as long as the client and server were on the same LAN there was no lag.

    From my hazy memory, it had these successes:
    * a crashed app (which was rare anyway) could be restarted right where it left off
    * clicking, drag/drop, typing, copy/paste, scrolling, and resizing were as fast as the host OS was capable of since most of the time these didn't involve the server
    * very little installation headaches since there was no business logic, databases, or special-case code on the client side, and the set of available widgets didn't change that often anyway
    * new servers could be tested by just pointing the client at them
    * server could be upgraded at our convenience
    * one server could handle dozens of users and the load was much lower than citrix, RDP, or X11 type of model since the whole GUI stack was offloaded to the client not just the final bit slinging
    * protocol wasn't that complex. "this widget with this data goes here" then "send a message when the user finishes doing things with it"
    * multiple windows could be open and be unrelated, so a server could make it look like you were running multiple apps even though it was just one GUI process and one server process
    * response over slow network wasn't that bad. the most back-and-forth communication mostly happened at points in the app where users expected things to be slow, like when you click on "Okay" or select "New..." from a menu so we didn't get many complaints.

    Okay, obviously we didn't invent this, but other attempts always seemed hobbled somehow. ActiveX and java applets are visually sandboxed and have a tough time breaking out into looking like a real app. Firefox had some experimental widgets that were actually pretty cool but in actual use they were laid out on the page in a very HTML-ish fashion and later withdrawn for security concerns.

    Anyway, I just want to share this as kind of compromise between desktop and html-based apps that seemed to work particularly well for us.

Facts are stubborn, but statistics are more pliable.

Working...