DEV Community: Arik Wald

JOPS Comes to WordPress: Class-Based SPAs Inside Your Pages

Arik Wald — Wed, 28 Oct 2026 14:06:38 +0000

We made a small detour before finishing our Electron integration and made a short stop for WordPress integration 🙂 A JOPS SPA can now run inside a WordPress page, next to the theme and the page's other content.

With jops-core 1.1.2, a new JOPS WordPress plugin adds a [jops] shortcode. Drop it into a page built with Elementor or the block editor, and a complete class-based single-page app renders there, below the theme's header and next to the rest of the page. WordPress stays the CMS and the backend. JOPS adds the parts of the page that behave like an application.

Why put an app inside a WordPress page

WordPress runs a large share of the web, and many of those sites eventually need more than content: a quote calculator, a customer portal, a booking flow, an internal dashboard behind the login. The usual options are a heavy plugin that almost fits, or a separate app on its own subdomain that loses the site's theme and menu.

JOPS offers a third option. The app lives in a folder of the site, keeps the site's look, talks to WordPress over its REST API, and needs no build step. Views are classes with an Android-style lifecycle, so the same structure that works in the browser, in hybrid mobile apps and inside Next.js now works inside WordPress too.

Two ways to run JOPS on WordPress

	Embedded in a page	Independent SPA
What it is	The app renders inside a WordPress page, next to the page's content	A complete JOPS app with its own `index.html`, opened at `https://<site>/<folder>/`
How	The JOPS plugin and the `[jops]` shortcode, or an Elementor HTML widget	Upload the app folder; no plugin
Shares the theme, menu and page	Yes	No

Both work because of how WordPress handles requests: it only processes URLs that are not existing files or folders. A JOPS app in a folder of the WordPress root is served as static files, and WordPress never gets in the way.

Install the plugin, three ways

Most WordPress sites don't use npm, so the plugin doesn't require it. Every GitHub release now carries a ready-to-upload jops-wordpress.zip with the jops-core library included:

No npm (hosting with wp-admin only, XAMPP, MAMP, LocalWP): download jops-wordpress.zip, then Plugins → Add New Plugin → Upload Plugin → Install Now → Activate.
An npm project run by wp-env: npx jops-core init --wp writes the plugin to plugins/jops/ and adds it to .wp-env.json. npx wp-env start installs and activates it.
An npm project inside a WordPress folder (a theme, a plugin, a Bedrock project): npx jops-core init --wp searches upward for WordPress and writes the plugin to its plugins folder. --wp-root <path> points to WordPress directly.

All three install the same plugin into wp-content/plugins/jops/. To update without npm, upload the newer zip and choose Replace current with uploaded; with npm, npx jops-core update refreshes the plugin and its library.

Add the app to a page

1. Put the app folder in the WordPress root, the folder with wp-config.php, for example <root>/jops-spa/. Upload it, copy it over SSH, or deploy it with your pipeline.

2. Use root-based paths for everything JOPS loads: the app module, layouts, stylesheets and images.

// /jops-spa/src/App.js
import { View } from "jops-core";

export default class App {
  constructor() {
    const root = new View();
    root.loadLayout("/jops-spa/src/layout/main.html").then(() => root.render());
  }
}

3. Add the shortcode. In Elementor, add a Shortcode widget (General → Shortcode); in the block editor, use the Shortcode block:

[jops app="/jops-spa/src/App.js" id="jops-spa-root" class="jops-spa"]

That's it. On the published page, the shortcode outputs the import map, the library in hosted mode, the app's root <div> and a small script that mounts the app once the library has loaded. In the Elementor editor, the widget shows a clear placeholder instead, so the app never fights the editor for the page.

Prefer no plugin? An Elementor HTML widget can hold the same code by hand, with the library vendored in the app folder. The README has the snippet.

How the two systems share a page

WordPress owns the path, JOPS owns the hash. /quotes/ is a WordPress page; /quotes/#details?id=7 is a screen inside the JOPS app.
The backend is WordPress. The app calls the REST API with fetch("/wp-json/…") on the same origin, so the login cookie is sent. Requests that act as the logged-in user also need a REST nonce, provided by your theme or plugin.
The theme owns the page's CSS. The app's stylesheet applies to the whole page, so scope every rule under the app's root class (.jops-spa .card { … }) and leave body and :root to the theme.

What we tested it on

We built and tested each install path on its own WordPress site before the release:

Install path	Environment	Stack
Zip upload, no npm	Docker, `wordpress:php8.3-apache`	WordPress 7.1.3, Elementor 4.3.5, Hello Elementor
`init --wp` in a wp-env project	`@wordpress/env`	WordPress 7.1.3, PHP 8.3, Elementor 4.4.0 beta
`init --wp` from a theme folder	Docker, root folder mounted	WordPress 7.1.3, Elementor 4.3.5, Hello Elementor

On each site the app rendered on the published page, every route switched, images loaded, and the page made exactly one library request with no console errors. We also checked the edge cases: a second [jops] on the same page, a wrong library URL, the block inserted later by JavaScript, and the Elementor editor's live re-render.

Testing on real WordPress also found a bug in jops-core itself: the jops:ready event could fire before the library had finished initialising. It's fixed in 1.1.2, which helps every hosted JOPS app, not only WordPress ones.

Know before you start

One JOPS app per page. A second [jops] on the same page logs a warning and doesn't start.
The app runs on the published page, not inside the Elementor editor.
Pick a folder name that isn't a page slug and doesn't start with wp-: a real folder always wins over a WordPress page at the same address.
WordPress in a subfolder (example.com/blog/) means every path includes it: /blog/jops-spa/….
Watch your caches. Caching plugins and CDNs may keep serving old copies of the app's static files after an update.

Also new in 1.1.2

View.removeSubViews(condition?) removes and destroys every subview, or only those that match a condition.
jops:ready now fires after jops-core has fully initialised, so calling mount() from the listener is safe.

Try it

Download the JOPS WordPress plugin (always the newest release)
jops-core on npm: the full guide is in the README section "WordPress Integration"
GitHub for issues and discussions
Introducing JOPS, if you're new to the framework
JOPS Meets Next.js, the same idea inside React apps

What's next: back to Electron

The detour is over, and the JOPS team is back on the road to the desktop. The Electron integration is in progress, so the same class-based views can power standalone applications on Windows, macOS and Linux. We'll share what we learn, including what doesn't fit.

JOPS is built and maintained at UIDB, a boutique team of senior engineers who build custom systems with our clients, side by side. If your WordPress site needs an application inside it, or a system that needs to hold up for years, we'd be glad to talk.

JOPS Meets Next.js: Class-Based SPAs Inside Server-Rendered Apps

Arik Wald — Fri, 23 Oct 2026 18:18:54 +0000

When we shipped hybrid mobile support in JOPS 1.0.13, we said the next step was to examine how JOPS and Next.js could work together. With jops-core 1.1.0, that work is done: a complete JOPS single-page app can now run inside a page of a Next.js app, next to React, with Next.js Route Handlers as its backend.

This isn't JOPS competing with React. Next.js keeps everything it does best: server rendering, data fetching, routing and the React ecosystem. JOPS adds class-based views with an Android-style lifecycle on the pages that need them. One codebase, two models, each where it fits.

Why bring classes into a Next.js app

Object-oriented design is how most backend and mobile developers think: Java, C#, Kotlin, Swift, Android and UIKit are all built around classes. Modern React has moved the other way. Server Components are async functions, and React's newest features are built for function components. Classes still work in client components, but a class-based architecture no longer fits naturally in a modern React and Next.js codebase.

Functions and hooks are a proven model, and many teams are productive with them. JOPS gives teams that think in classes a first-class place inside the same app, without asking anyone to switch.

How it works

The split is simple:

Next.js owns the path, JOPS owns the hash. The page /quotes is a Next.js route; /quotes#details?id=q2 is a screen inside the JOPS app.
The JOPS app lives in public/ and is served as-is. Turbopack and webpack never bundle it, so JOPS keeps its no-build design.
The backend is Next.js. The JOPS app calls Route Handlers with fetch(), on the same origin, with the session cookie sent automatically.

The bridge is a single React component, JopsApp, imported from jops-core/nextjs:

// src/app/quotes/page.tsx
import JopsApp from "jops-core/nextjs";

export default function QuotesPage() {
  return <JopsApp app="/quotes/App.js" id="quotes-root" />;
}

JopsApp is a Client Component, so a Server Component page can render it. On the server it renders an empty <div>. In the browser it loads the JOPS library once per page, adds the import map and starts the app inside that <div>. The app's entry module is the same App.js a standalone JOPS app uses:

// public/quotes/App.js
import { View } from "jops-core";

export default class App {
  constructor() {
    const root = new View();
    root.loadLayout("/quotes/layout/main.html").then(() => root.render());
  }
}

Proven on a real application

We didn't design the bridge on a whiteboard. We built a typical Next.js CRM first, on Next.js 16, React 19, the App Router and Tailwind CSS 4, and then rebuilt its entire Quote Builder as a JOPS app inside it:

A quote list with status filters and loading skeletons
Quote details with status actions and a printable quote document
A two-step quote editor with a product picker, live totals and server-side validation
A new-quote flow started from the CRM's own sales pipeline

All of it runs on the CRM's REST Route Handlers, styled with the same Tailwind classes as the rest of the app. Building a real feature end to end exposed issues no demo would have. We fixed them in the framework before the release, and the few that are better handled by convention are listed below.

An app lifecycle that respects the host

A JOPS app inside Next.js behaves like an app on a phone:

Leaving the page ends the app completely. Follow a Next.js link elsewhere, or press Back past the app's first screen, and the router, every view, the app's Store and EventBus, and JOPS's history hooks are all removed. Nothing keeps running in the background.
Coming back launches it again and restores the screen from the hash.
Next.js navigation keeps working. Next.js history state is preserved in every entry JOPS writes, so Back and Forward behave across both frameworks.

Get started

The quickest start is the new project template. In an empty folder:

npx jops-core init
# choose: 3. Next.js JOPS Embedded SPA
npm run dev

It creates a Next.js project with a React-only page, a page hosting a JOPS SPA (a mock login and a quotes list), and a Route Handler as its backend. To add JOPS to an existing Next.js app instead:

npm i jops-core
npx jops-core update   # copies the library to public/lib/

Then put your JOPS app in public/ and render <JopsApp app="/my-app/App.js" /> on the page that hosts it.

Not using React? The same mechanism works on any page: load the library with data-host, and start or stop the app yourself with window.JOPS.mount() and unmount().

Also new in 1.1.0

Building a full application inside Next.js shaped several additions that every JOPS app can use, standalone or hosted:

onPause(), the counterpart of onResume(), called when another view comes to the front while this one stays alive.
Tag props: attributes on a declared view, such as <Card jops title="Hi" item-id="7">, arrive as read-only this.props.
Layouts with several top-level elements, and find(id) for every element with a given id.
Owned event subscriptions: EventBus.subscribe(owner, event, callback) removes itself when its view is destroyed.
A round of router and view fixes found while building the Quote Builder, from reliable default routes to views that resume exactly once.

Know before you start

A few conventions keep the two frameworks out of each other's way:

One JOPS app per page. The router, Store and EventBus are page-wide.
Root-absolute paths for everything JOPS loads, and the library served from public/lib/ rather than a CDN.
Next.js owns the CSS. Inside Next.js, setStyle() is ignored; Tailwind picks up classes used in your JOPS files.
REST, not Server Actions. A JOPS app talks to Next.js through Route Handlers.
Deploy public/ with the app, and use short cache headers for the JOPS files there, since they aren't content-hashed.

Try it

jops-core on npm: the full guide is in the README section "Next.js Integration"
GitHub for issues and discussions
Introducing JOPS, if you're new to the framework
JOPS Goes Mobile, the hybrid iOS and Android release

What's next: JOPS and Electron for standalone applications

JOPS now runs in the browser, in hybrid mobile apps and inside Next.js. The next environment on our list is the desktop. The JOPS team will examine integration with Electron, so the same class-based views can power standalone applications on Windows, macOS and Linux, with access to the file system and native menus through Electron's main process. Many of the internal tools JOPS was built for live on the desktop, and we'll share what we learn as the work progresses.

JOPS is built and maintained at UIDB, a boutique team of senior engineers who build custom systems with our clients, side by side. If you're extending a Next.js system or planning one that needs to hold up for years, we'd be glad to talk.

JOPS Goes Mobile: Hybrid iOS and Android Apps with Cordova and Capacitor

Arik Wald — Tue, 13 Oct 2026 08:41:50 +0000

JOPS started from a simple idea: bring the structure of an Android app to the browser. Views are classes, every view has a lifecycle (loadLayout() → inflate() → onLayout() → onResume()), and navigation keeps a back stack. A framework shaped like a mobile app should also run as one, and with jops-core 1.0.13 it does.

The same JOPS app now ships to iOS and Android inside Apache Cordova or Capacitor, with no bundler and no changes to your views. This article covers what we changed, what we tested it on, and how to set up a hybrid project.

What's new in 1.0.13

The Android back button drives the router. The hardware key and the back gesture call Router.back(), and the first screen closes the app, as Android users expect.
A setup command that knows your project. npx jops-core init detects Cordova and Capacitor projects and writes the app into the folder the native shell actually serves.
Notch-safe layouts. Hybrid projects get viewport-fit=cover, and the Hello World template pads its header and footer for notches, the Dynamic Island and the home indicator.
A more precise router. A new canGoBack() method, and onBackPressed() now runs only on real back navigation. Before 1.0.13 it also fired when tapping a forward link, in every browser.
Nothing changes in a regular browser. Every mobile adjustment is either feature-detected or a CSS value that resolves to 0 outside a native shell. A plain web project gets exactly the same init output as before.

What we tested it on

Before the release, we ran JOPS test apps in both shells, on both platforms:

Shell	Versions	Platforms tested
Apache Cordova	Cordova 12, cordova-ios 8.1.1, cordova-android 15.1.0	iPhone 17 Pro Max simulator (iOS 26.4), Pixel 2 emulator (Android 16, API 36)
Capacitor	Capacitor 8.5, `@capacitor/app` 8.1	iPhone 17 Pro Max simulator (iOS 26.4), Pixel 2 emulator (Android 16, API 36)

Beyond the simulator and emulator, we also tested the apps on physical iPhone and Android devices.

Ionic works through its framework-free UI components (@ionic/core) on top of Cordova or Capacitor. ionic start always scaffolds an Angular, React or Vue app, so start from a plain Cordova or Capacitor project instead.

A hybrid app in four steps

1. Create the hybrid project and its platforms. With Cordova:

cordova create my-app com.example.myapp MyApp
cd my-app
cordova platform add ios android

Or with Capacitor:

mkdir my-app && cd my-app
npm init -y
npm i @capacitor/core @capacitor/ios @capacitor/android @capacitor/app
npm i -D @capacitor/cli
npx cap init MyApp com.example.myapp --web-dir www
npx cap add ios
npx cap add android

2. Install JOPS in the project root, the folder with package.json, not inside www/. The shell copies the whole web folder into the app, so a node_modules/ there would be bundled too.

npm i jops-core

3. Run init. It detects the project type and writes the app where the shell will find it:

npx jops-core init
# [jops-core] Detected cordova project → web folder: www/

4. Build and run with the shell's own tools: cordova run ios and cordova run android, or npx cap sync followed by npx cap run ios and npx cap run android.

Behind step 3, init handles the details that usually cost an afternoon. For Cordova it allows the inline import map and Thread workers in the Content-Security-Policy, adds cordova.js, keeps Cordova's sample page as index.cordova.html, and sets the iOS scheme to app://localhost. That last one matters: JOPS loads views and layouts with native import() and fetch(), which WebViews block on file:// pages. init never overwrites values you already set, and running it twice changes nothing.

The Android back button

This is the change that matters most on Android. On Android 16 (target SDK 36, with predictive back), an app that doesn't register a back handler closes on the first press of the back button, wherever the user is. For a single-page app, that means one accidental swipe ends the session.

JOPS now listens for the back button once the native shell reports it's ready:

If Router.singleton().canGoBack() is true, it calls Router.back(), and the current view receives onBackPressed() exactly as it does for browser back.
On the first screen, it closes the app, the standard Android behaviour.

It also smooths over a cordova-android 15 issue where a single key press fires the back event twice. In Capacitor, install the official @capacitor/app plugin and the same behaviour applies with no code; without the plugin, JOPS logs a console warning explaining what to add. If your app handles back itself, switch the built-in handler off:

<script type="module" src="/lib/jops-core.min.js"
        data-app="./src/App.js" data-native-back="off"></script>

Notches, the Dynamic Island and the home indicator

With viewport-fit=cover, the page extends under the status bar and the home indicator. Pad fixed bars with the safe-area insets. They are 0 in a regular browser, so the web layout doesn't change:

.header {
  padding-top: calc(1rem + env(safe-area-inset-top, 0px));
}
.footer {
  padding-bottom: calc(2rem + env(safe-area-inset-bottom, 0px));
}

What isn't covered yet

Two cases are still open, and we'd rather say so up front:

The iOS edge-swipe back gesture in Cordova hasn't been tested yet.
Navigating forward in the browser into a stacked view that was already closed does nothing.

One note for apps that are already published with Cordova on iOS: moving from file:// to the app://localhost origin means the app can't see data previously stored in localStorage or IndexedDB under file://. If your app stores data locally, plan a migration before switching.

Try it

jops-core on npm: the full guide is in the README section "Hybrid Mobile Apps (Cordova, Ionic & Capacitor)"
Live demo: JOPS Hello World, the template behind the mobile setup
GitHub issues for bugs and device reports
Introducing JOPS, if you're new to the framework

What's next: JOPS and Next.js

Next, the JOPS team will examine integration with Next.js and its server-side rendering. Next.js brings server rendering, routing and a large ecosystem; JOPS brings class-based views, an explicit lifecycle and no build step of its own. We want to find out how the two can work side by side, for example JOPS views running on the client inside server-rendered Next.js pages, so that teams can draw on the strengths of both and gain flexibility in each environment. We'll share what we learn, including what doesn't fit.

JOPS is built and maintained at UIDB, a boutique team of senior engineers who build custom systems with our clients, side by side. If you're planning a hybrid mobile app or a system that needs to hold up for years, we'd be glad to talk.

Building Web Apps the Android Way: Introducing JOPS

Arik Wald — Sat, 10 Oct 2026 19:27:14 +0000

Originally published on ui-db.com.

I've spent most of my career building native apps: Android, iOS, the WebView bridges that connect them to JavaScript, and C# desktop systems. Every time I came back to modern web development for an internal tool or a hybrid app, I found the same trade-off. Either I accepted a full build chain (bundler, transpiler, JSX, a hooks model) for a screen with five forms, or I wrote loose scripts with no structure at all.

I wanted something in between: the structure of an Android app, with a real view lifecycle and real navigation, running directly in the browser as plain JavaScript. That became JOPS (JavaScript Object-Oriented Programming), now on npm as jops-core.

What JOPS is

JOPS is a small single-page application framework built on native ES modules. There is no compiler and no bundler: you add an import map and a module script, and the browser runs your app.

Views are classes. Every screen and component extends View, and its state lives on the instance, where a debugger and a subclass can find it.
A real lifecycle. loadLayout() → inflate() → onLayout() → onResume(), plus onBackPressed(), modeled on Android.
Navigation with a back stack. A hash router with tab-style routes, a stack of screens, slide and fade animations, and deep links with query parameters.
Layouts in plain HTML. Write layouts as .html files or as escaped tagged template literals.
Small helpers, not a platform. A dot-path Store, a static EventBus, and a Thread class for background work in a Web Worker.
Tiny and typed. About 10 KB minified, 3.6 KB gzipped, with no dependencies, and TypeScript declarations so editors autocomplete the whole API.

The lifecycle, if you've written Android

The framework calls each view's methods in a fixed order, so you always know where a piece of code belongs:

Method	When it runs	What it's for
`loadLayout(path)`	First	Load the view's HTML layout
`inflate()`	After the layout loads	Turn the layout into live DOM
`onLayout()`	Once the DOM is live	Add subviews, read initial data
`onResume()`	Every time the view becomes visible	Refresh data, including on back navigation
`onBackPressed()`	When the user navigates back	Save state or confirm leaving

Here is a complete view. Event handlers are ordinary methods, wired to the markup with a single attribute:

import { View, Store, layout } from "jops-core";

export default class ProfileView extends View {
  async loadLayout() {
    await super.loadLayout("./src/layout/profile.html");
  }

  async onLayout() {
    this.addSubView("orders", new OrderList());
  }

  async onResume() {
    const name = Store.singleton().get("user.name");
    this.get("greeting").set(layout`Hello, ${name}`); // escaped
  }

  onSave(event) {
    Store.singleton().set("user.name", event.target.value);
  }
}

<!-- profile.html -->
<section>
  <h2 id="greeting"></h2>
  <input jops-event-bind onchange="onSave" />
  <div id="orders"></div>
</section>

Layouts are just HTML

Since version 1.0.12, a layout can be a plain .html fragment: no import, no export, no template syntax. Views nest declaratively, and the router is declared in the same markup:

<div class="app">
  <View jops layout="./src/layout/header.html"></View>

  <Router jops animation="slide">
    <View path="/home" jops layout="./src/layout/home.html"></View>
    <Orders path="/orders" jops src="./src/Orders.js"></Orders>
  </Router>
</div>

Each layout file is fetched once and cached for the life of the page. When you need dynamic markup in JavaScript, the layout tagged template escapes interpolated values by default, so user input can't inject HTML unless you explicitly mark it with raw().

Navigation that remembers where you were

The router supports the two navigation styles mobile developers already know:

Flat routes (href="#orders") switch between existing screens, like tabs.
Stacked navigation (Router.singleton().navigate("/detail?id=42", DetailView)) creates a new screen on top of the current one, like startActivity(). back() pops it with an animation, and the previous screen's onResume() runs again.

Deep links work out of the box: opening index.html#orders?tab=open lands directly on that route, and getParams() returns { tab: "open" } on first load.

Heavy work off the main thread

For CPU-bound tasks such as parsing, hashing or crunching a large dataset, extend Thread. The run() method executes in a Web Worker, and results come back to onMessage():

import { Thread } from "jops-core";

class ReportThread extends Thread {
  run(params) {
    // runs in a Web Worker, with no access to the page
    const total = params.rows.reduce((sum, r) => sum + r.amount, 0);
    self.postMessage(total);
  }
  onMessage(event) {
    console.log("Total:", event.data);
  }
}

new ReportThread().start({ rows });

Getting started in two minutes

Load JOPS from a CDN with two tags. No install required:

<script type="importmap">
{ "imports": { "jops-core": "https://cdn.jsdelivr.net/npm/jops-core@latest/lib/jops-core.min.js" } }
</script>
<script type="module"
        src="https://cdn.jsdelivr.net/npm/jops-core@latest/lib/jops-core.min.js"
        data-app="./src/App.js"></script>

Or scaffold a project with npm:

npm init -y
npm install jops-core
npx jops-core init

One practical note: ES modules don't load from file://, so serve the folder with any static server (for example npx serve) rather than double-clicking index.html.

When JOPS fits, and when it doesn't

JOPS is a good fit for internal tools, admin panels, dashboards, and hybrid apps running inside a WebView, where a build chain is overhead you don't need. It also suits teams coming from Android, iOS or C#, who think in classes and lifecycles rather than hooks.

It's worth being clear about the limits, too:

No reactive state. The Store is a plain key-value container on purpose. Views read it in onResume() and update the DOM explicitly. If you want automatic re-rendering on every state change, a reactive framework is a better match.
It's young. JOPS reached 1.0 in October 2026. The API is stable within the major version, but the ecosystem around it is small.
The source is private. JOPS ships as a minified module with full TypeScript declarations and is MIT-licensed for any use, including commercial projects. Feedback and bug reports go through GitHub issues.

Try it

I'd especially like to hear whether the lifecycle model feels natural to developers who don't come from mobile, and what you'd need before using JOPS in a production internal tool.

JOPS is built and maintained at UIDB, a boutique team of senior engineers who build custom systems with our clients, side by side. If you're planning an internal tool, a hybrid app or a system that needs to hold up for years, we'd be glad to talk.