Comparison of MiniApps and web apps

Overview

This document summarizes the differences of MiniApps and web apps. Although the API and implementation of each MiniApp platform are different, due to time constraints, the editor can only summarize a subset of them.

The first chapter of the MiniApp Standardization White Paper contains some comparison from the user's point of view. The following text mainly documents the differences from the implementer's and developer's point of view.

A MiniApp runs in a hosting platform (aka hosting environment or user agent). A hosting platform can be a native app (similar to a web browser), or (an engine embedded in) the operating system.

MiniApps usually need to be reviewed by the hosting platform to go online, and web apps just need to have a web server (and optionally a domain name) to go online.

A MiniApp includes a global [[[#manifest]]] file and zero or more page manifest files. The manifest files are usually in JSON.

See MiniApp Packaging for a typical example of directory structure of a MiniApp.

The running environment of MiniApps is divided into a view layer and a logic layer. The view layer only deals with rendering and listens out for the events happening. The logic layer only deals with data and logic.

The logic layer is usually written in JavaScript. It processes the data and sends it to the view layer, and receives feedback from the view layer.

Although using Web technologies, MiniApps usually does not run in the browser, so some capabilities of JavaScript in the Web are not available, such as document and window.

In a web app, rendering and script can block each other, which is why a long script running may cause the page to become unresponsive, but in a MiniApp, the two are separated and run in different threads. Web page developers can use the DOM APIs exposed by the browsers to do DOM manipulation. But since the logic layer and view layer of a MiniApp is separated, the logic layer (running in JavaScriptCore, for example) does not contain a document or window object, and can't use some web APIs. Therefore, some libraries like jQuery cannot run in MiniApps. Moreover, since the JavaScriptCore environment is not the same as Node.js, some npm packages cannot be run in MiniApps either.

In the [[[#view]]], the hosting platform will convert the layout language (WXML, for example) into a JavaScript object. When data changes in the logic layer, the data is passed from the logic layer to the view layer through a method provided by the hosting platform, and then the diff of the DOM before and after is generated. After that, the differences will be applied to the original DOM tree and render the changed UI.

View layer

There is usually a markup language with a template mechanism (such as WXML, swan, AXML, TTML etc.) for the view layer of the MiniApp pages, which is similar to HTML in Web development. The MiniApp runtime translates the markup language into HTML (each page is rendered in a different WebView, but all WebViews shares the image cache) or native code.

When styling a MiniApp page, CSS is usually used, sometimes with extensions such as responsive pixels (aka density-independent pixels).

The elements used in the view layer are described in the [[[#components]]] section.

Here are some examples:

<!-- xxx.swan -->
<view>
  Hello My {{ name }}
</view>

// xxx.js
Page({
    data: {
    name: 'SWAN'
    }
});

<view>
    <view s-for="p in persons">
    {{p.name}}
    </view>
</view>

Page({
    data: {
    persons: [
        {name: 'superman'},
        {name: 'spiderman'}
    ]
    }
});

  <view s-if="is4G">4G</view>
  <view s-elif="isWifi">Wifi</view>
  <view s-else>Other</view>

Page({
    data: {
    is4G: true,
    isWifi: false
    }
});

<view> Hello {{name}}! </view>
<button bindtap="changeName"> Click me! </button>

// This is our data.
var helloData = {
  name: 'WeChat'
}

// Register a MiniApp page.
Page({
  data: helloData,
  changeName: function(e) {
    // sent data change to view
    this.setData({
      name: 'MiniApp'
    })
  }
})

<view>
  <view class="test" style="background:{{background}};color:{{color}};height:{{height}}">This can be changed.</view>
  <button bindtap="changeStyle">Change the style</button>
</view>

/* The rpx unit does not exist in standard CSS, but since this is not the point of the
   example, it will not be explained in this section. */
.test {
  height: 150rpx;
  line-height: 150rpx;
  text-align: center;
  border: 1px solid #89dcf8;
  margin-bottom: 112rpx;
  margin: 13rpx;
}

Page({
  data: {},
  changeStyle: function() {
    this.setData({
      background: "#89dcf8",
      color:'#ffffff',
      height:"322rpx"
    })
  }
})

Pages

A MiniApp page represents a page of the MiniApp and is responsible for page display and interaction. Each page usually corresponds to a directory in the MiniApp package.

Each MiniApp page generally contains a JavaScript file for the logic layer, a template file for the [[[#view]]], and optional CSS and JSON files for page styling and metadata.

For each page in a MiniApp, the developer need to register in the JavaScript file corresponding to the page, and specify the initial data, lifecycle callback, event handlers, etc. of the page in the Page constructor.

  // index.js
  Page({
    data: {
      text: "This is page data."
    },
    onLoad: function(options) {
      // Execute when the page is created
    },
    onShow: function() {
      // Execute when the page appears in the foreground
    },
    onReady: function() {
      // Execute when the page is rendered for the first time
    },
    onHide: function() {
      // Execute when the page changes from the foreground to the background
    },
    onUnload: function() {
      // Execute when the page is destroyed
    },
    onPullDownRefresh: function() {
      // Execute when a pull-down refresh is triggered
    },
    onReachBottom: function() {
      // Execute when the page is scrolled to the bottom
    },
    onShareAppMessage: function () {
      // Execute when the page is shared by the user
    },
    onPageScroll: function() {
      // Execute when the page is being scrolled
    },
    onResize: function() {
      // Execute when the page size changes
    },
    // Event handler
    viewTap: function() {
      this.setData({
        text: 'Set some data for updating view.'
      }, function() {
        // this is setData callback
      })
    },
    // Custom data
    customData: {
      hi: 'MiniApps'
    }
  })

Behaviors (similar to mixins or traits in some programming languages) can be used to make multiple pages have the same data fields and methods.

  // my-behavior.js
  module.exports = Behavior({
    data: {
      sharedText: 'This is a piece of data shared between pages.'
    },
    methods: {
      sharedMethod: function() {
        this.data.sharedText === 'This is a piece of data shared between pages.'
      }
    }
  })


  // page-a.js
  var myBehavior = require('./my-behavior.js')
  Page({
    behaviors: [myBehavior],
    onLoad: function() {
      this.data.sharedText === 'This is a piece of data shared between pages.'
    }
  })

Components

MiniApps usually prohibit the use of some HTML elements, and add some new components (elements), such as swipers, commonly used icons (warning, search, setting, loading etc.), maps, rich text editors, advertisement and so on.

  ├── app.js
  ├── app.json
  ├── project.swan.json
  └── components
      └── custom
          ├── custom.swan
          ├── custom.css
          ├── custom.js
          └── custom.json

  Component({
      // ...
      pageLifetimes: {
          show: function() {
          // Triggered when the page where the component is located is displayed
          },
          hide: function() {
          // Triggered when the page where the component is located is hidden
          }
      }
      // ...
  });

Manifest

MiniApp uses JSON-based manifest file to enable the developer to set up basic information, window style, page route and other information of a MiniApp.

      {
        "dir": "ltr",
        "lang": "en-US",
        "appID": "org.w3c.miniapp",
        "appName": "MiniApp Demo",
        "shortName": "MiniApp",
        "versionName": "1.0.0",
        "versionCode": 1,
        "description": "A Simple MiniApp Demo",
        "icons": [
          {
            "src": "common/icons/icon.png",
            "sizes": "48x48"
          }
        ],
        "minPlatformVersion": "1.0.0",
        "pages": [
          "pages/index/index",
          "pages/detail/detail"
        ],
        "window": {
          "navigationBarTextStyle": "black",
          "navigationBarTitleText": "Demo",
          "navigationBarBackgroundColor": "#f8f8f8",
          "backgroundColor": "#ffffff",
          "fullscreen": false
        },
        "widgets": [
          {
            "name": "widget",
            "path": "widgets/index/index",
            "minPlatformVersion": "1.0.0"
          }
        ],
        "reqPermissions": [
          {
            "name": "system.permission.LOCATION",
            "reason": "To show user's position on the map"
          },
          {
            "name": "system.permission.CAMERA",
            "reason": "To scan the QR code"
          }
        ]
      }
    

The MiniApp Manifest comparison with Web App Manifest shows similarities between the 2 formats.

To facilitate the life of developers wanting to deploy a web app and a MiniApp of the same application, it would be beneficial to:

1. Use the Web App Manifest as the base format, since all properties in Web App Manifest are optional. Indicate which Web App Manifest properties are relevant, the set of restrictions applied to the values (such as only using local URLs for the pages). When backward compatibilities is needed, indicate so and recommend using duplicate values (the frameworks can make that transparent).
2. For properties that are specific to MiniApp, consider using a prefix or add them to a miniapp property to avoid future compatibility issues. For each MiniApp-specific property, consider raising an issue against the Web App manifest specification for future adoption in Web App manifest (such as the properties supported under window).
3. For permissions, consider re-using the same features used by document.featurePolicy.features(), e.g., "geolocation", "gamepad", "magnetometer", "accelerometer", "xr-spatial-tracking", "picture-in-picture", "camera", "payment", "pointer-lock", etc. Again, a prefix may be used for MiniApp specific features.

Packaging

Since MiniApps are downloaded to the user's local device and run in the form of a package, the MiniApp itself does not have an "origin" (because there is no domain), and there is no "cross-origin".

Developers can divide the MiniApp into a few sub-packages, and the user agent can load the sub-packages as needed when the MiniApp is used. Dividing a MiniApp into reasonable sub-packages according to business characteristics can increase the loading speed of MiniApp and optimize the user experience.

In addition, through the manifest file or MiniApp APIs, developers can preload some sub-packages when the user accesses a certain page of the MiniApp.

See also the packaging explainer for a primer.

Runtime

Lifecycle

MiniApps implementations provides some lifecycle events and the process to manage the whole MiniApp and each page's lifecycle. See the MiniApp Lifecycle specification for a typical example.

There are two ways to open a MiniApp:

• Cold launch: when the user opens the MiniApp for the first time (or the user exited the MiniApp for a long time, or opened too many MiniApps, causing this MiniApp to be destroyed);
• Hot launch: when the user reopens a MiniApp within a certain period of time;

When the MiniApp is cold-launched, the hosting platform will use the local package to load the MiniApp, and at the same time, it will automatically detect whether there is a new package version in the cloud and download it asynchronously. After the download is complete, the new version of the package will be used when the user triggers a cold launch next time.

  // pages/index/index.js
  Page({
    data: {
      title: "Alipay",
    },
    onLoad(query) {
      // Execute when the page is created
    },
    onShow() {
      // Execute when the page appears in the foreground
    },
    onReady() {
      // Execute when the page is rendered for the first time
    },
    onHide() {
      // Execute when the page changes from the foreground to the background
    },
    onUnload() {
      // Execute when the page is destroyed
    },
    onTitleClick() {
      // Execute when the title is clicked
    },
    onPullDownRefresh() {
      // Execute when a pull-down refresh is triggered
    },
    onReachBottom() {
      // Execute when the page is scrolled to the bottom
    },
    onShareAppMessage() {
     // Return to custom sharing information
    },
    // Event handler
    viewTap() {
      this.setData({
        text: 'Set data for update.',
      });
    },
    // Event handler
    go() {
      my.navigateTo({url:'/page/ui/index?type=mini'});
    },
    // Custom data
    customData: {
      name: 'alipay',
    },
  });

Navigation

To jump from one MiniApp to another in the same hosting platform, platform-specific API or component is usually used. For example, WeChat Mini Programs has a wx.navigateToMiniProgram(Object object) method and a navigator component:

  wx.navigateToMiniProgram({
    appId: 'com.company.miniapp', // See https://w3c.github.io/miniapp/specs/manifest/#appid
    path: 'page/index/index?id=123', // If it is empty, open the homepage of the MiniApp
    extraData: {
      foo: 'bar'
    },
    envVersion: 'develop', // The version of the MiniApp to open. Valid values: `develop`, `trial`, and `release`.
    success(res) {
      // Success
    }
  })

<!-- `target` can be `self`, which means the current Mini Program,
or `miniProgram`, which means another Mini Program. -->
<navigator target="miniProgram" open-type="navigate" app-id="com.company.miniapp" path="" extra-data="" version="release">Open a MiniApp</navigator>

Some MiniApp implementations also support the a element in HTML.

Jumping from one MiniApp to another MiniApp in a different hosting platform is currently not supported. MiniApp URI Scheme is a proposal to fix this issue.

Offline

In web apps, service workers provide the technical foundation for offline experiences. It is a script that the browser runs in the background and can intercept and handle network requests, including programmatically managing a cache of responses.

While in MiniApps, offline experience is achieved by downloading the MiniApp package to the user's device and updating it when needed.

Compared with web apps, MiniApp developers can focus more on business logic instead of caching static resources. The caching and update mechanism of the MiniApp package is automatically managed by the MiniApp hosting platform, and if needed, developers can influence this process through APIs provided by the hosting platform.

APIs

MiniApp platforms usually provide their own APIs, some have corresponding web APIs, some do not. See a comparison here.

Performance

Security and privacy

Since MiniApps run in the hosting platform, in a native app people only care about whether there are vulnerabilities in the app itself, in a MiniApp people also need to know whether the hosting platform is secure.

Native apps will directly invoke system APIs, so many vulnerabilities are related to the operating system version, such as the WebView version in the user's operating system. However, beacuse some MiniApp implementations use their own browser engines (see [[[#runtime]]]), if the engine mitigates the vulnerability, there is no need to consider the impact of this vulnerability even on low-version operating systems. On the other hand, if there is a vulnerability specific to the browser engine in the MiniApp hosting platform, it will affect the MiniApps but not other parts of the system.

Since MiniApps can not access DOM and the global object window (by seperating the view layer and the logical layer execution environment), and can only use the APIs and components the user agents provide, so it is not possible (or very difficult) for malicious code to jump to a random web page or MiniApp, or change the content on the UI. Since there are MiniApps components that can display sensitive data like username, avatar, gender, and geolocation etc., if developers can manipulate the DOM, it means that they can get user's sensitive information at will.

Since most MiniApp implementations disallow dynamic code loading like eval and new Function, XSS is very difficult.

MiniApps usually have a domain name safelist, to permit scripts contained in a MiniApp to access data from a URL only when the domain name is in the safelist.

Since MiniApps restrict the use of cookies, CSRF attacks is harder in MiniApps than normal web apps.