WSGIC + BridgeIO Ecosystem
A Python web framework and a family of cross-language bridges that let Python, JavaScript, and the browser call each other directly.
Read the build from several angles.
Authentic screens, terminal output, and architecture plates are kept together so the page shows the shape of the work without inflating the claim.
This record uses a procedural architecture view because no authentic public screenshot has been approved.
TOOLING
What exists.
WSGIC is a Python web framework. BridgeIO is the runtime layer underneath: py_bridge, js_bridge, browser-bridge, PybridgeWeb, JsBridgeWeb, and ExpressPy let Python control JavaScript DOM, serve Express-style routes, and share objects across language boundaries. The ecosystem also includes es62py (an ES6-to-Python transpiler) and virtual-dom (direct Python control of the browser DOM).
Where it resisted.
Python and JavaScript have different event loops, object models, and runtime lifecycles. Making them call each other without serialization overhead requires matching their execution contexts at the transport layer.
What I changed.
Built paired client-server bridges for each language boundary: py_bridge for Node-to-Python, js_bridge for Python-to-Node, browser-bridge for browser-to-server, and combined surfaces like ExpressPy and virtual-dom.
The obvious implementation was not the product.
Make each bridge a small, focused library rather than one monolithic runtime, so each language pair can be used independently.
Current proof
04- ExpressPy serves Express.js-style routes from Python using py_bridge and js_bridge.
- virtual-dom controls browser DOM directly from Python.
- es62py transpiles ECMAScript 6 syntax to Python equivalents.
- wsgic ships auth, API, and admin modules.
What this build changed.
Cross-language instinct starts with understanding what each runtime does well and building the thinnest possible bridge between them.