>>Why don't you consider starting with your VFP app adapted with FoxInCloud then progressively switch to a MVC-style application reusing the Bootstrap HMTL/CSS/JS built by FoxInCloud (http://foxincloud.com/tutotest/bs/)?
>>
>>It'll save you time to market and thousands of hours writing HTML code, and keep your Web app in sync with your VFP app that you know it works fine, rather than throw your clients into the complete unknown…
>
>Rewriting an desktop app to a web app also forces us to rethink the structure and GUI of the app. Just porting our desktop app to a webapp just does not cut it. It just sounds the time to do a total rewrite but since clients will have both the desktop app and the web app, just rewriting module by module (department by department) seems to make more sense than trying to keep hanging onto VFP and its current structure.
>

Depends a lot on what you currently have, what your definition/plans/targets are for web(/mobile?) app and so on.

I do believe that web apps (including mobile) should be something on the lines of SPA at least, PWA if the use case allows it (reactivity, needs for security, offline capability?): state managment and simple validation belong IMO to client in non-trivial apps, offline capability should be there (in a hospital app this need might be less severe...).

I also am a firm believer in MVVM being superior to MVC. Also believe in the onion model, with API calls only acting towards data structures further inside the onion, but should never know anything about data structures further outside than its own layer at maximum, also never skip layers and lastly in a chunky, not chatty approach to calls leaving own layer (esp. the client/server gap).

As long as your current data model does not have to be altered a lot and you already have a MVVM-similar architecture I would clean that up first.

Take a long uninterrupted weekend and read up on current JS fwks, there are probavly around a dozen articles. My base technological angle closest to Viv arguing to settle on a JS fwk[s] - including state managment, single source of truth vs. bilateral data binding vs dependency injection, JSX vs HTML, Redux, MobX, GraphQL vs. REST and so on.

On fwk to use I am diametrically opposed to Viv's hint of Angular2 as a more than full stack having all things decided for you, but would prefer Vue or similar lean fwk sporting both enough followers to guarantee enhancements, native versions and Stackoverlflow responses...).

Names should include Angular2, React, Vue and probably Aurelia. Look into Meteor as well: they build for instant reactivity across all currently connected clients, which is a special case useful for some scenarios - version 1 for me was a curious blend of genius ideas like a DB cache in the client coupled with dumb decisions like almost locking the backend to be Mongo and forcing the client DB into mini-Mongo. The contrast + reasons NOT to use a particular fwk like Meteor for your use case (going out on a limb knowing almost NIL about your needs...) might sharpen your ideas on why to pick your favorite ;-)

Having options to hop from SPA/PWA into installable JS based native apps should be considered: React has React Native, Angular can be coupled with Nativescript, Vue can be integrated with Nativescript as well and Alibaba is creating also a native layer with Vue-based architecture and native controls.

IMO the fwk should hint at one solid way of doing things but NOT be coupled too close - Vue allows swapping parts with more ease and React is built to be used together with other packages

You should spend 3 days to read up on JS fwk comparison and NOT follow blindly any names dropped here, as you probably have preferences, a special use case you did not describe in detail but know by heart and your team capabilities/leanings should be taken into account as well ;-))

There is a site having simple todo lists implemented in almost all fwks so you can compare architecture on a implementation in each fwk and most of them can be benchmarked via DBMonster as well, which might give better grasp if you plan to do heavy client side lifting.

Then decide on a protocol between client and server to decouple better (graphQL or REST).

If you think you have an architecture (plan) that you consider sound, in your shoes I'd call up Thierry and ask for a quote on enhancing FoxInCloud to the very specific list you prepared, giving you the option to run webified fox forms via your targeted server/client protocol ***and*** creating a JS VM layer in line with Walters planned architecture for FIC-based controls to work against, upon which you can later build new pure web GUIs with fwk of your choice, be it Angular2, React or Vue on a already battle tested client-side VM data layer.

Benefit for you: the protocol glue is written by someone knowing both fox and web, no training cost for your people. And Thierry should only provide glue to the targeted protocols and layers from that fwk bundle[s], NOT reinvent the wheel for VM data layer, calculated properties, message forwarding and so on - although the glue might sometimes replace some original code so to not create Spaghetti, but JS offers even more options to patch than pure OOP languages ;-)
Benefit for FIC: payed enhancement to support one of the globally accepted JS fwks offering a MVVM data layer as target API in that fwks convention/architecture, if Walters architecture is sound enough. If FIC is nimble and loosely coupled to allow such integration with ease, that is a big plus and save cost - if not, that is reason to rearchitect a bit and discount the rewrite effort ;-))

Benefit for both: if both of you think and work hard before deciding to go ahead, both secure from financial risk:
Walter will not run the risk of run-away cost due to unforseen problems(Thierrys problem if it occurs), Thierry will not have to finance a cleanup / enhancement without predefined+uncertain ROI. BOTH should drive a hard bargain on technical details UP FRONT.

I do think Walter is correct to wish to define his dream architecture if going web, but NOT asking someone like Thierry if it can be wedged into currently existing+working fwk code for a (sizeable!) fraction of own expected cost would be bad. Thierrys coders know both languages plus architecture of FIC (and probavly state of the art JS fwks) and might discount programming cost a bit as well, if the architecture enhancement/cleanup/modernize is also usable legally for FIC afterwards. (I always look for win-win if possible)

Having a backdrop approach already working for web desktops via same protocol will lift pressure from deadlines and give developers of new GUIs a leg up, as there is a working VM layer plus comm C/S protocol to check against - nice to debug if you only have to look for discrepancies.

Such a plan of course nearly impossible if Walters existing architecture stems from fpw origins with controls binding directly into table and no layered approach for code separation in existance ;-)

my 0.25 € (did think a bit before posting...)

thomas