topbanner_forum
  *

avatar image

Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
  • July 20, 2018, 04:45 PM
  • Proudly celebrating 13 years online.
  • Donate now to become a lifetime supporting member of the site and get a non-expiring license key for all of our programs.
  • donate

Author Topic: Quickly developed web application or slowly developed actual application?  (Read 586 times)

Tuxman

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 2,022
    • View Profile
    • Donate to Member
What would you rather use and why?

I prototyped a new project (basically, a decision helper) in Javascript and ugly CSS and I need an idea if it would be worth the additional effort to reimplement it as native applications. (Platform-independent, of course.)

Ath

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 3,191
    • View Profile
    • Donate to Member
Depends heavily on the purpose/goal of your application...

mouser

  • First Author
  • Administrator
  • Joined in 2005
  • *****
  • Posts: 38,722
    • View Profile
    • Mouser's Software Zone on DonationCoder.com
    • Read more about this member.
    • Donate to Member
I think you did the smart thing in terms of whipping up a quick prototype.  I think that is almost always the best first step.
So now that you've seen your prototype, is there enough reason to spend time making a more robust version?

wraith808

  • Supporting Member
  • Joined in 2006
  • **
  • default avatar
  • Posts: 9,550
    • View Profile
    • Donate to Member
Depends heavily on the purpose/goal of your application...

This.  So much this.  People look at web vs desktop as if it's a static decision.  It's very much based on use case, IMO.

Tuxman

  • Supporting Member
  • Joined in 2006
  • **
  • Posts: 2,022
    • View Profile
    • Donate to Member
The use case is that I want an application which helps me throwing a dice to reduce my shopping list from 30 to 15 or so items. Basically, by randomizing the list. (With additional parameters like "low/high priority" and "price per item / total budget". But that's the smallest part of the code as of now.)

The major advantage of my prototype is that it's already finished. The disadvantage is that it requires Javascript. Or, more generally spoken, it works on almost every OS and device, but it could be more efficient in terms of general security (I'm not really a fan of Javascript, as you might see) and performance when written natively.

app103

  • That scary taskbar girl
  • Global Moderator
  • Joined in 2006
  • *****
  • Posts: 5,741
    • View Profile
    • Donate to Member
It may depend heavily on how committed you are to supporting your app.

Do you plan on maintaining the hosting and availability of your web app for 10+ years? If not, perhaps a desktop app would be better in terms of availability, since it wouldn't depend on you to continue to host it. Once in the hands of the end user, they could keep and use it indefinitely, long after you have lost interest in the project.

I suppose the best of both would be to distribute the JS, so that it could be run locally, bearing in mind that the end user may not wish to use the browser of your choice, which could present its own problems, in terms of support. But that could be solved by embedding it into the browser of your choice, forcing the user to comply, and thereby eliminating most support complaints.

Example: The reason why Fried Babelfish was released as a desktop app was to force the end user to use Krishean's script from round 2 of our little game, locally, in Internet Explorer, otherwise the script wouldn't work. And no matter how you tell the user to only use it in IE, there would always be those that would try in another browser and complain that it didn't work or would just contact you with an IE bashing rant. This solved the first 2 problems and cut down on the amount of IE bashing we had to put up with. (the version released for NANY 2009 was a much later round of the game, using Google's translation API, rather than the original Babelfish scraper script that Krishean initially wrote)