#7168 polishing

Author: tobiu

README.md

@@ -124,7 +124,8 @@ That’s Neo.mjs in action — solving problems others can’t touch.
 * **Multi-Window & Single-Page Applications (SPAs)***: Beyond traditional SPAs, Neo.mjs excels at complex multi-window applications.
   Its unique architecture, powered by seamless cross-worker communication (enabled by `Neo.worker.mixin.RemoteMethodAccess`) and
   extensible Main Thread addons (`Neo.main.addon.*`), enables truly native-like, persistent experiences across browser windows,
-  all without a native shell.
+  all without a native shell. This is made possible by the same efficient delta-based DOM update engine, which can surgically
+  move and update components across window boundaries with unparalleled performance.
 
 * **No npm Dependency Hell**: Neo.mjs apps run with **zero runtime dependencies**, just a few dev dependencies for tooling.
   This means smaller bundles, fewer conflicts, and a simpler dependency graph.

learn/blog/v10-deep-dive-vdom-revolution.md

@@ -1,16 +1,14 @@
-# The VDOM Revolution: How We Render UIs from a Web Worker
+# The Surgical Update: From JSON Blueprints to Flawless UI
 
-The Virtual DOM is a cornerstone of modern frontend development. But what happens when you take this concept and move it
-off the main thread entirely, into a Web Worker? It's a compelling idea—it promises a world where even the most complex
-UI rendering and diffing can never block user interactions.
+**A deep dive into our off-thread rendering engine, which uses asymmetric batching and a secure `DomApiRenderer` to eliminate jank at an architectural level.**
 
-For developers, this isn't just an academic exercise. It's the answer to the constant tug-of-war on the main thread—the one that pits your application's complex logic against the user's expectation of a perfectly smooth experience. How do you build a feature-rich, data-heavy UI when every calculation and data fetch threatens to cause jank?
+In a world where some frameworks declare the VDOM "pure overhead," we've made a radical bet: we've doubled down on the VDOM and moved it entirely off the main thread. This isn't a defense of the traditional VDOM; it's a redefinition of its purpose.
 
-The answer is to end the war entirely. Architect the UI to be, by design, immune to the application's workload. This is why we built Neo.mjs.
+The debate between VDOM-based and "VDOM-less" frameworks misses the point. Both are fundamentally limited by the same bottleneck: the single main thread where your application logic, state management, and rendering all compete for resources. The result is inevitable—every complex calculation is a potential source of UI jank, and you're forced to write defensive code (`useMemo`, `useCallback`) just to keep your app afloat.
 
-But this architectural shift introduces a new set of fascinating engineering challenges. How do you efficiently
-communicate UI changes from a worker to the main thread? And what's the best language to describe a UI when it's being
-built by a machine, for a machine?
+Neo.mjs solves this by changing the battlefield. For any true off-main-thread architecture, a VDOM isn't a choice—it's a **necessity**. Since a Web Worker cannot directly access the DOM, it needs a serializable, abstract representation of the UI to send to the main thread. That representation *is* a Virtual DOM. We treat it not as a rendering engine, but as the essential **cross-thread communication protocol**.
+
+This architectural shift is the real revolution. It forces us to answer fascinating new questions: How do you best communicate UI changes between threads? And, most critically, what is the ideal language for describing a UI when it's being built not by a human, but by a machine? The answer is simple, structured data—a language that AI understands natively. This is the foundation for the next generation of applications.
 
 This article explores the solutions to those problems, focusing on two key concepts:
 1.  **Three Philosophies of UI Definition:** How Neo.mjs offers multiple layers of abstraction for building UIs, from high-level declarative trees to low-level VDOM blueprints.