MiniApps Standardization Overview
Hello, I'll continue Zitao's speech. The establishment of the W3C during the Spring Festival of 2021 marked a significant milestone in the development of the miniApp Working Group. Over the past two years, our focus has steadfastly remained on achieving the initial goals, which encompassed aspects such as the structure of the miniApp package, configuration files, and standards pertaining to the lifecycle. In parallel, we've diligently worked towards addressing various challenges, nurturing projects centered around cards, and advancing the development of UI components. The decision to collaborate with the W3C was motivated by several factors.
Notably, the miniApp ecosystem, originating from China, has extensively leveraged underlying web technologies. Consequently, as these foundational technologies continue to evolve, it's imperative to consider the specific scenarios unique to miniApps. Additionally, our objective is to foster a symbiotic relationship between miniApps and the web, elucidating the similarities and shared functionalities between the two platforms through the establishment of mappings on certain APIs. The W3C miniApp Working Group was established with the objective of addressing the challenges arising from the diverse range of platforms available for miniApps.
These miniApps, while sharing fundamental functionalities, exhibit variations in their API definitions and components across different platforms. The aim is to mitigate these disparities by means of standardization. One proposed approach involves miniApp vendors incorporating the established standards directly into their platform development process. A consensus can be reached among all stakeholders to establish a shared intermediate state mapped onto their respective platforms. This approach seeks to provide a comprehensive solution that not only ensures connectivity but also resolves interoperability.
The formation of the W3C miniApp Working Group stemmed from the recognition of this need. Prior to its establishment in 2021, an incubation phase was undertaken for a duration of over two years. Today's presentation serves as an update on the progress achieved thus far within the working group. Should you have any queries, I welcome an open discussion on the topic. In the realm of digital applications, miniApps are emerging as a novel infrastructure that extends beyond conventional web and mobile applications. In China, numerous internet companies and vendors now consider miniApps as an indispensable feature when developing their own applications.
To cater to diverse user bases, it has become customary to make miniApps available on various platforms including iOS, Android, web, and miniApp platforms. Consequently, miniApps have evolved into a fundamental foundation for internet services. Looking ahead, it is anticipated that miniApps will face new challenges as they strive to support more resource-intensive operations such as audio and video, while maintaining optimal performance.
The diagram provided above illustrates the initial focus on mobile devices, encompassing smartphone operating systems like Huawei and Xiaomi, as well as integration into prominent Chinese apps operating within super apps. Despite variations in specific implementations, the underlying architecture relies on runtime and framework components. Ongoing efforts in standardization are currently addressing crucial aspects such as APIs and manifest packaging. The proliferation of miniApp applications in China has reached unprecedented levels, with users considering them a standard offering across various platforms. Notably, the automotive sector has witnessed a remarkable surge in the adoption of these miniApps, as Chinese manufacturers embrace smart automotive solutions. It has led to a growing trend of users updating their miniApp applications directly on their car's infotainment system, thereby enhancing the overall user experience.
Most Chinese manufacturers specializing in intelligent automotive solutions primarily interact with their user base through the utilization of smartphones and in-vehicle infotainment systems. The development approach of miniApps allows for seamless deployment across multiple platforms using a single codebase. This multifunctionality has become pervasive, enabling at least one miniApp platform developer to run the same codebase on different platforms. The W3C miniApp Working Group was also working on it, but out current focus and capacity remain limited. Specifically, further exploration of scenarios and opportunities within the automotive sector has yet to be thoroughly explored. So we extend an invitation to interested experts to join our group, where we can engage in specific discussions and delve deeper into this domain.
In addition to the Working Group, we also have a dedicated community group aimed at incubating new directions. We warmly welcome your participation. This passage is an excerpt from the recently published miniApp whitepaper, which was released in the first half of the year. One of the key contributors to this chapter was Zitao.
Within this section, we engaged in multiple rounds of discussions to examine the disparities between miniApps and PWA. Fundamentally, the primary distinction lies in the extent to which the application operates within a WebView. miniApps solely employ WebView for specific sections that require web capabilities, whereas PWAs operate entirely within WebView and are supported by a subset of W3C standards. This substantiates our belief that miniApps possess a strong association with W3C standards, as numerous functionalities rely on WebView implementation. While avoiding unnecessary intricacies, the associated feature points bear considerable similarity, with certain variations in implementation.
We are actively exploring avenues to address these disparities, whether through the reuse of existing W3C standards or the proposal of new ones. As mentioned on the preceding page, the architecture of miniApps also encompasses several design considerations. During our initial discussions at W3C, we deliberated on whether miniApp runtime should mirror that of the web.
However, we ultimately concluded that there are indeed disparities in the runtime, prompting the establishment of distinct specifications for miniApp packaging, manifest, and lifecycle. Although web standards already exist, the divergent runtime characteristics necessitated these specifications when considering the demand for uniformity. However, it has also necessitated the need to establish a relationship between miniApps and the web within our specifications. For instance, our miniApp manifest builds upon the existing web app manifest specification by incorporating specific fields relevant to miniApps. Allow me to introduce our working group and the ongoing initiatives we are undertaking.
Since its inception in 2021, our working group has set forth the ambitious goal of defining multiple specifications as outlined in our charter. We are concurrently focusing on manifest packaging and lifecycle. Additionally, we are addressing various miniApp-related topics through group notes, including miniApp addressing and widget requirements, commonly referred to as "cards" in the Chinese context.
The development of these standards has been primarily facilitated through collaborative efforts among key industry players such as Huawei, Xiaomi, Baidu, and Alibaba. Together, we are actively driving the formulation of these standards. Allow me to present a concise summary of the fundamental aspects outlined in the specifications. Firstly, led by Zitao, the miniApp manifest plays a pivotal role in configuring miniApps. This file serves as a crucial initial step in recognizing and displaying miniApp packages obtained from various platforms.
The manifest encompasses essential information about the miniApp and incorporates additional elements, such as i18n, through collaborative discussions at W3C. These elements primarily pertain to static information and do not entail runtime support, thus facilitating relatively straightforward implementation. Secondly, developers define the structure of the miniApp package during the pre-compilation phase. Within this package, the aforementioned manifest specification is present, alongside global-level logic and layout for JavaScript (JS) and Cascading Style Sheets (CSS). Given that miniApps consist of multiple pages, each page possesses its own JS, HTML, and CSS files.
Additionally, the package encompasses reusable components, i18n JSON files, as well as mechanisms for compression and signing. Numerous intricate details are currently under discussion within W3C, including exploration of possibilities such as reusing Web bundles and implementing the same-origin policy from the Web perspective. Our working group has recently engaged in extensive deliberations on several directions that will be investigated in collaboration with TAG, aiming to support the foundational concept of "One Web."
This section pertains to the Lifecycle aspect, which necessitates runtime-level support, encompassing both global application and page lifecycles. This entails handling various stages, including startup, display, background hiding, error handling, and destruction, among other considerations. A comprehensive set of mechanisms has been devised to effectively manage this lifecycle. Moving on to miniApp Addressing, this crucial specification has been spearheaded by colleagues from Baidu.
It assumes a paramount role in ensuring that miniApp packages can be accessed across different vendors, opened by browsers, and discovered through search engines. Addressing defines the method through which URI serves as the core element enabling searchability and parsing. It is worth noting that the inclusion of addressing in the working group's rechartering would have been advisable, considering the current stage of maturity and the intention to progress through the formal W3C REC-track process. Widgets, advocated by colleagues from Xiaomi, represent a specialized form within the miniApp ecosystem.
These widget formats resemble card-like structures that occupy designated areas on the screen. The presentation format of miniApps, at present, is flexible and not restricted to selection from a dropdown menu within a super app scenario. They can be embedded in various contexts, such as chat conversations or accessed directly through office software. Basic functionality, including conducting simple surveys, can be achieved through inputting commands. This represents a novel form and marks the initial step in clarifying requirements. We have made significant progress in defining specifications for miniApps, with a particular focus on their reusability in widgets and the implementation of additional extensions.
To ensure the effectiveness and reliability of these specifications, rigorous testing is being conducted as part of the W3C standardization process. Interoperability testing among various vendors is underway, with a particular emphasis on updating and refining existing specifications as needed. Additionally, the development of comprehensive test cases is underway to establish a solid foundation for conducting interoperability testing among all stakeholders.
While UI components are still in the incubation phase, they have reached a relatively advanced stage within our CG. The primary objective is to achieve consistency among miniApp vendors in terms of essential components such as images, progress bars, text input boxes, buttons, and container components like tabs and swipers. These components are widely used and therefore require standardization within the miniApp ecosystem. At present, the focus remains on establishing a certain level of standardization within the miniApp domain, with considerations regarding the relationship with the web being handled within the CG. The ultimate aim is to address the interoperability challenges faced by developers working on miniApps and optimize interoperability points among our miniApp vendors, particularly by standardizing the fundamental components. Let me provide a succinct overview of the current W3C process.
Within the realm of miniApps, the initial stages of development take place in the CG, where novel concepts and scenarios are explored and cultivated. Once these ideas reach a level of maturity, they progress to the WG stage. However, this advancement necessitates amendments to the charter and the unanimous approval of all W3C members. The ultimate objective is to publish a Recommendation. Regular meetings are held, both within the CG and WG, to deliberate upon pertinent matters. Further details regarding these meetings can be accessed via the provided links.
Experts interested in participating in these discussions are encouraged to join our group. These are the introductions of miniApp. Let's thank An Qing for his presentation. Now, we have online participants as well, so please feel free to discuss any questions regarding our working group.
We have allocated five minutes for this discussion. You can raise your hand and I will pass the microphone to you. Please begin by introducing yourself. I am Ling Shi from Huawei. I would like to inquire about the considerations and differences between the miniApp components and web components standards that were mentioned earlier.
Zitao would be able to provide a better answer to this question. Thank you, Ling Shi. In the realm of web components and miniApp components, An Qing has previously elucidated our primary objective of minimizing development discrepancies resulting from corporate branding across different platforms.
Our focus was primarily on creating universal components, such as image sliders and general-purpose components, to foster a sense of uniformity. At first, we worked on general components, such as images slides, and components like that. However, as we delved deeper into the development process, we recognized that harmonizing this aspect necessitates minimal exertion and fails to address the most pressing concerns for developers. The crux of the challenge lies in comprehending the disparities between existing architectures, such as the web components proposed by the W3C, and the deployment-specific intricacies of miniApps. By meticulously documenting these distinctions, our aim is to streamline the transition for developers, whether they are transitioning from HTML5 to miniApps or vice versa.
Among the key issues we have identified is the employment of one-way data binding and the obstacles presented by the segregation of rendering and logic within the miniApp framework. The definition of components and their description in miniApps differs from the traditional DOM-based approach used in web development. In our latest standards, we have explicitly explained why components are designed this way in miniApps and what the underlying logic is, as well as the differences between miniApp components and web components. After documenting these differences, our next step is to outline the logic and implementation of basic components in our defined standards. Our focus is on providing developers with clear guidelines on how to define, customize components, and the coding practices. We have included detailed information in our latest documentation, which I believe provides comprehensive insights into this topic within the industry.
I believe that moving forward, one key focus is to standardize and align various aspects. On one hand, it is important to integrate existing W3C standards into the popular development logic of miniApps or lightweight applications, while respecting the current W3C architecture. This includes incorporating concepts such as one-way data binding and separating rendering from logic. Such efforts are highly meaningful and can directly facilitate seamless integration and compatibility between W3C and miniApps.
Ling Shi, do you have any other thoughts on this matter? Regarding the components in miniApps, they provide developers with the freedom to extend functionality or potentially form a community similar to other open-source communities. Such a community could freely expand and create standardized new components. This is indeed our vision. To achieve this, we will need to explore extensions to the development mechanisms and ensure compatibility with the existing customization practices within W3C. This will be a key focus for our working group moving forward.
2023-08-28 13:25
