Quickly developed web application or slowly developed actual application?

[Tuxman]

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]

Depends heavily on the purpose/goal of your application...

[mouser]

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]

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]

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]

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)