When seeing the many attractive frameworks that have flourished on the web since 2005 1, one could think that developing a Web Application is just a game of assembling components that you can pick here and there for free.

The reality is very different: as of today (2018), and despite 2 decades of continuous efforts to make it more simple (from antique asp to ‘modern’ frameworks) web development still has not found a paradigm where any regular developer can become a ‘full stack’ web developer within a couple of years.

Two main reasons for that:

  • the client-server nature of the HTTP protocol: with a desktop program, each user runs his/her private instance that is totally at his/her service; on the web conversely, a server can deal with any/many users, and a given user can deal with several servers; a shift from a simple 1-to-1 relation to many-to-many.
  • the many standards: after almost 20 years of a fierce battle between Microsoft willing to impose “his standards” through a quasi-monopoly of Internet Explorer as a browser, and the web designer community backed by Mozilla Firefox (heir of Netscape, only serious concurrent browser in the early 2000), the standards have finally won the battle.
    Nice outcome having a little drawback: each component (HTML, CSS, JavaScript) is maintained by a standard organization (W3C, ECMA), and developed by ‘volunteer’ third parties (thousands of contributors in discussion lists). Documentation depends on the goodwill of these parties: blog posts, discussions on stackoverflow, utility sites from service companies have replaced the good old documentation that developers used to have 20 years ago: maintained by a single source, consistent, accurate, etc.
    Ironically, efforts from opponents to a world regulated by a de-facto monopoly have led us to a completely de-regulated world where free stuff is often a troyan horse to sell more services than what licenses used to cost.

Whatever language or framework you choose, you’ll meet 2 serious obstacles down the road to a Web Application:

  1. Write responsive HTML/CSS/JS: if you want to somehow clone the layout of the forms of your VFP desktop application, and render it as responsive HTML using - eg. - the Bootstrap framework, it’ll take you up to 10 levels of nested divs to get a proper layout; no GUI editor at the rescue for that: you’ll have to hard code using a text editor, and choose appropriate class and IDs without getting messed up; and it soon becomes very complex and difficult to handle, especially because CSS computes the layout for you based on the structure and rules you define. If you want a responsive layout, you can no longer set .left, .width, etc., you must let the browser compute positions and dimensions. Generating HTML is the area where your server code will mostly be used and, strangely, this is only the emerged part of the iceberg as point 2. below explains.

  2. Maintain user state: in your VFP code, each time you write thisForm.… or this.… or alias.field, or read a public variable, you query (without knowing or realizing it) the user state, as it results from the succession of user actions applied to an initial state. In VFP, as a single instance of the application serves a single user, everything can persist in memory: easy and painless. On the Web conversely, as the same application can serve any user in any sequence, the user state can exist only if you somehow maintain it (save and restore). No framework, whether it’s Python-based or C#-based, will ever do that for you. Then you have roughly 2 options to maintain the user state: on the client or on the server.

Maintaining the user state on the client requires to:

  • write a lot of JavaScript, probably with some client-side framework such as jQuery, Angular or Ember (be aware that these frameworks are pretty conceptual and difficult to master properly; they at least require that you are very proficient in HTML/CSS/JS as they add several layers above these technologies). Whatever your choice, you write no Python, php or C# here, just HTML, CSS and JS.

  • use client side storage to create on the client something similar to a view that you’ll submit to the server once user decides to save. This requires a good knowledge of web storage API, another JavaScript-centric technology

  • expose all your business and presentation layer code to the outside world; just like you would expose all the VFP code you have in *.scx and *.vcx, except queries. You can only obfuscate this code (eg. minify renames variables in alpha sequence such as “a”, “b”, “c”, “d”, etc.), concealing it is impossible as the browser must be able to read it.

This is the solution that most developers use nowadays; exchange with the server are merely data conveyed in the JSON format.

Maintaining the user state on the server requires to:

  • write double code: client side code altering the user interface is almost the same, except it must query the user state from the server to take proper action; the amount of code is much higher, and client and server must somehow understand each other, this generally requires either being a ‘full stack developer’ or defining tight rules (eg. naming) between client and server.

  • store user state on a server disk so that any web server can retrieve the state for any user at any time (forget about assigning server instances to specific users like in the desktop world, it just does not work for high user counts; a typical web app serves 200 users and this figure can go up to several thousands)

  • choose or define a format to store user state: could be a simple JSON string that the client JavaScript provides after each action (then you need to choose a scalable structure), or a table that you can easily query to, eg., find differences between states before / after user action.

FoxInCloud helps you dramatically in these 2 critical areas:

  • generates responsive HTML/CSS/JS code from your VFP forms: FoxInCloud understand how controls are aligned and grouped on the page and builds the corresponding groupings (row, column, *-group) in the Bootstrap CSS system: eg. the FoxInCloud Live Tutorial

  • maintains user state automatically: as FoxInCloud runs your VFP forms on the server and these forms are object oriented, FoxInCloud is able to detect what the user actions change on the form and save these changes in a structured way; the same for the dataSession 2 and the general environment 3. FoxInCloud maintains the user state on server side, in tables using a naming convention (user\form\_[ante/post].dbf). The only thing you need to do is: declare the native properties (eg. visible, enabled) that the user action can affect (custom properties are saved by default); FoxInCloud compares the state before and after user action to identify the visual changes that the browser must apply: you have strictly nothing to code to make this happen.

As we already often wrote, FoxInCloud can be regarded either as a final, or just an intermediary step to a Web Application; you can:

  • take advantage of the generated HTML/CSS/JS to save months of writing responsive HTML
  • judge whether the user state maintenance mechanism suits you and eventually recode a similar mechanism in Python, C# or other
  • mitigate between a server-side and client-side user state maintenance to save response time while protecting the code that you consider critical.

At FoxInCloud we would be delighted if VFP developers would consider FoxInCloud as a community-inspired effort, and would like to cooperate towards a future suitable migration path to the Web, rather than like a “take or leave” product with the VFP stigmata.

FoxInCloud does incorporate thorough software engineering thinking about running a Web Application while taking advantage of a Desktop Application background, going far beyond and above the mere language level which, in any case, does not and will never provide a complete solution to building a Web Application.

  1. client-side: jQuery, Bootstrap, angularJS, emberJS, ReactJS, vueJS, etc. – server-side: asp.net, ruby-on-rails, django, telerik, flask, expressJS ↩

  2. views and parameters, cursor and contents, table/alias states, cursorAdapters, etc. ↩

  3. public variables, _Screen and _VFP custom properties, aliases in the default datasession, _sysmenu, etc. ↩

tags: architecture  strategy  productivity 

Watch FoxInCloud Marketing Videos :: Watch FoxInCloud Technical Videos :: Stay tuned on FoxInCloud Roadmap :: Learn how to use FoxInCloud :: Download FoxInCloud Adaptation Assistant for free :: Download FoxInCloud Web Application Studio for free