Should we mention W3C Widgets in the FAQ?

[xfq]

Because people asked about the difference between miniapps and W3C Widgets (and what lessons we learned from widgets) more than once in previous meetings, should we consider adding some content to the FAQ?

I am not very familiar with W3C Widgets, and maybe someone who is more familiar with the history of it can write it better.

I think the similarities between the two are that both are zip packages and weblike applications, and the differences include:

• the digital signature method used
• whether HTML is directly supported
• format of the manifest

In addition, miniapps already have a massive user base, so some technologies have enough practice. I think this is a big difference between the two.

[xfq]

About offline experiences, the current web uses service workers, while in MiniApps (and Widgets?) offline experience is achieved by downloading the 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.

[xfq]

Related: w3c/miniapp-white-paper#5

[marcoscaceres]

I'm familiar with Widgets, but not (yet) with the MiniApps work... so I'm happy to help - but might have to be a collaborative thing.

[marcoscaceres]

Compared with web apps, MiniApp developers can focus more on business logic instead of caching static resources.

That's a tradeoff (or potential disadvantage of Miniapps, in some sense)... does the packaging format support delta updates?
For a game, for example, you might need to re-download hundreds of MB of assets every time the app gets an update. With SW, you can selectively eject and download just the resources that have changed.

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.

I guess this is the same as SW... except SW update themselves in the background as needed.

[tomayac]

I'm familiar with Widgets, but not (yet) with the MiniApps work... so I'm happy to help - but might have to be a collaborative thing.

@marcoscaceres, maybe my article series can help change that?!

[xfq]

Compared with web apps, MiniApp developers can focus more on business logic instead of caching static resources.

That's a tradeoff (or potential disadvantage of Miniapps, in some sense)... does the packaging format support delta updates?
For a game, for example, you might need to re-download hundreds of MB of assets every time the app gets an update. With SW, you can selectively eject and download just the resources that have changed.

I agree that's a tradeoff.

Currently, developers can divide a MiniApp into a few sub-packages, and the user agent can load the sub-packages as needed when the MiniApp is used. Through sub-packaging, the size of the main package can be reduced. In theory, the sub-packages can be dynamically updated, but it depends on the build automation and sub-packaging mechanism of the platform.

However, most MiniApps at present are only a few megabytes in size, so this demand is not that strong.