# What Is the "No-Framework, Just Layers" Architectural Pattern in God's Eye View?

> Explore the no-framework, just layers architectural pattern in God's Eye View. Discover how vanilla JavaScript and self-contained data layers enable modularity via a CesiumJS plugin system.

- Repository: [Bilawal Sidhu/gods-eye-view](https://github.com/bilawalsidhu/gods-eye-view)
- Tags: architecture
- Published: 2026-09-11

---

**God's Eye View implements a deliberately minimal front-end architecture that rejects heavyweight UI frameworks in favor of vanilla JavaScript and self-contained data layers, enabling high modularity through a service-based plugin system built on CesiumJS.**

The "no-framework, just layers" architectural pattern represents a deliberate return to browser fundamentals, leveraging plain JavaScript and modular design principles to build complex 3D visualization applications. As implemented in the open-source project **bilawalsidhu/gods-eye-view**, this approach eliminates React, Vue, or Angular dependencies in favor of vanilla JS, **CesiumJS**, and **Vite**. Each feature is encapsulated as an independent layer module that interacts with the core application through well-defined service interfaces, creating a lightweight, hackable codebase.

## Core Philosophy: Vanilla JavaScript Without Framework Overhead

The foundation of the "no-framework" philosophy is handwritten state management and DOM manipulation living in plain JavaScript files. According to the [`README.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/README.md), the project explicitly states: "No framework. Vanilla JavaScript, **CesiumJS**, and **Vite**". All UI and interaction code resides in files like [`src/main.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/main.js) and [`src/ui.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/ui.js), where event handling and rendering logic are implemented without React hooks, Vue reactivity, or Angular components.

By avoiding framework abstractions, the codebase remains approachable for developers who prefer working directly with browser APIs. The [`src/main.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/main.js) file serves as the entry point, bootstrapping the CesiumJS viewer and registering all data layers, while [`src/ui.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/ui.js) handles HUD and panel construction using standard DOM methods rather than JSX or template syntax.

## The Layer-Only Design Pattern

The "just layers" concept implements a modular architecture where each live data source—flights, vessels, satellites, CCTV, and infrastructure—exists as an independent module under `src/data/`. Each layer exposes a standardized interface including methods such as `init`, `enable`, `disable`, `update`, `destroy`, and `getStats`, allowing the central data-layer manager to orchestrate them uniformly.

As documented in [`docs/INFRASTRUCTURE-LAYERS.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/docs/INFRASTRUCTURE-LAYERS.md), layers are not merely visual overlays but self-contained units that manage their own data fetching and rendering lifecycles. When registered with the global manager via `dataLayerManager.register()`, each layer receives the specific service callbacks it needs to render on the shared Cesium globe instance.

## Loose Coupling via Service Injection

Rather than accessing a global store or creating independent Cesium viewers, layers receive a set of service callbacks during initialization. These include the **overlay host** (providing `setEntries`, `setVisible`, and `clearSource`), entity-context helpers (`registerEntityContext`, `selectEntityContext`), and render governors (`governorRequestRender`).

This dependency injection pattern enforces strict boundaries between layers and the core application. The `createInfrastructureLayers` factory function demonstrates this approach, accepting a services object that satisfies the layer's requirements without hard-coding dependencies:

```javascript
// Creating infrastructure layers with injected services
import { createInfrastructureLayers } from 'gods-eye-view/infrastructure';

const layers = createInfrastructureLayers({
  overlayHost: { setEntries, setVisible, clearSource },
  registerEntityContext,
  selectEntityContext,
  clearSelectedEntityContextForLayer,
  removeEntityContextsForLayer,
  governorRequestRender,
});

// Register with the global manager
layers.forEach(layer => dataLayerManager.register(layer));

```

## Layer Visibility and Lifecycle Control

The architecture exposes explicit control over layer states through tools like `set_layer_visibility`, implemented in `src/voice/`. Because layers maintain clean separation between data fetching and rendering, disabling a layer simply halts its network requests and hides its graphics without side effects on other modules.

The OpenAPI specification in the voice tool directory defines this interface, allowing both programmatic and voice-driven toggling:

```javascript
// Toggle layer visibility via the tool API
await fetch('/api/tool', {
  method: 'POST',
  body: JSON.stringify({
    name: 'set_layer_visibility',
    arguments: { layerId: 'flights', enabled: true }
  })
});

```

For direct UI interactions, vanilla JavaScript event listeners can call these APIs without framework boilerplate:

```javascript
// Minimal "no-framework" UI component
document.getElementById('layer-toggle').addEventListener('click', () => {
  const enabled = !layer.isEnabled;
  setLayerVisibility('flights', enabled);
});

```

## Key Implementation Files

Understanding the pattern requires examining specific source files that illustrate the architecture's minimal surface area:

- **[`src/main.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/main.js)**: The application entry point that initializes Cesium, configures the viewer, and registers all available data layers.
- **[`src/ui.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/ui.js)**: Implements panels, HUD elements, and interaction handlers using standard DOM APIs rather than framework components.
- **`src/data/`**: Directory containing individual layer modules (e.g., [`flights.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/flights.js), [`cctv.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/cctv.js), [`satellites.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/satellites.js)), each implementing the standard layer interface.
- **`src/voice/`**: Houses the 28 voice-controlled tools, including the `set_layer_visibility` tool that manipulates layer states.
- **[`docs/INFRASTRUCTURE-LAYERS.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/docs/INFRASTRUCTURE-LAYERS.md)**: Formal documentation describing the layer factory API and required service callbacks for infrastructure visualization.
- **[`README.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/README.md)** (sections "No framework" and "Under the Hood"): High-level architectural philosophy and pattern rationale.

## Summary

The "no-framework, just layers" pattern in God's Eye View delivers a highly modular, framework-free codebase by adhering to these principles:

- **Vanilla JavaScript core**: All UI logic in [`src/main.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/main.js) and [`src/ui.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/ui.js) uses standard browser APIs without React, Vue, or Angular dependencies.
- **Self-contained layer modules**: Each data source in `src/data/` implements standardized methods (`init`, `enable`, `disable`, `update`, `destroy`, `getStats`) via the layer interface.
- **Service-based dependency injection**: Layers receive scoped callbacks (overlay host, entity context, render governor) rather than accessing global state or creating duplicate viewers.
- **Explicit lifecycle management**: The `set_layer_visibility` tool in `src/voice/` provides granular control over layer activation without cross-module side effects.
- **Vite and CesiumJS foundation**: The build pipeline and 3D rendering engine represent the only significant external dependencies.

## Frequently Asked Questions

### What exactly is the "no-framework, just layers" pattern?

The "no-framework, just layers" pattern is an architectural approach that builds complex web applications using **vanilla JavaScript** instead of React, Vue, or Angular, where every feature is encapsulated as an independent "layer" module. Each layer in `src/data/` handles its own data fetching and rendering logic while communicating with the core application through a predefined service interface, eliminating the need for heavyweight framework abstractions while maintaining modularity.

### How do layers communicate without Redux, Vuex, or similar state managers?

Layers communicate through **dependency injection** of service callbacks rather than global stores. When created via factories like `createInfrastructureLayers`, each layer receives specific functions for rendering (`overlayHost`), entity selection (`registerEntityContext`), and render scheduling (`governorRequestRender`). This approach keeps layers loosely coupled while allowing the central application in [`src/main.js`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/src/main.js) to coordinate their activities through the `dataLayerManager`.

### Can I add custom data sources to God's Eye View without learning React or Vue?

Yes, the pattern is specifically designed for framework-free extension. Developers can create new layer modules in `src/data/` by implementing the standard interface methods (`init`, `enable`, `disable`, `destroy`, etc.) and registering them with `dataLayerManager.register()`. As documented in [`docs/INFRASTRUCTURE-LAYERS.md`](https://github.com/bilawalsidhu/gods-eye-view/blob/main/docs/INFRASTRUCTURE-LAYERS.md), the layer only needs to accept the required service callbacks to integrate with the existing CesiumJS viewer, making the system accessible to developers familiar with vanilla JavaScript and browser APIs.

### What performance benefits come from avoiding frameworks in this architecture?

By eliminating virtual DOM diffing and framework reactivity overhead, the application maintains direct control over CesiumJS rendering cycles and network request batching. The `governorRequestRender` callback allows layers to request frames only when necessary, while the explicit `enable`/`disable` lifecycle in each layer prevents background data fetching for inactive visualizations. This results in predictable memory usage and render performance critical for real-time 3D globe visualization.