← All posts

Guides

Migrating from Tampermonkey or Greasemonkey to JustZix

17 May 2026 · by JustZix Team

If you have lived with Tampermonkey or Greasemonkey, you already understand the core idea: run your own code on someone else\'s site. JustZix keeps that power but reshapes it around URL-matched rules — small, scoped, individually toggleable CSS or JS units. This guide maps the userscript model onto JustZix and shows where each tool shines.

The mental model: scripts vs rules

A userscript is one file with a metadata header. JustZix splits the same job into two things: a URL match (where it runs) and a payload (CSS or JS). The metadata block you used to write becomes a field in the rule editor.

• @match / @include → the rule\'s URL pattern, e.g. *://*.youtube.com/*
• @run-at document-end → JustZix runs JS rules after the DOM is ready by default
• Styling via GM_addStyle → a dedicated CSS rule, no JS needed
• One big script → several small rules you toggle independently

The biggest shift: in JustZix, CSS is first-class. Anything you did with GM_addStyle becomes a pure CSS rule that is faster, safer and easier to read.

Porting a CSS-only userscript

Plenty of userscripts exist only to inject a stylesheet. Here is a typical one:

// ==UserScript==
// @name    Hide YouTube Shorts
// @match   *://*.youtube.com/*
// ==/UserScript==
GM_addStyle(`
  ytd-reel-shelf-renderer { display: none !important; }
`);

In JustZix this collapses to a CSS rule. URL match: *://*.youtube.com/*. Payload:

ytd-reel-shelf-renderer { display: none !important; }

That is the entire migration. No wrapper, no GM_addStyle, no metadata comment — the rule editor holds the match for you.

Porting a DOM-manipulation userscript

Scripts that change the page at runtime become JS rules. The script body usually ports verbatim; you just drop the metadata header. A userscript that waits for an element:

// ==UserScript==
// @name    Auto-expand comments
// @match   *://example.com/*
// @run-at  document-end
// ==/UserScript==
(function () {
  const btn = document.querySelector('.show-comments');
  if (btn) btn.click();
})();

Becomes a JustZix JS rule with match *://example.com/* and payload:

const btn = document.querySelector('.show-comments');
if (btn) btn.click();

For single-page apps, the same pattern you used in userscripts still applies — observe the DOM rather than assuming a single load:

function run() {
  const btn = document.querySelector('.show-comments');
  if (btn && !btn.dataset.done) {
    btn.dataset.done = '1';
    btn.click();
  }
}
run();
new MutationObserver(run).observe(document.body, {
  childList: true, subtree: true
});

What does not port directly

JustZix runs your JS in the page context with standard web APIs. Userscript-manager extras need a rethink:

• GM_setValue / GM_getValue → use localStorage for per-site persistence
• GM_xmlhttpRequest (cross-origin fetch) → not a JustZix goal; keep those scripts in your userscript manager
• @require external libraries → inline what you need, or paste the library into the rule
• GM_registerMenuCommand → build your own in-page button instead

This is the honest dividing line below.

When to use which

JustZix is the better fit when your goal is tweaking how sites look and behave: hiding clutter, restyling, small UX shortcuts, scoped automation. The rule model keeps each tweak isolated, easy to toggle, and trivial to share as plain CSS or JS.

Keep a userscript manager when a script needs cross-origin network access, a heavy third-party library, or a value store that survives across many sites. The two tools coexist fine — many users run JustZix for the dozens of small visual tweaks and reserve their userscript manager for the two or three heavyweight scripts.

A migration checklist

• List your userscripts and label each: CSS-only, DOM tweak, or network-heavy.
• Move every CSS-only script to a JustZix CSS rule — usually a copy-paste of the style block.
• Move DOM tweaks to JS rules; strip the metadata header, keep the body.
• Split large multi-purpose scripts into several small rules so you can toggle features.
• Leave network-heavy scripts where they are.

The payoff is clarity: instead of one opaque script file, you get a tidy list of named rules, each scoped to exactly one site. Start with our ready-made examples to see the rule format in action, or jump to a concrete tutorial like GitHub developer tweaks. Download JustZix and port your first stylesheet today.