The Runtime Web: Why Qbix Built the Framework Everyone Wanted All Along
For more than a decade, the web ecosystem has been trapped in a strange arms race.
Every year, developers were told they needed another layer of tooling just to ship HTML, CSS, and JS:
• Webpack, Browserify, Rollup, Parcel
• Babel, SWC, TypeScript, JSX
• React, Angular, Vue, Svelte
• Vite, Turbopack, Snowpack
• Hydration, partial hydration, islands, workers, service workers, module federation…
And all of it ultimately existed to solve a problem the web already solved:
loading code dynamically at runtime.
While the world built more complicated tools to simulate dynamic loading, Qbix quietly built a framework that actually is dynamic — the way the browser was meant to be used.
Welcome to the Runtime Web.
1. The Web Already Had a Great Module System
Browsers have always supported:
• <script src="...">
• <link rel="stylesheet">
• native caching
• runtime loading
• zero-build workflows
Yet the mainstream ecosystem acted like this wasn’t good enough. So bundlers reinvented dependency graphs, module loaders, transpilers, and massive build pipelines — all to reimplement functionality that already shipped with the browser.
Qbix took the opposite path: use the web as the module system.
No bundler. No build step. No SSR hydration gymnastics. No virtual DOM.
Just an actual runtime.
2. Tools: Components Without Bundlers, Hydration, or Compiler Magic
A Tool in Qbix is a self-contained unit of behavior defined by separate files:
Q.Tool.define("MyBrand/chatroom", {
js: "MyBrand/chatroom/js/main.js",
css: "MyBrand/chatroom/css/styles.css",
html: "MyBrand/chatroom/templates/view.html"
});
Place it in the DOM:
<div class="MyBrand_chatroom_tool"></div>
The runtime loads exactly what’s needed, when it’s needed:
• JS
• CSS
• HTML templates
• localization text
• placeholder UI if configured
Everything is loaded and cached on-demand, using the browser’s native mechanisms. No bundler constructs a giant monolith. No hydration. No mismatch errors. No compile step. This feels closer to a dynamic plugin architecture than a giant monolithic framework!
3. Tools Inherit Behavior via Prefix Rules
A Tool with ID:
id="Q_profile-12_tool"
automatically gets a prefix:
Q_profile-12_
This prefix becomes a namespace for:
• option inheritance
• tool hierarchies
• declarative overrides (via .classname and #id keys)
• activation order
• scoping child tools
It behaves somewhat like CSS cascading, but for component configuration.
For example, any Tool inside this prefix can be targeted with:
{
"#Q_profile-12": { ... options ... }
}
This means no global state, no React context, no dependency injection container.
Just deterministic prefix-based scoping, visible directly in the DOM.
4. Runtime Loading Instead of Bundling
When a Tool activates, the runtime:
• fetches the JS file if not cached
• fetches CSS (in slot order)
• fetches template HTML
• runs constructor
• resolves dependencies declared via require
• ensures Tools only activate once
• tears down cleanly when removed
This is similar to Objective-C’s dynamic loader combined with modern caching.
But on the web.
If a Tool is never used, nothing is loaded.
If a Tool is added later, it loads instantly without rebuilding the app.
You don’t need Webpack’s Module Federation.
You don’t need import maps.
You don’t need tree shaking.
The browser already knows how to load files.
Qbix just uses it.
5. A Real Module System for the Browser
You can require a file at runtime:
Q.require("Utils/format.js", function (Format) {
// use Format
});
And the next Tool requiring it gets the cached export instantly.
No bundler needed to “simulate” this.
6. State, Rendering, and DOM — Without Virtual DOM Tax
Tools manipulate the real DOM directly.
State changes trigger rendering callbacks only when necessary.
tool.rendering("expanded", function (changed, prev) {
if (changed.expanded) openSidebar();
else closeSidebar();
});
There’s no virtual DOM, no diffing engine, no hydration waterfall. There are just explicit, predictable DOM updates triggered by explicit state changes. Everything is observable, inspectable, and debuggable using the same DevTools you already know.
7. What This Enables Today
Because you don’t compile anything, you can:
• ship widgets as drop-in JS files
• embed tools via <script> on any website
• serve Tools from npm through unpkg or Cloudflare
• run a Qbix playground entirely in the browser
• build a widget marketplace with no installation friction
• create an AI-driven “widget builder” that generates Tools on the fly
You can host a whole framework on a CDN, and every widget still loads dynamically, scoped, and cached automatically. This is something people in the mainstream ecosystem have been trying to claw its way back to for years.
Welcome to the Runtime Web.
If you want the simpler, faster, browser-native future—we’re already living in it. It’s free and open source, if you want it too. Here’s the lean front-end version with no back-end dependencies at all:
Related Articles: