If "stick with VFP" was your takeaway from Rick's post, you read it differently than I did. In fact he was probably the first prominent VFP developer to move on to other things.

>AMEN. It's nice to hear the experts confirm this.
>
>Many of the new tools coming out require you to learn 2 new dev languages whereas you could stay with VFP on the server and just learn jQuery. I remember someone here mentioned they looked forward to the challenge of learning a new dev language. I would recommend just learning jQuery for the challenge and keep your investment in VFP on the server.
>
>"FWIW, I've just been involved in a mobile only application (built with ASP.NET MVC 4 but honestly that could have just as easily been done with Web Connection or *any other* Web dev tool for that matter) that was exclusively built for mobile devices - phones and tablets - and it's a very rich app that gets pretty close to what you would expect in native applications, including browser based touch controls and local storage etc. It's possible to build apps that are pretty close to a native experience and run on most current mobile devices.
>
>If I had to bet money on where the dev market is heading I'd say it's either here or native platforms migrating to using HTML/JavaScript to manage layout and logic."
>
>>John,
>>
>>I think that given a bit more time we'll find that all the 'native' platforms will eventually run on HTML5,CSS,JavaScript. Perhaps with native libaries to plug into but this native platform for each mobile device won't be around much longer IMHO. It's such a collossal waste of time to build the same app in several different environments to get anywhere near the 90% reach point even.
>>
>>FWIW, I've just been involved in a mobile only application (built with ASP.NET MVC 4 but honestly that could have just as easily been done with Web Connection or *any other* Web dev tool for that matter) that was exclusively built for mobile devices - phones and tablets - and it's a very rich app that gets pretty close to what you would expect in native applications, including browser based touch controls and local storage etc. It's possible to build apps that are pretty close to a native experience and run on most current mobile devices.
>>
>>If I had to bet money on where the dev market is heading I'd say it's either here or native platforms migrating to using HTML/JavaScript to manage layout and logic.
>>
>>+++ Rick ---
>>
>>>>>I'm not going to write native iOS apps, so if a client wants that he can go elsewhere.
>>>
>>>OK. Hank's solution that you criticize doesn't involve shutting out 29% of *the* growing market.
>>>
>>>>>We're building asp.net apps with javascript mapping components (ESRI) and jquery to spruce up the client side. Works fine on pretty much any current browser.
>>>
>>>Browser is not a natural decision for business apps on a mobile device- which is why banks, online travel agents, ebay and others are all offering native apps rather than pushing their traditional web interface. It was fine for desktops that usually used a network under the customer's direct control, but mobile devices are distributed by telephony providers who encourage customers to use the provider's data network and once hooked into that, it's hard to go back. Outages are to be expected and are tolerable- unless you're using a browser app that may crash or lose work if an inconvenient outage strikes at a bad moment. Customers won't put up with it, especially if somebody else is doing it properly.
>>>
>>>>>Try it in VFP.
>>>
>>>That's not the proposal. Hank is contemplating re-using VFP code in native apps to run on any platform. The comfortable pejoratives to justify a move away from VFP aren't useful rebuttals if he can do that and you cannot.