deniz.in

Markets

Weather

Loading weather

· via dev.to (home feed)

myjs: a pure-Python JavaScript runtime with DOM and C FFI lands on PyPI

A new open-source package called myjs runs JavaScript inside a pure Python interpreter, giving scripts direct access to a server-side DOM tree and native C libraries without any compiled engine.

myjs: a pure-Python JavaScript runtime with DOM and C FFI lands on PyPI

A new open-source project called myjs has landed on PyPI, offering a JavaScript runtime implemented entirely in Python. According to the announcement post on dev.to, installing the package with pip or pipx provides a myjs command that parses JavaScript using a Python port of the Acorn parser and executes it inside the host Python process, where scripts can reach the Python standard library, a live DOM tree, and native C libraries.

One process instead of several tools

The author positions the project against a familiar pain point in polyglot engineering. If you want JavaScript to call a C library or manipulate DOM structures outside the browser, the usual routes involve node-gyp and C++ addon build chains, or heavyweight IPC such as gRPC or REST between a Node service and a Python service. myjs folds those layers into a single pure-Python process, with no compiled JavaScript engine attached.

Three capabilities anchor the design, as described in the post:

  • DOM access through domonic, a Python DOM library, so document.createElement, textContent, appendChild and outerHTML operate on a real Python object tree from inside JavaScript.
  • Direct C interop: scripts can load shared libraries such as libc.dylib, 'c' or msvcrt depending on the platform, call exported functions, allocate raw C memory buffers and pass function pointers. No C compiler is involved, since Python's ctypes/cffi tooling resolves the ABI dynamically at load time.
  • A mapping between JavaScript scopes and the host Python standard library, so OS-level capabilities sit alongside the JS environment.

What the demo shows

The dev.to post includes a sample script that loads libc from JavaScript, calls abs(-42) and sqrt(2), then builds a small page with a hyperscript-style helper function using createElement and appendChild before printing document.body.outerHTML. The logged output shows the expected 42 and 1.4142135623730951, plus the rendered markup, produced on macOS arm64 under Python 3.13.12. The demo is compact, but it exercises all three pillars: FFI calls into system C, DOM mutation, and ordinary JavaScript control flow in between.

Questions the announcement leaves open

The post publishes no benchmarks, and a JavaScript interpreter running on top of Python is unlikely to approach the speed of a JIT-compiled engine like V8; the stated selling point is embeddability anywhere Python runs, not raw throughput. Compatibility depth is also unspecified: a ported Acorn parser covers the syntax layer, but the announcement does not detail how much of the modern ECMAScript surface and browser API set is implemented. And because scripts can reach raw C memory and system libraries, myjs is best treated as an environment for code you trust rather than a sandbox for third-party scripts.

Why it matters

Most JavaScript runtimes outside the browser chase performance; myjs chases reach. Anywhere Python runs, a script can now render and inspect a DOM tree or drive a C library without pulling in Node, a compiler toolchain or a message bus between services. That makes it a plausible fit for server-side DOM generation and testing, lightweight glue tooling, and education: a runtime small enough to read is a useful object lesson in how parsers, host bindings and FFI fit together. It also reflects a broader interop pattern of hosting one language's semantics inside another runtime rather than bridging the two. The author says feedback, feature ideas and use cases are welcome from anyone working on language runtimes, Python/JS interop or native bindings.

  • #javascript
  • #python
  • #ffi
  • #dom
  • #open-source

Related posts