|
Future of desktop development
I pay the bills by working on a monolithic commercial desktop application. This is a constant point of contention as I felt that the world, at least by now, would be moving toward thin client/server based architectures.
In fact I was so convinced of it, that years ago, I moved 2000 miles to the middle of nowhere to work on a citrix like thin client system. I chose my current job for the location and domain over the technology choice.
I think the migration is slowly happening. I do all my email either in squirrel mail or yahoo. I filed my taxes online with turbo tax. Salesforce.com is making it with a server based CRM model.
I wonder if the longhorn desktop is really going to complete my vision. Applications will get thinner and server driven, with Microsoft's blessing.
Tonight this topic came up. I claim that frameworks like MFC are a thing of the past. Future frameworks will have a significant server component to them. I used Zope as an example. I also argued that for modern applications like iTunes that there is a significant server side that doesn't fit neatly into the desktop model. Autodesk's buzzsaw is another example of merging desktop and server components.
I hope that the days of the monolithic desktop application are finally numbered and we will see more server-based, on demand applications. What do you all think?
christopher baus (www.baus.net)
Friday, May 21, 2004
I can see web based applications becoming the norm for most form based applications. You may find this interesting reading too: http://www.paulgraham.com/road.html
Matthew Lock
Friday, May 21, 2004
I look forward to doing all my video editing and audio production through a web interface.
Tony Chang
Friday, May 21, 2004
You probably won't be doing any video editing online in a hurry, but you may well buy and view your videos online, in a video type of itunes, or share your videos online in a video wiki.
Matthew Lock
Friday, May 21, 2004
> I look forward to doing all my video editing and audio production through a web interface.
This is the exact argument I got. I think that line between desktop based and server based is content creation vs content consumption. Photoshop: creation. Web Browser: consumption.
Although I prefer to edit my blog directly from the server. I would be nice if the edit control was more feature rich, but I still prefer it to be server based.
What I would like from video editing and audio tools is direct publish and collaboration to the network. Much like Buzzsaw.
christopher baus (www.baus.net)
Friday, May 21, 2004
My personal observation is that web apps are generally several times more difficult to develop than desktop ones of the same functionality. There aren't hell of a lot of cases where this additional effort can be justified from the business standpoint.
Egor
Friday, May 21, 2004
For those that think that thin client uber alles, you had best become strong, very strong advocates of SLA's and five nines reliability for both intranets and ISP's.
I think you're talking 5-10 years before you even have the infrastructure in place.
Just a thought.
Philo
Philo
Friday, May 21, 2004
If our lan or even internet connection goes down there is virtually no business being done away. We have fat clients that all connect to databases.
Think of google. How much business would they lose if they went down for even 2 hours? But they don't go down.
christopher baus (www.baus.net)
Friday, May 21, 2004
MFC is a very old framework. It is primitive, and has low productivity.
Examples of high productivity component libraries, a lot more productive than MFC:
- .NET WinForms
- Delphi's VCL
Web application development still has a long way to go in order to become as efficient as desktop application development.
Developing desktop applications simply is a lot faster.
Also, web applications can't have very rich user interfaces like desktop applications can.
The thin client, or "everything will be a web site" ideas are just HYPE left over from the dot-net boom.
In the future, some of the apps will indeed be web based, but serious application will still run on the desktop.
Desktop applications have several advantages over web applications:
- they can have rich user interfaces
- you can develop a desktop application much faster than you can develop a web application (of course, this happens if you use the right tools - if you choose MFC, then it's no wonder that you develop slowly)
- desktop applications are not affected by network and server down times
Gemix
Friday, May 21, 2004
At somepoint the toolkit isn't really the limiting factor of productivity. Certain small applications can be knocked out quickly with something that offers more functionality than MFC, I think, but in the end I don't think that is our limiting factor to productivity.
To give you some idea of the scope of the application. It is about 5 years old and contains over 300k lines of C++ code.
For instance a full charting engine:
http://www.styleadvisor.com/products/styleadvisor/graph_editing.html
And custom workbook manipulation:
http://www.styleadvisor.com/products/styleadvisor/page_design.html
I could be wrong, but my guess, in what I would now consider a rather large application, MFC really isn't buying us ALL that much. In someways I think it gets in the way.
There no doubt will always be desktop apps like this, but will there be a framework for creating these types of apps? I'm not sure. Those of us that work in this niche might be using QT and/or MFC for a long time.
What is the plan for WinForms? I'm confused by Microsoft's longhorn strategy. What is the status of XAML for instance?
christopher baus (www.baus.net)
Friday, May 21, 2004
The arguments about Web Apps vs Desktop Apps miss the point. Nobody is saying that web apps will totally replace desktop apps.
Web applications are for businesses that want to supply a service but not have to have people download applications to run it. Like this board and Joel's articles for instance. Joel created these to attract visitors so he could publicize his products.
Matthew Lock
Friday, May 21, 2004
As for rich user interfaces, if you really want to you can make quite decent interfaces using javascript. Check these out for example:
http://www.tcpiq.com/tcpiq/HTMLRichTextArea/Default.asp
http://rte.webwizguide.info/
Matthew Lock
Friday, May 21, 2004
Its not all thin client, fat slobbering server models, the best ones are where the servers are as skinny as the client, there's just a lot of them, all doing different things.
And clients that use stateless services and protocols such as HTTP will always be a pain for the user, the developer and whoever's responsible for the PTT.
We need more graceful ways of handling disconnections, we need fake local interfaces that let the client know that the universe is disappeared but that they're safe, warm and protected until the universe wakes up again.
Simon Lucy
Friday, May 21, 2004
Christopher,
Why do you feel so strong about putting all the beef in the server? What would be the benefits? Since there are many possible answers to this question, it is not obvious which position you hold.
Just me (Sir to you)
Friday, May 21, 2004
For the past year or so, I've been steadily converting my home network over to this model...
I have a Samba shared called (amazingly enough) "sharedapps". Within it, I have numerous (mostly java-based) apps that I need to function on a daily basis.
Then, on my box and my wife's box, this driver is automatically mapped and *viola* all our apps are available. This allows me to bring my work laptop home and use all of my home apps without an install and without having to think about versions, paths, etc.
I do this same thing at work too...
KC
Friday, May 21, 2004
You're all right!!!!!!
The future of apps will be a mix between server side & client side.
Check out:
1) Java Web Start
2) .Net Zero Touch (No Touch) Deployment
These technolgies are fairly new, but will be the future.
Gen'xer
Friday, May 21, 2004
Thin-clients are nice, but what I'm more interested in is the data. From what I've seen, companies have more trouble sharing their data, than worrying about who has which app installed on their desktop machine.
As an example, take my personal email. I can read it at work, but if I want a copy at home, I have to leave it on the server. Then, when I get home, I still have to go through them all again as I download them. My ISP doesn't allow for enough space on the server to leave it there.
Solutions like GMail are possible, but that still leaves my email in the hands of another party.
Edward
Friday, May 21, 2004
Conversations like this always amuse me. When it comes to the history of computers, unfortunately I was just a child for most of it, and didn't _really_ become a part of it until the Internet boom.
It seems to me that the industry seems to be quite cyclical. In the old days, you had your big mainframes and thin terminal clients. Then the world moved to decentralize the mainframe and place the power on the desktop. Then the internet came along and started pushing back in the direction of centralized servers and thin clients.
I don't know what all the reasons for the initial push away from centralized computing was (I know the personal computer was much of it) but I'm sure usability issues asside from cost also factored into the move. Either way, maybe the best ground lies somewhere in the middle.
Personally, I'd like to see grid computing come into its own. Best of both worlds in my oppinion. Thin client supported by a lot of horsepower when you need it, and a thick client living locally on your desktop when you want it.
Elephant
Friday, May 21, 2004
I suspect a major part of the push away from centralised computing was a tendency for operators to tell users to sod off when they asked questions. See the BOFH for details.
a cynic writes...
Friday, May 21, 2004
Keeping data on the server is reasonable, but keeping the app on the server isn't. If you'r e downloading the app to the client, then run it there in the first place, and if you're using a web browser, then you running with one leg tied behind your back.
Stephen Jones
Friday, May 21, 2004
To me the biggest downside of data on the server, is there is a lot of data that I wouldn't want stored on a server (even if it was encrypted).
Such things as financial records, legal documents, proprietary engineering documents, personal photos, business letters, etc.
Maybe I'm just a privacy nut, but I like to keep such things as close as possible. Then again, I'm still refuse to deposit a check at an ATM so I probably am just a nut.
Elephant
Friday, May 21, 2004
*** Man my grammar/spelling is bad today ***
Elephant
Friday, May 21, 2004
To me it sounds like now that we have the credit card people will not use real money anymore.
blaZiT
Friday, May 21, 2004
I was reading about ASP.NET 2.0, and if the trend of server side frameworks continue in Microsoft's vision, I am afraid server-side programming will just become so easy that more people will have to contemplate web services at the very least--even if they want to continue to write desktop apps.
With the ease of distribution more programming shops will want to try web services adn shareware distribution--resulting in more piracy and loss of revenue--I think this will lead to the requirements of logins accounts as a challenge to web services access to prevent piracy.
As networks become more available and easier to keep up 24/7, I think we will reach the point where more people are open tot he ideas of server side development.
Li-fan Chen
Friday, May 21, 2004
I think there's one crucial point that's being left ouf of this discussion: The Smart Client. I know that's a MS-specific marketing term, but the concept applies everywhere. Have a thick UI residing on the client's PC, but keep the data at the server. Implement one or more middle tiers to decouple the client from the nitty gritty. Install the app once, but then it auto-updates itself whenever necessary. Or use no-touch web deployment. Although not required, it's also recommended to build in an offline data cache, so that your users aren't tethered to their ethernet jack.
For data-centric apps, this model works quite nicely. On some level it really is just a revision of the old client-server way of doing things, but with the power we have with today's frameworks, we can mitigate most of the issues people had with that system.
I doubt we'll ever reach a state of complete peace and contentment on the issue of thick vs thin client. Both have their merits, and the Powers That Be will forever evangelize one, only to change their mind a couple years later. The grass is always greener on the other side, afterall.
What it really comes down to, is what your app is trying to accomplish, and what tools you have available. If it's 1965, you're going to use a mainframe and terminals, because it's hard to cram that many vacuum tubes into someone's office and still leave a place for them to sit. If it's 1985, you'll want to decentralize, because mainframes are god awful expensive and desktop PC's are becoming commonplace. And if it's 2005, you'll have 100 times as much data, so you'll have no choice but to centralize, but at the same time you'll also want to mobilize your workforce. And in 2025 I'm sure we'll all be singing yet another song...
Joe
Friday, May 21, 2004
"I am afraid server-side programming will just become so easy that more people will have to contemplate web services at the very least--even if they want to continue to write desktop apps."
This is a good thing. Desktop apps need to go the way of the dodo.
Mike
Friday, May 21, 2004
Every time subjects like this come up, I have to sit back and smile (maybe laugh quietly to myself).
The general pattern for new "save-the-world" technologies is as follows:
1. it makes a loud, flashy entrance
2. it gets hyper-hyped, way beyond its intended boundaries
3. everybody claims it to be the "next big thing", drops what they're doing, and rushes on the bandwagon
4. a few years elapse
5. people come back to their senses and the new technology settles down to its rightful niche
6. the next "save-the-world" technology comes along
7. GOTO 1.
Web-based apps are cool because they're new, they give us capabilities to do SOME things in a different, perhaps better way. Like any other technology, web-based stuff is not the answer to everything.
AnMFCAndJavaProgrammer
Friday, May 21, 2004
UH JOE someone did mention Smart Apps.
Didn't you see my post above??????
I.E.
1) Java Web Start
2) .Net Zero Touch (No Touch) Deployment
Gen'xer
Friday, May 21, 2004
> proprietary engineering documents
This is EXACTLY the kind of think I would want stored on a server. The problem is if these documents are copied and spread all over to client machines tracking, securing, and backing up such documents becomes nearly impossible.
christopher baus (www.baus.net)
Friday, May 21, 2004
"My personal observation is that web apps are generally several times more difficult to develop than desktop ones of the same functionality. There aren't hell of a lot of cases where this additional effort can be justified from the business standpoint."
I can't speak to the difficulty of developing desktop apps, but here is a little pitch for web apps. I have become a believer in the ASP (Application Service Provider) business model. In my case, I have built a pretty feature-rich application hosted on a web server, which provides a valuable service that is not being met at the moment. Because its a web app, we don't have to pay overhead for CD replication, packaging, printing, shipping, etc. We don't have to bang the phones to get retailers or distributors to carry the product. Its all in one place, and will work the same for anyone on any computer. We pay a nominal fee for web hosting. It only takes one customer a month to make our money back in operating costs. Marketing costs only involve travel, taking potential customers to lunch, business cards and brochure printing, and other small things like that.
Based on this product, we are looking to start a full on development company building one ASP after the other. If we were to build the same applications for the desktop, it would increase our costs quite a bit.
Clay Whipkey
Friday, May 21, 2004
--------
"Desktop applications have several advantages over web applications:
- they can have rich user interfaces
- you can develop a desktop application much faster than you can develop a web application (of course, this happens if you use the right tools - if you choose MFC, then it's no wonder that you develop slowly)
- desktop applications are not affected by network and server down times"
--------
Point 1: This is only true if you are actually creating a rich user interface for the desktop app. I haven't seen much of that to be honest. I've seen websites with pretty nice interfaces, and desktops with terrible ones. Its not automatic.
Point 2: If you use components, modules, object oriented design, etc. web applications can start to be developed pretty fast re-using common code. Don't know if its as fast as software development, but it doesn't have to be "slow" if you do it right.
Point 3: desktop applications ARE affected by: compatibility, driver conflicts, other software breaking your stuff, local viruses, system requirements. Its much easier to control just one (or a few) servers, rather than every user is an unpredictable variable.
Not that I'm trying to start a holy war or anything. I like software for some things and I think it will always hold its place for many functions. I just want to be fair.
Clay Whipkey
Friday, May 21, 2004
I think thin client apps appeal to the IT departments but thick clients appeal to the actual users who sit infront of the box doing the work.
Every thin client app that I've had to use was just dreadful to run. They probably run fine if you know exactly what you're doing and have a LAN connection to the backend server. With DSL or T1 connection speed, they can suck.
I agree with the cyclic nature of it, but it's only cyclic from a promotion aspect. It's not like we are all using dumb terminals again or anything.
The other thing is that I think that in the long run, things will change. When new applications are written they will put appropriate amounts of data/processing on the client and server. Existing legacy apps will continue with a thick client or thin client until they are replaced with something new
MilesArcher
Friday, May 21, 2004
Most everyone is assuming today's thin client architectures. What about when XAML and longhorn hit the market? Do you think the debate will be refueled?
christopher baus (www.baus.net)
Friday, May 21, 2004
I agree with Egor, when he says that the additional time and cost, for web apps, can be hard to justify from a business standpoint.
I have noticed four things in particular:
- many companies see .NET as a "web technology". (I.e. ASP .NET)
- BUT, it's arguably the best tool yet for doing NON-web development. It solves several of the problems that drove us to web clients in the first place.
- the strongest arguments I have found, in favour of rich clients, were on Microsoft's own site. (See http://homepages.paradise.net.nz/jjrusk/tech/rich_clients.htm for links.)
John Rusk
Friday, May 21, 2004
And the fourth thing was:
- MS are making it easier and easier to deploy rich clients (e.g. ClickOnce in VS 2005)
John Rusk
Friday, May 21, 2004
Here's a real world example of thick clients going bad. Outlook with POP3. The boss's wife lost all her email that was on the client. Since it is impossible to back up every client, she lost all her mail. If it was up to me, I'd force all corporate mail through IMAP.
christopher baus (www.baus.net)
Friday, May 21, 2004
> Why do you feel so strong about putting all the beef in the server?
1) ease of administration (deployment, upgrades, etc.).
2) available anywhere I have a network connection (which for me is everywhere).
3) Easier to colaborate between multiple users. Each user isn't an island of functionality.
christopher baus (www.baus.net)
Friday, May 21, 2004
Sorry Gen'xer, I did see your comment, but I wanted to point the advantage of the smart client appearing to the user as a normal application.
Java Web Start requires a special launcher, which can be a little weird. (I'm not very familiar with the Java side of things, so correct me if I'm wrong there). No-Touch requires the user to navigate to a URL, which can be inconvenient and unintuitive. I believe both approaches are subject to sandbox security restrictions which make things like printing, file system access, etc more complicated.
I know I also mentioned no-touch, but it's really not my preference. If you veer away from no-touch, and do something like the MS-Application Updater Block, then the app really does act like a normal thick client. It gets a program group in the start menu, an icon on the desktop, and all the OS priveledges of a standard installed app.
Joe
Friday, May 21, 2004
I find it very telling that despite my stern comment that thin clients aren't viable without a solid network, not one person after that commented on the need for network stability (even if only to say today's networks are stable enough, thank you)
Most unnervingly is Clay's "I have become a believer in the ASP (Application Service Provider) business model" with no mention of the need for a solid network and SLA.
When the proposal has to be in by 6am and your ISP decides to screw around with routers, knocking you offline for eight hours, the fragility of thin clients becomes very, very apparent.
Networks are almost there; the internet will get there. But neither one is as dependable as the telco network, which is where they need to be for us to really have this discussion.
BTW, InfoPath (smart client) can be designed to operate in an online/offline mode, so even if your server lets all the smoke leak out your users can keep filling out forms and storing the data locally until connectivity is back. I think *that* is a model worth thinking about.
Philo
Philo
Friday, May 21, 2004
(BTW, that wasn't meant as an InfoPath pitch - just as an example)
Philo
Philo
Friday, May 21, 2004
Joe,
You're looking for:
" a program group in the start menu, an icon on the desktop, and all the OS priveledges of a standard installed app."
With the possible exception of the icon on the desktop, ClickOnce will give you what you're looking for. (In VS 2005)
See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickonce.asp
John Rusk
Friday, May 21, 2004
Philo
Apparently the networks are near stable enough. Like I said not much work gets down around here anyway without the network anyway. I usually hear it right away when the network is down.
I do all my email through the web, and it very rare that I can't check my email due from a network outage. It is common that a user's hard drive goes on their laptop which uses POP3 and hasn't been backed up in ages, and they lose all their mail.
The server has RAID mirroring and a backup procedure, people's laptops have mall hard drives and are often forgotten.
christopher baus (www.baus.net)
Friday, May 21, 2004
> I don't know what all the reasons for the initial push away from centralized computing ...
The end-user apps were horribly straight jacketed, and the user could only run things that corporate management decided to run. Normally these were just horribly boring things like Account Information Module.
For someone who didn't see that old environment, it would be difficult to understand the phenomenal emplowerment (not too strong a word) brought about by Macs and PCs on destkops.
It gave execs nice writing and spreadsheet tools, and loads of other things considered really exciting at the time, like the ability to view pictures on the machine, and even play games.
Friday, May 21, 2004
Errrm, Philo
"We need more graceful ways of handling disconnections, we need fake local interfaces that let the client know that the universe is disappeared but that they're safe, warm and protected until the universe wakes up again."
Wasn't that someone addressing networks and their lack of robustness, hein?
Simon Lucy
Saturday, May 22, 2004
Hey Philo,
Regarding your network availability concern. It's a good thing your employeer doesn't make routers. I could see it now, "Windows XP routing platform. Now with Outlook Express and Windows Media Player pre-installed!"
christopher baus (www.baus.net)
Saturday, May 22, 2004
---"Hey Philo,
Regarding your network availability concern. It's a good thing your employeer doesn't make routers."----
Well, if they ever do, at least they've got the advertising slogan already.
"Where do we want you to go today?"
Stephen Jones
Saturday, May 22, 2004
John Rusk & Joe,
.NET Click Once is one and the same as the technology formally known as "one touch" or "zero touch" deployment. Microsoft marketing is changing the name to "Click Once" in the next version of Visual Studio.
Gen'xer
Monday, May 24, 2004
>.NET Click Once is one and the same as the technology formally known as "one touch" or "zero touch" deployment.
Do you mean its the same as something that they've already released?
Actually, it's similar but better, as described here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwinforms/html/clickonce.asp
John Rusk
Tuesday, May 25, 2004
 Recent Topics
Fog Creek Home
| 
