eQuantic.UIeQuantic.UI
Docs
Playground
GitHub
DocsRuntime
Performance and Optimization
Edit this page
3 min read
The focus of eQuantic.UI is to deliver a Single Page Application (SPA) experience with minimal overhead, leveraging the power of C# to generate highly optimized frontend code.
🚀 Reconciliation and Virtual DOM
The Virtual DOM system was designed to be efficient and anticipate state changes.
Diffing Strategy (Keyed LIS Algorithm)
The reconciliation algorithm uses an efficient Keyed Diffing strategy based on the Longest Increasing Subsequence (LIS) algorithm.
•
Key Property: The key property identifies elements across renders. Elements with the same key are reused and updated in place.
•
LIS Optimization: When elements are reordered, the algorithm computes the longest increasing subsequence to minimize DOM movements. Only elements outside the LIS need to be moved.
•
Prefix/Suffix Optimization: Common prefixes and suffixes are processed first without complex diffing, improving performance for typical list operations (append, prepend).
•
Memory Efficiency: Unmoved elements preserve their browser state (input focus, scroll position, etc.).
🧠 Resource Management (Memory Management)
Memory leaks are mitigated through the intelligent use of weak references and automatic cleanup.
Event Listener Tracking
Event listeners are tracked using WeakMap<HTMLElement, Map<string, EventHandler>>.
•
Weak References: WeakMap allows DOM elements to be collected by the Garbage Collector when removed from the tree, even if the framework still has internal references to their handlers.
•
Automatic Cleanup: When removing a component, the reconciler attempts to explicitly disconnect listeners, but the WeakMap acts as a safety net to prevent leaks in complex lifecycles.
📦 Bundling and Loading
Hybrid Strategy with Bun
The SDK uses an embedded Bun binary to process the final output.
•
Build Performance: Bun processes TS/JS files up to 10x faster than Node.js-based tools.
•
Tree-shaking: Dead code is automatically removed during build.
•
Minification: Scripts are delivered compressed.
Atomic CSS, named the same on both sides
A style is an abstract C# value (BoxStyle, layout props, roles), never CSS. The web realizer turns each property into a deduplicated ATOMIC class, named by a hash of the value (the same FNV rule on the server (StyleAtomizer) and in the browser (style-atomizer.ts)), so the markup SSR wrote and the tree the client builds name one class for one style, and hydration rewrites nothing.
•
One rule per distinct value: a hundred cards with one style share its classes instead of repeating a hundred inline style strings.
•
No stylesheet to fetch: the server writes the rules a page uses into the page itself (<style id="eq-atomic">), and the browser adds a rule to that same sheet the first time its tree needs a class the page did not have.
•
No layout shift from styling: the classes the server rendered are the ones the client keeps.
Code Splitting
•
Chunks per Page: Each page is its own module, which the boot imports on the first navigation to it, and what two or more pages share is a chunk bun splits out once. The user downloads only what is necessary for the current route.
•
Lazy Loading: Complex components and libraries can be loaded on demand.