The Rise of Web-Based Applications

When you launch a modern application—whether it’s a chat client, a music player, or a code editor—the interface you interact with was likely built with HTML, CSS, and JavaScript, even if the app runs natively on your desktop. This is not an accident. Over the past two decades, web technologies steadily moved from serving simple documents to powering rich, interactive experiences everywhere. Understanding that transformation explains why tools like Tauri exist and why they are designed the way they are.

From Static Pages to Interactive Experiences

In the early days of the web, a website was a collection of static HTML files. Clicking a link caused a full page reload, and any interaction that required changing the screen meant the server had to send an entirely new page. JavaScript existed, but it was used sparingly—mostly for form validation or small animations.

The turning point came with a combination of two technologies: the XMLHttpRequest object (the foundation of what we now call AJAX) and more capable JavaScript engines in browsers. AJAX allowed a page to fetch data from a server asynchronously and update only part of the screen without a full reload. Suddenly web applications could behave more like desktop software—saving work without reloading, loading new content in the background, and responding to user input instantly.

This shift created a need for better ways to manage complex frontends. Early libraries like jQuery helped smooth over browser inconsistencies, but the real leap came with component-based frameworks: React, Angular, Vue, and later Svelte and Solid. These gave developers tools to structure large applications, keep UI in sync with state, and build interfaces declaratively. The web stopped being a platform for documents and became a platform for applications.

Single-Page Applications Reshape User Expectations

A single-page application (SPA) loads one HTML document and then uses JavaScript to handle navigation, rendering, and data fetching without full page refreshes. This model became the standard for many web apps because it eliminates the jarring flash of a blank page between screens and allows richer transitions and interactions.

The mental model to adopt as a beginner: an SPA is a miniature operating system inside a browser tab. It manages its own routing, keeps application state alive across “pages,” and decides what to render based on that state. The browser’s traditional role as a document viewer is replaced by a runtime for application logic.

Here is a minimal SPA built with React and Vite—a combination you are likely to encounter in a Tauri project because Tauri’s frontend is often scaffolded with Vite.

import { useState } from 'react';
function App() {
  const [count, setCount] = useState(0);
  return (
    <div className="container">
      <h1>Hello, Tauri!</h1>
      <p>You clicked {count} times.</p>
      <button onClick={() => setCount(count + 1)}>Click me</button>
    </div>
  );
}
export default App;

This tiny example captures the essence of an SPA: the page never reloads when you click the button; React compares the virtual DOM with the real DOM and only updates the text node that shows the count. When this component is part of a Tauri application, that same efficiency carries over—the webview renders only what changed, and the Rust backend stays idle until explicitly invoked.

SPAs brought enormous productivity gains, but they also introduced a cost that is easy to overlook. Because the entire application now runs inside a browser tab, the client bears the burden of rendering, routing, and state management. When the same approach is lifted directly into a desktop environment without adjustment, you end up with applications that consume hundreds of megabytes of memory to render a UI that native code could handle with a fraction of that. The Performance Overhead of Web Apps chapter covers this in depth; for now, the important point is that the SPA model, while powerful, was not designed with desktop resource constraints in mind.

Progressive Web Apps Blur the Line Between Web and Native

Progressive Web Apps (PWAs) represent the next step in the web’s evolution toward native capabilities. A PWA is a web application that uses modern browser APIs to offer features once exclusive to installed software: offline access, push notifications, background sync, and the ability to appear as a standalone app on the device’s home screen.

At the heart of a PWA are two pieces:

• Service Workers — JavaScript files that run separately from the page, intercept network requests, and enable offline caching.
• Web App Manifest — a JSON file that describes how the app should look when launched from a home screen (name, icons, theme colour, display mode).

A minimal manifest looks like this:

{
  "name": "My PWA App",
  "short_name": "MyApp",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#4f46e5",
  "icons": [
    {
      "src": "icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

When a user adds this PWA to their home screen on a mobile device, the browser uses the manifest to determine how to present it—full screen, without the browser’s address bar, with the specified icon and splash screen colour. To the user, the experience starts to feel indistinguishable from a native app.

PWAs were a breakthrough for web developers because they demonstrated that web technology could deliver experiences that compete with native apps on mobile. But they also revealed a friction point: the browser still sits between the application and the operating system. Access to hardware, file system, and certain system-level APIs remains gated behind browser permissions, and the app is ultimately at the mercy of the browser’s resource management. Tauri takes a different path: it lets the same web-based UI run directly inside a system webview, with Rust code handling the parts that need deeper system integration.

Web Technologies Become the Cross-Platform User Interface Layer

The combined effect of SPAs, PWAs, and the explosive growth of frontend frameworks was a reality that reshaped the software industry: web technologies became the most widely understood and most accessible way to build user interfaces. A developer who knows React or Vue can build interfaces for browsers, mobile browsers, and—via tools like Electron or Tauri—desktop and mobile apps.

This universal UI layer solved a massive business problem: instead of maintaining three separate codebases for web, Windows/macOS/Linux, and iOS/Android, teams could share the same UI logic everywhere. That promise of “write once, run anywhere” had been chased for decades, and web tech finally delivered a version of it that was practical enough for production.

The first widely adopted framework that packaged web UIs into desktop applications was Electron. Electron combined a Chromium browser instance with a Node.js backend, giving developers full access to the operating system from JavaScript. It worked, and it worked well enough that many companies adopted it. But every Electron application carries a complete copy of Chromium, so even a simple “Hello, World” app can be over 100 MB in size and consume hundreds of megabytes of RAM at idle.

That trade-off—unmatched development speed in exchange for large binaries and high resource usage—was acceptable for many projects, but it also created a visible gap. The web UI layer was clearly the right choice for developer productivity, but the runtime packaging strategy needed to be rethought. Tauri emerged from this tension: keep the web frontend that developers already know, but replace the bundled browser engine with the operating system’s native webview and move the backend logic to Rust. The next sections explore exactly why that matters for performance, security, and final application size.

The Common Misconception About Web-Based Desktop Apps

A belief that causes real pain in production is the assumption that a web UI tested in one browser will behave identically in every webview across every operating system. When an application is packaged for desktop with Tauri, the rendering engine is not Chrome—it is WebKit on macOS and Linux, and WebView2 (Edge’s engine) on Windows. While these engines all implement modern web standards, the implementations are not pixel-identical.

This is not a reason to avoid web-based UIs. It is a reason to treat the target webview as a first-class platform, test on all supported operating systems from the start, and avoid relying on browser-specific APIs that are not yet standardised across the engines Tauri uses.

Where This Leaves Us

Web-based applications went from an experiment in interactive documents to the default way the world builds software interfaces. That success created a natural demand: developers wanted to reuse their web skills and existing UI code to build desktop and mobile apps. The first answer—bundling an entire browser engine—worked, but left behind applications that were larger and hungrier than necessary.

Tauri starts from the same foundation: a web frontend built with standard HTML, CSS, and JavaScript. But instead of shipping a browser, it draws on the system’s own webview and pairs that frontend with a Rust backend. The rise of web-based applications is not something Tauri fights against—it is the very reason Tauri exists.