DEV Community: Alexandr Zhelonkin

How I Shipped a Zero-JavaScript Landing Page from a React Router App

Alexandr Zhelonkin — Tue, 21 Jul 2026 14:00:00 +0000

The page has a headline, product copy, screenshots, a call to action, metadata, Open Graph tags, and JSON-LD. It does not need hydration, client-side routing, or a React runtime in the browser. It should be HTML and CSS.

But the product itself is still a React Router app. The app routes need JavaScript. They use browser APIs, offline behavior, camera permissions, WebRTC, connection state, and interactive UI. Splitting the landing page into a separate static site would work, but it would also create another build pipeline, another layout system, and another place to keep product metadata in sync.

So the target was narrower: keep one React Router project, prerender the public pages, and avoid shipping the client runtime where the page does not need it.

/           prerendered HTML, no client runtime
/privacy    prerendered HTML, no client runtime

/start      app route, scripts enabled
/connect    app route, scripts enabled
/exploit    app route, scripts enabled

The setup

I use an explicit React Router route config. A simplified version originally looked like this:

export default [
  layout('./components/shared/RootLayout.tsx', [
    index('./components/landing/LandingPage.tsx'),
    route('/privacy/', './components/privacy/PrivacyPage.tsx'),
    layout('./components/shared/OfflineLayout.tsx', [
      route('start', './components/start/StartPage.tsx'),
      route('connect', './components/connect/ConnectPage.tsx'),
      route('exploit', './components/exploit/ExploitPage.tsx'),
      route('*', './components/shared/NavigateToStart.tsx'),
    ]),
  ]),
] satisfies RouteConfig;

This works, but it makes LandingPage.tsx both the page component and the route module. For a regular app page, that is acceptable. For a public page, I wanted a cleaner boundary.

The route module owns framework-specific exports. The page component only renders the page. So I changed the route config to point to a small route wrapper:

export default [
  layout('./components/shared/RootLayout.tsx', [
    index('./components/landing/LandingRoute.tsx'),

    // Same stuff
  ]),
] satisfies RouteConfig;

LandingPage.tsx became pure UI:

export const LandingPage: React.FC = () => {
  return <main>{/* Landing page content */}</main>;
}

And LandingRoute.tsx became the adapter between the page and React Router:

export {LandingPage as default} from './LandingPage';
export {landingMeta as meta} from './landing.meta';

That small wrapper ended up being useful. The route file stays boring, the page component stays reusable, and metadata does not leak into the visual component.

Metadata belongs to the route

For the landing page, I wanted the document head to contain the usual SEO metadata plus JSON-LD: title, description, canonical URL, Open Graph tags, and structured data.

I keep that in landing.meta.ts:

import {seo} from '@extroid/common/constants';
import type {MetaFunction} from 'react-router';

const TITLE = 'Extroid – Use Your Phone as a Webcam in Browser Video Calls';
const DESCRIPTION = 'Use your phone as a webcam for browser video calls with fast QR pairing, no drivers, and no desktop apps';

export const landingMeta: MetaFunction = () => [
  {
    name: 'robots',
    content: 'index, follow',
  },
  {
    tagName: 'link',
    rel: 'canonical',
    href: seo.siteUrl,
  },
  {
    title: TITLE,
  },
  {
    name: 'description',
    content: DESCRIPTION,
  },
  {
    property: 'og:title',
    content: TITLE,
  },
  {
    property: 'og:description',
    content: DESCRIPTION,
  },
  {
    property: 'twitter:title',
    content: TITLE,
  },
  {
    property: 'twitter:description',
    content: DESCRIPTION,
  },
  {
    'script:ld+json': createLandingPageStructuredData(),
  },
];

function createLandingPageStructuredData() {
  return {
    '@context': 'https://schema.org',
    '@graph': [
      {
        '@type': 'WebSite',
        '@id': `${seo.siteUrl}#website`,
        name: 'Extroid',
        url: seo.siteUrl,
        inLanguage: 'en',
        publisher: {
          '@id': `${seo.siteUrl}#organization`,
        },
      },
      {
        '@type': 'Organization',
        '@id': `${seo.siteUrl}#organization`,
        name: 'Extroid',
        url: seo.siteUrl,
        logo: {
          '@type': 'ImageObject',
          '@id': `${seo.siteUrl}#logo`,
          url: seo.logoUrl,
          width: 512,
          height: 512,
        },
        sameAs: [seo.chromeStoreUrl, seo.productHuntUrl],
      },
      {
        '@type': 'WebPage',
        '@id': `${seo.siteUrl}#webpage`,
        url: seo.siteUrl,
        name: TITLE,
        description: DESCRIPTION,
        isPartOf: {
          '@id': `${seo.siteUrl}#website`,
        },
        about: {
          '@id': `${seo.siteUrl}#software`,
        },
        primaryImageOfPage: {
          '@id': `${seo.siteUrl}#logo`,
        },
        inLanguage: 'en',
      },
      {
        '@type': 'SoftwareApplication',
        '@id': `${seo.siteUrl}#software`,
        name: 'Extroid',
        alternateName: TITLE,
        url: seo.siteUrl,
        mainEntityOfPage: {
          '@id': `${seo.siteUrl}#webpage`,
        },
        description: DESCRIPTION,
        operatingSystem: 'Windows, macOS, Linux, ChromeOS, Android',
        applicationCategory: 'BrowserApplication',
        applicationSubCategory: 'Webcam software',
        browserRequirements: 'Requires a Chromium-based desktop browser.',
        softwareRequirements:
          'Chromium-based desktop browser, Android phone recommended, same Wi-Fi network recommended.',
        softwareVersion: '1.0',
        datePublished: '2026-04-27',
        author: {
          '@type': 'Person',
          name: seo.author,
          url: seo.about,
        },
        publisher: {
          '@id': `${seo.siteUrl}#organization`,
        },
        offers: {
          '@type': 'Offer',
          price: '0',
          priceCurrency: 'USD',
          availability: 'https://schema.org/InStock',
          url: seo.chromeStoreUrl,
        },
        downloadUrl: seo.chromeStoreUrl,
        installUrl: seo.chromeStoreUrl,
        image: {
          '@id': `${seo.siteUrl}#logo`,
        },
        screenshot: [
          `${seo.siteUrl}/screenshots/screen-1-v1.png`,
          `${seo.siteUrl}/screenshots/screen-2-v1.png`,
          `${seo.siteUrl}/screenshots/screen-3-v1.png`,
          `${seo.siteUrl}/screenshots/screen-4-v1.png`,
          `${seo.siteUrl}/screenshots/screen-5-v1.png`,
        ],
        sameAs: [seo.chromeStoreUrl, seo.productHuntUrl],
        inLanguage: 'en',
      },
    ],
  };
}

The nice part is that the page does not need to manually render a JSON-LD script. The route exports metadata, and the root layout renders it through React Router’s <Meta/>.

import {Links, Meta, Outlet} from 'react-router';

export default function RootLayout() {
  return (
    <html lang="en">
      <head>
        <meta charSet="utf-8" />
        <meta name="viewport" content="initial-scale=1, width=device-width" />
        <meta name="language" content="English" />
        <meta name="theme-color" content="#6180d3" />

        {/* Many other common metadata */}

        <Meta /> {/* 🤺 Page specific metadata */}
        <Links />
      </head>

      <body>
        <Outlet />
      </body>
    </html>
  );
}

At this point, the static page has proper metadata in the head. But it still has a bigger problem.

Prerendered HTML can still ship JavaScript

Prerendering gives you HTML. It does not automatically mean «no JavaScript». If the root layout renders <Scripts/>, the generated page still gets React Router client scripts. That is fine for /start, /connect, and other app routes. It is not useful for the landing page.

The first attempt was direct: prerender the pages, then cut scripts from the generated HTML. Not with regex. A parser-based version is still simple enough:

import {parse} from 'node-html-parser';
import fs from 'node:fs';
import path from 'node:path';

for (const file of ['index.html', 'privacy/index.html']) {
  const filePath = path.join('build/client', file);

  try {
    const rawHtml = fs.readFileSync(filePath, 'utf-8');
    const doc = parse(rawHtml, {comment: false});

    doc.querySelectorAll('script[src^="/assets/"]').forEach((el) => el.remove());
    doc.querySelectorAll('link[rel="modulepreload"]').forEach((el) => el.remove());

    fs.writeFileSync(filePath, doc.toString());
    console.info(`✔ Stripped external scripts & modulepreloads from ${file}`);
  } catch (error) {
    console.warn(`❌ Error while striping ${filePath}`, error);
  }
}

This is better than regex because it understands the document structure and can keep JSON-LD. It is still the wrong level of abstraction. The output broke. The browser showed only the loading state instead of the full page.

The mistake was assuming that anything inside a <script> tag was optional client runtime. In a prerendered React Router document, some inline scripts may be part of how the document is completed or restored. Once the page is already generated, a script stripper cannot reliably know which scripts are safe to remove and which ones are part of the rendering result.

The fix was not to delete scripts after the build. The fix was to prevent unnecessary scripts from being rendered for static routes.

The final version

The final version is a small wrapper around <Scripts/>.

import {MobileEnv} from '@extroid/mobile/utils/env';
import React from 'react';
import {Scripts, UNSAFE_FrameworkContext, useLocation} from 'react-router';

function ClientScripts() {
  const location = useLocation();
  const frameworkContext = React.useContext(UNSAFE_FrameworkContext);
  const isStaticPrerender = frameworkContext?.isSpaMode === false && MobileEnv.isStaticUrl(location.pathname);

  return isStaticPrerender ? null : <Scripts />;
}

And the root layout uses ClientScripts instead of Scripts directly:

export default function RootLayout() {
  return (
    <html lang="en">
      {/* Same stuff */}

      <body>
        <Outlet />
        <ClientScripts />
      </body>
    </html>
  );
}

This moves the decision into rendering, where route context still exists. Static prerendered public pages can return no client scripts. App routes still render the scripts they need.

The tradeoff is that this uses UNSAFE_FrameworkContext. I do not like that part, and I would rather not depend on an internal API. But keeping the usage isolated in one component is acceptable for this case, and it is less fragile than editing generated HTML after the build.

Headers and caching

Once public pages are static, the hosting side should avoid one common mistake: treating HTML like a versioned asset. HTML should stay easy to refresh. Fingerprinted assets can be cached aggressively. Public metadata files should be cached, but not forever.

The rule I use is:

HTML documents:
Cache-Control: no-cache

fingerprinted JS, CSS, images, fonts:
Cache-Control: public, max-age=31536000, immutable

robots.txt, sitemap.xml, manifest:
Cache-Control: public, max-age=3600

The exact hosting provider is not the interesting part. The useful distinction is between documents and assets. A document is the current page. A fingerprinted asset is a versioned file. They should not have the same cache policy.

Let’s check it

The quickest verification is to open the production page and view the HTML. For the landing page, I expect the source to contain real page content and the metadata I care about:

I also expect not to see a bundle of React Router client scripts on the static landing page.

Then I check the opposite on app routes. /start, /connect, and /exploit should still work normally. If the static page source is clean and the app routes still run, the split is correct.

Conclusion

The important lesson was the failed script stripping attempt. It is easy to look at generated HTML and think the solution is to delete scripts. Even with an HTML parser, that approach is blind. It happens after React Router has already produced the document, so it can remove things that are not safe to remove.

Conditional rendering is cleaner. The root layout decides whether scripts are needed while React Router still has enough context to make that decision.

For a hybrid product, this is a practical setup: one React Router project, static public pages, dynamic app routes, metadata in the head, and no unnecessary runtime cost on the landing page.

This article is based on work I did while building Extroid, a browser extension that lets you use your phone as a wireless webcam for browser-based video calls – without a desktop client, virtual-camera driver, or native phone app. I'd love to hear your feedback!

How to build a browser‑based virtual webcam

Alexandr Zhelonkin — Tue, 19 May 2026 11:00:00 +0000

What if we could make our video calls even better?

With softer colors, better resolution, a higher frame rate, and a more flattering angle, our video calls would be much more enjoyable. But the laptop webcam falls short of all these expectations, while the camera in our pocket already offers ten times better quality.

The challenge is how to use that phone camera for video calls without installing additional drivers, pushing video through another cloud server, or building a native app for the phone. Let's explore building a Chrome extension and a mobile PWA.

Make a website see the virtual camera 🖊️

Most video conferencing platforms rely on the same browser API, MediaDevices, to capture video. To inject a virtual camera into a website, two things need to happen: the website must believe there is a new device, and calls for that device should return a live stream from the phone's camera.

The camera must be injected before the website collects a list of devices. Therefore, the content script must be injected before any page scripts run, i.e., at document_start.

It should intercept navigator.mediaDevices and override both getUserMedia and enumerateDevices. The overridden enumerateDevices adds a virtual entry to the device list, so the new camera appears in any selector the page uses. The overridden getUserMedia checks the requested device ID: if it matches the virtual device, the call returns a stream from the phone; otherwise, it falls through to the original function.

As an additional measure, it is possible to dispatch an event about changing the device list. In some cases, if the site takes this event into account, it helps ensure the virtual camera is picked up.

What we have now:

export function monkeyPatchMediaDevices({fakeDeviceInfo, onFakeSelected}: PatchMediaDevices): void {
  const mediaDevices = window.navigator.mediaDevices;
  const enumerateDevicesFn = mediaDevices.enumerateDevices.bind(mediaDevices);
  const getUserMediaFn = mediaDevices.getUserMedia.bind(mediaDevices);

  mediaDevices.enumerateDevices = async () => {
    const devices = await enumerateDevicesFn();
    return [...devices, fakeDeviceInfo];
  };

  mediaDevices.getUserMedia = async (constraints) => {
    if (checkDeviceConstraints(constraints, fakeDeviceInfo)) {
      return onFakeSelected(constraints);
    }

    return await getUserMediaFn(constraints);
  };

  mediaDevices.dispatchEvent(new Event('devicechange'));
}

The end result: On any page where the extension has permission to run, the virtual camera appears as an option in a browser-based video app, without any site-specific integration.

WebRTC without a dedicated server 🍏

WebRTC requires signaling – a way for two peers to exchange connection offers, answers, and ICE candidates before they can communicate directly. What if we cannot afford a dedicated server?

An alternative is to use Google Drive's appdata folder as a mailbox. Both the desktop extension and the mobile PWA write and read signaling messages to the same hidden folder, which is invisible to users and accessible only by the extension.

The exchange follows a request-response pattern:

 Desktop                  Drive                   Mobile
   ┃                        ┃                        ┃
   ┃ 1. Write offer         ┃                        ┃
   ┃ └────────────────────> ┃                        ┃
   ┃                        ┃                        ┃
   ┃ 2. QR (fileId+token)   ┃                        ┃
   ┃ └──────────────────────╂───────┐                ┃
   ┃                        ┃       │                ┃
   ┃ 3. Poll for answer     ┃       │                ┃
   ┃ ├────────────────────> ┃       │                ┃
   ┃ ┊                      ┃       │                ┃
   ┃ ┊                      ┃       │                ┃ 4. Scan QR
   ┃ ┊                      ┃       └──────────────> ┃
   ┃ ┊                      ┃                        ┃
   ┃ ┊                      ┃                        ┃ 5. Read offer
   ┃ ┊                      ┃ ─────────────────────> ┃
   ┃ ┊                      ┃                        ┃
   ┃ ┊                      ┃                        ┃ 6. Write answer
   ┃ ┊                      ┃ <──────────────────────╂─┘
   ┃ ˅                      ┃                        ┃
   ┃ 7. Read answer         ┃                        ┃
   ┃ <───────────────────── ┃                        ┃
   ┃                        ┃                        ┃
   ┃ 8. Delete all files    ┃                        ┃
   ┃ └────────────────────> ┃                        ┃
   ┃                        ┃                        ┃

To avoid a separate authorization step on the mobile side and ensure that access to the file will be preserved, a Google OAuth token can be embedded directly into the QR code. This means that the QR code contains everything needed to authenticate with Drive, so scanning the QR code is the only action required to establish a connection. A new QR scan is needed for each new connection, but after the WebRTC handshake is complete, the connection can continue without interruption for any duration.

/**
 * Offerer uploads its description and calls back the business part 
 */
public async sendOffer(description: "RTCSessionDescriptionInit): Promise<void> {"
  const fileCreationResponse = await driveGapi.files.create({
    media: new Blob([JSON.stringify(description)], {type: 'application/json'}),
    name: `${this.options.sessionId}-offer.json`,
    mimeType: 'application/json',
    parents: ['appDataFolder'],
  });

  this.options.onDescriptionCreated(fileCreationResponse.id);
}

/**
 * Answerer downloads the offer and returns it to the business part 
 */
public async checkOffer(): Promise<RTCSessionDescriptionInit> {
  const offerFileBlob = await driveGapi.files.download(this.options.driveId);
  const offerFileJson = await offerFileBlob.text();
  return JSON.parse(offerFileJson) as RTCSessionDescriptionInit;
}

/**
 * Answerer uploads its description 
 */
public async sendAnswer(description: "RTCSessionDescriptionInit): Promise<void> {"
  const offerFileMeta = await driveGapi.files.get(this.options.driveId);
  const fileCreationResponse = await driveGapi.files.create({
    media: new Blob([JSON.stringify(description)], {type: 'application/json'}),
    name: offerFileMeta.name.replace('offer', 'answer'),
    mimeType: 'application/json',
    parents: ['appDataFolder'],
  });
}

/**
 * Offerer downloads the answer and returns it to the business part 
 */
public async checkAnswer(): Promise<RTCSessionDescriptionInit> {
  const listFilesResponse = await driveGapi.files.list({
    pageSize: 2,
    query: `name contains '${this.options.sessionId}'`,
    spaces: 'appDataFolder',
  });

  const listFiles = listFilesResponse?.files ?? [];
  const answerFileMeta = listFiles.find((file) => file.name.endsWith('-answer.json'));

  if (answerFileMeta) {
    const answerFileBlob = await driveGapi.files.download(answerFileMeta.id);
    const answerFileJson = await answerFileBlob.text();
    const answerDescription = JSON.parse(answerFileJson) as RTCSessionDescriptionInit;

    for (const file of listFiles) {
      await driveGapi.files.delete(file.id);
    }

    return answerDescription;
  }

  return null;
}

Stick it together 🍍

To avoid making the user scan a QR code for every call, we can keep a long-lived WebRTC connection alive and reuse it. The ideal place for this connection would be the service worker. Since WebRTC cannot be used there, it's necessary to set up offscreen.

let offscreenSettingUp: Promise<void>;
export async function setupOffscreenDocument(filename = 'offscreen.html'): Promise<void> {
  const offscreenUrl = chrome.runtime.getURL(filename);
  if (await hasOffscreenDocument(offscreenUrl)) {
    return Promise.resolve();
  }

  await (offscreenSettingUp ||= chrome.offscreen.createDocument({
    reasons: ['WEB_RTC'],
    url: offscreenUrl,
    justification: 'WebRTC stuff',
  }));

  offscreenSettingUp = null;
}

However, while there is no way to stream video from offscreen to content script, the only solution is to connect content script to mobile directly. The offscreen document assists with the offer/answer exchange but stays out of the media path.

The architecture that makes it work:

 ┌────────────┐     ┌────────────────┐     ┌────────────────────┐
 │ Side Panel ├───> │ Service Worker │ <───┤ Offscreen Document │
 │  (React)   │ <───┤  (dispatcher)  ├───> │   (WebRTC host)    │
 └────────────┘     └───────┬────────┘     └───────┬────────────┘
                            │ ▲                    │ ▲
                            │ │                    │ │
                            │ │                    │ │
                            ▼ │                    ▼ │
                    ┌─────────┴──────┐     ┌─────────┴──────┐
                    │ Content Script │ <───┤     Mobile     │
                    │ (monkey-patch) │     │    (camera)    │
                    └────────────────┘     └────────────────┘

Side Panel: The UI. A React component that displays the Google Sign-in, the QR code, and device status. All inputs go to the service worker.

Service Worker: A lightweight message dispatcher. This component never touches video. It creates an offscreen document, stores user settings, and proxies messages between the side panel, the offscreen document, and the content script(s).

Offscreen Document: The hidden WebRTC manager. It owns the long-term RTCPeerConnection and uses it to establish new ephemeral connections.

Content Script: Injected into each page. Its only job is to inject the virtual camera with the phone stream, using the monkey patch described above. The script receives the stream from the mobile device and exposes it to the page.

// Configuring peer for receiving video
peer.addTransceiver('video', {direction: 'recvonly'});
peer.addEventListener('track', ({transceiver}) => {
  const track = transceiver.receiver.track;
  track.addEventListener('mute', () => {
    this.options.onStream(null);
  });
  track.addEventListener('unmute', () => {
    this.options.onStream(new MediaStream([track]));
  });
});

// Setting up the stream in the video element
public setStream(targetStream?: MediaStream): void {
  if (targetStream) {
    const videoElement = window.document.createElement('video');
    videoElement.srcObject = targetStream;

    videoElement
      .play()
      .then(() => (this.targetVideo = videoElement));

    return;
  }

  this.disposeTargetStream();
}

// Drawing the video element or a stub animation
private loop(streamOptions: FakeMediaStreamOptions): void {
  window.requestAnimationFrame((time) => {
    if (this.targetVideo) {
      this.canvas.drawVideo(this.targetVideo);
    } else {
      this.canvas.drawStub(time);
    }

    this.loop(streamOptions);
  });
}

What this architecture enables

The solutions chosen in each problem section produced capabilities that weren't designed independently. Instead, they emerged from the overall architecture.

Minimal permissions. The OAuth token stored in the QR code only has two scopes: read and write access to the app's own hidden Drive folder. It doesn't have permission to see files outside that folder or access email, contacts, or other user data.

WebRTC provides built-in security guarantees. Media streams are end-to-end encrypted regardless of the signaling method. The video stays inside the user's WiFi network or, in a fully wired setup, is transferred via USB tethering, which provides a stable wired connection that bypasses Wi-Fi entirely.

Flexibility beyond the webcam. The peer-to-peer nature of the connection allows for any type of data to be transmitted through the same channel. This includes images, screen captures, and even completely different video sources, which can replace the camera feed without affecting the signaling or transport. The architecture views video as just another type of payload among many.

Cross-platform compatibility. The desktop side is a Chrome extension, meaning it works on all operating systems that support a Chromium-based browser, such as Windows, macOS, Linux, and ChromeOS. The mobile side is a PWA, which doesn't require installation from an app store, and works on both Android and iOS. The only exceptions are platform-specific WebRTC behaviors (for example, how iOS Safari handles background streaming differently), but the core connection model remains consistent across all platforms.

The concrete result of this path is Extroid, a Chrome extension that turns your phone into a wireless webcam for any browser-based video call. Extroid is designed for browser-based video calls. See the compatibility guide for supported browsers, meeting apps, and unsupported desktop apps. It works without the need for cloud servers or drivers, and there's no need for a native app on your phone. I'd love to hear your feedback!