Skip to content

Language

Vanilla JavaScript and PWAs

We write plain JavaScript where a framework would be overhead: canvas games, embedded widgets, and progressive web apps that must stay small and start instantly.

Laptop on a software development workspace

Usage

What we build with Vanilla JS and PWAs

  1. Canvas rendered games and simulations with a fixed timestep loop
  2. Embedded widgets that load inside someone else page
  3. Progressive web apps with service workers and offline storage
  4. Interactive visualisations and configurators
  5. Lightweight enhancement on otherwise static pages

Rationale

Why we choose it

  • Nothing to download

    A widget or a game that ships without a framework starts faster and stays measured in kilobytes, which matters most on the slow connections where these run.

  • Full control of the frame budget

    A render loop that draws every frame has no room for a reconciliation pass it did not ask for.

  • No dependency on a framework lifecycle

    An embedded widget has to coexist with whatever the host page is running, which is simpler without a second framework in the tab.

Practice

Architecture patterns we use

  • Fixed timestep with interpolated rendering

    Simulation advances in fixed increments and rendering interpolates, so behaviour is identical regardless of frame rate.

  • Shadow DOM for embedded widgets

    Styles are encapsulated so the host page cannot break the widget and the widget cannot break the host page.

  • Service worker with a versioned cache

    The application shell is cached under a version, and an update activates cleanly without stranding an open tab.

  • Structured local storage with migrations

    Saved state carries a version and a migration path, so an update does not invalidate what a user has already done.

Build with our Vanilla JS and PWAs engineers

Tell us what you are building and what it has to connect to. We will come back with an approach, a scope and what it would take.

  • A mutual NDA is signed before project details are shared.
  • Scope is fixed in writing before any build starts.
  • You own the source code, the IP and the documentation at delivery.
  • Support plans are available and tailored on a discovery or technical call.