DEV Community: Rick M

Why Local-First Web Apps are the Future: Building a Zero-Server PDF Engine with WebAssembly

Rick M — Thu, 06 Aug 2026 09:02:33 +0000

Modern web applications are changing.

A few years ago, building a document editor, image compressor, or PDF toolkit almost always meant uploading files to a backend server, processing them remotely, and sending the results back to the user.

Today, modern browsers are powerful enough to perform many of those same tasks locally.

When building Fillora PDF, we re-evaluated our architecture and discovered that many common PDF operations didn't actually require a server. By moving supported workflows directly into the browser, we reduced unnecessary network requests while improving performance and privacy.

In this article, I'll explain what local-first means, the browser technologies that make it possible, and the engineering trade-offs we encountered along the way.

🏗️ What Does "Local-First" Mean?

A local-first application performs as much work as possible on the user's device before relying on cloud infrastructure.

Instead of treating the browser as a thin client, it becomes the primary execution environment.

For document applications, that means:

📄 Opening files locally
✏️ Editing documents in memory
📥 Generating downloads without uploads
☁️ Using the server only when it provides real value

Local-first doesn't mean eliminating servers completely.

Instead, it means choosing the right place to execute each workload.

🌐 Traditional Server-Centric Architecture

Many online document tools still follow this workflow:

Browser
    │
    ├── Upload File
    ▼
Cloud Server
    │
    ├── Process Document
    ▼
Browser
    └── Download Result

Although straightforward, this architecture introduces several challenges:

Upload latency for large files
Higher bandwidth usage
Increased server CPU and memory consumption
Processing queues during peak traffic
Privacy concerns when handling sensitive documents

For many PDF editing operations, these round trips simply aren't necessary.

⚡ Browser-Native Architecture

Modern browsers already provide the APIs needed to process many documents locally.

Browser
    │
    ├── Read Local File
    ├── Process in Memory
    ├── Generate Output
    └── Download Result

For supported workflows:

✅ Documents remain on the user's device
✅ No upload is required
✅ Server CPU isn't consumed
✅ Users receive results without waiting for upload and download cycles

🧩 Browser APIs That Make It Possible

The browser has evolved into a capable application runtime.

Several Web APIs make local-first document processing practical.

📂 FileReader API

The FileReader API allows applications to read files directly from a user's device.

const reader = new FileReader();

reader.onload = (event) => {
  console.log(event.target.result);
};

reader.readAsArrayBuffer(file);

Perfect for:

Image previews
PDF editors
CSV importers
Markdown editors

📦 ArrayBuffer & Uint8Array

PDFs, images, and many other file formats are fundamentally binary data.

ArrayBuffer and Uint8Array allow JavaScript to manipulate those bytes efficiently without converting everything into strings.

These typed arrays are the foundation of many browser-native document tools.

💾 Blob & URL.createObjectURL()

After generating a new file, browsers can immediately create a downloadable object.

const url = URL.createObjectURL(blob);

const link = document.createElement("a");
link.href = url;
link.download = "merged.pdf";
link.click();

setTimeout(() => URL.revokeObjectURL(url), 0);

Common use cases:

PDF generation
CSV exports
Image editors
ZIP downloads

Instead of uploading generated files back to a server, everything happens locally.

⚙️ Web Workers

Heavy JavaScript running on the main thread can freeze the user interface.

Web Workers move expensive computations into a background thread.

const worker = new Worker("worker.js");

worker.postMessage(data);

worker.onmessage = ({ data }) => {
  console.log(data);
};

They're particularly useful for:

Large PDF processing
Image manipulation
OCR
Data parsing
Compression

Keeping long-running tasks off the main thread makes applications feel significantly more responsive.

📄 JavaScript PDF Libraries

Libraries like pdf-lib make browser-native PDF editing remarkably straightforward.

A simplified merge example looks like this:

import { PDFDocument } from "pdf-lib";

async function mergePdfFiles(buffers) {
  const mergedPdf = await PDFDocument.create();

  for (const buffer of buffers) {
    const pdf = await PDFDocument.load(buffer);

    const pages = await mergedPdf.copyPages(
      pdf,
      pdf.getPageIndices()
    );

    pages.forEach((page) => mergedPdf.addPage(page));
  }

  return await mergedPdf.save();
}

For many everyday PDF operations, the entire workflow completes without requiring the document to leave the user's device.

🧠 Where WebAssembly Fits In

JavaScript is incredibly capable, but some workloads demand even more performance.

WebAssembly (Wasm) enables code compiled from languages like C, C++, or Rust to run securely inside the browser at near-native speed.

It's particularly valuable for computationally intensive tasks such as:

OCR engines
Image processing
Compression algorithms
Advanced rendering
Computer vision

Rather than replacing JavaScript, WebAssembly complements it by accelerating performance-critical components while JavaScript orchestrates the overall application.

⚖️ Engineering Trade-Offs

Local-first architecture isn't a silver bullet.

Several practical limitations remain.

1. Browser Memory Limits

Browsers enforce memory limits for each tab.

Very large PDFs or thousands of pages can exceed available memory, particularly on mobile devices.

2. Complex Document Formats

High-fidelity Office document rendering often depends on sophisticated rendering engines that are still better suited to dedicated backend services.

3. Bundle Size

Shipping every processing engine to every visitor would dramatically increase initial page load times.

Code splitting and lazy loading are essential for maintaining performance.

4. Hybrid Architectures Still Matter

Not every workload belongs in the browser.

A practical architecture combines:

Browser-native processing for supported editing tasks
Server-side processing for workloads that genuinely require backend compute

Choosing the right execution environment is often more important than forcing everything onto one side.

📈 What Changed

Moving supported PDF workflows into the browser produced several practical improvements.

✅ Reduced infrastructure costs

✅ Lower bandwidth consumption

✅ Faster perceived performance

✅ Better privacy for supported workflows

✅ Improved scalability by reducing dependency on server compute

Most importantly, backend resources became available for workloads that genuinely benefit from server-side processing.

💡 Lessons Learned

The browser has evolved far beyond rendering HTML.

Modern Web APIs, JavaScript, Web Workers, and WebAssembly make it possible to build applications that once required dedicated backend infrastructure.

Local-first architecture isn't about eliminating the cloud.

It's about using cloud resources intentionally while allowing capable client devices to perform the work they're already equipped to handle.

🎯 Final Thoughts

The future of many web applications isn't about moving everything to the server.

It's about moving the right workloads to the client.

For us, adopting a local-first approach led to faster interactions, improved privacy for supported workflows, and a more scalable architecture while still relying on server-side processing where it provides clear benefits.

As browsers continue to evolve, the line between desktop software and web applications will only become thinner.

If you're building document tools, editors, design software, or productivity applications, it's worth asking one simple question:

Does this operation really need to leave the user's device?

I'd love to hear how you're using browser APIs, WebAssembly, or local-first architecture in your own projects.

5 Browser APIs Every Web Developer Should Know (But Probably Aren't Using Enough)

Rick M — Thu, 06 Aug 2026 08:22:27 +0000

🚀 5 Browser APIs Every Web Developer Should Know (But Probably Aren't Using Enough)

Modern browsers have become incredibly powerful application platforms.

Features that once required backend services or heavy third-party libraries can now run directly in the browser using built-in Web APIs.

Whether you're building dashboards, productivity tools, editors, AI applications, or document software, these APIs can help you build faster, more responsive, and more privacy-friendly experiences.

Let's explore five browser APIs that every frontend developer should have in their toolkit.

📋 Quick Overview

API	Best For	Why It Matters
📂 FileReader	Reading local files	No uploads required
💾 URL.createObjectURL()	Downloading generated files	Faster file downloads
⚙️ Web Workers	Heavy computations	Keeps the UI responsive
📋 Clipboard API	Copying text	Modern replacement for `execCommand()`
👀 Intersection Observer	Detecting visibility	Better than scroll listeners

📂 1. FileReader API

Need users to open local files without uploading them first?

The FileReader API lets your application read files directly from the user's device.

This is one of the easiest ways to improve both privacy and user experience.

Perfect for

🖼️ Image previews
📊 CSV importers
📄 PDF viewers
📝 Markdown editors

Example

const reader = new FileReader();

reader.onload = (event) => {
  console.log(event.target.result);
};

reader.readAsArrayBuffer(file);

💡 Why it matters

Users can immediately work with their files without waiting for uploads or worrying about sensitive documents leaving their device.

💾 2. URL.createObjectURL()

Generating a PDF, CSV, ZIP, or image?

Instead of uploading the file to a backend just to download it again, you can create a downloadable file directly in memory.

Example

const url = URL.createObjectURL(blob);

const link = document.createElement("a");

link.href = url;
link.download = "document.pdf";
link.click();

URL.revokeObjectURL(url);

Great for

📄 PDF generators
📊 CSV exports
🖼️ Image editors
📦 ZIP downloads

💡 Why it matters

Eliminating unnecessary uploads makes downloads feel much faster and reduces server bandwidth.

⚙️ 3. Web Workers

Have you ever clicked a button and watched the entire page freeze?

That's because JavaScript normally runs on the browser's main thread.

Web Workers allow expensive tasks to run in the background without blocking the interface.

Example

const worker = new Worker("worker.js");

worker.postMessage(data);

worker.onmessage = (event) => {
  console.log(event.data);
};

Great for

🖼️ Image processing
📊 Parsing large datasets
🧮 Heavy calculations
📄 Document processing

💡 Why it matters

A responsive application feels dramatically faster—even when it's doing complex work behind the scenes.

📋 4. Clipboard API

Copying text used to rely on document.execCommand(), which is now deprecated.

The modern Clipboard API makes copying text simple.

Example

await navigator.clipboard.writeText("Copied!");

Great for

🔗 Share buttons
💻 Copy code
📋 Productivity apps
📄 Generated text

💡 Why it matters

Cleaner code, better browser support, and a much nicer developer experience.

👀 5. Intersection Observer API

Listening to every scroll event can quickly become inefficient.

The Intersection Observer API tells you when an element enters or leaves the viewport.

Example

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      console.log("Visible");
    }
  });
});

observer.observe(document.querySelector(".card"));

Great for

⚡ Lazy loading
♾️ Infinite scrolling
✨ Scroll animations
📈 Visibility analytics

💡 Why it matters

It's far more efficient than constantly checking scroll position.

🎯 Which API Should You Use?

If you're building...	Use
Image uploader	FileReader
PDF generator	URL.createObjectURL()
AI application	Web Workers
Code editor	Clipboard API
Blog or portfolio	Intersection Observer

🌟 Final Thoughts

Modern browsers already provide many of the tools needed to build rich web applications.

Learning these APIs can help you:

🚀 Improve performance
🔒 Enhance user privacy
⚡ Reduce unnecessary backend requests
📦 Depend less on external libraries
😊 Deliver a smoother user experience

The best part?

Most of these APIs have been supported by modern browsers for years—you can start using them today.

💬 What About You?

Which browser API has had the biggest impact on your projects?

Or is there another underrated Web API that every developer should know?

I'd love to hear your recommendations in the comments!

Building Fillora PDF: Why We Moved Heavy PDF Processing to Client-Side WebAssembly

Rick M — Thu, 06 Aug 2026 07:41:43 +0000

Building Fillora PDF: Moving PDF Processing from Server APIs to Browser-Native Execution

Every developer who has built document conversion features has probably encountered the same challenges: large file uploads, server memory pressure, processing queues, timeout limits, and users who hesitate to upload sensitive documents to third-party servers.

When building Fillora PDF, we redesigned many of our core PDF manipulation tools to run directly inside the browser instead of relying on server-side processing.

This article explains why we made that architectural decision, how modern browser APIs make it practical, and the trade-offs we discovered along the way.

🏗️ Server Processing vs. Browser-Native Processing

Traditional online PDF tools typically process every operation on a remote server.

Traditional Server Workflow

Browser
   │
   ├── Upload PDF
   ▼
Server
   │
   ├── Process Document
   ▼
Browser
   └── Download Result

While this approach works well, it introduces several challenges:

Upload latency for large files
Higher server CPU and memory usage
Increased bandwidth costs
Privacy concerns when processing sensitive documents
Scalability challenges during traffic spikes

For many PDF editing operations—such as merging, splitting, rotating, rearranging pages, and metadata editing—the browser is now capable of doing the work locally.

Browser-Native Workflow

Browser
   │
   ├── Read Local File
   ├── Process Document
   └── Download Result

In this model:

Documents do not need to be uploaded for supported browser-native operations.
Processing happens on the user's device rather than consuming server CPU.
Users receive immediate results without waiting for upload and download cycles.

⚡ Why Modern Browsers Can Handle PDF Processing

Modern browsers provide powerful APIs that make client-side document processing practical.

Some of the key building blocks include:

FileReader API for reading local files
Blob and URL.createObjectURL() for generating downloadable files
ArrayBuffer and Uint8Array for binary data manipulation
JavaScript libraries such as pdf-lib for PDF editing
Web Workers for moving heavy processing off the main UI thread

A simplified merge example looks like this:

import { PDFDocument } from "pdf-lib";

async function mergePdfFiles(buffers) {
  const mergedPdf = await PDFDocument.create();

  for (const buffer of buffers) {
    const source = await PDFDocument.load(buffer);

    const pages = await mergedPdf.copyPages(
      source,
      source.getPageIndices()
    );

    pages.forEach((page) => mergedPdf.addPage(page));
  }

  return await mergedPdf.save();
}

Because the entire operation runs locally, many everyday PDF tasks can complete quickly without requiring the document to leave the user's device.

🧵 Keeping the Interface Responsive

One challenge with client-side processing is preventing expensive operations from freezing the interface.

Heavy computations performed on the main thread can block rendering and make the application feel unresponsive.

To avoid this, long-running tasks can be executed inside Web Workers, allowing the browser to continue rendering the interface while processing documents in the background.

The result is a smoother experience, especially when working with larger files.

⚖️ Trade-offs We Encountered

Moving processing into the browser is not a universal solution.

Several practical limitations remain.

1. Browser Memory Limits

Browsers enforce memory limits per tab.

Very large PDFs or documents containing thousands of pages can exhaust available memory, particularly on mobile devices.

2. Complex Document Formats

Converting richly formatted Office documents into PDF often requires sophisticated rendering engines.

These workloads are generally better suited to dedicated server-side services.

3. Bundle Size

Adding every processing engine to the initial application bundle would significantly increase page load times.

We therefore load only the functionality required for the current tool whenever possible.

4. Fallback Processing

Some workloads simply exceed what browsers can comfortably handle.

In those situations, server-side processing remains an important fallback.

📈 What Changed

For browser-native PDF operations we observed several practical benefits:

Reduced server infrastructure costs
Lower bandwidth consumption
Faster perceived performance by eliminating upload delays
Improved privacy for supported workflows
Better scalability because document processing no longer depends on server compute

Rather than replacing server processing entirely, we found that a hybrid architecture works best:

Browser-native execution for supported PDF editing tasks
Server-side processing only when the workload genuinely requires it

💬 Final Thoughts

Modern browsers have evolved into powerful application platforms.

Features that once required dedicated backend infrastructure can now often be performed directly on the user's device using standard browser APIs and mature JavaScript libraries.

For us, moving many PDF operations into the browser simplified our infrastructure while providing a faster and more privacy-friendly experience for users.

If you've built browser-native document tools, I'd love to hear what approaches worked well for you.

You can explore our implementation at https://fillorapdf.com.