Differences between MiniApp APIs and Web APIs

[espinr]

Among the aspects we need to agree on for the current specifications are if the MiniApp user agents must support [a subset of the] standard HTML elements and the rest of the technologies around Web Components (#160), the standard CSS, and the standard DOM for view (#162) and event manipulation.

As I presented in the meeting on 13th Jan, I did a brief research on some of the common APIs or services available in some of the MiniApps. Although the list of the APIs and the analysis of their functions are not exhaustive, we can see there is overlap with the W3C Web APIs (some of them under the incubation phase). This is the list of some of the APIs I showed on my slides:

Feature	Description	Similar Web API (or work in progress)
App	Get app information (version, name,.)	Navigator interface
Logging	Logging on the console.	Console API
Router	Routing control of the application.	(Usually at server-side and history Interface)
Resident	Runs the app in the background.	Cooperative Scheduling and Background Tasks
Share	Share content with other apps	Web Share API
Prompt	Pop-up dialog.	HTML dialog element
Webview	Management of web documents.	DOM window object, WICG’s Visual Viewport API
Notifications	Management of notifications.	Notifications API, Push API
Fetch	HTTP calls management.	Fetch API
Upload, Download	Upload and download files.	Fetch API
Web Sockets	Management of Web Sockets.	Web Sockets
Storage	App database management.	Web Storage
File System	In-device file system operations.	WICG’s File API
Exchange	Set and get data on the QA platform	Web Storage API
Media	Image and video management.	HTML media elements; MediaStream Image Capture
Image	Image edition.	HTML images, Shape Detection in Images API
Animations	Management of animations	Animation frames
Canvas	Access to and manipulation of the canvas element.	HTML canvas element
Video	Management of video documents.	HTML video element
Audio	Management of audio documents.	HTML audio element
Vibrator	Vibrator	Vibration API
Barcode	QR code readings	Barcode detection API
Sensor	Access to sensors (gravity, light, proximity, steps…)	Generic Sensor API, and several sensor specifications
Clipboard	Clipboard management.	Clipboard API and events
Geolocation	Geographical location.	Geolocation API
Calendar	Calendar events management.	Calendar API (discontinued)
Shortcut	Management of shortcuts (installations)	Service Workers (PWA installation)
Network	Get information of the network.	WIGC’s Network Information API
Device	Access to device & user info.	DOM Navigator object (only info about the browser)
Brightness	Screen brightness management (e.g., screen always on).	Screen Wake Lock API; Ambient Light Sensor API
Battery	Get status of the battery.	Battery Status API (deprecated for security reasons)
Audio Recording	Audio recordings.	MediaStream Image Capture
Volume	Management of the media volume.	Web Audio API
Package	Get information about apps installed.	Web App Manifest
Sms	Sending SMS messages.
Contact	Pick contacts.	WIGC’s Contact Picker API. Navigator.contacts
Wifi	Management of the WiFi connections.
Bluetooth	Manage the Bluetooth adapter.	Web Bluetooth CG Web Bluetooth API
Alarm	Set alarms on the device.
Configuration	Locale management, get orientation, etc.	Navigator interface (only info about the browser)
Encryption	To encrypt and decrypt objects.	Web Cryptography API

In summary:

• Most of the MiniApps APIs have equivalent WebAPIs (covering same functionalities with other implementations). These WebAPIs are already defined (several available in browsers, some experimental).
• There are some specific additions, depending on the type of MiniApp. Some differences:
  • Router API (Web Apps routing is implemented in the server)
  • Others depending on the device and OS, like SMS (Part of the Messaging API, discontinued for security reasons) or WiFi (to attach the device to networks)
  • The upcoming proposals for MiniApp IoT protocols and interfaces (e.g., I2C, UART, etc.)

So, following a similar approach as I proposed in #162, if we rely on the standard DOM and Web APIs, MiniApps could have access to these (and other) APIs.

If we could agree to use the standard WebAPIs, we can collect the APIs required and recommended by each MiniApp vendor in a Working Group Note, indicating the minimum set of APIs that a MiniApp user agent must implement. For those APIs that are not created yet (routing, IoT I/O pins, etc.) we can start defining them in parallel.

Comments? Thanks in advance.

[xfq]

FWIW, @Honry and @kenny-y also did a comparison in 2019: https://w3c.github.io/miniapp/white-paper/comparison.html

[espinr]

FWIW, @Honry and @kenny-y also did a comparison in 2019: https://w3c.github.io/miniapp/white-paper/comparison.html

Thanks, @xfq . I'll update the list created by @Honry and @kenny-y .

[espinr]

I've included some styles to the table to easily visualize the differences.
https://raw.githack.com/espinr/miniapp/table-colors/white-paper/comparison.html (If you like it, I can submit a PR)

A summary of the analysis we can include in the white paper:

The comparison table identifies and highlights the differences between Progressive Web Applications (PWA) and various MiniApp implementations. In broad terms, one of the significant differences between these technologies is the execution environment. PWA may run in almost any web-enabled environment in a browser, while MiniApps are bound to specific platforms -primarily Android. Another essential difference is the distribution mechanisms, with MiniApps packed and self-contained and the PWA's resources distributed across the Web.

Both technologies use similar programming and markup languages and CSS-based stylesheets in terms of coding. MiniApps implements dedicated domain-specific languages based on HTML subsets and specific mechanisms for data binding and event management, following the MVVM paradigm with Virtual DOM management.

In terms of services, PWA and MiniApp developers have access to APIs with the same purpose and equivalent features but not following the exact specifications.

MiniApp vendors include exclusive APIs oriented to the app release and distribution management through their own channels, also other dedicated APIs tied to concrete scenarios and the running platform -e.g., services to set up reminders using the device's native alarm and calendar features, perform phone calls and trigger performance warnings.

[xfq]

https://raw.githack.com/espinr/miniapp/table-colors/white-paper/comparison.html (If you like it, I can submit a PR)

Looks great. Please submit a PR!

[xfq]

MiniApps are bound to specific platforms -primarily Android

I don't think we need to mention this. It would give people the impression that MiniApps are only or primarily for Android. But in fact PCs (like 360 and WeChat MiniApps), HarmonyOS, iOS, and cars/TVs/IoT devices (I'm not sure what OS they use) can also run MiniApps.

[espinr]

Thanks @xfq , I agree.
I will remove that annotation.

[espinr]

My apologies for the late update (#188), I was waiting for the HTML version but I forgot to include this part once it was published here. In any case, if it is too late, this update does not affect the White Paper, it complements the PWA-MiniApp Gap section.

[espinr]

PR merged. So, I'm closing this issue.