Hi Alejandro,

You want to rewrite your application right? the real question is: how many times do you want to rewrite your application?

If you intend to write both 'native' (formerly 'desktop') and web applications, you'll need between 1 and 4 rewrites, depending on the amount of code you can (really) share between the 'native' instance and the 'web' instance of your application, between the iOS, Android and Windows instances of your application, and between the mobile and desktop instances of your application.

Using WinDev you'll need almost 2 rewrites as the WinDev code can't run in Web mode (http://www.mysnip.de/forum-archiv/thema-27131-184118/Survey+about+windev+inside+browser.html); .net, java and python (dabo) would be pretty similar.

Lianja and Servoy claim to run the same code on 'native' and 'web' deployments, might be good candidates for you.

You might also want to look at FoxInCloud (in fact you've already looked at it and its predecessors since 2005, right?); using FoxInCloud you can:
1/ get a web version of your VFP application by adapting less than 1% of your VFP code
2/ adapt your VFP UI to mobile devices using CSS
3/ build hybrid applications to push your application into the various app stores
4/ slide the server part, initially in VFP, to another language such as php, java or .net, simply by rewiring the event handlers generated by FoxInCloud to some other server-side URLs

You end with a single, 100% web-based application that the user can run on any device, any OS, anywhere, without writing a single line of HTML.

Considering the amount of 'soft' investment required (getting familiar with new paradigms such a client/server, HTTP, HTML/CSS/JS, etc.), I'm convinced that the only valuable and durable investment are the Web techs, as they can fit any device and any OS.

You can experiment the response time of a true stateless web app here: http://foxincloud.com/tutotest/wFormStandardPage.tuto?awForm=Event.scx
where you'll get the response time broken down into:

• browser


• internet


• application (close to 0)


• server (where the user state management occurs)

In this tutorial, the server saves and restore the full user state on each request. Of course in this example the application times are close to 0 - you'd need to add your own application times to get a fair vision of the overall response time.

FWIW, these response time have been divided by 3 in 10 years, and I'm quite sure we'll get another ÷2 before 5 years.


>We have a successful payroll application developed with VFP and DBFs specifically for the laws of Panama. We feel we have a very good handle on the business problem and are looking to rewrite the application with up to date tools.
>
>Requirements:
>1. The update should be able to run in the cloud or in a customer's server and PC if customer requires it.
>2. Though the main processes are normally run from a terminal in the office, the app will receive and provide data access from phones and tablets and who knows what else in the future.
>3. Some of the data capture screens provide immediate feedback which requires a lot of computation, such as significant checking of historic data. Stateless web server behavior is not really acceptable.
>4. The tools used should be reliable and expected to have a long life left in them. I am especially bothered by MS's habit of periodically making updates to their tools which require you make substantial changes to your code if you wish to use them. Backward compatibility of updates is something we value.
>5. Developer productivity enhancing tools are a key consideration.
>
>All suggestions and comments are welcome.
>
>Thank you very much,
>
>Alex