macOS Standalone vs Web App

[rev316]

This question is directed more to the members with developing experience in the IT field; rather then just hobbyists. Love to hear on what criteria is considered about when choosing between a desktop or web-top application. Seems more recent technologies make the line even narrower when deciding. Please consider all platforms.


-Rev

 

[robbieduncan]

This sounds suspiciously like a homework assignment. If it is have you considered actually doing the work and learning something?

 

[rev316]

Well, thanks for replying. But that wasn't really the answer I was expecting. And no, this isn't a bloody homework assignment question. Just a man in search of enlightenment?

 

[toddburch]

...Please consider all platforms.
-Rev

I was going to respond, and when I kept reading, this turned into a thesis opportunity that I am totally incapable of answering.

If I may ask, where are you going with this? Sounds to me like a good conversation over a draft (or 5) at a pub.

Todd

 

[rev316]

Yea. Sometimes I see software become a web application when I believe it should be a desktop application and visa versa. Rather then just hear my own opinion, it would be nice to know what OS X. Windows, and Linux desktop applications offer (and when) that gets a director to point towards a desktop rather then web-top application.

Thanks for the reply Todd.

 

[MongoTheGeek]

I always look at the use cases. Does it use networked data? Does it require networked data? Do you want to be able to use it off network? Do you want to be able to access it anywhere?

 

[HiRez]

I agree with Mongo, you need to look at each app separately. If there's a good reason to go web app, I'll do it because I just think it's a better, more modern, more flexible model when possible. I just had to face this decision on a project. Even though I'm more comfortable writing Cocoa apps, I chose Python/Django/HTML because:

-- I had some Mac and some potential PC users (and future users who I didn't know what platform they'd be using).
-- The app accesses a common running process which was behind a corporate VPN barrier. This process could not be duplicated on each user's individual machine.
-- People needed to run this app from anywhere in the world and I wanted to ensure everyone was always using the current version.
-- The need for an overly swanky interface was low.

 

[ChrisA]

This question is directed more to the members with developing experience in the IT field; rather then just hobbyists. Love to hear on what criteria is considered about when choosing between a desktop or web-top application. Seems more recent technologies make the line even narrower when deciding. Please consider all platforms.

-Rev

It depends on how much user interaction is taking place and maybe more mportantly where the data should live. If the data needs to be in a centralized location and accessed by many people then web-baed loos better, although I've worked on one system that was written in C and X-Windows and ran locally but accessed a centroal Oracle DBMS.because we had some complex graphics and did quite a bit of computation. I'm doing another one now that is going to be web based. My rule is that if it can be done with just some simple HTML forms and a "submit" button I'll make it web based otherwise I'll use a cros platform GUI toolkit

 

[Stile]

I personally believe a lot of the decision comes down to sophistication of the UI. With web based apps you get instant update of all clients as soon as the server/s are updated. But it's also harder to create complex UIs that require a lot of state. Of course if you want to use the application offline this can be difficult, though I've seen an application that runs a local web server and database for offline usage with the ability to synchronize the local database to the server when back online.

At my current job we took kind of a hybrid approach. We have a web server that acts as a remote object host that we access using a thick client on Windows. We use a binary data over HTTP mechanism for accessing the remote objects. The web server is responsible for persistence to a database, assembling data, and serving documents to the thick-client.

I think Flex/Apollo from Adobe and Silverlight from Microsoft look like interesting ideas. They basically will give you the ability to create applications that run from the web or from the desktop using the same technology. Flex being Flash/Actionscript based, Silverlight being more geared towards the .Net crowd.

 

[AlmostThere]

For me, much of this is down to the per-user processing and (transient) storage requirements, the greater each is, the greater the tendency to favour the desktop option (my work is mostly numerical analysis / data mining).

If you write a decent library and abstract your model from the UI, then you can probably move reasonably easily from one to another or flesh out something simple for each and then buiilding up the most effective option (thinking Java / Python / .NET rather than something like PHP).

 

[rev316]

HiRez, ChrisA, Stile & AlmostThere...

Fantastic replies. Much appreciated.

 

[robbieduncan]

OK, as it's not a homework assignment I'll give you a real answer! (sorry for the delay: I was asleep):

When we are designing new apps our users often want web apps as they seem cool. But we often give them desktop apps! Why?

1) The users want near-instantanious UI actions. This is difficult on the web where calculations too large to run in Javascript are required as the server must be involved.

2) The users want to view large tabular datasets (100,000s of rows of data). This is simply not efficient on the web! It can be done, but the results tend to be disappointing.

3) Printing. The users often want total control over the printed results. Web apps are not good for this (sure you could generate a PDF on the server but that's really not a good as simply printing from a desktop app).

4) Multi-view. We have MDI apps and the users often want to open multiple reports and multiple copies of one report. This is difficult on the web (but not impossible).

So given these requirements (which are somewhat specialised) what would be the good points of web-apps?

1) Deployment. There is none (assuming you don't use any plugins etc). This is a super massive win. It takes us weeks to push a new application through the various processes to desktops!

2) Centralisation of resources. Using desktop client/server apps you need a fast server AND fast enough desktops. If the client is simply displaying data with all calculations on the server you can have a fast server and thinner clients. This may result in cost saving.

3) Flexibility of presentation. Want to run on a Mac instead of Windows? On a phone? On a Wii? Web apps make this simple. With custom proprietary apps inside a single company this is not a real win though: all our desktops run a customised version of Windows.

Robbie

 

[HiRez]

3) Flexibility of presentation. Want to run on a Mac instead of Windows? On a phone? On a Wii? Web apps make this simple. With custom proprietary apps inside a single company this is not a real win though: all our desktops run a customised version of Windows.

I assume you are speaking of your own company there. I work at a Fortune 500 company and we have a very good mix of platforms. All flavors of Windows including desktop and server varieties, lots of Macs running OS X 10.2 through 10.4, and various kinds of *NIX. Plus a lot of mobile devices (including iPhones!). You mentioned the simplification for deployment, but another advantage is for debugging. Even though that's somewhat offset by having to test on various browsers, it's still generally far easier to target browsers than a dozen different native OSs (assuming you're not using a bunch of custom plugins and such). This can make a significant difference in your life as a developer. Of course if you know all your clients will be running the exact same OS, then the more robust native debugging tools might be better.

 

[yg17]

Depends greatly on the needs.

I spent 2 summers working for a huge company (I'll refrain from saying which, as I don't want to say too much about my work. But if you live in the US, Canada or a few European countries, you've heard of them and may have even been a customer once, and no, it's not Wal-Mart, McDonalds or any other fast food restaurant). This past summer, I was a software engineer for the program that clients (several thousand worldwide) use to access our system and do stuff (yeah, real descriptive, I know ). And that was web-based, because new versions of it (every month was a new release) just had to be deployed to, I think it's 4, production web servers, as opposed to thousands of PCs at hundreds of client companies all around the world. There's no way to feasibly have it as a standalone app. Clients wouldn't update as often as they should or at all. So with a webapp, as long as they go to the proper URL, they have the latest version. We're not supporting 50 different releases at once because company X is on the latest, company Y is on the last release, and company Z hasn't upgraded in a year, yet they all need to use the app on a daily basis. Being a web app just makes it so much easier. Plus, you never know what sort of computers clients have. Although IE5 was the only official supported browser, there was no reason it wouldn't work in Firefox or Safari and the like. What if the standalone is Windows and a potentially huge client uses Mac or Linux? Too bad.

Web apps can be a bit easier to secure too, since all the end user gets is HTML/JS and images. If the executable is on their local machine, they can possibly do all sorts of crazy stuff with debuggers to do things they shouldn't be doing. Then again, poor web server configuration and lack of firewalls and such could be just as bad

Of course, standalone apps typically are more advanced and have better GUIs (although, you'd be surprised to see what another purely web-based, IE only webapp this company has for those 7,000 locations can do using Javascript and such. Most of it's probably due to the fact that IE fails to meet web standards, but whatever ). And, plus, depending on what sort of connectivity is needed, it may work without an internet connection in case someone is on the road.

 

[robbieduncan]

I assume you are speaking of your own company there. I work at a Fortune 500 company and we have a very good mix of platforms.

Yes, I'm talking about where I work. We can basically assume Windows 2000 at the moment. We have a good mix in the servers but not desktops

 

[aquanutz]

1) Deployment. There is none (assuming you don't use any plugins etc). This is a super massive win. It takes us weeks to push a new application through the various processes to desktops!

When I started working for my current company I was in the mindset that a standalone would be better for our company, then I realized that deployment and updates (which are a HUGE constant in our business) are much easier to maintain when you have one centralized location for your application (the web) that can be updated without bothering the users. This is huge.

 

[Eraserhead]

Don't things like Sparkle help blur the line a bit with regards to version management?

EDIT: I suppose not in a corporate setting.

 

[rev316]

One of the major points I've seen some of your make was the ability to, "serve once, serve them all". Though, I'd like to add some emphasis to that. As we know, code gets handled very differently among IE, Gecko, and Webkit browsers (whole web standards issue). So much, occasionally we sacrifice functionality and/or time to just make it work. Even then, sometimes it doesn't come close to look and feel we expected. Just another tidbit for readers.

 

[georgio8]

I personally believe a lot of the decision comes down to sophistication of the UI. With web based apps you get instant update of all clients as soon as the server/s are updated. But it's also harder to create complex UIs that require a lot of state.

This was the only mention (albeit indirect) of the limitations of running apps within a browser. I'd contend that it's not 'harder to create complex UIs that require a lot of state' because JavaScript is actually quite a powerful o-o programming environment, but it may well be too cpu/memory intensive for practical use. My experience with Google Maps - based applications that display substantial quantities of overlayed information points in that direction - you have to design the UI to minimise the load by limiting the amount of information visible at any time. (Because all the visible information has to be re-displayed by client-side code in the Google API package whenever the view changes, which happens whenever the map is scrolled or zoomed).

It would be interesting to hear other's views on this - do the same considerations apply in non-mapping applications?

Georgio8

 

[robbieduncan]

Don't things like Sparkle help blur the line a bit with regards to version management?

EDIT: I suppose not in a corporate setting.

That would be OKish if the bit on the desktop was stand-alone. But in our client-server environment that doesn't really work. A lot of the changes we make require a co-ordinated release of code onto the database server and to the desktop. So everyone has to get the same desktop front-end version at the same time!