Update Framework Comparison Guides #7036

Author: tobiu

learn/comparisons/NeoVsAngular.md

@@ -38,12 +38,11 @@ This is where the two frameworks diverge significantly, each offering unique tra
     *   **DOM Pollution:** Angular often adds numerous internal `data-set` attributes to the real DOM for its own tracking and debugging purposes. While functional, this can lead to a less clean and more verbose DOM structure.
     *   **Immutability Considerations:** While Angular doesn't enforce immutability, performance optimizations like `OnPush` change detection often benefit significantly from immutable data patterns. This can introduce a cognitive burden for developers to manage data immutably for optimal performance.
 
-*   **Neo.mjs: Virtual DOM (Off-Main-Thread Diffing & Fine-Grained Reactivity)**
-    *   Neo.mjs uses a Virtual DOM. Your `createVdom()` method (within functional components) returns a plain JavaScript object representing the desired UI structure. **This VDOM is defined using simple nested JavaScript objects and arrays, akin to a JSON-like description of the DOM. Crucially, Neo.mjs's VDOM objects are mutable.**
-    *   **Mutable VDOM & State (By Design):** Unlike Angular, Neo.mjs embraces mutability for both its VDOM and its reactive state (configs and state provider data). Developers can directly modify properties of VDOM objects or state data. This is a deliberate design choice enabled by Neo.mjs's worker architecture. The App Worker sends a *snapshot* (a serialized copy) of the VDOM (or relevant parts of state) to the VDom Worker or Main Thread for diffing or rendering. This allows developers the convenience of direct mutation without sacrificing performance, as the framework handles the efficient snapshotting and communication across workers.
-    *   **Off-Main-Thread Diffing:** The VDOM diffing process occurs in a dedicated **VDom Worker**, offloading this computational work from the Main Thread.
-    *   **Surgical Direct DOM API Updates (`Neo.main.DeltaUpdates` & `DomApiRenderer`):** The VDom Worker sends "deltas" (minimal change instructions) to the Main Thread. `Neo.main.DeltaUpdates` then applies these changes using direct DOM APIs.
-    *   **Fine-Grained Reactivity & Decoupled DOM:** Neo.mjs's `Neo.core.Effect` system precisely tracks dependencies. When a reactive config or state changes, only the specific `createVdom()` effect that depends on it re-executes, leading to highly targeted VDOM updates. Crucially, Neo.mjs components are **completely decoupled from the real DOM**; they reside in the App Worker and never directly read from or write to the DOM. This fundamental architectural choice eliminates the performance bottleneck associated with frequent DOM access, ensuring Main Thread responsiveness and predictable performance. Neo.mjs also strives to keep the real DOM as clean as possible, avoiding the addition of numerous internal framework-specific attributes.
+*   **Neo.mjs: Off-Thread VDOM & Surgical Effect-Based Updates**
+    *   Neo.mjs uses a Virtual DOM defined by plain JavaScript objects (no JSX/build step needed).
+    *   **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.
+    *   **Surgical Updates:** The VDom Worker sends minimal "delta" instructions to the Main Thread, which applies them with efficient, direct DOM APIs.
+    *   **Fine-Grained Reactivity vs. Zone.js:** Instead of Angular's Zone.js, which broadly detects changes by monkey-patching browser APIs, Neo.mjs uses a precise, `Effect`-based system. When a piece of state (`config`) changes, only the `createVdom` functions that *directly depend* on that state are re-executed. This avoids the overhead of Angular's change detection cycles and eliminates the need for manual optimizations like `OnPush` change detection strategy. The result is optimal performance by default.
 
 ### 3. Component Model & State Management
 
@@ -52,7 +51,8 @@ This is where the two frameworks diverge significantly, each offering unique tra
     *   **State Management:** Often relies on services for shared state, or third-party libraries like NgRx (RxJS-based state management).
 
 *   **Neo.mjs: Class-Based & Functional Components, State Providers**
-    *   Neo.mjs offers both a robust class-based component system (`Neo.component.Base`) and modern functional components with hooks.
+    *   Neo.mjs offers a dual component model. Developers can use a robust class-based system (`Neo.component.Base`) for complex, stateful components, or leverage modern, lightweight functional components via the `defineComponent()` API.
+    *   This functional approach uses hooks like `useConfig()` for state, providing a clean, declarative way to build UI while benefiting from Neo.mjs's underlying fine-grained reactivity.
     *   **State Management:** Features integrated state providers and a unified config system for managing and sharing bindable data across the component tree, often simplifying cross-component communication compared to traditional DI or prop passing.
 
 ### 4. Build Process & Development Workflow

learn/comparisons/NeoVsExtJs.md

@@ -112,12 +112,9 @@ limitations of Ext.js.
     *   **Change Detection:** Updates are often triggered manually or through specific framework mechanisms, which can
         sometimes lead to developers needing to explicitly refresh components or views.
 
-*   **Neo.mjs: Fine-Grained Reactivity (Config & Effect System)**
-    *   Neo.mjs uses a modern, fine-grained reactivity system based on `Neo.core.Config` and `Neo.core.Effect`. When a
-        reactive config or state changes, only the specific parts of the UI that depend on it are re-rendered.
-    *   **Benefit:** This leads to highly efficient and precise updates, reducing unnecessary work. It conceptually aligns
-        with the "signals" pattern for granular updates. Developers can directly modify state, and the framework
-        automatically handles the updates.
+*   **Neo.mjs: True, Fine-Grained Reactivity**
+    *   Neo.mjs is built on a modern, fine-grained reactivity system powered by `Neo.core.Config` and `Neo.core.Effect`. When a reactive config or state changes, only the specific parts of the UI that depend on it are automatically updated.
+    *   Developers can simply change a value (`this.myConfig = 'new value'`), and the UI updates automatically and efficiently. There is no need for manual event listeners or explicit setter calls to trigger UI changes. This dramatically simplifies development, reduces boilerplate, and eliminates a common source of bugs.
 
 ### 4. Development Workflow & Modern JavaScript
 
@@ -152,20 +149,10 @@ limitations of Ext.js.
     *   **Class-Based Only:** Ext.js is exclusively class-based. It does not natively support the modern functional
         component paradigm, making it challenging to adopt contemporary UI development patterns.
 
-*   **Neo.mjs: Comprehensive & Technically Superior Component Library & Modern Extensibility (including Functional Components)**
-    *   Neo.mjs also offers a vast component library, providing a breadth of essential UI components (grids, forms,
-        `OffscreenCanvas`, etc.) that achieve **feature parity** with many of Ext.js's offerings. Built on its
-        `Neo.core.Base` class, its comprehensiveness stems from providing a broad set of essential UI components that
-        are designed for **modularity, composability, and high customizability**. Beyond feature parity, Neo.mjs
-        components often offer **technically superior implementations**, such as its highly optimized buffered grid and
-        buffered columns, which provide unparalleled performance for large datasets. It supports both traditional
-        class-based components and modern functional components with hooks (`defineComponent`, `useConfig`), allowing
-        developers to choose the most appropriate paradigm.
-    *   **Superior Extensibility:** Neo.mjs offers a more modern, flexible, and performant level of extensibility.
-        Leveraging native ES Modules and ES6+ classes, its clean class hierarchy, **mixins, plugins**, and reactive config
-        system simplify extending core functionalities. The worker-based architecture enables extensions that run off the
-        Main Thread, opening new possibilities for highly performant features without impacting UI responsiveness.
-        Dynamic module loading further enhances its pluggability.
+*   **Neo.mjs: A Modern, Dual Component Model**
+    *   Neo.mjs offers a flexible, dual component model. Developers can use a powerful, full-featured class-based system (`Neo.component.Base`) that will feel familiar yet superior to Ext.js developers, or they can adopt a modern, lightweight functional component paradigm using the `defineComponent()` API with hooks.
+    *   This provides a clear upgrade path and allows teams to choose the best tool for the job, from complex enterprise grids to simple, declarative UI functions. Its component library achieves feature parity with many of Ext.js's offerings, but with technically superior, modular, and more performant implementations.
+    *   **Superior Extensibility:** Leveraging native ES Modules, a clean class hierarchy, mixins, and plugins, Neo.mjs offers a more modern and performant level of extensibility. The worker-based architecture enables extensions that run off the Main Thread, opening new possibilities for high-performance features without impacting UI responsiveness.
 
 ## Conclusion: Why Neo.mjs is a Modern Successor to Ext.js