React.js: Modern Frontend Development
Declarative UI Thinking
From Commands to Declarations
When you work with vanilla JavaScript to build a user interface, you operate like a micromanager. You give the browser a precise, step-by-step list of commands. Find this element, create a new one, add this text, append it over there. This is the imperative approach: you're telling the browser exactly how to do its job.
// Imperative approach: telling the browser what to do
// 1. Find the container element
const rootElement = document.getElementById('root');
// 2. Create a new element
const greeting = document.createElement('h1');
// 3. Give it some content
greeting.textContent = 'Hello, World!';
// 4. Add a class for styling
greeting.className = 'greeting-class';
// 5. Append it to the container
rootElement.appendChild(greeting);
This works for small projects, but it quickly becomes complex. You have to manually track the state of your UI and write detailed instructions for every single change. What if we could just describe what we want the UI to look like and let something else handle the tedious steps?
This is the declarative approach, and it’s the core philosophy of React. You declare the desired state of your UI, and React figures out the most efficient way to update the browser's DOM to match it. You manage the what, and React manages the how.
JSX: HTML in Your JavaScript
To describe what the UI should look like, React uses JSX, a syntax extension for JavaScript. It looks a lot like HTML, but it's fully empowered by JavaScript. You can embed variables, run functions, and use logic directly within your UI markup.
// Declarative approach with React and JSX
const greeting = <h1 className="greeting-class">Hello, World!</h1>;
// Tell React to render this element in the 'root' container
ReactDOM.render(greeting, document.getElementById('root'));
Notice there are no step-by-step instructions. We simply describe the <h1> we want. This approach makes code more predictable and easier to debug because the UI is a direct reflection of the application's state. If you want to change the text, you change the state, not the DOM itself.
The Virtual DOM
So how does React translate a declarative description into actual UI on the screen? It uses a clever concept called the Virtual DOM.
Manipulating the real browser DOM is slow and resource-intensive. Every time you change an element, the browser may have to recalculate layouts and repaint the screen, which can be costly. React avoids this bottleneck by first building a lightweight copy of the DOM in memory—the Virtual DOM.
When your application's state changes, React creates a new Virtual DOM tree. It then compares this new tree with the old one, a process called . React's 'diffing' algorithm quickly identifies what changed. Finally, it calculates the most minimal, efficient way to update the real DOM and applies those changes in a single batch.
This process ensures that only the necessary parts of the page are re-rendered, making React applications feel fast and responsive.
Thinking in Components
The final piece of the puzzle is breaking down your UI into small, reusable pieces called components. A button, a search bar, a user profile card—each can be its own component. Components are like custom-made HTML tags that encapsulate their own markup, logic, and state.
This modular approach forces you to think of your UI as a collection of independent, composable parts. A complex screen is just a component made of other components. This makes your codebase far easier to manage, test, and scale compared to a single, monolithic script controlling the entire page.
By shifting from imperative commands to declarative components, you move from telling the browser how to work to describing what the UI should be. This is the fundamental mindset shift for building with React.
Which statement best describes the difference between the imperative approach of vanilla JavaScript and the declarative approach of React for UI development?
What is the primary reason React uses a Virtual DOM?