React caught my attention because it felt slightly uncomfortable.
Most of the front-end work I had been doing still followed a fairly familiar mental model. HTML described the page, CSS controlled the presentation and JavaScript added behaviour around it. Even when the code became more complex, the separation still felt reassuring. React seemed to question that arrangement by bringing interface structure and behaviour much closer together.
At first, I was not sure whether I liked that.
The idea of describing interface pieces in JavaScript felt strange, especially when so much front-end practice had been built around keeping concerns apart. The more I looked at it, though, the more I could see the problem it was trying to solve. Dynamic interfaces were already becoming difficult to manage with scattered selectors, templates and event bindings. React was not creating that complexity. It was responding to it.
The Problem Was Already There
By 2013, a lot of websites were no longer behaving like simple documents.
A product filter might update without reloading the page. A dashboard might need to redraw parts of itself after data changed. A form might show validation messages, loading states and conditional fields. A navigation area might behave differently depending on screen size and user interaction. The page was still HTML in the browser, but the experience was becoming much more stateful.
The traditional approach could handle this, but it often became messy. A template might live in one place, a jQuery selector in another and the current state of the interface somewhere else entirely. After a few rounds of changes, it could become difficult to understand which part of the code was responsible for what the visitor was seeing.
That is where React became interesting. It encouraged the interface to be described as pieces that knew how to render themselves based on their current data. Instead of manually nudging the DOM into the correct shape after each change, the component became the place where the output was described.
The Difficult Part Was JSX
The part that initially felt hardest to accept was JSX.
Seeing markup-like syntax inside JavaScript challenged a lot of habits. It looked wrong at first glance because I was used to thinking about HTML and JavaScript as separate layers. The more I thought about it, though, the more I realised that the separation I cared about was not necessarily file type. It was responsibility.
If a small piece of interface has its own structure, its own behaviour and its own state, there is a reasonable argument that those things should live close together. A button that changes text while saving, a panel that opens and closes, or a notification that appears and disappears is not just markup with some JavaScript attached. It is a small interactive unit.
That does not mean every website should move in this direction. For a mostly static marketing site, JSX would probably create more questions than answers. But for interfaces that are constantly changing in response to user actions, I can understand why keeping structure and behaviour together might make the code easier to reason about.
var SaveButton = React.createClass({
render: function() {
return (
<button className="save-button">
{this.props.isSaving ? 'Saving...' : 'Save changes'}
</button>
);
}
});Even in a simple example, the thinking is clear. The component describes what the button should look like when the state changes. The interface is not being patched manually in several places. It is being described from the current information available to it.
Thinking In Components
The component idea is the part I found most useful.
On client projects, interfaces often repeat themselves in slightly different forms. Cards, tabs, filters, navigation items, form fields and alerts all appear across different pages. Traditionally, those patterns might be repeated in templates and then connected to JavaScript separately. That works until the pattern changes and every version needs checking.
Thinking in components changes that conversation. Instead of treating the page as one large interface, I can think about the smaller pieces that make it up. Each piece has its own inputs, output and behaviour. That makes the interface easier to discuss and, potentially, easier to maintain.
This is also where the connection to UX becomes interesting. A component is not just a chunk of code. It represents a small interaction that someone will use. A form field with errors, a search result with an empty state or a menu with active and inactive versions all have behaviour that affects the experience. Keeping that behaviour close to the structure can make those states harder to forget.
State, Rendering And DOM Updates
The other idea that stood out was the way React thinks about rendering.
A lot of front-end code becomes difficult because the DOM is treated as the source of truth. A script checks what is on the page, changes a class, updates some text, hides an element and then another script does something similar later. After a while, the visible interface becomes the result of many small changes made over time.
React seems to push towards a different model. The interface should be a result of state. If the state changes, the view changes. That sounds simple, but it affects how a developer thinks about the work. Instead of asking which DOM node needs to be modified, the question becomes what the interface should look like for the current state.
I can see why that would help larger interfaces. A dashboard, application panel or live feed can have many possible states. If those states are not managed clearly, the code can become difficult to trust. Having a component render from data gives the interface a more predictable route from information to output.
Where I Would Use It In 2013
I would not reach for React on every project.
For many websites, plain HTML, CSS and a small amount of JavaScript still make more sense. A brochure site, a simple portfolio or a content-led WordPress theme does not automatically need a new interface library. Adding one because it is interesting would make the project harder to maintain without giving the client much benefit.
Where I would consider React is on interfaces where the page changes frequently after it has loaded. Admin tools, dashboards, complex forms, live search, filtering systems and application-style areas are much better candidates. In those situations, the cost of managing DOM changes manually can start to outweigh the cost of learning a different approach.
That distinction matters. New tools are easiest to justify when they solve a real pressure in the project. If the interface is mostly static, React is probably unnecessary. If the interface has lots of changing states, the component model becomes much more compelling.
Retrospective Thoughts
What I find interesting about React is that it challenges a habit rather than just adding another tool.
For years, front-end development has encouraged a certain kind of separation. HTML in one place, CSS in another, JavaScript somewhere else. That separation still has value, but it does not always map neatly onto dynamic interfaces. Sometimes the more useful boundary is not the language being used, but the piece of interface being built.
I am still cautious about using React everywhere. It adds a build step, a different way of writing markup and a learning curve that needs to be justified. But I can see the thinking behind it. As websites become more interactive, we need better ways to describe how an interface behaves over time.
The most useful thing I have taken from looking at React is not necessarily that I should rewrite everything with it. It is that I should think more carefully about interface ownership. If a part of the page has structure, behaviour and state, maybe it should be treated as a component even if the project does not use React.
That idea feels like it will continue to matter. The specific tools may change, but the need to build interfaces in smaller, understandable pieces is not going away.