FediScanner

#react

← Back
21.09.2026 11:52
habr (@habr@zhub.link)

[Перевод] React 19.3

React 19.3 уже доступен в npm! В прошлом году мы представили View Transitions и Fragment Refs как новые экспериментальные API, которые готовились к появлению в React. Теперь оба API получили стабильный статус в React 19.3. В этой статье разберём, как они работают, а также рассмотрим другие заметные изменения в этом релизе.

habr.com/ru/articles/1084612/

#react #reactjs #react_native #javascript #js

Show Original PostReport
21.09.2026 10:12
display (@display@www.urbanmind.net)

A button changes on hover. A modal needs to finish leaving before React removes it. A launch page pins the viewport while several elements enter, overlap, and hand control back to normal scrolling.

All three are “animations,” but that label does not tell me which tool to reach for.

When I evaluate an interaction for Hyperiux Vault, I find one question more useful than asking whether the animation is simple, intermediate, or advanced:

Who owns the interaction?

If the browser already owns the relevant state, I usually evaluate CSS first.

If the animation is a consequence of React state, presence, layout, or gestures, I look at Motion.

If the authored sequence itself needs explicit control, especially across several elements or against scroll, I look at GSAP.

And if movement does not improve feedback, continuity, hierarchy, or storytelling, I leave it static.

That model is more useful than treating CSS, Motion, and GSAP as levels you unlock.

Start with ownership, not complexity


The familiar rule is:

Simple animation → CSS
Medium animation → Motion
Advanced animation → GSAP


The hierarchy falls apart as soon as visual complexity and implementation complexity stop matching.

A shared-layout transition between two React states can look elaborate. Cards reorder, an active indicator moves between controls, and one surface appears to grow into another. Motion has layout and layoutId APIs specifically for animation that follows changed layout in React.

Meanwhile, a hero sequence might contain nothing more technically exotic than opacity and transforms. But if six elements need to overlap at deliberate moments, moving one beat earlier should not require recalculating five unrelated delays. A GSAP timeline gives that timing a shared model.

The second animation may look simpler while needing more explicit choreography.

Visual complexity did not route those examples. Their ownership model did.

The interaction ownership model


I use four starting points.

Who owns the interaction?What that usually meansFirst tool to evaluateThe browserHover, focus, pressed state, straightforward visual state changes, predefined keyframesCSSThe React componentMount/unmount, conditional rendering, layout changes, shared elements, gesturesMotionThe choreographySeveral elements share timing, sequence control matters, scroll progress drives an authored compositionGSAPNobody needs toMovement adds no useful feedback, hierarchy, continuity, or narrativeNo animation


This is a routing model, not a capability table. GSAP can animate hover states. Motion can handle scroll. CSS can produce sophisticated sequences.

The question is which abstraction describes the interaction with the least unnecessary machinery.

Browser-owned state: evaluate CSS first


A button already has hover and focus states. CSS already understands them.

If the design asks for the icon to move four pixels, the background to change, and the button to scale slightly on pointer hover, moving that behaviour into a JavaScript animation system usually adds an abstraction without adding much control.

Transitions fit naturally because the state already exists in the browser:

```css id="pr37xf"
.button {
transform: translateY(0);
transition: transform 180ms ease;
}

.button:hover {
transform: translateY(-2px);
}

Keyframes extend the same idea when the browser should run a predefined sequence rather than interpolate between two states.

CSS stops being the obvious answer when orchestration starts leaking into the implementation.

If adjusting one duration forces you to recalculate delays elsewhere, time has become a relationship between elements. If React is removing the node you are trying to animate, the problem now includes component lifecycle. If JavaScript keeps measuring layout so that CSS knows where something moved, another abstraction may describe the interaction more clearly.

Watch the orchestration instead of the visual ambition.

## Component-owned state: evaluate Motion

Motion becomes particularly useful when movement follows state React already owns: what is mounted, what state is active, how layout changed, or which gesture is occurring.

A modal is the obvious lifecycle example.

React wants to stop rendering it when `open` becomes `false`. The interface may need the modal to remain visible long enough to finish its exit transition. Motion's [`AnimatePresence`](motion.dev/docs/react-animate-…) exists around this exact boundary, allowing exiting elements to animate before they are removed from the DOM.

Layout changes are another strong signal. Adding Motion's `layout` prop lets an element animate between layouts after a React render changes its position or dimensions. `layoutId` can connect matching elements between states.

That is a different kind of problem from running a timed sequence. The important event is the render and the resulting layout change.

Motion also provides gesture APIs for hover, tap, focus, and drag, keeping interaction state close to the component producing it.

This is why I do not think of Motion as “GSAP Lite.” Its advantage is not that it sits halfway up an animation difficulty ladder. Its abstractions line up well with component-owned interactions.

Motion also supports [scroll-triggered and scroll-linked animation](motion.dev/docs/react-scroll-a…), so the presence of scroll alone does not route the work to GSAP.

A viewport reveal and a pinned, scrubbed product story both involve scrolling. Only one makes scroll position part of a larger choreography.

## Choreography-owned state: evaluate GSAP

Sometimes the timeline becomes a first-class part of the design.

Imagine a launch hero:

* a product render enters;
* a mask begins revealing before the first movement ends;
* the heading starts against that overlap;
* supporting copy appears at a named beat;
* the whole sequence needs to be paused or replayed during development.

The individual animations are simple. Their relationships are not.

A [`gsap.timeline()`](gsap.com/docs/v3/GSAP/Timeline…) gives those relationships a shared playhead. Timing can be positioned relative to other moments instead of encoded as independent delays scattered across components.

Scroll choreography strengthens the case.

[`ScrollTrigger`](gsap.com/docs/v3/Plugins/Scrol…) supports behaviours such as triggering, scrubbing, and pinning. If a feature story keeps a claim fixed while product states change against scroll progress, the implementation now coordinates pin duration, scroll distance, sequencing, and the return to normal document flow.

At that point, time, or scroll mapped onto time, is part of the system.

### React still owns the component lifecycle

Using an imperative animation API does not make React lifecycle irrelevant.

GSAP provides `useGSAP()` through `@gsap/react` to scope animation work and clean up GSAP objects created during the hook's execution when that scope is reverted. Animations created later in event handlers may need `contextSafe()` so they participate in the same cleanup model.

In a Next.js App Router setup, a component using `useGSAP()` needs the appropriate client boundary.

This matters more than it does in a demo. Route changes, repeated mounts, listeners, and ScrollTriggers can expose lifecycle mistakes that are invisible during a single polished run-through.

## A worked example: an animated product filter

Suppose a React product page has a filter panel.

Opening the filter changes the panel state. Selecting an option reorders the product cards. An active filter indicator moves between controls. On narrow screens, the filter becomes a modal sheet.

There are plenty of animations here. The first question is still ownership.

The button's hover treatment is browser-owned. CSS is sufficient.

The panel appears and disappears because React state changes. The mobile sheet needs an exit before unmounting. The grid reflows after filtering, and the active indicator changes layout with the selected state.

Those requirements are component-owned, so Motion is the first library I would evaluate.

Now imagine the design changes.

Selecting a filter launches a deliberately authored sequence: the current cards compress, the heading shifts, a loading treatment crosses the grid, new cards enter in staggered groups, and the entire sequence needs exact replayable timing.

The interaction has changed categories. React still determines which products exist, but choreography is now carrying a significant part of the design. GSAP becomes a more reasonable candidate.

The visible interface may have changed only slightly. The ownership of the motion changed a lot.

That is the decision I care about.

## The tools still overlap

Ownership narrows the choice; it does not settle every project decision.

A basic viewport reveal can reasonably be built with CSS and browser APIs, Motion, or GSAP depending on the surrounding system. A team already using GSAP heavily may prefer to keep a small additional animation inside the same mental model. A Motion-heavy application may have little reason to introduce another dependency for one sequence that Motion already expresses clearly.

Maintenance matters alongside capability.

The first tool to evaluate is not automatically the tool you must use.

| Interaction | First evaluation | Reconsider when… |
| ------------------------------------ | ---------------- | --------------------------------------------------------- |
| Hover/focus/press state | CSS | Runtime coordination appears |
| Mount/unmount transition | Motion | The sequence extends far beyond component lifecycle |
| Layout/shared element | Motion | Authored timing dominates the interaction |
| Multi-element timed sequence | GSAP | The sequence is simple enough to remain declarative |
| Pinned scroll narrative | GSAP | A simpler non-pinned treatment communicates the same idea |
| Decorative motion with no useful job | None | There is a reason for the movement |

## Production changes the answer

Tool selection does not solve the mobile version, reduced motion, cleanup, or runtime cost.

I usually run the chosen interaction through three additional gates.

### 1. Does the input still exist?

A hover-led effect has no direct equivalent on a touchscreen. A desktop cursor interaction may need to disappear or become a different interaction entirely.

Pinned scrolling also deserves a mobile rethink. A wide-screen composition can keep a claim fixed while evidence changes beside it. Compressing the same behaviour into a narrow viewport can leave the user dragging through several screens of artificially constrained content.

The fallback needs to be designed, not merely disabled.

### 2. What happens when motion should be reduced?

The [`prefers-reduced-motion`](developer.mozilla.org/en-US/do…) media feature gives the interface a signal that the user has requested less non-essential movement.

That does not necessarily mean replacing every transition with zero duration.

A large pan, parallax effect, or scroll-linked camera move may deserve a static alternative. A subtle opacity transition may still communicate a state change without producing the same motion burden.

The static state also needs to remain readable and usable when animation never runs.

### 3. What work survives after the animation?

Check what continues running when the interaction moves offscreen. Check whether listeners, observers, timelines, and ScrollTriggers are cleaned up. Look for repeated layout measurement and unnecessary continuous work.

A demo can hide all of this because demos are unusually polite environments.

Production pages are not.

## This is how Vault approaches dependencies too

The same ownership logic influences how we think about interactions inside **Hyperiux Vault**.

The catalogue does not force every effect through one animation engine. Dependencies vary by effect: an interaction may use CSS, Motion, GSAP, browser APIs, or a graphics stack when the behaviour actually requires it.

The [Vault dependency model](vault.hyperiux.com/docs/depend…) exposes those dependencies at the effect level.

CSS, Motion, and GSAP can all be used without Vault. Vault becomes relevant when you have already decided that a page needs a particular interaction and would rather start from an implementation than rebuild its behaviour from an empty component.

Because the effect lands as editable source in the project, the surrounding decisions can still change: timing, layout, breakpoints, interaction behaviour, reduced-motion handling, and whatever else the final product requires.

## The rule I keep

When choosing between CSS, Motion, and GSAP in React, I ask who owns the behaviour.

If the browser already owns the state, CSS is difficult to beat for clarity.

If the animation follows the component tree, Motion gives React concepts an animation model that fits them closely.

If the sequence itself needs authored control, GSAP makes that choreography explicit.

And if nobody can explain what the movement is helping the user understand, I leave it out.

**The tool follows the interaction.**

That order is much easier to maintain than choosing an animation library first and asking the interface to justify it afterward.

[**Browse React interaction effects in Hyperiux Vault →**](vault.hyperiux.com/effects)#react #javascript #webdev #animation #software #coding #development #engineering #inclusive #community
CSS, Motion, or GSAP? I Choose by Who Owns the Animation

Show Original PostReport
21.09.2026 08:13
display (@display@www.urbanmind.net)

If you're a frontend developer today, it's easy to feel like every new website should be built with React.

Need a landing page? React.

Need a portfolio? React.

Need a company website? React.

Need a simple blog? React.

But there is one question we don't always ask:

Do we actually need React for every website?


The short answer is no.

React is a powerful tool, but like any tool, it makes more sense when it solves a problem you actually have.

What Problem Does React Solve?


React is useful when the UI becomes interactive and complex.

For example, imagine an application with:

  • Product filters
  • Shopping cart
  • User authentication
  • Notifications
  • Modals
  • Tabs
  • Search
  • Real-time updates
  • Complex forms
  • Shared application state

Managing all of this with manual DOM manipulation can become difficult.

React gives us a component-based approach.

function ProductCard({ product }) {
return (
<article>
<h2>{product.name}</h2>
<p>{product.price}</p>
<button>Add to Cart</button>
</article>
);
}

The UI is broken into reusable components.

That becomes valuable as the application grows.

But What If My Website Is Simple?


Let's say you're building a website for a small business.

It has:

Home
About
Services
Projects
Contact

Maybe there are a few animations, a contact form, and a mobile menu.

Do you need React?

Probably not.

You could build it with:

HTML
CSS
JavaScript

And potentially use a server-rendered CMS or backend if required.

The browser already knows how to render HTML.

You don't need a JavaScript framework just to display a heading and an image.

The Cost of Adding React


React itself isn't necessarily a problem.

The question is what additional complexity you're introducing.

A React project may involve:

React
↓
Package manager
↓
Build tool
↓
Dependencies
↓
Components
↓
State management
↓
Routing
↓
Data fetching
↓
Deployment configuration

For a large application, this complexity can be justified.

For a five-page static website, it might be unnecessary.

This doesn't mean React is bad.

It means architecture should match the problem.

Example 1: Portfolio Website


Imagine a developer portfolio:

Home
About
Skills
Projects
Contact

Most of the content doesn't change frequently.

You could build it with plain HTML, CSS, and JavaScript.

Benefits:

  • Simple architecture
  • Very little JavaScript
  • Easy to deploy
  • Easy to maintain
  • Fast initial rendering

Could React build it?

Absolutely.

But being able to use React doesn't automatically mean you should.

Example 2: E-commerce Website


Now consider a large e-commerce application.

You might have:

Product Listing
↓
Filters
↓
Product Details
↓
Cart
↓
Checkout
↓
User Account

The UI has lots of state.

For example:

Selected filters
Cart items
Quantity
User authentication
Loading states
Errors
Product data
Search results

Here, a component-based architecture can be very useful.

React can help organize this complexity.

Example 3: Dashboard


Consider an admin dashboard.

Dashboard
├── Sidebar
├── Header
├── Statistics
├── Charts
├── Tables
├── Filters
└── Notifications

The user may:

  • Filter data
  • Sort tables
  • Open modals
  • Change settings
  • Update records
  • Navigate between sections
  • Fetch data from APIs

This is a very different problem from a static marketing website.

React can be a natural fit here.

What About a Landing Page?


This is where things become interesting.

A landing page might contain:

  • Hero section
  • Animations
  • Testimonials
  • Pricing
  • FAQ
  • Lead form
  • Scroll interactions

You don't need React just because the page has animations.

CSS can handle many animations.

JavaScript can handle interactions.

Libraries such as GSAP can handle more advanced animations.

So the question shouldn't be:

"Is the website interactive?"


Almost every modern website is interactive.

The better question is:

"How complex is the interaction and UI state?"


React vs Plain JavaScript


Here's a simple way to think about it.

RequirementPlain JSReactStatic pages✅Usually unnecessarySimple interactions✅Often unnecessarySmall landing page✅OptionalSimple portfolio✅OptionalLarge dashboardPossibleUsefulComplex formsPossibleUsefulLarge SPADifficult to organizeUsefulComplex shared statePossibleUsefulHighly interactive applicationPossibleOften useful


The important word here is possible.

Almost anything can be built with vanilla JavaScript.

The question is how maintainable the solution will be.

But There Is Another Side


React can also be useful even for smaller websites if your team already has:

  • A React design system
  • Reusable components
  • Existing React infrastructure
  • Shared frontend libraries
  • Developers experienced with React
  • A larger application planned for the future

For example, if a marketing website is only the first part of a larger product, choosing React may reduce the cost of switching architectures later.

So context matters.

Don't Confuse React With Modern Web Development


One thing I noticed while learning frontend development is that developers sometimes associate:

React = Modern
Vanilla JS = Old

That's not correct.

Modern web development also includes:

  • Semantic HTML
  • Modern CSS
  • Responsive design
  • Accessibility
  • Performance optimization
  • Web APIs
  • Progressive enhancement
  • Good UX
  • SEO

You can build an extremely modern website without React.

You can also build a poorly designed website with React.

The framework doesn't automatically determine the quality of the website.

What About SEO?


SEO is another reason this discussion becomes more complicated.

A simple content-heavy website doesn't automatically need React.

HTML itself is excellent for content.

For applications that need JavaScript rendering, frameworks and rendering strategies such as SSR or SSG can help.

But it's important to understand that:

React itself is not an SEO strategy.


You still need to think about:

  • Semantic HTML
  • Metadata
  • Structured content
  • Page performance
  • Crawlability
  • Accessibility
  • URLs
  • Internal linking


Performance Matters Too


Adding React doesn't automatically make a website slow.

But adding unnecessary JavaScript can create unnecessary work for the browser.

For a simple page, imagine sending:

HTML
CSS
JavaScript
React
Dependencies
Application code

when the browser could have rendered most of the page directly from HTML and CSS.

That's worth thinking about.

At the same time, for a complex application, React can provide an organized architecture that makes the overall product easier to develop and maintain.

Again:

It depends on the problem.

The Better Question


Instead of asking:

"Should I use React?"


I think we should ask:

1. How interactive is the application?

2. How much UI state do I need?

3. How large will the application become?

4. Does the team already have a React ecosystem?

5. How important are initial performance and JavaScript size?

6. Does the project need a component system?

7. Will the application communicate heavily with APIs?

8. How frequently will the UI change?


These questions give you a better starting point than simply choosing a popular framework.

My Simple Rule


I like to think about it this way:

Simple website
↓
Start simple
↓
HTML + CSS + JavaScript

For a more complex application:

Complex UI
↓
Many components
↓
Lots of state
↓
Frequent UI updates
↓
Consider React or another framework

The framework should solve a problem.

Don't create a problem just to justify using the framework.

Final Thought


React is not the enemy of simple websites.

And vanilla JavaScript isn't the enemy of modern development.

Both have their place.

The real skill isn't knowing how to use React.

The real skill is knowing when you don't need it.

Before starting your next project, don't ask:

"What framework is trending?"


Ask:

"What is the simplest architecture that can solve this problem well?"


Sometimes the answer will be React.

Sometimes it won't.

And that's perfectly fine.#react #webdev #frontend #devchallenge #software #coding #development #engineering #inclusive #community
Do We Really Need React for Every Website?

Show Original PostReport