$ du -sh .\/node_modules
\n1.2G .\/node_modules
\n$ du -sh ..\/rtos_project\/src
\n420K ..\/rtos_project\/src
\n$ npm install
\nnpm ERR! code ERESOLVE
\nnpm ERR! ERESOLVE could not resolve dependency
\nnpm ERR! Conflicting peer dependency: react@18.3.1
\n…
\n$ node -v
\nv21.7.1<\/p>\n
I\u2019ve spent the last two decades optimizing interrupt service routines to fit within 50-microsecond windows. I\u2019ve fought for every byte of SRAM on an STM32. Now, management has decided that our industrial controller needs a "modern, responsive web dashboard." They\u2019ve handed me a MacBook Pro with 32GB of RAM and told me to use React. Within twenty minutes, I watched a "Hello World" application consume more memory than the entire flight control system of a Boeing 747. \n\nThe web is a graveyard of engineering principles. We\u2019ve traded deterministic execution for a stack of abstractions so high that no one actually knows what\u2019s happening at the silicon level anymore. This is a log of my attempt to understand why we are doing this to ourselves.\n\n## I. The Document Object Model: A Structural Failure\n\nBefore we even get to React, we have to talk about the DOM. In any sane system, if you want to update a pixel, you write a value to a memory-mapped register or a framebuffer. In the browser, you have the DOM\u2014a bloated, tree-based data structure where every single node is a massive C++ object. \n\nWhen you change a single piece of text in a `<span>`, the browser doesn't just update a character buffer. It triggers a cascade. It recalculates styles. It recomputes geometry. It repaints layers. It\u2019s an O(n) operation where 'n' is the complexity of the entire UI. For someone used to O(1) register writes, this is offensive. \n\nReact claims to solve this by adding *another* layer of abstraction on top of the already broken one. This is the "Virtual DOM." Instead of touching the slow DOM, you touch a "fast" JavaScript representation of it. But "fast" is a relative term. In the world of Node.js v21.x, "fast" means "only slightly slower than a turtle with a limp."\n\n## II. The Reconciliation Tax and the Fiber Scheduler\n\nReact 18.3.1 uses something called the Fiber reconciler. To an embedded engineer, this looks like a poorly implemented cooperative multitasking kernel running inside a single-threaded virtual machine. \n\nWhen state changes, React doesn't just update the screen. It starts a "render phase." It builds a new tree of "Fiber" nodes. Each Fiber node is a heap-allocated object containing pointers to its parent, child, and siblings, along with a "memoized" state and a set of "update queues." \n\n**What is** the sanity behind maintaining two entire trees of objects\u2014the "current" tree and the "workInProgress" tree\u2014just to decide that a button's color changed from #FFF to #000? \n\nThe "Diffing Algorithm" is the core of this tax. It\u2019s a heuristic approach to the tree-to-tree transformation problem. Since the general problem is O(n^3), React settles for O(n) by making assumptions. It assumes that two elements of different types will produce different trees. It assumes you\u2019ll provide a "key" prop for list items so it doesn't have to guess which element moved where. \n\nIn C, if I have an array of structs and one changes, I know the index. I update the index. In React, the framework iterates through the old tree and the new tree, comparing types and keys, trying to figure out what changed. It\u2019s a massive amount of CPU cycles spent rediscovering information the developer already knew. \n\n## III. JSX: The Transpilation Nightmare\n\nWe used to write code that the compiler turned into machine instructions. Now, we write JSX\u2014a bastardized marriage of HTML and JavaScript\u2014that must be "transpiled" by Babel or SWC before it can even be parsed by the V8 engine.\n\n```javascript\n\/\/ What I write:\nconst Component = ({ label }) => <div className="btn">{label}<\/div>;\n\n\/\/ What the browser actually gets (roughly):\nconst Component = ({ label }) => React.createElement("div", { className: "btn" }, label);\n<\/code><\/pre>\nEvery time that component “renders,” React.createElement<\/code> is called. That\u2019s an object allocation. Every. Single. Time. If your component renders 60 times a second (the “smooth” UI dream), you are flooding the heap with short-lived objects. You are practically begging the Garbage Collector to step in and freeze your execution thread. <\/p>\nIn an RTOS, we avoid heap allocation during critical loops. In React, the entire philosophy is built on heap allocation during the UI loop. We\u2019ve replaced the stack with a garbage-collected heap and then wondered why the “frame rate” of our web apps feels like a slideshow on anything less than a Core i9.<\/p>\n
\nTable of Contents<\/p>\n