DEV Community: Tomasz Szewczyk

React Server Components without Next.js - what are the real alternatives today?

Tomasz Szewczyk — Tue, 03 Feb 2026 19:07:57 +0000

React Server Components have moved from an experimental curiosity to a core part of the React roadmap. With React 19, the concept itself is considered stable, but the surrounding ecosystem is not. For most teams, React Server Components are synonymous with Next.js. That association is not accidental. Next.js is currently the only framework that offers a complete, production-grade implementation with routing, bundling, streaming, caching, and developer tooling integrated around RSC.

This raises a practical question for teams that do not want to commit to Next.js conventions or infrastructure assumptions. Can React Server Components be used realistically without Next.js today? And if so, what are the tradeoffs?

This article looks at the current landscape with a strictly engineering-first lens. It focuses on what actually works in production, what is still fragile, and why adoption outside Next.js remains limited.

What does RSC support really mean?

Before comparing frameworks, it is important to define what RSC support means in practice. Supporting React Server Components is not a single feature toggle. A usable implementation requires several pieces working together.

At minimum, a framework or setup must support the React Flight protocol for streaming server-rendered component payloads to the client. It must integrate this with a server rendering pipeline capable of streaming HTML and Flight responses together. It must also split server-only and client-capable code at build time, which requires deep bundler integration. Finally, routing and data fetching patterns need to be compatible with the server component execution model.

Many tools claim RSC support but only implement parts of this pipeline. That distinction matters.

The current landscape of RSC outside Next.js

Next.js remains the reference implementation. It is the baseline against which all other approaches should be evaluated. It provides stable RSC support, but it also tightly couples RSC with specific routing conventions, caching semantics, and optional Vercel infrastructure features.

Outside Next.js, the options fall into three categories: experimental frameworks, partial integrations, and custom setups.

RedwoodJS introduced React Server Components in its Bighorn release line. The implementation is currently marked as canary or experimental. Redwood integrates RSC into its router and build pipeline and aims to make server components the default in the future. However, key pieces such as full SSR parity, authentication integration, and generator support are still in progress. This makes Redwood a reasonable choice for experimentation, but not yet a safe default for production systems that depend heavily on RSC.

Gatsby supports React Server Components in its SSR mode. The implementation is stable, but the scope is narrow. Gatsby primarily targets content-heavy and hybrid static use cases. While RSC can be used for dynamic server rendering, the framework is not optimized for deeply interactive applications built around server components. For certain classes of sites, this is acceptable. For general-purpose applications, it is limiting.

Waku is a minimal framework built explicitly around React Server Components. All components are server components by default unless marked otherwise. Architecturally, it is clean and instructive. Practically, it is highly experimental. The ecosystem is small, routing is minimal, and production tooling is immature. Waku is valuable as a learning tool or for small prototypes, not as a foundation for complex systems.

React Router has introduced experimental support for React Server Components. This is a significant signal. Instead of a monolithic framework, React Router provides primitives for integrating RSC into a custom stack. This approach offers maximum flexibility and avoids framework-level lock-in, but it shifts responsibility to the application team. Streaming responses, bundler configuration, error handling, and caching must be assembled manually. This path is viable only for teams with deep React and infrastructure expertise.

There are also no-framework approaches. These rely directly on React-provided packages and low-level integrations with bundlers like Webpack or experimental support in tools like Bun. While technically possible, these setups are fragile. React explicitly does not guarantee stability of these internal APIs. Any team choosing this route must accept ongoing maintenance risk.

Why adoption outside Next.js is still low

The slow adoption of React Server Components beyond Next.js is not accidental. Several factors combine to raise the barrier.

Tooling maturity is the most visible issue. Outside Next.js, bundler support remains uneven. Vite-based setups require workarounds. Development mode behavior can differ significantly from production. These issues surface early and consume engineering time that many teams cannot justify.

The mental model is another major cost. Developers must constantly reason about execution context. Server components, client components, and shared modules have different constraints. A missing or misplaced "use client" directive can break builds or introduce subtle runtime errors. Debugging these failures is harder than traditional client-side React or even classic SSR.

Server and client boundaries introduce real failure modes. Teams often leak client-only dependencies into server components or accidentally serialize more data than intended. In other cases, teams overuse client components due to third-party library constraints, eliminating most of the performance benefits while retaining the complexity.

Observability and testing lag behind. Errors during server rendering do not always surface with useful context. Traditional frontend monitoring tools are not designed around streamed server component execution. Testing RSC-heavy codebases often requires integration-level testing rather than isolated component tests, increasing feedback time.

Finally, organizational factors matter. Very few engineers have production experience with RSC. Hiring and onboarding costs increase. Teams must invest in internal documentation and guardrails. For many organizations, the cost-benefit equation does not yet justify early adoption.

Vendor lock-in and the Next.js question

React Server Components do not inherently lock a team into a hosting provider. However, specific implementations can create practical coupling.

Next.js integrates RSC with features such as image optimization, caching, revalidation, middleware, and server actions. While these features can run outside Vercel, they often assume infrastructure characteristics that Vercel provides out of the box. Replacing them requires additional systems and operational effort.

The risk is not that migration is impossible, but that architectural patterns become shaped around Next.js-specific abstractions. Server actions embedded deeply into UI code are harder to extract than traditional API boundaries. Caching semantics tied to framework behavior are harder to replicate elsewhere.

Teams that care about portability should be deliberate. Using framework-agnostic data access layers, avoiding proprietary helpers where possible, and isolating infrastructure-specific code reduces switching costs. Periodically validating that the application can run outside the primary hosting environment is a useful discipline.

Looking ahead to 2026

React Server Components are not going away. The React core team has clearly committed to the model. The instability today is mostly in framework and tooling layers, not in the concept itself.

Over the next one to two years, several improvements are likely. Frameworks outside Next.js will stabilize their implementations. Error messages and debugging tools will improve. Testing and observability libraries will catch up. The mental model will become more familiar as more teams share real-world experience.

The most likely outcome is not universal adoption, but selective use. RSC will become a standard option for content-heavy or latency-sensitive paths, while highly interactive areas remain client-driven.

A practical decision heuristic for 2026 looks like this. Adopt now if you are starting a greenfield project, have senior React expertise, and can tolerate some churn. Experiment incrementally if you see clear benefits but want to limit risk. Avoid RSC entirely if your application is dominated by client-side interactivity or your team cannot afford architectural complexity.

Why BluesBrackets is a strong choice for teams evaluating RSC

BluesBrackets approaches React Server Components as an architectural decision, not a trend. Our starting point is always a framework maturity and risk assessment. We evaluate whether RSC provides measurable value for a given product and which parts of the system benefit from it.

We design with deployment portability in mind. When using RSC, we avoid unnecessary coupling to a single provider and keep infrastructure-specific concerns isolated. This allows applications to evolve without being boxed into one execution model.

Security and maintenance discipline are central to our process. Server components expand the server-side surface area of frontend code. We enforce clear boundaries, review serialization paths carefully, and maintain an aggressive upgrade cadence to keep dependencies current.

We also favor incremental adoption. Instead of rewriting entire applications, we introduce RSC where it makes sense, validate outcomes, and expand deliberately. Throughout the process, we document patterns and train client teams to own the architecture.

For teams exploring React Server Components beyond Next.js and actively evaluating a Next.js software house Poland, this combination of technical rigor and pragmatism is essential. If you are looking for a partner that can assess RSC adoption realistically, balance performance gains against long-term maintainability, and deliver production-ready systems without unnecessary lock-in, learn more about how we work at next.js software house from poland.

Arduino vs STM32: When the Arduino Platform Becomes Limiting

Tomasz Szewczyk — Sun, 11 Jan 2026 11:16:29 +0000

Arduino got many of us into embedded development. It's approachable, has a
massive community, and lets you get something working in an afternoon. But if
you've been building more complex projects, you've probably hit some walls.

This post is for those of you who are asking: is it time to move on?

The Arduino Sweet Spot

Let's be clear: Arduino isn't bad. It's genuinely excellent for:

Rapid prototyping
Learning embedded concepts
One-off projects and proof of concepts
Low-volume production where cost per unit isn't critical

The Uno R3 and its siblings have earned their place in labs and workshops
worldwide. The ecosystem—thousands of libraries, shields, and tutorials—is
unmatched for getting started quickly.

But "getting started" and "shipping a product" are different beasts.

Signs You're Outgrowing Arduino

Here's what I've seen repeatedly in projects that start on Arduino and hit the
ceiling:

1. Memory Constraints

The ATmega328P on an Arduino Uno has 2KB of SRAM and 32KB of flash. That sounds
fine until you're buffering sensor data, handling string operations, or adding
"just one more library."

When you start seeing stability issues, random crashes, or the compiler warning
about low memory—you're not imagining things. You've hit a real limit.

2. Processing Power

16 MHz and 8-bit architecture. No floating point unit. No DMA.

If your project involves any of these:

Real-time signal processing
Complex control loops
Driving graphical displays
Multiple tasks that shouldn't block each other

...you'll feel the CPU struggling. And no amount of code optimization will fix
physics.

3. Connectivity Requirements

Need Wi-Fi? Bluetooth? You're adding external modules and managing them through
AT commands or serial protocols. It works, but it's clunky, adds cost, increases
power draw, and creates more points of failure.

4. Power Consumption

An Arduino Uno draws around 50mA continuously. The USB interface alone pulls
~20mA. Try running that on batteries for a remote IoT sensor and watch your
battery life measured in days, not months.

5. Production Reality

An Arduino Uno costs ~$25 retail. The ATmega328P chip itself is about $2 in
quantity. For a hobby project, who cares. For production? That's a massive
difference at scale.

Enter STM32 (and Friends)

STM32 is STMicroelectronics' family of ARM Cortex-M microcontrollers. They're
not the only alternative—ESP32, nRF52, RP2040 are all valid options depending on
your needs—but STM32 is often where professional embedded development lands.

Here's why:

Raw Performance

A mid-range STM32F4 runs at 168 MHz with hardware floating point. That's roughly
10x the clock speed, with a 32-bit architecture that actually handles math
efficiently. CoreMark benchmarks put these chips at 100-200+ compared to single
digits for AVR.

Memory That Breathes

Even cheap STM32 variants give you 64KB+ of RAM and 256KB+ of flash. The
higher-end chips go into megabytes. You stop thinking about memory and start
thinking about the actual problem.

Proper Peripherals

Multiple UARTs, SPI buses, I2C interfaces. Hardware timers with DMA. CAN bus for
industrial applications. ADCs that don't make you cry.

Real-Time Capabilities

These chips were designed for control systems. Deterministic interrupt handling,
precise timing, and the option to run FreeRTOS if you need actual multitasking.

Power Efficiency

The STM32L series targets ultra-low-power applications. We're talking microamps
in sleep mode with RTC active. If battery life matters, the hardware can get out
of your way.

But What About ESP32?

Fair question. ESP32 deserves mention because it occupies an interesting middle
ground:

ESP32 wins when:

You need Wi-Fi or Bluetooth built-in
You want dual cores without leaving Arduino-style development
Cost is critical (~$4 for modules)

STM32 wins when:

You need deterministic real-time behavior
Industrial protocols like CAN matter
You want maximum control over the hardware
Ultra-low-power is non-negotiable

Many professional projects use ESP32 for connectivity and STM32 for control.
They're not mutually exclusive.

The Migration Path

Here's the practical part. Moving from Arduino doesn't mean throwing everything
away.

1. You Can Keep the Arduino IDE (Sort Of)

Both STM32 and ESP32 have Arduino cores. Your high-level code—digitalRead(),
Serial.print(), basic library calls—often ports with minimal changes. It's not
perfect, but it lowers the barrier.

2. Start with a Dev Board

STM32 Nucleo boards are cheap (~$15) and have debugger hardware built-in. Get
one, port your critical code paths, and validate that the new platform actually
solves your problems.

3. Expect to Learn New Things

The Arduino IDE abstracts almost everything. Moving to STM32 means understanding
peripheral clocks, HAL layers, and possibly an RTOS. There's a learning curve,
but it's knowledge that transfers to professional embedded work.

4. Use Proper Debugging

JTAG/SWD debugging changes everything. Instead of littering your code with
Serial.println(), you can step through execution, inspect variables, and set
breakpoints. It's faster and you actually understand what's happening.

When Arduino Is Still the Right Answer

Not every project needs an ARM chip. Arduino remains solid for:

Internal tools: You're building something for your own factory floor. Cost isn't critical, time to deployment is.
Educational products: The whole point is that it's accessible.
Very low volume: Making 50 units? The engineering time to migrate might not pay off.
Simple, stable requirements: If an Uno does the job today and requirements won't change, don't over-engineer it.

The Arduino Pro line (Portenta, Opta) also bridges some gaps for industrial use
cases, though pricing moves into professional territory.

Real Talk on the Transition

I've worked on projects that started as Arduino prototypes and evolved into
production systems. The pattern is consistent:

Prototype works great on Arduino
Features get added
Limits emerge (usually memory or timing first)
Decision point: hack around it or migrate?

The hack-around approach works until it doesn't. Adding external memory,
offloading to co-processors, aggressive optimization—you can push Arduino
surprisingly far. But at some point you're spending more effort fighting the
platform than solving the actual problem.

The move to STM32 or similar isn't a failure of Arduino. It's graduation.
Arduino did its job: it got you to a working prototype quickly. Now you need
different tools for different constraints.

Wrapping Up

Arduino is a prototyping platform that occasionally ends up in production. STM32
is a production platform that can also be used for prototyping. Understanding
where each fits prevents a lot of pain.

If you're hitting the limitations we discussed—memory, speed, power,
connectivity, cost at scale—it's probably time to look beyond Arduino. The
embedded world has excellent options, and the skills you built on Arduino
translate more than you might expect.

And if you're working on something that needs to move from prototype to
production, that's the kind of challenge
we work on regularly—taking
Arduino concepts and turning them into robust, manufacturable systems.

What's been your experience with Arduino limitations? Have you made the jump to
STM32 or another platform? I'd be curious to hear what drove the decision in the
comments.