An Angular developer spends a week in React

I build most of my interfaces with Angular. A Netflix style project gave me a reason to spend a week in React and compare the lived experience rather than the feature matrix. The goal was not to declare a winner. It was to notice which habits travel between frameworks and which ones are simply products of the tool.

What felt immediate

Creating a component in React is direct. A function, some markup, and a small amount of state can produce a working screen without a module declaration or a separate template. For small experiments, that directness is a pleasure. It lowers the distance between an idea and a rendered result.

Hooks also made local state feel natural. A piece of state can live near the behavior that uses it, and the component can be read from top to bottom. The model is easy to hold in your head when the component is small. It becomes more demanding when several effects and shared values start to interact.

Where the friction appeared

Styled components offered strong scoping, but writing styles inside the component file created a different kind of maintenance problem. Small styles were pleasant. A growing design system felt harder to scan than a shared stylesheet with clear class names. The issue was not the library itself. It was the number of places a visual decision could live.

Context felt less comfortable than I expected. Passing a value through the tree without an explicit prop is useful, but the consumer still has to know that the context exists. In Angular, dependency injection provides a similar kind of ambient access. Both approaches trade explicitness for convenience. The right balance depends on how far the value has to travel.

Tool choice was another surprise. React's ecosystem is large, and that is both an advantage and a burden. A new project can choose from many routers, state libraries, styling systems, and testing setups. Angular narrows that space by providing a more opinionated path. The narrower path can feel restrictive, but it also makes it easier to move between projects that share the same conventions.

Angular habits that still held

Angular's directives, schematics, and CLI remained strong points in comparison. The framework's consistency across projects is underrated. A developer can enter a new Angular codebase and recognize the structure quickly. That consistency is a form of documentation.

The larger lesson was about interface state. React's hooks make local state easy to express, while Angular's services make shared state easy to inject. Neither model removes the need to decide where a piece of truth belongs. That decision is architectural, not syntactic.

Notebook note: a framework is a set of defaults for common problems. Learn the defaults, then learn what they make difficult.

What I took back

The project used Firebase for data and Jest for tests. It was a good reminder that a first project in a new framework should be small enough to finish. The comparison was useful because it was concrete. The next time a tool choice appears, the question should be about the team and the product, not about which community is louder.