The system remains understandable
A component's code can be directly linked to the behavior it produces in the browser. The framework's conventions help organize development while keeping the underlying platform accessible and easy to work with.
A standards-based frontend framework for building modular web applications with vanilla JavaScript and browser APIs.
ModularCube provides a complete component model, declarative templates, scoped
styling, lifecycle orchestration,
application routing
,
communication utilities, and differential DOM updates. Application code remains
expressed through HTML, CSS, JavaScript, and the
browser platform.
ModularCube is useful when the browser itself is meant to remain the application’s main
environment and rule set. It brings recurring frontend work, components, templates,
lifecycle
timing, styling, events,
routing
, and updates into one consistent model while preserving
direct access to HTML, CSS, JavaScript, and DOM APIs.
Software projects often become difficult to manage not because the problem itself is complicated, but because coordinating the different parts of the solution becomes increasingly complex. ModularCube addresses this challenge by providing a clear structure that removes repetitive coordination work while keeping that structure easy for both developers and software tools to understand. [1] [3] [4]
A component's code can be directly linked to the behavior it produces in the browser. The framework's conventions help organize development while keeping the underlying platform accessible and easy to work with.
A component brings together its structure, presentation, configuration, and behavior into a single, clearly defined unit. This follows the well-established software engineering principle of hiding implementation details behind carefully designed module interfaces. [2]
A shared lifecycle, file convention, directive syntax, and initialization model reduce the number of local patterns that must be remembered and maintained across releases. [5]
Registered components are custom HTML elements that continue to work seamlessly with standard HTML documents, JavaScript modules, developer tools, accessibility APIs, and the browser's built-in event system. [9]
The core component model does not require a package dependency tree. Additional libraries can still be adopted when they provide clear value, but their versions, transitive dependencies, and maintenance requirements are treated as deliberate architectural decisions. [7]
The core idea behind ModularCube is that a full-featured front-end framework can provide a solid structure while preserving the browser platform's transparency, simplicity, and clarity.
This framework is especially well suited for projects that value direct control over the browser, clear component boundaries, and a straightforward development model.
Application developers
Well suited for applications that benefit from explicit components, scoped styling, and direct access to browser APIs.
Existing product teams
Custom elements can be integrated into existing pages and applications without requiring an immediate redesign of the surrounding system.
Platform and UI teams
A consistent component format supports internal design systems, reusable features, and interface development across multiple projects.
Educators and learners
The runtime stays grounded in the same HTML, CSS, JavaScript, and DOM concepts that form the foundation of web development.
Integration authors
Native custom elements provide a practical way to organize widgets, documentation tools, dashboards, and reusable UI packages.
AI-assisted development teams
Standard files, familiar syntax, well-defined lifecycle stages, and explicit update calls provide coding assistants with a structured and transparent development model. [10]
ModularCube began as a system for quickly prototyping and assembling web pages. Its early versions recreated familiar front-end development patterns and interactions using plain JavaScript and the browser's built-in APIs.
As the framework evolved through repeated use, a consistent set of ideas emerged. These
concepts were refined into component configuration, lifecycle stages, declarative
directives, scoped resources, application initialization,
routing
, communication utilities,
and targeted updates. Over time, ModularCube grew from a simple prototyping tool into a
full-featured framework designed for complete applications and long-term maintainability.
Rendering work is scoped to component content, and explicit differential updates avoid treating every state change as a full-page operation. Practical performance remains a measurable property of each application, device class, and workload.
Named lifecycle stages establish when resources are loaded, when markup enters the view, when the Shadow DOM is ready, and when frame-based work runs. [8]
A regular component layout and declarative template vocabulary reduce repeated setup decisions, allowing page construction to move quickly from structure to behavior.
Each component has explicit ownership of its configuration, template, styles, and JavaScript behavior, making responsibilities visible in the project structure.
Registered components are ordinary custom elements. They can be nested, reused, and combined into larger interfaces through standard HTML composition.
The constrained file structure and explicit execution stages make relevant context easier to gather for an agent helper. Generated changes remain subject to tests, review, and responsible-use controls. [11]
A component is normally described by four files. Configuration names the component and points to its HTML and CSS resources; the JavaScript module defines lifecycle behavior.
MyComponent/
├── MyComponent.config.json
├── MyComponent.html
├── MyComponent.css
└── MyComponent.js
Loads configuration and resources.
Runs before HTML is attached to the view.
Receives the completed Shadow DOM.
Runs at the FPS defined by component behavior.
this.updateHTMLContent()
updates the component’s HTML and CSS through the
framework’s differential DOM process. It is called after state changes that need
to be reflected in the rendered component.
The shortest path is to load the framework through an import map, register the application components, and initialize the DOM.
Step 1
Add the import map and load the initialization module with type="module".
Step 2
Declare component tags and module paths in app.config.json.
Step 3
Create the configuration, HTML, CSS, and JavaScript files for the first component.
Step 4
Call Dom.init() after the configuration is available.
<script type="importmap">
{
"imports": {
"@modular-cube": "https://cdn.jsdelivr.net/gh/mxi-git-repo/modular-cube-release@v1.0.1/main.js"
}
}
</script>
<script type="module" src="./init.js"></script>
ModularCube is intended for real-world applications. Production readiness is established by applying ordinary engineering controls to the application, its browser targets, its component behavior, and its delivery environment.
The documentation is organized from first use to framework internals.
Create the first application and component.
Learn registration, component ownership, lifecycle, and rendering.
Configure files, resources, behavior, and composition.
Use interpolation, conditions, iteration, parameters, and event bindings.
Work with processing stages, FPS behavior, cleanup, and DOM updates.
Apply routing, state, Observable communication, and common patterns.
Find classes, methods, configuration fields, and directive syntax.
Track releases, compatibility notes, and upgrade instructions.
Questions are directed according to whether the subject is usage, a reproducible defect, or documentation.
Usage questions, design discussions, examples, and shared solutions.
Missing explanations, inaccurate examples, terminology, and navigation.
Defects, regressions, compatibility problems, and minimal reproductions.
The Factory documents how the framework itself is studied, changed, tested, reviewed, and released. It is intended for contributors and maintainers working below the public component API.
Runtime responsibilities, rendering, registry, routing, and data flow.
Source layout, local development, diagnostics, and tooling.
Unit behavior, browser checks, performance evidence, and accessibility.
Issues, proposals, pull requests, review, and decision records.
Terminology, runnable examples, diagrams, and API change notes.
Versioning, compatibility, release checks, ownership, and roadmap.
Current priorities, planned work, and compatibility direction.
Release historyPublished versions and behavior changes.
LicenseTerms for use, modification, and distribution.
Security policyReporting channels and supported release policy.
GovernanceDecision ownership, contribution review, and release authority.
Source repositoryFramework code, issues, releases, and project activity.
The project source documents ModularCube’s history and behavior. The remaining references provide established context for complexity management, modular design, software evolution, dependency ecosystems, browser performance, web architecture, AI-assisted programming, accessibility, and secure development. They are not presented as independent certification of the framework.
Review the permissions and limitations for using this material.
Copyright (c) [Year] [Author or Organization Name]
Permission is hereby granted, free of charge, to any person obtaining a copy of this document, software, and associated media files (the "Material"), to deal in the Material without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Material, and to permit persons to whom the Material is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Material.
The material is provided "as is", without warranty of any kind, express or implied, including but not limited to the warranties of merchantability, fitness for a particular purpose and noninfringement. In no event shall the authors or copyright holders be liable for any claim, damages or other liability, whether in an action of contract, tort or otherwise, arising from, out of or in connection with the material or the use or other dealings in the material.
Last updated:
Read full legal documentationContent or functionality unavailable
Some content and features in this application are still under development and are not yet implemented. They will become available in a future release. Thank you for your patience and understanding.