"Just build a native app."

For years, this was the default answer whenever someone wanted to build something powerful. Need camera access? Native app. Need offline support? Native app. Need push notifications? Native app.

But something changed. Companies that bet on the web platform—using browser APIs instead of building native apps—often ended up winning. Not because browsers are theoretically better, but because the tradeoffs favor web in more situations than people realize.

Let's look at real companies that chose browser APIs over native apps, and why they came out ahead.

Case Study 1: Figma — GPU Graphics in the Browser

The challenge: Build a professional design tool that competes with Adobe Illustrator, Sketch, and other native applications.

The conventional wisdom: "Complex graphics apps need native code. Browser performance isn't good enough. Serious professionals won't accept a web app."

What Figma did: Built entirely on web technologies—Canvas API, WebGL for hardware-accelerated rendering, WebAssembly for compute-heavy operations.

Why Web Won

1. Zero friction collaboration

Native approach:
1. Download 500MB installer
2. Run installer, wait
3. Create account
4. Receive invite link
5. Accept invite
6. Find file in app
7. Finally collaborate

Figma approach:
1. Click link
2. Collaborate

The "click link, you're in" experience was impossible with native apps. When a designer shares a Figma link, reviewers don't need to install anything. They view in browser. This dramatically increased collaboration velocity.

2. Instant updates

When Figma ships a feature, every user has it immediately. No update prompts. No version fragmentation. No "please update to collaborate with teammates on different versions."

3. Cross-platform by default

Figma works on Windows, Mac, Linux, and ChromeOS with the same codebase. They didn't build four native apps—they built one web app.

4. Browser capabilities caught up

• WebGL: Hardware-accelerated 2D/3D rendering
• WebAssembly: Near-native performance for compute
• SharedArrayBuffer: Multi-threaded processing
• IndexedDB: Local file caching
• Service Workers: Offline support (Figma works offline)

The Result

Figma was acquired for $20 billion (deal later unwound, but valuation stood). It beat Sketch (native Mac only) and competed effectively with Adobe products that had decades of native development. Web won.

Technical Implementation

// Figma uses WebGL for rendering
// This pseudocode illustrates the approach

class FigmaRenderer {
  constructor(canvas) {
    this.gl = canvas.getContext('webgl2');
    this.initShaders();
    this.initBuffers();
  }

  render(document) {
    // Batch similar objects
    // Use instanced rendering for shapes
    // Leverage GPU for transformations
    this.gl.drawArraysInstanced(...);
  }
}

// Heavy computation in WebAssembly
const wasmModule = await WebAssembly.instantiate(figmaComputeWasm);
const result = wasmModule.exports.layoutCalculation(data);

Case Study 2: Spotify — Audio Streaming

The challenge: Build a music streaming app that works everywhere.

What happened: Spotify built native apps for iOS, Android, Mac, Windows, and Linux. They also built a web player.

The Web Version's Advantages

1. No installation required

For casual listening, browser Spotify just works. Open tab, play music. Perfect for:

• Work computers where you can't install apps
• Trying Spotify without commitment
• Quick sharing ("listen to this song" → link opens in browser)

2. Simpler distribution

Native apps require:

• App Store approval (iOS)
• Update cycles
• Platform-specific builds
• Supporting old OS versions

Web version updates instantly for everyone.

3. Web Audio API maturity

// Browser audio is now quite capable
const audioContext = new AudioContext();
const source = audioContext.createBufferSource();

// Audio processing
const gainNode = audioContext.createGain();
const analyser = audioContext.createAnalyser();

source.connect(gainNode);
gainNode.connect(analyser);
analyser.connect(audioContext.destination);

The Hybrid Approach

Spotify uses native apps for:

• Background playback on mobile
• System integrations (media keys, control center)
• Offline downloads

They use the web player for:

• Desktop listening (Electron app is basically web)
• Casual access
• Lower friction entry point

Key insight: The "native vs web" debate is often a false dichotomy. Smart companies use both, choosing based on specific requirements.

Case Study 3: Google Docs — Replacing Desktop Software

The challenge: Build a document editor that competes with Microsoft Word.

The conventional wisdom: "Office software requires native app performance. Complex document rendering needs native code. Offline is impossible."

What Google did: Built Google Docs entirely in the browser, eventually making it the default for millions of organizations.

Why Web Won

1. Real-time collaboration was transformative

// Operational Transformation enables real-time collaboration
class CollaborativeDocument {
  applyOperation(operation) {
    // Transform operation against concurrent edits
    const transformed = this.transform(operation, this.pendingOps);
    this.document.apply(transformed);
    this.broadcast(transformed);
  }
}

Native Word: "Please close the file so I can edit it." Google Docs: "We're both editing the same sentence right now."

This wasn't just better—it changed how people work.

2. Access from anywhere

School computer? Library? Friend's laptop? Your phone? Google Docs works everywhere without installing anything.

3. Automatic saving and version history

• Every change saved automatically
• Complete version history
• No "I lost my document" disasters

4. Sharing without file attachments

Word workflow:
1. Attach file to email
2. Recipient downloads
3. Opens in their Word version
4. Formatting breaks
5. Edits, re-attaches to email
6. Original author has to merge changes

Google Docs workflow:
1. Share link
2. Done

Browser APIs That Made It Possible

• ContentEditable: Rich text editing
• Selection API: Cursor and selection management
• Clipboard API: Copy/paste
• IndexedDB: Offline document cache
• Service Workers: Offline access
• WebSocket: Real-time sync

The Result

Google Workspace has 3+ billion users. The combination of collaboration, accessibility, and zero installation beat native apps that had decades of head start.

Case Study 4: Discord — Real-Time Communication

The challenge: Build a communication platform for gamers that supports voice, video, text, and screen sharing.

The conventional wisdom: "Real-time audio/video requires native code. Low latency is impossible in browsers. Gamers need native performance."

What Discord did: Built on web technologies, with Electron for desktop and native apps for mobile.

Why Web Won (Partially)

1. WebRTC enabled real-time communication

// Browser-native peer-to-peer communication
const peerConnection = new RTCPeerConnection(configuration);

// Add local media
const stream = await navigator.mediaDevices.getUserMedia({
  audio: true,
  video: true,
});
stream.getTracks().forEach((track) => peerConnection.addTrack(track, stream));

// Handle incoming media
peerConnection.ontrack = (event) => {
  remoteVideo.srcObject = event.streams[0];
};

Discord's voice chat is built on WebRTC. The browser API handles:

• Codec negotiation
• NAT traversal
• Encryption
• Adaptive bitrate

2. Cross-platform through Electron

Discord's desktop app is Electron (Chrome + Node.js). Same codebase runs on Windows, Mac, Linux.

3. Web-first enables "join without installing"

Discord in browser: click link, join voice chat. No installation. This reduces friction for new users dramatically.

Where Native Still Matters

Discord uses native code for:

• Game overlay (needs OS integration)
• Krisp noise suppression (compute-intensive)
• Low-level audio APIs on mobile

The Result

Discord reached 150+ million monthly users. The web foundation enabled rapid development while strategic native code handled edge cases.

Case Study 5: Notion — Complex Document Apps

The challenge: Build a flexible document/database tool that combines notes, wikis, databases, and project management.

What Notion did: Built entirely as a web app, with Electron for desktop.

Why Web Won

1. Block-based editing with web components

// Notion's block architecture maps naturally to web
class NotionBlock extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' });
  }

  render() {
    // Each block type renders differently
    // Text, headings, images, embeds, databases...
  }
}
customElements.define('notion-block', NotionBlock);

2. Embedding anything

Web apps naturally embed web content. Notion can embed:

• Google Maps
• Figma designs
• GitHub repos
• YouTube videos
• Other Notion pages

Native apps would need to implement each integration separately.

3. Instant sharing

Share a Notion page: recipient clicks link, views page. No app required.

4. Real-time sync

Like Google Docs, real-time collaboration "just works" with web technologies.

The Result

Notion reached $10B valuation. Built by a small team using web technologies, competing against native apps with much larger development teams.

Pattern Analysis: When Web Wins

Looking across these case studies, patterns emerge:

Web Wins When:

1. Collaboration is core

• Real-time editing
• Link-based sharing
• No file exchange needed

2. Distribution matters

• "Click link, you're in" is important
• Supporting multiple platforms is required
• Frequent updates are needed

3. The capability gap has closed

• WebGL/WebGPU for graphics
• WebRTC for communication
• Service Workers for offline
• WebAssembly for performance

4. Native-only features aren't essential

• Background processing isn't critical
• Deep OS integration isn't needed
• Hardware-specific features aren't required

Native Wins When:

1. Background execution is required

• Music playing while phone is locked
• Fitness tracking all day
• Background sync

2. Deep OS integration is needed

• Widgets
• System-level shortcuts
• File system integration
• Hardware peripherals

3. Maximum performance is essential

• AAA games
• Professional video editing
• 3D modeling

4. Offline-first is mandatory

• Apps that must work without any network
• Large local data sets

The Capabilities That Changed Everything

Several browser APIs shifted the balance toward web:

WebRTC (2012)

Before: "Real-time audio/video? You need a native app." After: Google Meet, Discord voice, browser-based telehealth.

// P2P video in ~20 lines of code
const pc = new RTCPeerConnection();
const stream = await navigator.mediaDevices.getUserMedia({ video: true });
stream.getTracks().forEach((t) => pc.addTrack(t, stream));

Service Workers (2015)

Before: "Offline web apps are impossible." After: PWAs work offline, cache assets, background sync.

// Offline-capable in ~30 lines
self.addEventListener('fetch', (e) => {
  e.respondWith(caches.match(e.request).then((r) => r || fetch(e.request)));
});

WebAssembly (2017)

Before: "Browsers are too slow for serious computation." After: Figma, Photoshop web, AutoCAD web, game engines.

// Near-native performance
const result = await WebAssembly.instantiate(wasmBytes);
result.instance.exports.compute(data);

WebGL/WebGPU (2011/2023)

Before: "3D graphics require native apps." After: Complex visualization, games, ML inference.

// GPU-accelerated rendering
const gl = canvas.getContext('webgl');
// or modern:
const adapter = await navigator.gpu.requestAdapter();

IndexedDB + Cache API

Before: "Web apps can't store significant data locally." After: Large offline datasets, local-first apps.

// Store megabytes of data locally
const db = await openDB('app', 1, {
  /* schema */
});
await db.put('documents', { id: 1, content: largeData });

The Business Case for Web

Beyond technical capabilities, web often wins on business metrics:

Development Cost

Time to Market

• Native: Build each platform sequentially or hire parallel teams
• Web: Ship once, works everywhere

User Acquisition Cost

• Native: App Store discovery, install friction, storage concerns
• Web: Link click, instant access, no installation

Update Cycle

• Native: Submit to stores, await approval, users must update
• Web: Deploy, everyone has new version immediately

The Future: Even More Capability

The web platform continues to expand:

Shipping now:

• WebGPU (GPU compute for ML)
• File System Access (read/write local files)
• Web Codecs (direct video/audio codec access)

In development:

• WebNN (neural network acceleration)
• WebTransport (low-latency networking)
• Multi-screen window placement

On the horizon:

• Native AI APIs (navigator.llm equivalent)
• Extended reality (WebXR maturing)
• More hardware access (USB, Bluetooth, Serial expanding)

Each new API closes another gap between web and native capabilities.

Conclusion: Choose Based on Requirements

The "native vs web" debate is outdated. The real questions are:

1. What capabilities do you need? Check if browser APIs cover them.
2. How important is distribution? Web wins on frictionless access.
3. How important is collaboration? Web wins on sharing and real-time.
4. Do you need deep OS integration? Native still wins here.
5. What's your development capacity? Web means one codebase.

Figma, Google Docs, Notion, Discord, and hundreds of other successful products chose web—not because web is always better, but because for their requirements, it was the right choice.

The next time someone says "just build a native app," ask: "What capability do we need that browsers don't have?" The answer might surprise you.

Further Reading

• How Browser APIs Become Standards
• WebGPU Explained: What GPU Access Means for Web Apps
• The Next Browser APIs: What's Coming to navigator.*
• Progressive Web Apps on web.dev