React is a good way to build screens that change, and a heavy way to build pages that do not.
Most business software is a set of screens that react to what a person does. A filter changes a table, a tick box reveals a field, a total updates as a line is added. React was made for exactly that kind of screen, and it handles it well.
It also asks for more than a plain page does. You take on a build step, a package list and a way of thinking in components. That is a fair price for an application and a poor one for a page of text.
React is a JavaScript library for building screens out of small reusable pieces called components. Each piece describes how it should look for the data it is given, and React redraws only what changed. It handles the screen and nothing else. Routing, data fetching and structure are separate choices that you or your developer make.
Where it earns its place.
What it is genuinely good at
- Dashboards where many numbers and charts refresh without reloading the page
- Forms with rules that depend on earlier answers
- Admin screens with tables, filters, sorting and editing in place
- One button, one table or one dialog reused across forty screens
- Large teams, because components give people clear edges to work within
Where plain React turns against you
A React app is drawn in the visitor’s browser. That is fine behind a login and awkward for anything a search engine or a slow phone must read quickly.
- Public pages that need to be found, since the first load can arrive nearly empty
- Visitors on cheap phones, who download and run all the code before seeing anything
- Small sites where the toolchain is bigger than the content
- Teams that keep state in five places and cannot say which one is right
Next.js fixes the first two by drawing pages on the server first. It does not fix the third, which is a question of whether you needed an app at all.
Where we use it
- Admin panels and back-office screens for the software we build
- Customer dashboards that sit behind a login
- Public sites that must be found, built with Next.js on top of React
- Shared component sets, so every screen in a product looks the same
- Prototypes that become the real screens instead of being thrown away
The upkeep nobody budgets for
React itself changes slowly. The packages around it change constantly, and a screen library you chose three years ago may no longer be looked after.
- Regular dependency updates, done in small steps rather than one frightening jump
- A short list of libraries, each one chosen on purpose
- Tests on the screens people use every day, such as login and checkout
- A written record of why the state is held where it is
React is only the screen layer of a system
It does not store anything or enforce any rule. Those jobs belong behind it, and the screen should never be the only place a rule lives.
- An API on Node.js, Laravel or similar, which holds the real data and rules
- TypeScript, so a screen and its API agree on what a field is called
- Next.js when pages must be searchable or fast on a first visit
- React Native or Expo if the same team also needs a phone app
When this is the right choice.
- You are building a web application where people log in and work all day
- The screens show live or frequently changing data, such as orders or stock
- Many screens share the same tables, forms and dialogs
- You may want a phone app later and would like to reuse the team’s skills
- Several developers will work on the front end for years
When it is not.
- A brochure site of a few pages, where plain HTML or a simple site builder is cheaper to run
- A blog or documentation site, where a static generator does the job with far less code
- Pages that live or die on search, unless you also use Next.js or similar
- A team already fluent in Angular or Vue, with a working app and no reason to move
- A single form on one page, which a few lines of ordinary script can handle
Questions we are asked about it.
Is React a framework?
No, it is a library for drawing screens. Routing, data loading and page structure come from other tools, which is why people often pair it with Next.js. That gives you freedom, and it also means someone must make those choices carefully.
Do we need Next.js as well?
Only if people must find your pages through search or the first load must feel quick. A dashboard behind a login rarely needs it. A marketing site or public catalogue usually does.
Will React work for our brochure website?
It will work, but it is more than the job needs. A brochure site has few moving parts, and a simpler build is easier to host and to hand to someone else. We would suggest React only if the site is likely to grow into an application.
Can the same developers build our mobile app?
Largely, yes. React Native uses the same ideas, so the habits carry over, although the screens themselves are written again. Business rules and the API can be shared between the web and the phone.
Is React hard to hire for?
No. It is one of the most widely taught front-end tools, so finding people who can read your code is not usually the hard part. Finding people who keep it tidy over several years is harder, and a clear structure helps.
Can you move an old site to React gradually?
Often yes. New screens can be written in React and sit beside the old pages until the last one is replaced. That keeps the business running and spreads the risk across small releases.
Services that use it.
What it sits with.
Not sure React is the right choice?
Tell us what the software has to do and who opens it. If something else fits better, we will say so, and say why.
- No obligation
- A reply within one business day
- Your details stay private
Start with your requirements
Seven short steps that tell us what you need. An engineer reads them before getting in touch.
Share your requirements