Rethinking JSX: Why the Traditional Component Model Is Straining Frontend Development

JSX (JavaScript XML) gives developers a familiar way to write UI by combining HTML‑like syntax with JavaScript power, but as applications grow in complexity the JSX‑based model shows its era‑bound limits.

“This article is translated from *Beyond JSX: Rethinking the Component Model in Frontend*, which discusses challenges of the current JSX‑based component model and future directions.”

The problem lies not in JSX itself but in the assumptions we make when using it. To push frontend development forward, we must rethink the role of components and the structures built around them.

Components Are Under Heavy Abstraction Pressure

Early React components were small and focused, rendering markup from props. Over time, components have become overloaded, handling business logic, data fetching, side effects, state transitions, and performance tuning, turning them into micro‑applications rather than clean UI units.

This leads to fragility: a tiny state change deep in the tree can break functionality elsewhere, cause performance drops, and make debugging harder. When concerns coexist in a single file, documentation can’t keep up with the complexity developers must remember.

“Let components describe structure and appearance. Put logic in independently reusable and testable services or state layers.”

A more resilient approach separates concerns: components describe structure and appearance, while services, state machines, or reactive stores manage logic, keeping render functions predictable and declarative.

Function‑Based UI Models Struggle with Stateful, Event‑Driven Reality

Viewing UI as a pure function of state sounds elegant, but web apps respond to events, user input, latency, and time. Treating components as pure functions that re‑run on every change creates unnecessary work.

React’s re‑render model forces developers to use useMemo, useCallback, and similar tools to avoid waste, layering optimizations on a system not designed for fine‑grained updates.

Modern frameworks take a different route: they track which UI parts depend on which data, updating only the affected parts when changes occur. This improves performance and makes behavior easier to reason about.

Coupling Effects with UI Leads to Entanglement, Not Cohesion

React hooks make it easy to keep logic where it’s used, which initially feels like good design. Over time, however, placing data fetching, animation, or subscriptions alongside layout code creates new chaos.

Effects bound to a component’s lifecycle become harder to extract, test, and reuse; minor mistakes in dependency arrays or async logic can cause hard‑to‑track bugs.

“Services, state machines, or reactive stores can manage logic, allowing components to focus on rendering.”

Moving responsibilities to services or reactive stores makes components easier to understand: they receive state as input and output a view, simplifying testing and scaling.

Structural Composition Should Not Rely on Deep Tree Nesting

Nested JSX is the default way to compose UI. Adding a ThemeProvider or router wrapper quickly leads to ten‑level‑deep trees, most of which render no visible output.

This pattern clutters the tree and hides logic origins, creating an implicit dependency network that turns tracing component behavior into a guessing game.

“Modern frameworks are moving toward more flexible composition.”

Instead of wrapping everything, modern frameworks let reactive values flow independently. Components subscribe to a value or state without being buried in a specific structural context, flattening the UI hierarchy and making it more predictable.

JSX Is Not the Problem, But Its Execution Model Limits It

JSX offers clear, expressive syntax that reads like HTML while supporting JavaScript expressions. The challenge is how JSX is used at runtime: it compiles to function calls that re‑run on every state change, coupling rendering with function execution.

“A better model treats JSX as a description, not a process.”

A superior model compiles JSX into a static layout with reactive bindings, updating only the parts affected by state changes.

Frameworks that rethink JSX compilation and execution include:

Marko : Compiles JSX‑like syntax to streaming output, allowing the browser to start rendering before all JavaScript loads, reducing perceived load time.

Qwik : Resumes execution on the client from where the server stopped, eliminating hydration and skipping redundant rendering logic.

SolidJS : Uses fine‑grained reactivity with compile‑time optimizations to update only changed DOM parts, avoiding virtual DOM diffing.

Svelte : Compiles components into efficient imperative code, moving work from runtime to build time for smaller bundles and faster apps.

JSX can remain the preferred syntax when paired with models that respect stability and minimize churn.

Components Remain Fundamental to Frontend Ideas

Components provide structure and remain useful, but building everything around them limits how we model state, behavior, and rendering.

The frontend ecosystem has matured: we now understand that state should live outside the view, updates should be precise, and reactivity should be independent of visual structure. Components organize views but should not manage logic, orchestrate effects, or bear reactive burdens.

“The next wave of frontend development is arriving.”

Viewing components as parts of a system rather than the system itself unlocks more flexible design, scalable state management, easier testing, and more predictable interfaces.

The next wave embraces finer‑grained reactivity, resumable rendering, and clearer boundaries—JSX and components can still play a role, provided we rethink how we use them.