{"id":4791,"date":"2026-05-17T21:33:58","date_gmt":"2026-05-17T16:03:58","guid":{"rendered":"https:\/\/itsupportwale.com\/blog\/what-is-react-a-beginners-guide-to-the-js-library\/"},"modified":"2026-05-17T21:33:58","modified_gmt":"2026-05-17T16:03:58","slug":"what-is-react-a-beginners-guide-to-the-js-library","status":"publish","type":"post","link":"https:\/\/itsupportwale.com\/blog\/what-is-react-a-beginners-guide-to-the-js-library\/","title":{"rendered":"What is React? A Beginner’s Guide to the JS Library"},"content":{"rendered":"

text
\n$ du -sh node_modules
\n428M node_modules<\/p>\n

$ top -p $(pgrep -d ‘,’ node)
\nPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
\n12842 silas 20 0 1.244g 312.4m 45.2m S 4.2 1.9 0:18.42 node<\/p>\n

I have spent the last three decades working with the 8051, the AVR, and various ARM Cortex-M cores. I am accustomed to fighting for every single byte of SRAM. I have written bootloaders that fit into 512 bytes of flash. I have optimized interrupt service routines to execute in under twenty clock cycles because the timing of a motor controller depends on it. Yesterday, my CTO informed me that our legacy industrial control interface\u2014a rock-solid, C-based serial protocol that has functioned without a single bit-flip since 1998\u2014is "outdated." He wants a "modern, responsive web dashboard." \n\nHe told me to look into "React."\n\nAfter forty-eight hours of staring into this abyss, I have come to the realization that the modern web is not a feat of engineering; it is a house of cards built atop a landfill. We have traded deterministic execution and memory safety for a bloated, non-deterministic stack of abstractions that would make a mainframe cry. I have been asked to document my findings. Here is my report on the absolute state of "modern" software development.\n\n## What is React? A Layer of Grease on a Broken Axle\n\nTo answer the question "what is react" is to describe a solution to a problem that should never have existed. In the embedded world, if I want to update a display, I write a value to a memory-mapped I\/O register. The hardware reflects that change instantly. In the browser, you have the Document Object Model (DOM). The DOM is a tree structure so inefficient and slow that developers had to invent a "Virtual" version of it just to keep the UI from stuttering like a damaged stepper motor.\n\nReact v18.3.1 is, at its core, a "declarative" library. In the vocabulary of people who don't have to worry about stack overflows, "declarative" means "I will tell the computer what I want, and I will pray the library figures out the most efficient way to do it." As an engineer, I find this offensive. I don't want to "declare" my state; I want to manage it. React sits between the developer and the browser, intercepting every change and running a "reconciliation" algorithm that consumes more CPU cycles than a PID loop running at 10kHz.\n\nIt is a dependency nightmare. To get a "Hello World" running in Node v20.11.0, I had to download 428 megabytes of JavaScript files. For context, the entire Apollo 11 guidance computer source code is about 40 kilobytes. We are using half a gigabyte of disk space to render a text string in a browser. We have lost our way.\n\n## The Virtual DOM: Solving Problems We Didn't Have\n\nThe "Virtual DOM" is the primary selling point of React. The marketing\u2014which I will ignore\u2014claims it makes updates fast. Let\u2019s look at the reality. When a piece of "state" changes, React creates an entirely new virtual tree of the UI. It then compares this new tree with the old tree (a process called "diffing") to find out which parts of the actual DOM need to be updated.\n\nImagine if I did this in an embedded system. Imagine if, to turn on a single LED on a control panel, I first had to create a virtual map of every LED, compare it to the previous map, calculate the difference, and then finally send the command to the GPIO port. The watchdog timer would reset the system before I even finished the comparison. \n\nThis "reconciliation" is a massive waste of resources. It is an admission that the underlying platform (the browser) is too slow to handle direct manipulation. Instead of fixing the platform, we\u2019ve added a massive, memory-hungry middleman. They call it "efficient." I call it a resource leak disguised as a feature.\n\n## JSX: A Syntax Error Disguised as a Feature\n\nIn C, we have a clear separation between logic and data. In React, they use something called JSX. It looks like HTML, but it lives inside your JavaScript. It\u2019s a pre-processor\u2019s nightmare. You are essentially writing tags inside your logic, which then get transpiled by something called Babel into a series of `React.createElement()` calls.\n\nWhy? Why are we mixing concerns? If I put assembly instructions inside a string in a C file and expected the compiler to just "figure it out," I\u2019d be fired. But in the web world, this is considered "best practice." It makes the code unreadable and requires a massive build pipeline just to turn it into something the browser can actually execute.\n\n## Code Comparison 1: State Management\n\nLet\u2019s look at how we handle a simple toggle switch.\n\n**The C Way (Embedded):**\n```c\n\/\/ Direct, deterministic, uses 1 bit of memory.\nvolatile uint8_t system_flags;\n#define PUMP_BIT 0\n\nvoid toggle_pump() {\n    system_flags ^= (1 << PUMP_BIT);\n    update_hardware_output(system_flags);\n}\n<\/code><\/pre>\n
The React Way (Hooks):<\/strong><\/p>\n
\/\/ Indirect, non-deterministic, involves closures, objects, and garbage collection.\nimport React, { useState } from 'react';\n\nfunction PumpControl() {\n  const [isPumpOn, setIsPumpOn] = useState(false);\n\n  const togglePump = () => {\n    setIsPumpOn(prevState => !prevState);\n  };\n\n  return (\n    <button onClick={togglePump}>\n      {isPumpOn ? 'Stop Pump' : 'Start Pump'}\n    <\/button>\n  );\n}\n<\/code><\/pre>\n
In the C version, I know exactly where that bit is. I know when it changes. In the React version, useState<\/code> triggers a re-render of the entire component. The togglePump<\/code> function is re-created on every render unless I wrap it in another abstraction called useCallback<\/code>. We are generating garbage for the Garbage Collector to clean up every time a user clicks a button. It\u2019s a disgrace.<\/p>\n
\n
Table of Contents<\/p>\n