React
Your proposal says React, and that word covers less than it sounds like
The short answer
React is a library for building interfaces, not a full framework. It draws what a person sees and leaves routing, data and the build to whoever assembles the rest, which is why it usually arrives inside a framework. It's the easiest front-end skill to hire for, and it isn't a complete answer to how a project gets built.
Somebody put React in a proposal and the word did a lot of work. It isn't a platform you buy, a site you log into, or a decision that finishes the front end. It's one part, and knowing which part tells you what else is in the quote and what quietly isn't.
A library, not a framework, and the difference is the whole page
This decides what's in your quote and what isn't. A framework arrives with answers. Where the code for an address lives, how a page gets its data, how it all gets built and put on a server. React answers one question: what should be on the screen right now. The rest is left open, deliberately.
It's free and open source under the MIT licence, maintained by Meta with outside contributors. No seat to buy, and no vendor who can change the terms underneath you. The cost lands in the assembly.
React's own documentation says to start a new project with a framework built on React rather than wiring one together from parts. That's an unusual thing for a tool to say about itself.
Drawing the screen
React does this
Turning what's true right now into what a person sees, and redrawing it when that changes.
Routing
Chosen separately
Deciding which screen a web address shows, and what a shared link opens.
Getting the data
Chosen separately
Fetching records, and showing something sensible while they load or when they fail.
Building and shipping
Chosen separately
Turning source into files a browser can download, then getting them onto a server.
Components and state, without the vocabulary
Two ideas carry almost all of it, and neither is hard once the jargon comes off.
A component is one piece of the interface, defined once and used everywhere it appears. A search box, a property card, a row in a table. Change the definition and every instance changes with it. That's why one React build can be restyled quickly and another can't, because in the second the same button was written from scratch on every screen.
State is what's true on the screen at this moment. Which tab is open, what's typed in the box, whether the list has loaded, which record is selected. Keeping a screen in step with all of that used to mean writing an instruction for every possible change, and screens drifted. React describes what the screen should look like for a given state, compares that against what's on display, and redraws only the difference.
The ecosystem is the best argument for it, and why two React projects look nothing alike
Because React left so much open, other people filled it. A well-known package for routing, several for fetching and caching data, more for forms, tables and charts. Most are free and maintained, so whatever the unusual requirement is, something credible already does it.
Hiring is the other half, and for a business with no in-house engineer it's the bigger one. Stack Overflow's annual developer survey has put React at or near the top of the most-used web technologies for years. You can get three firms to quote the same job, and replace somebody who leaves.
The price of that choice is that no two React projects agree. Somebody who has shipped React for years still has to learn your particular arrangement, and that's weeks. When a proposal calls a codebase standard React, ask which parts.
Where it stops
The ceiling isn't what React can draw. Almost any interface you can describe can be built. It stops one step earlier, by design. Somebody has to pick the router, the data layer, the build tooling and how it gets deployed, then own those picks for as long as the software runs. That's invisible in a quote that just says React.
The other thing it doesn't do by itself is arrive as a readable page. In the plain arrangement a browser downloads the code first and draws the words second, which is fine behind a login and expensive on a page you want found. Frameworks built on React send finished HTML instead.
So the honest question is rarely React or not. It's which framework, and whether what you're building needs a codebase at all.
React on its own
React inside a framework
- Who picks the parts
React on its own: Each pick fits your case. The set is rarely written down.
React inside a framework: Mostly picked already, so less to decide. You inherit choices you can't cheaply undo.
- The first page load
React on its own: No server to run. The browser fetches code then draws words, which costs you on public pages.
React inside a framework: Finished HTML by default, at the cost of a server or build step somebody owns.
- A new developer
React on its own: React itself is easy to hire for. Your particular assembly takes weeks to learn.
React inside a framework: Common ground a stranger recognises, plus conventions they may not share.
- Keeping it current
React on its own: One package at a time, so each step is small. Nobody coordinates them, so drift is yours to spot.
React inside a framework: They move together, so less to track. The timetable is the framework's, and a major version is a project.
Who has to be available in year two
This settles more builds than anything technical, and it's almost never in the proposal.
A React codebase needs somebody available. Not full time, not urgently, but reliably. Packages release new versions, a security advisory lands on one, a build that worked in March fails in September on a new laptop. None of it is dramatic, and all of it needs a person whose job it is.
Somebody in-house picks it up, or there's a standing agreement with whoever built it, settled before the last invoice. A handover document is not a third option.
Worth knowing before you start
Ask which framework the build sits on before you ask anything about React. If there isn't one, get the router and the data layer named in writing. They commit you as much as the library does.
Ask to see the shared component list. A build with a named set of reusable pieces can be restyled. One drawn from scratch on every screen costs far more to change later.
Ask whether the pages you want found in search are assembled on a server or drawn in the browser. Anybody who has thought about it answers in a minute.
React Native shares the language and the ideas with React, not the screens. If a mobile app is quoted cheaply because the web app is already React, ask how much of the code actually moves.
Common questions
No. React runs inside several frameworks, can be assembled by hand, and can be dropped into one corner of a site built on something else. Its own documentation recommends a framework for a new project, which is about the parts React leaves out, not any one company's product.
It depends on how the build is arranged. Drawn in the browser, a React page can arrive nearly empty and get judged on that. Assembled on a server first, it competes on the same terms as anything else. Ask which one you're getting, page by page.
Usually, yes. React earns its cost on screens that change in response to what somebody does. A dozen pages that mostly sit still don't have that problem, and a platform your marketing lead can edit without booking a developer will serve you better.
Related
Want to talk through your situation?
A short call is usually enough to tell whether this is the right work for you. If it isn’t, we’ll say so.