Key Points of the Web Apps Proposal

Background

The World Wide Web stands as one of the most successful platforms in history, built on the principles of openness and universal access. It excels as a platform for distributing documents and information. However, as user expectations on mobile devices have evolved, a significant gap in user experience has emerged between the web and native applications. Users now demand the fluid, responsive, and seamless interactions that native apps provide by default. The web’s foundational model, while perfect for its original purpose, often struggles to deliver this modern, app-like experience, leading to a pressing need for a new approach. This proposal outlines a path forward for an evolved web architecture, one designed specifically for the application era on mobile.

The Challenge: The Web’s Mobile Experience Deficit

The foundational model of the web, based on the real-time loading of fragmented resources (HTML, CSS, JS), is a primary source of performance bottlenecks on mobile. Unlike native apps, which are installed as complete binary packages, web pages must be downloaded, parsed, and compiled on every visit, often resulting in white screens, layout shifts (reflow/repaint), and a generally disjointed user experience.

Here is a comparison of mainstream mobile technologies in terms of rendering and threading differences. As we can see, all mobile frameworks separate the UI and logic processing. Moreover, the frequent updates to the UI by logic and the dynamic nature of the web make web UI more unstable and prone to reflow and repaint.

Besides performance, Key differences highlight the web’s disadvantages in a mobile context:

• Loading & Execution: The web’s real-time, fragmented loading contrasts sharply with the pre-installed, holistic nature of native apps. This leads to unpredictable performance and repeated loading waits.
• User Experience: Native apps offer smooth, animated page transitions (e.g., 300-500ms slide animations) that effectively mask data-fetching latency. The web, by default, presents a jarring “white screen” between page navigations.
• Interaction Model: Core web features were designed for a desktop-and-mouse paradigm. The click event’s inherent 300ms delay on touch devices, the lack of standardized gesture controls (e.g., swipe, long press), and unstable zooming behavior make the web feel non-native and cumbersome on mobile.

The current W3C motto is to make the web work for everyone. However, functionality is no longer enough. We must shift our focus from pragmatism to “experiencism”—prioritizing the quality of the user experience.

Proposal: A New Architectural Baseline

To bridge the experience gap, we propose the development of a new web core standard focused on high performance for mobile. This new standard should not be seen as a replacement for the existing web, but as a complementary, opt-in baseline for developers building modern, app-like web experiences. It offers a dedicated path for high-performance application development, while the traditional web continues to serve its vital role for content and document-centric sites.

This new baseline should be built on three foundational principles:

1. Packaged Application Model: We should standardize a packaging format for web applications. Web pages have evolved into complex applications and should be distributed as such. A packaged model, potentially extending the Web Application Manifest draft, would treat the application as a single, coherent unit. This reduces complexity, improves performance, and enables more robust update mechanisms.
2. Decoupled Architecture (Rendering/Logic Separation): A new standard must endorse and facilitate a multi-threaded architecture where rendering and logic are inherently separate. This is the single most important change required to unlock native-level performance and smoothness on the web.
3. Rich, Mobile-First Experience Primitives: The new engine must provide a core set of standardized, easy-to-use APIs for functionalities that are currently difficult to implement. This includes:
   1. High-performance page transitions and animations.
   1. A native touch and gesture system (tap, long-press, swipe).
   1. Efficient long-list rendering and virtualization.
   1. Built-in support for mobile UI idioms like pull-to-refresh and safe-area layout management.
   1. Extensibility with binary modules for performance-critical tasks.

Path Forward: Merging and Building on MiniApp WG Success

This initiative is perfectly aligned with the mission of the W3C High-Performance Community Group. To accelerate progress and unify efforts, we propose migrating the charter and deliverables of the W3C MiniApp Working Group into this new, broader initiative.

This approach allows us to reuse and build upon the significant achievements already made by the MiniApp WG, avoiding redundant work. The following specifications provide an excellent foundation:

By consolidating these efforts, we can leverage this progress and focus the W3C’s resources on the shared goal of creating a next-generation, high-performance web platform for mobile.

Conclusion: Key Points of the Proposal

To elevate the mobile web, we must move beyond incremental improvements and embrace a new architecture designed for a mobile-first, experience-driven world.

This proposal advocates for:

• Establishing a new, complementary web core standard for creating high-performance, mobile-first web experiences.
• Adopting a packaged application model to treat web apps as coherent programs, improving performance and versioning.
• Implementing a decoupled architecture that separates rendering and logic to ensure a smooth, non-blocking user interface.
• Standardizing a rich set of mobile experience primitives, including gestures and transitions, to make great UX the default.
• Merging the efforts of the MiniApp Working Group into the High-Performance Community Group to reuse its existing specifications and accelerate progress.

We hope that more people, whether you agree or disagree with this idea, will join the this group to jointly advance the development of the web.

A Proposal for High-Performance Web

The Web was born 35 years ago, back when desktop computers were the main way to get online. Today, mobile internet and touchscreens dominate. To keep up with this shift, the Web needs some changes.

Let’s start by comparing the old PC internet to today’s mobile internet.

What’s Changed?

1. How We Access the Internet

In the desktop era, browsers were the gateway to the internet. People used search engines or navigation sites to find stuff, and websites were linked together by hyperlinks (remember that term?).

Now, in the mobile world, the entry points are app icons on your phone and push notifications. Browsers? Most people don’t bother with them anymore. Typing URLs by hand feels clunky, and who even remembers more than a couple of addresses?

2. Where Web Traffic Comes From

User habits have shifted, and so has web traffic. It’s moved from browsers to inside apps—think social media, news feeds, or e-commerce platforms. These apps still use Web tech (like H5 pages), but they’re not open internet sites anymore. They’re custom pages locked inside each app’s ecosystem. This weakens the Web’s interconnectedness. 

So, in the mobile era, the internet isn’t really a “web” anymore—it’s more like a chain of isolated islands. Apps prioritize keeping users inside rather than letting them jump around.

Looking at the Web Through a Mobile Lens

Despite all these changes, Web standards haven’t evolved much.

1. PC-First, Mobile as an Afterthought

The Web was built for desktops—mice and keyboards ruled the day. Mobile devices, with fingers and touchscreens, work totally differently. Features like long list scrolling, gesture controls, and smooth page transitions? The Web doesn’t have them natively.

The most the Web has done for mobile is make sure desktop pages work on phones. That makes sense—smartphones didn’t take over overnight, and early on, people just wanted to view PC sites on their tiny screens. W3C did a ton of compatibility work for that, like adding zoom effects so small phone screens could handle desktop layouts.

Even the forward/back buttons from PC browsers got copied over to mobile. But if you look at native apps, none of them use zoomable pages or arrow buttons for navigation. That’s not mobile-friendly. Today, with mobile traffic calling the shots, it’s backward to keep patching the Web to fit phones. Mobile isn’t the guest anymore—it’s the host. Tons of apps exist only on mobile, no desktop version in sight. Compatibility patches feel outdated now.

2. Performance Problem

If Web pages performed as well as native apps, we wouldn’t have so many cross-platform frameworks like React Native or Flutter. Their popularity is proof the Web’s performance isn’t cutting it.

Performance gripes are old news, so I’ll keep it short with some numbers:

• A default <div> comes with 246 properties and 82 methods.

• HTML has 139 tags. Compare that to React Native’s 5 default tags.

Analyze tag usage on core pages of major sites. Turns out, they don’t use that many:

(These Include 8 non-UI tags like <html>, <head>, <style>, <script>. Subtract those, and the average drops to 24.) Most HTML tags barely touched.

• CSS has 380 properties. React Native get by with ~100. But even then, they implement way fewer values than raw CSS. Take display: CSS has 23 options; React Native has 2 (none, flex). 

W3C keeps adding features but rarely cuts anything. New CSS and APIs pile up, making it nearly impossible to build a new browser engine from scratch—it’s too much baggage. Even outdated stuff like document.write() still has to stick around.

That said, the Web still holds a huge chunk of mobile usage. Its cross-platform nature, flexible UI, and dynamic updates make it a go-to for hybrid app development. A survey of China’s top 1000 apps found 60% of pages were Web or Web-like.

But these mobile Web pages? They’re not full-fledged sites anymore—they’re fragmented pieces.

So, if we had a shot at making the Web truly mobile-friendly, where should we take it?

A High-Performance Web Built for Mobile

Different companies have different ideas on how to pull this off. Generally, there are two paths: slim down the existing Web or build a brand-new Web core. Let’s break them down.

Option 1: Slim Down the Web

This means taking the Web’s full feature set and carving out a leaner subset to boost browser efficiency.

Vendors with legacy projects love this—it keeps old code mostly intact. Developers wouldn’t need to rewrite much to get started. But there are downsides:

1. Performance Limits

Slimming down hits a ceiling fast. The Web’s big flaw—logic and rendering threads fighting each other—means long JS tasks drop frames. Without scrapping that outdated design, performance won’t soar.

1. Experience Gaps

A trimmed Web still won’t feel mobile-native. You’d need to bolt on stuff like long lists and gestures anyway.

1. Long-Term Bloat

Defining the subset is tricky and subjective. Worse, it’ll grow over time as tech evolves, undoing the “slim” part. Google’s AMP tried this route and fizzled out.

Option 2: A New Core

If we’re branching off the Web anyway, why not go all-in and build a fresh core?

This means creating a new runtime kernel for next-gen Web apps. Future browsers could run dual engines—the old one stays for legacy, while the new one starts clean. Benefits? Ditch the baggage, separate rendering and logic threads, slim down UI components, and bake in mobile-friendly features.

What might this new Web app look like?

1. Distributed as Packages Mobile internet’s island-like structure calls for self-contained, low-linkage packages—think mini-apps or cross-platform frameworks.

• Bundle UI, CSS, and JS together.
• Use a new content-type: application/webapp to define it.
• Give packages self-managed lifecycles and updates.
• Unlike mini-apps, keep packaging flexible—bundle one page or a full app.

Why? Packages fit mobile use cases:

• Embedded in Apps: Most Web traffic comes from apps. Packages can preload locally for native-like performance.
• Real-Time Pages: Like H5 share links or QR code pages—small packages users fetch on the fly, downloading and running simultaneously for speed.
• Mini-App Ecosystem: This could standardize mini-apps under W3C. The Mini App Working Group started in 2021 but stalled. A solid Web app model could jumpstart it, making mini-apps a global standard. Any browser or Webview could run them natively.

1. Extensibility Redoing a full browser kernel (GPU, audio, XR, WebTransport, etc.) is insane—too much work. Most apps don’t need it all anyway. A new core should let developers or platforms plug in custom native components, written in high-performance languages. For Webviews, devs could pick only what they need, keeping the core lean. Web devs could call native components directly, no matter the language. High performance, Web efficiency—best of both worlds. Plus, native components could grow into a thriving ecosystem.
2. Mobile-Friendly by Default This means friendly for devs and users. (Sometimes dev-friendly design helps users too—like iOS’s built-in fade animations. Set animated:YES, and it’s smooth. Most iOS apps feel polished by default.) H5 pages, though? Flickering, jitters, abrupt shifts—few devs bother with transitions, widening the gap with native. A new core should bake in smooth animations, page switches, long lists, and gestures, cutting dev effort.

Bonus: A new core lands easily. As a cross-platform alternative, devs just drop the new Webview into their app—no system or browser updates needed. Full control.

Beyond Phones

It’s not just phones—smartwatches, glasses, car systems, speakers, TVs, and appliances all need UI platforms. Right now, every device and vendor uses different OSes and dev stacks. Building for one means learning its quirks from scratch. Standardized, low-cost software development could even spark innovation in hardware devices.

Imagine a unified, cross-device Web tech that works everywhere. Dev costs drop, and W3C standards could tie it all together. That’s pretty exciting.