Slashdot Mirror
People Don't Hate to Make Desktop Apps, Do They?
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?"
Desktop programming is so nineties. I'm a laptop programmer!
Be relentless!
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.
Is it sad that I am more likely to recognize you and your posts by your sig than your name or UID?
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.
Turning coffee into code.
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.
"To strive, to seek, to find, and not to yield." - Tennyson
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.
I wonder if I use bold in my signature, people will notice my posts.
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.
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.
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
Web apps are great, except...:
Why not just leave the web to things that require the Internet and keep applications on the PC?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
Wait for Firefox 3.0. Soon you'll be able to use your web apps, even if you're connected at 0 Mbps.
http://news.com.com/2100-7345_3-6163015.html
Channel Zilch: In Your Face From Outer Space!
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.
Real Men code GREEN SCREEN!
It runs faster! It is more secure!
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.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
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.
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.
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, availability of mature frameworks is the decisive point when it comes to enterprise-level development. As a junior developer in my company my requests to change frameworks (or at least, conform to the rules of the one we use). Web development, or at least the variant I've seen 'here' (at my work place), almost forces you to work correctly (don't think I haven't encountered terrible code that broke all conventions as well). I could be wrong (again, little experience with these things), but from what I've seen so far, if I'm stuck with UI development, I'd prefer the web over desktop.
When in danger or in doubt, run in circles, scream and shout [Robert Heinlein]
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.
SSL Certificate
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.
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).
"Slashdot - News and Chat Sites Deviant". (Click "homepage" link above for details).
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.
From reading the answers, I think the true statement is that people hate developing desktop apps for Windows.
.NET version hell, all that stuff is specific to Windows development.
The crufty GUI code, the horrible installers, the COM string and duct tape, the
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 development any day.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
You have to admit, it's pretty cringe-worthy when you discover Frozen Bubble was written in Perl.
I Browse at +4 Flamebait
Open Source Sysadmin
As an owner of a Treo 700w, 2 Cingular 2125s and an 8125 (HTC Tornado and Wizard), and as an engineer for products based on these platforms, I disagree.
...
The only point to mobile apps is connectivity. Text messaging? Check. Email? Check. Media sharing? Check. Sure, I can write a Word doc on my Pocket PC phones, or on a Smartphone with a Bluetooth keyboard (I'm not out to grow Asian SMS thumbs) but do I WANT to? Will I do so in anything but the most desperate scenario? No, I'm going to do it on my laptop or desktop. Am I going to do Photoshop work on a 2.5" diagonal screen? Heck no! Am I going to write software ON my phone? Probably not, though I have edited HTML and ASP from a Pocket PC phone before. Yes, I maintain a list of contacts and calendar events, but only for purposes of keeping myself in sync at home and at work -- without a desktop or laptop flashing up an event notice in front of me, I'd miss half my meetings. Yes, having that schedule available to me on the road has value, but again, not without integration with less-mobile platforms.
One product I engineered is, essentially, a self-contained web cam. No electrical requirements (battery/solar powered) not hard line to a network (GPRS driven). Take a picture, send it to the server. All the interaction on the client's part is with the server, not their deployed camera, and from their own desktop or laptop (though yes, there has been some talk of making the camera viewing/controlling app mobile-friendly). All in all, however, you're never going to have serious clientside applications doing much of ANYTHING on something with a 2.5" screen. Now, if I could easily run screen output to a real monitor, that's a different story
I am, therefore you think.
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 Supreme Commander. SC is known as a great game, but one must wonder if using Lua for the AI is part of the reason it takes so much processor to run it. The game is fun, but due to the number of individual units that can be active at once it can run like a dog on all but multi-core systems. Using a more efficient language for the AI may have made it scale a bit better, but the flexibility of using something like Lua I'm sure is worth the trade-offs involved. The hardware will catch up shortly, as with lots of other games when they were first released. It's nice to see one stress the CPU instead of the GPU for once, anyway.
People often get stuck in a false dichotomy when choosing between a web and desktop app.
The simple answer is to use the web version for what it's good for (centralized updates, rapid development) and the desktop version for what it's good for (performance, offline access).
Some apps run a local webserver on a non-standard port (Yahoo Music Engine) to create a hybrid model. Javascript/HTML can be a very effective rapid prototyping tool.
For instacalc, I have an online version and downloadable gadgets to fill this need. I use both thunderbird (fast access to mail, offline access) and gmail (access from any computer) to read my email. The "secret" is letting a web app be a web app, and a desktop app be a desktop app. Use the right tool for the job.
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.
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.
The problem, yet again, is that "getting close to the simpler end of Photoshop" is saying that the TEXTAREA box in Firefox can compete with Indesign and solve all you typesetting needs.
In a word, no.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism