Cross-Platform (Web-based) Apps: Challenges and Opportunities

Martin Alvarez-Espinar

WebEvolve 2025

Hangzhou (🇨🇳), 05 September 2025

Light apps ecosystem

Several MiniApp versions depending on SuperApps

Light apps

Incremental image from previous one, plus several for Android, including WebAPKs, Instant Apps, Quick Apps...

Challenges

Development: how to code my MiniApp for n+1 SuperApps
- Specific elements, APIs, ...
- Scripts, third-party libraries...
- Architecture and performance
Publication: how to deliver it on different platforms (i.e., registration, validation, maintenance)
Versioning and maintenance...

Taro: Cross-Platform Framework

Conversion & distribution as…

HTML5
React Native
Mini-programs: WeChat, Jingdong, Baidu, Alipay, ByteDance, QQ, DingTalk, Alipay IOT...

Based on System’s WebView (or Tencent’s X5 WebView) or React Native WebView

Taro Sample Code

<View className='at-article'>
    <View className='at-article__h1'>
      这是一级标题这是一级标题
    </View>
    <View className='at-article__info'>
      2017-05-07   这是作者
    </View>
    <View className='at-article__content'>
      <View className='at-article__section'>
        <View className='at-article__h2'>这是二级...</View>
        <View className='at-article__h3'>这是三级...</View>
        <View className='at-article__p'>
          这是文本段落。这是文本段落。这是文本段落...
        </View>
        <View className='at-article__p'>这是文本段落</View>
        <Image className='at-article__img' src='https...'/>
      </View>
    </View>
  </View>

Source

What is rendered

<div class="taro_page" style="min-height: 100%;">
    <div class="page">
      <div class="doc-header">
        <div class="doc-header__title">Article 文章</div>
      </div>
      <div class="doc-body">
        <div class="panel">
          <div class="panel__title">示例</div>
          <div class="panel__content no-padding">
            <div class="at-article">
              <div class="at-article__h1">这是一级标题这是一级标题</div>
              <div class="at-article__info">2017-05-07   这是作者</div>
              <div class="at-article__content">
                <div class="at-article__section">
                  <div class="at-article__h2">这是二级标题</div>
                  <div class="at-article__h3">这是三级标题</div>
                  <div class="at-article__p">这是文本段落。</div>
                  <div class="taro-img"><img class="taro-img" src="http...">
                </div>
            ...

Another example

<div class="panel">
  <div class="panel__title">Custom colors</div>
  <div class="panel__content">
    <div class="example-item">
      <div class="at-timeline">
        <div class="at-timeline-item">
          <div class="at-timeline-item__tail"></div>
          <div class="at-timeline-item__dot"></div>
          <div class="at-timeline-item__content">
            <div class="at-timeline-item__content-item">
              Brush your teeth and wash your face
            </div>
          </div>
    </div>
    <div 
      class="at-timeline-item at-timeline-item--green">
      ...

Another Example: Divider <hr>

Header dividers rendered in a smartphone

<div class="at-divider">
  <div class="at-divider__content" 
      style="color: red;">
      No more
    </div>
  <div class="at-divider__line" 
    style="background-color: red;">
  </div>
</div>

Examples simplified for readability.

(Some of us) can see it properly, but...

Not optimal for:

AI, SEO: No semantics
Accessibility: No structure for assistive tools (e.g., screen reader)
Portability: What if I have a good and accessible H5 page?
Performance: Heavy CSS, markup files?

Wait...

W3C Core Standards are optimal for:

AI, SEO: No Full semantics
Accessibility: No Full structure for user assistants (e.g., screen reader)
Portability: I have a good and accessible H5 page. Just share the URL
Performance: Heavy CSS, markup files? Platform optimizations based on standards

Need for a Standard?

In 2021, Taro proposed an RFC on common usage of markup to benefit of the directly use of HTML5 standards.

We hope to reduce the cost of migrating [HTML5] applications to Mini Programs, and even run them directly in Mini Programs

Taro's RFC

Taro’s H5/MiniApp Mapping

HTML elements	Mini Program components	Difference in attributes
Block-level text	view
Inline text	text
span	view
img	image
a	navigator	href ->url; target ->openType
input	input	autofocus ->focus; readonly ->disabled; ...
input["type=checkbox"]	checkbox
input["type=radio"]	radio
button	button	type=submit ->form-type=submit ...
textarea	textarea
progress	progress	value, max ->percent
label	label
form	form
audio	audio
canvas	canvas
video	video
iframe	web-view
slot	slot

Isn't it a Good Idea?

Why not use existing (mature) standards?

Case Study: MiniApps

CSS: subset of CSS3 (+a few additions)
Scripting: ECMAScript with limited execution
Markup: ~HTMLish domain-specific language
APIs: platform-specific, but similar functionality of Web APIs

See the standards gap analysis of MiniApp APIs and MiniApp elements.

MiniApps APIs Gap

Type	API	Description	#1	#2	#3	#4	2+	Standard
Data management	Data storage	Get, set key=value pairs	yes	yes	yes	yes	yes	Storage API (IndexedDB API), Web Storage API
	File system management	Storage, management in the local file system	yes	yes	yes	yes	yes	File System API, File and Directory Entries API
	Data exchange with other MiniApps	Data exchange between installed apps	yes		yes	yes	yes	Broadcast Channel API, Channel Messaging API
	Compression/Decompression	ZIP file management	yes	yes		yes	yes
	Clipboard	Clipboard set/get	yes	yes	yes	yes	yes	Clipboard API
	Cryptography	Encryption, decryption, random	yes		yes	yes	yes	Web Crypto API
	Cache	Cache management (rules, cleaning, etc.)				yes		Content Index API
Sensors	Accelerometer	Sensors	yes	yes	yes	yes	yes	Sensor APIs (Accelerometer)
	Compass	Sensors	yes	yes	yes	yes	yes	Sensor APIs (Magnetometer)
	Gyroscope	Sensors	yes	yes	yes	yes	yes	Sensor APIs (Gyroscope)
	Proximity sensor	Sensors	yes					Proximity Sensor
	Step counter	Sensors	yes		yes	yes	yes
	Ambient light sensor	Sensors						Sensor APIs (Ambient Light)

MiniApps Markup Elements

Type	Feature	Style?	Funct.?	Rec?	Standard solution?
Container	Content division			`<div>`	direct usage
	Inline container			`<span>`	direct usage
	Dialog			`<dialog>`	direct usage
	Stacking container	yes		`<div>`*	HTML + CSS (`div { position: relative; }`)
	Slideshow (carousel)	yes		`<div>`*	HTML + CSS Flexbox + `overscroll-behavior` + `scroll-behavior`...
	Tabs	yes		`<nav><section>`*	(OpenUI) (`nav`s + `section` + CSS)
	List container	yes		`<ul><li>`	HTML + CSS
	Fixed container	yes		`<div>`*	HTML + CSS
	Scrolling container	yes		`<div>`*	HTML + CSS
	Grid layout	yes		`<div>`*	HTML + CSS
	Marquee	yes		`<marquee>` (deprecated)*	HTML + CSS
	Drag and drop		yes	`<div>`*	HTML + Drag and Drop API
	Pull to refresh		yes	`<div>`*	HTML + JS + CSS
	Conditional block			`@style`	CSS media queries
	Navigation Bar			`<nav>`	HTML + CSS

What About the Platform-Specific Components

Better for developers, better for the platform

Examples: <icon>, <scroll-list>, <map>, <ad>...

Web Components (e.g., <icon>)

https://espinr.github.io/sandbox/miniapps/customelements/icon

Web Components

https://espinr.github.io/sandbox/miniapps/customelements/scroll-view

A "Pure Web" SuperApp

https://espinr.github.io/sandbox/miniapps/pureweb/superapp

Opportunities

MiniApps paradigm overseas is still unknown, but gaining traction
Web standards bring: security, internationalization, accessibility by default
MiniApps Working Group, ongoing and ready to continue

Technologies to consider

Progressive Web Apps: installable, offline, ready worldwide
Isolated Web Apps: packaging, distribution through HTTP
High-Performance Engines: dedicate and performant web engines?

Embedding Browsers for my SuperApp

Do we need a full-fledged embedding browser?

Use Case Optimization

Definition of priorities for developing new Web Engines based on scenarios

Only subsets selected from the full set of standards

Priorities for Use Cases

Web Application Profiles?

Important: the objective is not to fragment the web, just to bring new use cases to the Web

Support development of dedicated embedding browsers
Guarantee interoperability within use cases
Maximize engine performance in concrete use cases
Support incremental development of full-fledged browsers (prioritize the features to implement)

Successful use cases: EPUB and Web Media.

How to Develop Profiles?

Reference guidelines (for web engine developers) profiles of standards
"Web Features" to map profiles (MUST/SHOULD/MAY-Feature-profile)
Extending "Baseline" for "Web Profiles" (e.g., Shopping MiniApp Web Profile, AI Chatbot Web Profile)
Creating specific documents in Open Web Docs
Extending CanIUse (CanIWebProfileUse)? for integration with toolsets (e.g., editors, frameworks)

Where?High-Performance Web Engines CG, MiniApps CG, Web DevX CG