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?"
Unfortunately, my company (and many many other large multi-nationals) *do* hire outside consulting companies to do payroll.
Wait for Firefox 3.0. Soon you'll be able to use your web apps, even if you're connected at 0 Mbps.
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 =)
Mod this and its parent post up. It's so true. Unless you're in research or embedded devices (or maybe in Google), we (typical programmers) *assemble* applications. All that fancy education getting engineering degrees, just to do some assembling. We're equivalent of the car plant assembly workers of the bygone era. With no Union.
Nobody wants to use web-apps. There is only one reason why this abomination is artificially hyped again and again: Open Source.
No, really, you cannot sell standard software very good anymore. It gets more and more ridiculous to spend hundreds of bucks on something like Word, Excel, or even Photoshop if you can get similar programs for free. Even if you say that those replacements are not as good as the original, which I doubt, they are getting better and better. So what do you do if you are a mega-corp, which made most of its money from standard software?
You are starting your marketing machinery to tell the people that they need something you can provide, your open source competition cannot. Web based apps sound fine, for the provider. They need a big and expensive infrastructure of servers, which hardly can be provided even by large open source projects. They are the wet dream of every marketing person, being able to charge per use. Being able to get detailed using statistics and spamming you with ads. For the more criminal (more usual?) ones, I would take it as given, that they snoop through your content if this is technically feasible. Web based apps are technically inferior? Nothing a good marketing can fix....or perhaps it cannot. People are stupid, but it seems that they are not that stupid.
So, tell me one, just one advantage of web based apps, for the average user. Desktops apps are out? Yeah, right, and nobody needs more than 640K ever.
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:
- standardized documentation system
These essential features are lacking from web apps chiefly because http and html were designed for static hypertext. Yet the layout and design capabilities of css allows web apps to succeed in one way that is wholly inapplicable to text-mode apps: web apps can look good. And in our visually oriented wysiwyg culture, that means a lot. But while laughing at text-mode advocacy might build your karma, I urge you to bear in mind that you would likely prefer text-mode if you took the time to become accustomed to it, lest you mistake maturity for antiquation.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 a short of middle ground between X-Windows and web applications: the GUI is served by Swing, but the underlying widgets' callbacks are executed on a server. Development is similar for native Swing apps, and the Eclipse plug in also has a visual designer. The toolkit is commercial though...
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.
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.