Template, logic and style
in one compiled file.
MMO is a full framework, not a component kit bolted onto someone else's build tool: a
PHP application layer (mmo.core) and a native Web Component runtime
(mmo.client) that share one manifest, one dependency graph, and one file format
— .jhs.
markup, the element class and its styles, per component — compiled to one .js
no dart, no java, no node, no watcher: .jhs, Simple CSS and the javascript bundle all compile in php
the css prelude an element pays, instead of a second copy of the design system
Source: src/JHSCompiler.php, src/JSCompiler.php, src/styles/shadow.scs.
One file, three languages
Every custom element is a single .jhs file, compiled by
MMO\client\JHSCompiler, in PHP. The file above is one; here are
its three regions, one at a time.
template - real markup, which becomes the element's shadow dom.
script - the element class, ES2022 — the compiler gives it its base class, its observed attributes
and a
render()built from the markup. style - scoped Simple CSS, written against the same design tokens the document declares.
Reactive without the ceremony
Every element and view carries a View over a Map. Bind a template path
to it once and reads, writes, loops and conditionals all resolve against the same live object
— no virtual DOM, no separate state library to wire in.
this.view.watch- re-runs a callback whenever a bound path changes — that's your only render loop.
{path}/bind-text- bindings resolved against the current scope:
{path}for markup you wrote,bind-textfor a value a user typed, set as text. <for>/<if>- structural directives, not string templates — they compile to real DOM operations.
$this/$key- the element instance and the loop key, dropped straight into event handlers.
MMO.core.dom.createElement, a template or a message of
the shell (notify, alert, confirm…) is a text node. Markup is
what you ask for, with MMO.core.dom.html() — never what a user's input turns into.
A component library that ships with the framework
Calendars, charts, trees, a PDF viewer, a Swagger explorer, a code editor — shipped, themed, and built from the exact same primitives you'll use for your own elements.
Layout
Inputs
Modules
Elements & tools
The whole application in one element
<mmo-app> is the chrome of this very site: the menu, the breadcrumb, the table of
contents, the notifications and the search. A page only brings its content.
Three templates
admin, landing and blog, picked by the host's class: one shell for a back office, a product site and a journal — each in light and dark, from the same tokens.
One search box
Alt / opens the command palette: pages, commands and every remote source — the documentation included — grouped in one list.
A developer drawer
The status bar opens the journal of the request and, in dev, the server: php, its extensions and every package included.
A styling language we compile ourselves
The style block of a .jhs file is Simple CSS — .scs, a thin
compile-time layer over css with variables, design tokens, reusable styles, functions, nesting and
responsive blocks. The lexer, the parser, the evaluator and the emitter are php, so a stylesheet
compiles anywhere the framework runs.
Spacing, colour, radius and elevation are names, not memorised utility classes, and the recipes built from them are fragments a rule inlines. Change the brand ramp once and everything follows: buttons, links, focus rings, charts, the active menu item, the dark theme.
- @theme
- the only construct that emits runtime css variables
- @style / @use
- a block of declarations, inlined where it is used
- lib:: / controls::
- a file is a namespace
- @screen / @order
- named breakpoints, explicit cascade order
A shadow root never sees the document's css — but it does inherit its custom properties. So the document declares the tokens once and an element only references them: 53 bytes of prelude per element instead of a second, drifting copy of the design system. The same recipes paint both sides, which is why a control looks identical whether it was written in a page or inside an element.
Tokens — the vocabulary
Styles — the recipes
And a whole design system comes with it — buttons, forms, tables, lists, cards, panels, tabs, callouts, overlays, prose, marketing and editorial sections, in light and dark. Every class, every variant and the html that produces it is listed under Design system; the language itself is under Simple CSS.
.scs: a colour derived from the brand stays derived.
One manifest ties the backend to the browser
Every MMO package — mmo.core, mmo.client, your own app —
declares itself in a single mmo.json: dependencies, bootstrap entry, i18n, docs and
version, resolved together by the same PackageManager.
The backend is a real application framework, not a thin API shim: entities and repositories, an HTTP router and controllers, schemas, an event system — all resolvable from the same package graph that ships your UI.
And the libraries built on it, each one a package like your own:
AdminController.
From a commit to production, and back
The framework carries its own release tooling. This site is deployed by it, to a shared webspace that only lets ssh in.
Targets in deploy.json, one immutable release built from a git ref, an atomic symlink swap, a health check and a one-command rollback — on a server of yours or a shared webspace.
The reference documentation built from the source itself: PHP and JavaScript doc comments, markdown guides, runnable examples.
PHPUnit for every library, and the whole JavaScript runtime under Node: npm test, no browser needed.
Your framework already speaks MCP
Every package's mmo.json already lists its documentations folder. Drop
markdown in it, and the framework's own MCP server — full JSON-RPC 2.0, in
MCPController — discovers and serves it automatically. So do the agent skills a
package ships, for the PHP side and for .jhs: an assistant reads how the framework is
written before it writes any of it.
search_documentation
Full-text search over every package's markdown, documented symbols first.
documentation_index
Every namespace, class, function, element and guide mmo.doc documented.
describe_class
Introspects any class on the manifest graph: parent, role, public methods.
list_routes
Every connected #[APIRoute]: method, url, operation id.
get_entity_schema
An entity's full JSON Schema, straight from its class.
generate_controller_stub
A new controller that follows the framework's conventions, as text.
Connect your AI to MMOFramework
That server runs in public at https://mcp.mmoframework.fr/,
with the documentation and the API of every mmo.* library. Point an MCP client at it and your
assistant reads the framework's guide, searches the documentation and introspects its classes —
instead of guessing from its training data. Read-only: nothing it exposes writes a file or a record.
https://mcp.mmoframework.fr/mcp.json — JSON-RPC 2.0 over http (POST), no authentication.
Run once, from any folder: the server is then available in every session.
Settings › Connectors › Add custom connector: name it, paste the url, no authentication.
Any client speaking MCP over http: add it to the client's MCP configuration (.mcp.json, .cursor/mcp.json, .vscode/mcp.json…).
Read the source. Then read the docs it writes about itself.
Everything above is real, running code — not a curated highlight reel. The full API is generated
straight from that source by mmo.doc.