React 16 stood out to me because it was not only about building interfaces from components. It also made me think more carefully about what happens when part of an interface fails.
Component-based development encourages you to split an interface into smaller pieces. That is useful because each piece can own its own behaviour, state and rendering. The risk is that a failure inside one piece can affect more of the page than it should. If a dashboard widget breaks, should the whole dashboard disappear? If a product card fails to render, should the rest of the listing become unusable?
That is why error boundaries were interesting. They made failure something the interface could handle deliberately rather than something that only appeared as a broken screen.
Components Made Interfaces Easier To Structure
By 2017, React had already changed how many developers thought about front-end work. Instead of treating a page as one large script manipulating the DOM, the interface could be broken into components. A search box, filter panel, result card or navigation item could each be represented as a piece of UI with its own logic.
That way of working made larger interfaces easier to reason about. The code could follow the shape of the interface. If a feature changed, I could often find the component responsible rather than searching through a general script file full of selectors and event handlers.
For real projects, that mattered because interfaces rarely stay still. Clients ask for changes, new states appear and data starts arriving in shapes that were not expected during the first build. Component structure gives those changes somewhere to go.
Why Error Boundaries Mattered
Error boundaries added a useful idea to that structure. A component could catch rendering errors from its child tree and show a fallback UI instead of allowing the whole interface to collapse. That changed how I thought about resilience.
A broken widget does not always need to break the page. If part of a dashboard cannot load, the user should still be able to use the rest of the interface. If a non-critical component fails, the page should explain what happened or quietly remove that section rather than leaving the user with a blank screen.
This is not only a developer concern. It affects UX directly. People using a web application care less about the internal reason for the failure and more about whether they can continue doing what they came to do. Handling failure carefully is part of designing the experience.
The Rewrite Behind The Same Public Shape
React 16 was also interesting because of the work behind it. The internals had been rewritten while keeping the public API broadly familiar. From a developer’s perspective, that kind of change is valuable because it gives the library room to improve without forcing every project to be rewritten immediately.
That is the kind of evolution I appreciate in tools. Developers need progress, but they also need stability. A library used in real projects cannot treat every release as an opportunity to make everyone start again. React 16 felt like a major internal change that still respected existing projects.
That balance matters because companies build long-lived systems on top of these tools. A release that improves the foundation without creating unnecessary migration pain is easier to adopt responsibly.
Where React Made Sense
I still would not reach for React for every website. A content-led site with a few small interactions does not automatically need a component toolkit. In some cases, a little JavaScript and well-structured templates are easier to maintain.
React made more sense where the interface had changing data, repeated components, complex state or application-like behaviour. Dashboards, account areas, dynamic search interfaces and admin tools were the kinds of places where component thinking started to pay off.
That is why the decision had to come from the interface. If the page behaves like an application, React might make the code easier to manage. If the page behaves like a document with a few enhancements, React may be more structure than the project needs.
Retrospective Thoughts
React 16 made me think about component design beyond rendering. A component should not only display part of the interface when everything works. It should also have a sensible relationship with loading states, missing data and failure.
That was the useful lesson for me. Interfaces need to be designed around imperfect conditions. Data may not arrive, a request may fail and a component may throw an error. If the system can handle that without punishing the user, the interface is stronger.