>>I was thinking along the lines of that SCX to dHTML renderer
>
>Basically that's FoxInCloud is doing today...

I share this view.
Beyond adapting a VFP app. to the web, FoxInCloud provides a HTML/CSS/JS clone of a VFP app. UI, and separates the UI and the server (business) layers, allowing to migrate the server code without the users even noticing it.
If one admits that a responsive web app. is the safest bet for the future, progressively sliding from a desktop app. to a web app. with the server code written in some 'modern' language is a very safe migration option; at least safer than rewriting from scratch.

>The problem with a renderer is that it falls apart very quickly unless there's a lot of external stuff that's specific to the HTML platform. This is why I long ago discontinued work on the original dHtml renderer - it would have been an endless support nightmare trying to make all the crazy combinations of controls and FoxPro behaviors work - especially with people then expecting them to work the same as FoxPro did.
This is where FoxInCloud picked up where I left off and they are doing basically the hard work of providing the infrastructure to actually produce the HTML and support behavior that has to be available ontop of just the rendered form output. And if you go to their message board you can see what I mean - there are lots and lots of edge cases that need to be addressed - and Thierry and team do a great job of addressing those, but I imagine it's a monumental job. Compared to Web Connection FIC is likely exponentially bigger in terms of scope.

The most difficult issues were:

• date fields handling


• handling user state table with multiple servers (eg. avoid access collisions between servers)


• generating Responsive HTML/CSS/JS using Bootstrap


• support for VFP menus (eg. parsing VFP instructions)


• support for cursor Adapter


• support for .QueryUnload()

A FoxInCloud application supports all VFP behaviours except some very seldom used events (eg. .DownClick()), and some classes not suited to a Web display (toolbar, formset, and control that FAA replaces by container because control hides its members).

FoxInCloud tallies about 100k LOC (VFP and JS), was twice as much as WWWC V.5, last version I counted.

>There are a lot of external dependencies to make even standard FoxPro controls work - simple rendering of a form is not enough. FoxInCloud actually provides that with a complete framework that provides the behavior for stock controls plus a host of common activeX controls. You can't do that with **just** HTML rendering and so I don't think having a native HTML renderer is going to really be very useful in the language on its own unless a big effort goes into building a client side support framework (ie. rebuild something similar to FoxInCloud).

Yes, when generating the client side it's important to always think how it'll interact with the server side.
In FoxInCloud, most changes happen on server side, using original VFP app code. FoxInCloud identifies the UI visual changes and tells the client side what updates are required to keep in sync with server side; orders go to simple HTML controls like input, and much more complex controls like the ActiveWidgets grid.
Update responses are a mixture of XML (could be JSON), and JavaScript.