POH Performance Apps History

Table of contents

• Introduction
• Gen 0
• Gen 1
• Gen 2
• Gen 3
• Alternatives
  • React + JSX + Webpack + Babel
  • Alternatives to JSX + Webpack + Babel
  • State Variables
  • Why not React?
  • The React experiment
• MVCS

Introduction

The POH Performance app is a series of aviation-related apps built around a common infrastructure. This is a brief history of the infrastructure.

Gen 0

The Gen 0 app was a spreadsheet for G36 Bonanza performance. It looked up performance data in the G36 tables entered in different worksheets and was ported to the spreadsheet app on Palm Pilot.

Gen 1

When the original iPhone came out, the only app development platform was building WebaApps. Mobile Safari had sufficient support of the Application Cache to enable running while disconnected, A key capability for an aircraft performance app.

The initial WebApp consisted of a lot of static HTML with Javascript to get results directly from the DOM nodes, do the computations, and insert the results directly into the DOM nodes.

The architecture had many deficiencies. It was difficult to support consistent mirroring and formatting of input and output values on multiple pages and the HTML and JavaScript were tightly tied together.

Gen 2

The Gen 2 app (major versions 2 through 4) was completely re-architected. Several public-domain frameworks were evaluated, but none seemed mature at the time, though Angular was very interesting. In the end, a custom Model, View, and Controller (MVC) framework inspired by Angular was designed.

• State variables combined the state, formatting, multiple units, and rendering of the dynamic parts of the View.
• Pages provided Model computations and a View template. State variables were used to specify dependencies and trigger Model computations.
• Page views were specified as a template tree using JavaScript objects representing semantic elements (not raw HTML elements) in a Web Component-like style. The templates used JavaScript objects due to the limitations of JS strings at the time. Each component in the template tree was responsible for rendering the component into an HTML string.
• The DOM tree was built from the root by building the HTML for the entire tree and inserting it into the root elements' innerHTML. The DOM tree was mostly static. Dynamism was accomplished through three mechanisms.
  • show/hide properties that could take state variables or functions
  • state variables references
  • state variable templates

This was a simple and flexible infrastructure. Its main problems were:

• The code to render the various state variable types accreted into a mass of spaghetti code over time. This was a huge impediment to implementing more sophisticated and dynamic user elements.
• The object representation of the component tree did not meet modern standards. It was chosen at the time because the earlier version of JavaScript did not have features like template strings, but that is no longer true.
• The implementation forced the entire tree to be synchronized since the show/hide properties could contain functions that could reference arbitrary variables.
• All functions and variables were globally visible in the ES5 namespace.

Gen 3

The next generation of infrastructure has several goals:

• Move to ES6 and more modern HTML and CSS
  The POH Performance ground rules state that an app should function on 5-year-old devices, even if they have not been updated. That means that ES6+ (ES201 through ES2020) is now viable. Arrow functions, spread operators, and destructuring would make the code more succinct and readable.
• Maintain State Variables and Model
  The generation 2 app successfully used state variables to consolidate state, verification, and formatting. It also provided a simple way to handle multiple display units, and input save/restore. It also provided the basis for triggering Model computation when input state changes and to handle error messages. All of this should be preserved.
• Fix State Variable and View spaghetti code
  As is typical of such systems, the state variable and associated view code grew incrementally over time. Since variable type, input vs. output, and formatting were all handled in one place, the code to handle these cases became very complex. This code needed to be refactored by type using polymorphism.
• Redo CSS to a more BEM-like style using relative units
  The gen2 CSS was originally designed before relative units were in wide use. Being responsive required many media breaks. A new design with very few fixed units will make the pages more responsive to form factor. The Block Element Modifier provides a common naming architecture for CSS that will improve understanding.

Alternatives

The Gen 2 app built a WebComponent-style tree that captures the view semantics with high-level components like Page or Group (a Card). This worked well, and a similar approach seemed desirable. React was the obvious choice. Potentially, React would allow the importation of third-party components. React did not have anything like State Variables, but that could be added. JSX seemed like a better, more familiar replacement for specifying the templates as objects. The following additional frameworks were briefly considered:

• Angular
• Aurelia
• Ember
• Inferno
• Mithril
• Svelte
• Ractive
• Vue

React + JSX + Webpack + Babel

Taking advantage of the React ecosystem entails buying into the whole Babel and Webpack infrastructure. Using third-party components can cause an uncontrollable number of dependent libraries to load. Using Babel, Webpack, and JSX causes a divergence between the source seen by the programmer and the code executed by the browser. Sourcemaps make up this difference 90% of the time, but it breaks debugging 10% of the time, and you are left debugging with console logging.

The nature of POH Performance applications is such that the packing, tree shaking, and minifying that Webpack does is not as valuable as it might be with normal apps. On mobile devices where the bandwidth might be constrained, all the source files are kept locally in native apps by the Cordova infrastructure. On desktop computers that use the WebApp, the bandwidth is usually quite good and loading time is minimal, and once loaded, the source files are kept locally by the application cache or Service Workers. Lastly, the code for the application itself is usually dwarfed by the airport and runway database, so minifying and packing the application code has little advantage.

Using Babel would have been very useful when ES6 support was rare in browsers. However, it’s been well over five years since browsers started supporting ES6. The information sent to the app’s backend server indicates that 99% of active users are running a browser or WebView that supports ES6. In short, Babel is no longer a huge advantage.

Alternatives to JSX + Webpack + Babel

As the React documentation notes, it’s possible to simply use the React library without Webpack or transpiling. When you do that, you need to decide on an alternative to JSX. The most JSX-like alternative is to use template strings to transform JSX-like syntax into a component tree for React. An existing library, htm, does just that. While there are advantages to compiling and optimizing JSX before runtime, htm does a very good job at caching, parsing data, and reusing it when able. In addition, once you take a template string approach, it is easy to extend JSX syntax where desired by simple modifications to the htm library. For example, adding Angular-like “{{stateVarName}}” to insert state variable data.

State Variables

The state variable infrastructure in Gen 2 apps ensures that the state is formatted uniformly, values are verified properly, and numeric data can be manipulated or viewed in different units (e.g., English or metric). This infrastructure was so useful that eliminating it for more distributed state management or libraries like Redux was not seriously considered. In addition, state variables were used to trigger Model computation and declare dependencies, which was also very useful.

Why not React?

React is a very flexible and general-purpose system. However, it does have quirks:

• React Components represent all similar Components in the app. The only way to get information for the specific element in the tree is to use constructs like useState(). This is un-DOM-like and a bit stilted. Similarly, you need to use useRef() to operate on individual DOM tree nodes where required.
• React relies on changing props or Contexts to know when something has changed. It’s easy to get into a situation where an element is not updated without realizing it.
• React implements a synthetic event dispatcher. This can impose non-standard behavior on certain events (e.g., onchange). However, this may also have an advantage in unifying cross-browser behavior, though this is less of an issue nowadays and since the demise of IE.

A huge advantage of using React would be to import third-party Components. However, as noted above, doing so would entail using Webpack and Babel since components rely on them to gather dependencies and smooth over syntax beyond ES2015. Given that, you're forced to debug with Sourcemaps. Also, since many components rely on other components, you quickly lose control of application dependencies.

Lastly, React is not the easiest paradigm for people to learn. The web is full of questions about "How do you do this in React?"

The React experiment

An experiment was done to use React under state variables and an early version of tml. The conclusion was that this is quite doable, but it avoids most of the React advantages, since third-party components would need to be translated to the non-JSX, non-Webpack environment.

MVCS

In the end, a rewrite of the Gen 2 system that took a lot of inspiration from React was chosen, as it seemed better to use state variables to uniformly trigger change in the Model and View and not fight to match this to React semantics. See the MVCS overview for a description. In any case, a future version could substitute React to implement the View or perhaps some of the new WebComponent frameworks.