# Neo.mjs vs Solid.js

Neo.mjs is a comprehensive JavaScript ecosystem for building high-performance, multi-threaded web applications. Unlike libraries such as Solid.js that focus purely on rendering and are typically part of a manually assembled toolchain, Neo.mjs is a self-contained system with **zero runtime dependencies**. It provides a complete, out-of-the-box solution that includes four distinct development and deployment environments, from a revolutionary zero-builds development mode to thread-optimized production bundles.

This article provides a focused comparison between the Neo.mjs ecosystem and Solid.js. While both architectures leverage fine-grained reactivity for high performance, they employ fundamentally different architectural and rendering strategies to achieve their goals. We will explore their approaches to **rendering, reactivity, and DOM updates**, highlighting the trade-offs between Solid's "no-VDOM," Main-Thread-bound model and Neo.mjs's holistic, worker-based paradigm.

## Core Similarities: Fine-Grained Reactivity

At their heart, both architectures share the philosophy of **fine-grained reactivity**:

*   **Direct Updates:** When a piece of reactive state changes, only the specific parts of the UI that directly depend on that state are updated. This minimizes unnecessary re-renders of entire component trees, a common performance bottleneck in traditional Virtual DOM architectures.
*   **Reactive Primitives:**
    *   **Solid.js:** Utilizes "signals" (`createSignal`) as its primary reactive primitive.
    *   **Neo.mjs:** Employs `Neo.core.Config` instances as its core reactive primitive.
*   **Automatic Dependency Tracking:** Both architectures automatically detect dependencies. When code executes within a reactive context (e.g., an effect, a memo, or a component's render logic), any reactive primitive accessed during that execution is automatically subscribed to. This eliminates the need for manual dependency declarations in many cases.

## Key Differences: Architectural & Rendering Strategies

This is where the two architectures diverge significantly, each offering unique trade-offs.

### 1. Rendering Mechanism: A Tale of Two Architectures

*   **Solid.js: No VDOM—A Consequence of Single-Threaded Design**
    *   Because it operates entirely on the Main Thread, Solid.js can forgo a Virtual DOM. It compiles JSX directly into highly optimized, imperative JavaScript instructions that create and surgically manipulate the real DOM.
    *   When a signal (which holds an immutable value) updates, Solid's reactive graph knows precisely which DOM node to change and updates it directly, without any VDOM diffing overhead.
    *   **Benefit:** This "no VDOM" approach is extremely fast for DOM updates, as it eliminates the overhead of VDOM reconciliation. This is the peak of Main-Thread rendering performance.

*   **Neo.mjs: VDOM as a Necessity for Multi-Threading**
    *   For Neo.mjs, a Virtual DOM is not an optional design choice—it is a **necessary and powerful consequence** of its multi-threaded architecture. Since components and application logic live in the App Worker, they have **no access to the DOM**.
    *   The VDOM serves as the essential, serializable blueprint of the UI. It's a lightweight description defined using plain JavaScript objects (no JSX).
    *   **Mutability by Design, Immutability in Process:** Neo.mjs allows for convenient, direct mutation of state and VDOM in the App Worker. When an update is triggered, it sends an immutable JSON snapshot of the VDOM to a dedicated VDom Worker for diffing. This provides developer convenience without sacrificing performance.
    *   **Benefit:** This architecture makes off-thread VDOM diffing possible, which in turn guarantees Main Thread responsiveness. The overhead of the VDOM is the price for keeping the UI from ever freezing. The process is further optimized via atomic DOM insertions, where entire subtrees are built in a detached state and inserted into the live DOM in a single operation.

### 2. Component Execution Model

*   **Solid.js: Components Run Once**
    *   Solid's functional components execute only *once* during their initial render. Their primary role is to set up the reactive graph (signals, effects, memos) and create the real DOM nodes. They do not re-run when state changes. Updates are handled by the fine-grained reactivity system directly updating the DOM.
    *   **Benefit:** Extremely efficient, as component functions are not re-executed.

*   **Neo.mjs: `createVdom` Re-runs Inside an Effect**
    *   In Neo.mjs, the `createVdom` method of a functional component is wrapped in a `Neo.core.Effect`. This effect automatically tracks which `config` values it reads.
    *   When a dependency changes, the `Effect` re-executes the `createVdom()` function to get a new VDOM description. This is fundamentally different from a React re-render, as it's a targeted re-execution of only the VDOM generation logic, not the entire component setup, and it doesn't cascade to children whose configs haven't changed.
    *   **Benefit:** This model is highly intuitive (the VDOM function re-runs when its inputs change) and provides automatic, surgical updates without the developer needing to worry about manual dependency tracking or memoization.

### 3. Overall Architecture

*   **Solid.js: Single-Threaded (Main Thread Focused)**
    *   Solid.js operates entirely on the main JavaScript thread. Its optimizations are focused on making the Main Thread's work as fast and efficient as possible.
    *   **Benefit:** Simpler deployment and debugging model, as all JavaScript runs in one context.

*   **Neo.mjs: Worker-Based (Main Thread + App Worker + VDom Worker)**
    *   This is Neo.mjs's most distinctive feature. Application logic (including component instances, state, and `vdomEffect`s) runs in a dedicated **App Worker**, separate from the Main Thread. The VDOM diffing occurs in a **VDom Worker**.
    *   Communication between workers and the Main Thread happens via message passing.
    *   **Benefit:** Keeps the Main Thread free and responsive, preventing UI freezes even during heavy computations or complex application logic. It inherently leverages multi-core CPUs for parallel processing.

### 4. Update Aggregation & Batching

*   **Solid.js:** Relies on its fine-grained reactivity and direct DOM manipulation for efficient updates. While it has its own batching mechanisms for signal updates, it doesn't have a VDOM reconciliation phase to aggregate changes.
*   **Neo.mjs:** Employs sophisticated batching and aggregation:
    *   **Roundtrip-Based Batching:** Multiple reactive changes within a single tick can be batched into one VDom worker request.
    *   **VDom Tree Aggregation (`VdomLifecycle`):** Changes in child components can be aggregated into a parent's update. If a parent is updating, a child's update is deferred and its changes are included in the parent's VDOM diff, minimizing redundant VDom worker roundtrips.
    *   **`requestAnimationFrame` Aggregation:** The final application of deltas on the Main Thread (via `DeltaUpdates`) is implicitly batched by the browser's `requestAnimationFrame` cycle, ensuring all DOM changes for a frame are applied efficiently.
    *   **Benefit:** This multi-layered batching and aggregation strategy leads to significantly fewer real DOM changes and smoother visual updates, especially in complex applications.

### Other Considerations:

*   **JSX vs. Plain Objects:** Solid uses JSX (requiring a build step), while Neo.mjs uses plain JavaScript objects for VDOM (no JSX compilation needed). **This means Neo.mjs's VDOM is defined using simple nested JavaScript objects and arrays, akin to a JSON-like description of the DOM.**
*   **Side Effects:** Solid has explicit `createEffect` and `createRenderEffect` hooks for managing side effects. In Neo.mjs, `createVdom` is the primary effect for rendering, and other side effects would typically be managed by separate `Neo.core.Effect` instances or dedicated hooks.
*   **Ecosystem & Maturity:** Solid.js has a growing community and ecosystem. Neo.mjs has a smaller but dedicated community, with a focus on engine-level solutions.

## Conclusion

Both Neo.mjs and Solid.js are highly performant, modern reactive solutions.

*   **Solid.js** excels by completely sidestepping the Virtual DOM, compiling directly to efficient DOM operations, and running components only once. It's a lean, fast choice for Main Thread-bound applications.
*   **Neo.mjs** offers a unique value proposition with its worker-based architecture, offloading heavy computation from the Main Thread to ensure UI responsiveness. It combines this with a sophisticated VDOM pipeline that includes off-Main-Thread diffing, intelligent batching/aggregation, and surgical direct DOM API updates.

The choice between them depends on the specific application's needs: Solid.js for ultimate Main Thread rendering speed, and Neo.mjs for guaranteed Main Thread responsiveness and leveraging multi-core processing, especially in complex, data-intensive applications.