We came across React after it was open-sourced by Facebook and spent an evening reading through the introductory material out of curiosity more than any client need. Nothing about our actual client work, still mostly WordPress, PHP and jQuery, calls for anything like this yet, but a new approach to building interactive interfaces from a company operating web applications at Facebook's scale seemed worth understanding even without an immediate use for it.
The core idea
The core idea, that you describe your UI as a function of state and let the library figure out the minimal DOM changes needed, is a real departure from how we usually write jQuery-driven interfaces, where we're manually finding elements and mutating them as things change. In our usual approach, updating a piece of the page means writing code that says "find this element, change this attribute, add this class." React's approach, from what we can tell reading through it, is closer to describing what the page should look like given the current state, and letting the library work out which specific DOM changes are needed to get there.
JSX, and why it looks strange at first
It's very new, JSX in particular looks unusual mixing markup into JavaScript files, which runs directly against the separation of concerns instinct that's been drilled into us for years, keep your markup, your styling, and your behavior in separate files, each doing one job. React's argument, as best we understand it from the documentation, is that markup and the logic that generates it are already tightly coupled in practice, and that keeping them in separate files doesn't actually separate those concerns, it just separates them physically while the logical coupling remains. We're not sure yet whether we buy that argument, but it's a genuinely different way of thinking about the question that's worth sitting with rather than dismissing on first reaction.
Where this could matter for the kind of work we do
We don't have a project where reaching for it would make sense yet given our jQuery-based stack, most of what we build is closer to "mostly static pages with some interactive widgets" than "a complex, stateful application interface," which is where a tool like this seems most obviously suited. A contact form, an accordion, a simple image gallery, none of that needs the kind of state-management-driven rendering approach React is built around, and reaching for it on projects like that would very likely add complexity without a proportional benefit.
But it's the kind of thing worth keeping an eye on rather than dismissing, especially if any future client work moves toward something more like a web application than a brochure site, a client dashboard with a lot of interdependent, frequently updating pieces of UI, say, which is exactly the kind of interface where manually tracking which jQuery-manipulated elements need updating in response to which changes becomes genuinely hard to maintain as complexity grows.
What would need to change before we'd use it
Realistically, several things. Our own familiarity with the library and its ecosystem is close to zero beyond one evening of reading, and there's a real cost to introducing an unfamiliar tool on client work, especially for a two-person team where both of us need to be able to maintain whatever we ship. There's also the build tooling question, JSX isn't valid JavaScript on its own, it needs a compilation step to become code a browser can run, which is a new category of tooling for projects that currently ship plain, unprocessed JavaScript files directly.
None of that is a reason to dismiss it, tooling and familiarity are the kind of gaps that close with time and deliberate practice, but it does mean we're a long way from reaching for this on an actual client project, and we're comfortable with that. Some tools are worth learning ahead of an immediate need, and some are worth revisiting once a genuine need actually appears. We suspect this one falls into the first category, worth understanding early even without an immediate application, precisely because if the interactive, application-like side of client work ever grows for us, we'd rather already have some familiarity with an approach like this than be learning it from zero under a deadline.
Why we're writing this down at all
Partly just to have a record of our own first impressions, which we suspect we'll find either prescient or badly wrong looking back in a couple of years, and partly because writing through an unfamiliar idea, even briefly, tends to surface questions and objections we wouldn't have noticed just skimming documentation passively. Whether React specifically turns out to matter for the kind of work we do, or whether it's one of many interesting ideas from a large company's engineering team that never quite finds its way into small client-project work, feels like a genuinely open question worth revisiting later rather than one we're confident enough to answer today.
What we're doing about it for now
Nothing dramatic, no project is being restructured around this. We've bookmarked the documentation, saved a couple of the more detailed articles we found genuinely clarifying, and left it there, filed as background context rather than an active line of investigation. If we do decide to spend real time on it, it'll be as a deliberate, scheduled evening of tinkering rather than something squeezed into an already-billable week, since half-learning a tool during scraps of spare time tends to leave us with a shakier understanding than either fully committing time to it or waiting until there's an actual reason to.