Rick,
Agree with you, solutions are available that can cover a similar scope as desktop apps.

The issue is that, as Walter mentions later in this thread, the solutions are multiple, evolving, and involve numerous layers of composite technologies (HTTP, HTML, CSS, JS, JS frameworks, Web server, HTML generation, AJAX transactions, ...); the web has become a little like medicine ... you need a whole team of professionals to cure a given disease - very hard for a single developer, especially with 20 years of desktop experience, to catch up with all these skills while assuming the every day living with existing clients.

(@Bill) FoxinCloud does not pretend to be an alternative web app development platform, just a way to
(1) re-cycle the fundamentals of a desktop app into a Web app
(2) provide web capabilities similar to any other web app.

It occurs that some developers, after adapting a VFP desktop app to the Web, keep developing web apps using FoxInCloud; in fact this surprises us - we had not anticipated that.

Let me expand a little on (1)
As a student [decades ago :(] I learned that the most part of an application is determined by its data model: tables, columns, relations, cardinalities and rules drive the application structure and most of the processing; these structures depend neither on the programming language, nor on the kind of User Interface.
As a professional I realized that a significant part of the effort in a application sits between the chair and the keyboard: the way controls are arranged (menus, forms, pages, containers etc.) and interact, the time user have spent to get accustomed to these functionalities does have a value that is worth preserving.
Besides, we all learned that applications can be structured in 3 independent tiers/layers (UI, data, business) and the interface between these layers can be defined, isolated so that layers can be considered non-dependent.

FoxInCloud just takes advantage of these lessons to replace the 'native' UI by a clone Web UI (in HTML/CSS/JS), while keeping all the rest (data, business) nearly unchanged and still compatible with the desktop.

The main difference between FoxInCloud and a 'modern' web app platform is where and how the UI updates take place;
- in a modern web dev. platform, say using Angular or Aurelia, the UI layer deals with raw data loaded from the server (generally in JSON) and implements 'business rules' such as 'when a parent is selected, children in tables x,y,z need be requeried', or 'if customer has not payed his bill a warning should appear', etc.
- in FoxInCloud, UI updates occur on the server, in the original UI structures (forms, controls, etc.): FoxInCloud simply compares the UI state (properties) before and after the event, finds out the differences and applies the same changes on the Web UI through JavaScript. In FoxInCloud, the UI layer manipulates UI entities only such as styles, positions, adding/removing elements, etc. - not a single piece of data or business rules ever appears in the UI.
This is possible because VFP is object-oriented and 'integrated'/RAD (in contradiction to the tiers separation principle above): mechanisms like .Control/Row/RecordSource, .Refresh() and Requery() make the 3 tiers stay in sync natively and automatically. And anyone may choose to isolate the tiers through separate classes, procedures, use stored procedures and/or a SQL database.
In a web dev. platform, one needs to (re)code the business rules in JavaScript (thus making them public), implement the relations from the database, make sure the table and field names match, update whenever the database structure changes, etc. As all components are separate (angular, jQuery, server, database) no design-time integration providing intellisense or any assistance: all you need is a text editor and a lot of patience.

For someone having an existing successful desktop application, the need to re-code everything using a raw text editor without any kind of automation (welcome back to the early 90’s) is more than tedious and - IMO - incompatible with running a software house. IMO again, the market will require some kind of integrated/RAD Web app IDE where one can, just like in VFP, drag and drop fields, trigger global .refresh(), etc., and code all the business rules on the server and not in JavaScript, while keeping all the HTML5/CSS3+ capabilities (responsiveness, animations, etc.).
Microsoft can be a legitimate pretender to do such and environment. In any case, I doubt the present ‘web dev stack’ can be really attractive for long-time desktop developers as a transition path.

Regarding (2), FoxInCloud natively clones the existing UI elements into separate HTML and CSS files:
- HTML reflects the structures and controls: forms, pages, containers, textboxes, etc.
- CSS reflects the existing layout that developer can override with his own CSS

FoxInCloud could go far beyond this:
(a) using additional properties in the FoxInCloud control classes, generate responsive CSS instead of the ‘traditional’, absolutely-positioned default CSS
(b) based on the .Control/Row/RecordSource and the events implemented in VFP, and given a target JavaScript framework (Angular, Aurelia, etc.), generate a JavaScript code canvass removing the tedious JavaScript writing, implementing the corresponding event listeners and HTML attributes, where developer only needs to implement a minimum amount of code.

In short we can recycle into web applications most of the structural value accumulated in VFP applications for decades, without ‘making the single worst strategic mistake that any software company can make: rewrite the code from scratch’ (http://www.joelonsoftware.com/articles/fog0000000069.html), especially in a completely new technology.

Rather than keeping ‘kicking the can down the road a few more years’, FoxInCloud’s goal is to find the easiest and affordable path for VFP developers to move into web development.
Let’s hope that, once for all, this lengthy post will have made it clearer.

Rick, as you and we have always done so far, let’s cooperate on this endeavor!



>Not sure I follow you on the databinding aspects. Modern frameworks totally support no-touch, non-code data updates at the UI layer. Change a value in a text box and if that model value is bound it will update anywhere in the UI, including in lists etc. As will selections if they affect other things. This type of databinding is in a lot of ways much more flexible than what FoxPro ever had because it works with anything, not just ControlSource values.
>
>Getting data from the server still needs to be accomplished yes, but there are actually solutions for that as well (Meteor for example) although I don't really like that type of approach - you lose too much control with that sort of thing. OTOH I don't see pulling data into a client app as a problem - that's the way apps are supposed to be designed - you talk to a business/service layer that feeds data to you and the UI is responsible for displaying it. In Angular or Ember you use services to pull the data down and store the retrieved data into a model - usually that's a handful of lines of trivial code.
>
>FoxInCloud is very impressive in what it accomplishes - don't get me wrong. You guys have done a phenomenal job of making this work. But I think it's much wiser to start now with learning HTML, CSS and Javascript than kicking the can down the road a few more years.
>
>+++ Rick ---
>
>>>Ultimately desktop and Web UIs are very different in behavior and expectation and it's a terrible idea IMHO to try and try to shoehorn a desktop app into a browser especially when it comes to building modern and responsive device friendly applications.
>>
>>>+++ Rick ---
>>
>>IMO the differences in behavior and expectation between a desktop and a web app may be overrated.
>>
>>There is a fundamental difference between FoxInCloud/desktop and web behavior: event transactions;
>>- with a typical web system such as angular you need to query data from the server (say in JSON) and let the browser JavaScript build the HTML. It means you need a specific server transaction for each component you need to update on the client side, such as lists; or you can design compound transactions and write complex browser JavaScript to dispatch the data to each contained control.
>>- FoxInCloud offers a much more simple paradigm: browser just send the user event to the server (control address, event name, value if applicable), server updates each relevant control and, in a single response, sends back a global update order message addressing on an unlimited number of controls, just because the client (HTML) and server (VFP) addressing schemes match.
>>
>>Until HTML and JS frameworks are able to address a mechanism as simple as .controlSource() and .Refresh(), I think the processing of a user event will be simpler on a desktop-type application than in a Web design.
>>
>>Based on an existing VFP application, FoxInCloud applications implement over 1,000 user events, will all the required UI updates (any visual property on lists, grid, an any other type of control), without writing a single line of JavaScript and/or server code.
>>
>>Regarding the GUI layout, it's true that for now FoxInCloud mainly implements the equivalent of the VFP forms, plus any CSS3 override the developer may see fit.
>>
>>We are working hard at breaking this 'absolute layout' paradigm in favor of a standard responsive approach - IOW fully override the default VFP-like HTML/CSS layout by something responsive such as BootStrap.
>>Inside existing 'fieldsets' like forms, pages and containers, we need to build an algorithm able to render the controls in an order logical for the user, pair labels and controls, make the grid control responsive by adding properties to the FoxInCloud column class and providing standard responsive CSS.
>>
>>Then FoxInCloud web applications will behave and look just like any other 'full stack' web application - while sharing code with desktop versions.