Forem: Israel Michael

React vs Next.js vs TanStack Start: Deciding on the Right Tool

Israel Michael — Sun, 08 Feb 2026 16:32:51 +0000

React vs Next.js vs TanStack Start: Deciding on the Right Tool

Choosing the right tool for a frontend project is more than just picking something familiar. React, Next.js, and the new TanStack Start framework each solve similar problems in different ways, and understanding their design goals can help you make the best choice for your needs.

React: The Core UI Library

React is the foundational UI library for building interactive interfaces. It doesn’t come with routing, data fetching, or server rendering by default, but it gives you the pure building blocks — components, state, hooks, and rendering. React is flexible, battle-tested, and supported by a massive ecosystem of tools and libraries.

When to use React alone:

Your app is heavily interactive, and you don’t need server rendering.
You want total control over your stack and are comfortable choosing your own routing and data libraries.
You’re building dashboards, internal tools, or SPAs where SEO isn’t a priority.

React is essentially the baseline for everything that follows here.

Next.js: The Production Ready Framework

Next.js is built on top of React and adds routing, server rendering, static site generation, and automatic optimizations. It’s ideal for production applications where performance and SEO matter.

Next.js supports features like SSR, SSG, and incremental static regeneration out of the box, and its App Router makes server components the default. This can simplify building content-rich sites, but it also brings complexity and conventions you have to learn.

Strengths of Next.js:

Excellent SEO and performance with server rendering
Built-in file-based routing and tooling that gets you shipping quickly
Mature ecosystem and widespread adoption

Considerations:

Automatic caching and server component behavior can feel opaque to debug
It has heavier defaults and tight integration with the Vercel platform, though it can be deployed elsewhere

Next.js remains the established choice for content sites, e-commerce platforms, and applications where SEO or SSR is critical.

TanStack Start: A New Framework with Strong Dev Ergonomics

TanStack Start is a new full-stack React framework powered by TanStack Router and Vite. It aims to unify modern frontend needs with clearer control and a simpler mental model than larger frameworks, while still offering SSR, streaming, server functions, and deployment flexibility.

TanStack Start takes a different approach than Next.js. It uses traditional client-side React components that are server-rendered by default, giving you SSR benefits with full client-side interactivity. Server Components are planned but not yet supported.

TanStack Start is currently in release candidate and near v1, meaning it’s feature-complete and considered production-ready by many early adopters for real projects, even though it hasn’t reached a stable v1 release yet.

Strengths of TanStack Start:

Deep TypeScript support and type-safe routing
SSR and streaming through explicit primitives
Flexible deployment anywhere JavaScript runs
Developer experience powered by Vite with fast startup and HMR

Considerations:

Still newer than Next.js with a smaller ecosystem
Doesn’t support React Server Components yet, though integration is planned

Many developers report that Start feels closer to the React way of thinking, without as much framework magic, which leads to predictable behavior and easier debugging.

Which One Should You Choose?

React alone is a great core library for flexible UI work and complex SPAs.
Next.js shines when you need SEO, SSR, and a mature framework with established conventions.
TanStack Start is a promising alternative when you want performance, type safety, explicit control, and flexibility without the implicit complexity of larger frameworks.

These tools are not mutually exclusive. For example, you can use TanStack libraries like TanStack Query and Router within Next.js. Understanding the philosophy and current landscape helps you choose with confidence.

Mastering the art of frontend performance optimization

Israel Michael — Sun, 08 Feb 2026 15:48:56 +0000

As a Frontend Software Engineer, I’ve worked on a range of challenging projects, and one area I focus on constantly is frontend performance. Why? Because a fast, responsive application directly improves user experience, retention, and overall satisfaction.

Step 1: Don’t Ignore Performance Issues

It’s easy to overlook slow load times or laggy interfaces, but ignoring them is not just lazy programming—it can drive users away and hurt your product’s reputation. A smooth, efficient user experience is our responsibility as developers.

Why Performance Matters

User experience: Fast websites keep users happy; slow pages frustrate them.
SEO benefits: Search engines favor speed, boosting your site’s ranking.
Conversion rates: Quicker, responsive sites encourage users to stay and engage.

Effective Strategies I’ve Used

Refactoring: Optimizing and cleaning up code improves load times and maintainability.
Responsive design: Using React and Next.js, I ensure applications work seamlessly across desktops, tablets, and smartphones.
Advanced analytics: Tracking user interactions helps identify performance bottlenecks and improve UX based on real feedback.
Security measures: Secure APIs and strong authentication are essential for reliable, safe applications.

A Call to Action

Let’s take pride in our work and prioritize performance from the start. Fast, reliable applications are not just a technical goal—they shape the user’s experience and trust.

What are your go-to strategies for frontend performance optimization? Have you faced challenges in this area? Let’s share experiences and learn from each other.

Reach out if you’d like to discuss frontend development, ask questions, or collaborate on exciting projects. Stay curious and keep coding! 💻✨

The Principles of Good Design

Israel Michael — Sun, 08 Feb 2026 15:35:04 +0000

We’ve all experienced it—scrolling through social media and stopping at a design that just grabs your attention. It looks polished, engaging, and effortless. Then there are those designs that feel… off. They lack cohesion, confuse the viewer, or just don’t resonate.

Good design isn’t magic, but it can feel like it. A well-crafted graphic or interface can inform, entertain, and evoke emotion. The secret is understanding a few core principles that make design work.

Here are four key principles to level up your designs:

1. Contrast
Contrast adds visual interest by using opposing elements such as light and dark, big and small, or bold and subtle. Without it, a design feels flat and unengaging. Contrast helps guide the viewer’s eye through the composition.

2. Balance
Balance makes a design feel stable and harmonious. This doesn’t always mean symmetry. By distributing visual weight thoughtfully, you create a sense of order and cohesiveness that feels natural to the viewer.

3. Hierarchy
Not all information is equally important. Hierarchy uses size, colour, and placement to prioritize elements, guiding attention to the most crucial parts first. It ensures your message is clear and easily digestible.

4. Simplicity
Simplicity focuses on what matters most and removes distractions. A clean design communicates effectively and leaves a stronger impression. As Steve Jobs said, achieving simplicity requires effort, but the result allows your work to move mountains.

Mastering these principles allows you to create designs that captivate, inform, and leave a lasting impression.

Syncing Data Across Browser Tabs in Next.js: A Frontend 'Cron Job' Solution for Timed Fetching

Israel Michael — Sun, 08 Feb 2026 15:26:54 +0000

Imagine this. You are building a dynamic Next.js app where data needs to refresh every two minutes. Sounds simple. Drop a setInterval inside useEffect and move on.

That was my assumption too, until I opened multiple browser tabs.

Each tab was fetching data on its own schedule. Nothing was aligned. One tab refreshed, another lagged behind, and the experience felt messy. That was not acceptable.

This post documents how I solved that problem by building a frontend “cron job” that synchronizes data fetching across all open tabs. I will walk through the initial approach, the issue it caused, and the solution that finally made everything click.

Starting out: the timer-based approach

I began with a straightforward setup. Fetch on mount, then fetch every two minutes.

"use client";

import { useEffect, useState } from "react";

export default function Page() {
  const [data, setData] = useState(null);

  const fetchData = async () => {
    const response = await fetch("/api/getData");
    const newData = await response.json();
    setData(newData);
  };

  useEffect(() => {
    fetchData();
    const interval = setInterval(fetchData, 120000);
    return () => clearInterval(interval);
  }, []);

  return <div>{data ? data : "Loading..."}</div>;
}

At first glance, this works perfectly.

The problem: tabs falling out of sync

The issue appeared as soon as I opened a second tab.

Each tab runs its own instance of setInterval, which means timing depends on when the tab was opened.

For example:

Open tab A at 12:01. It fetches at 12:03, 12:05, and so on.
Open tab B at 12:02. It fetches at 12:04, 12:06, and so on.

Same app, same user, different data states. That inconsistency was the real problem.

What I actually needed was this:

All tabs should fetch at the same exact moments. Ideally at fixed two minute boundaries like 12:00, 12:02, 12:04, no matter when the tab was opened.

The idea: align all fetches to real time

Instead of starting a timer immediately, I decided to align fetching to the clock.

The plan was simple:

Calculate how long until the next even two minute mark.
Wait until that moment using setTimeout.
From there, run a steady two minute interval using setInterval.

This way, every tab locks onto the same schedule.

The final implementation

"use client";

import { useEffect, useState, useCallback } from "react";

export default function Page() {
  const [data, setData] = useState(null);

  // Fetch function wrapped in useCallback to prevent unnecessary re-renders
  const fetchData = useCallback(async () => {
    try {
      const response = await fetch("/api/getData");
      const newData = await response.json();
      setData(newData);
    } catch (err) {
      console.error("Error fetching data:", err);
    }
  }, []);

  useEffect(() => {
    // Fetch immediately on mount so users don't wait up to 2 minutes
    fetchData();

    // Get current time
    const now = new Date();

    // Calculate milliseconds until the next even 2-minute mark (12:00, 12:02, 12:04, etc.)
    // Formula: 120000ms (2 min) - (current position within 2-min cycle)
    const millisecondsUntilNextEvenMinute =
      120000 - 
      ((now.getMinutes() % 2) * 60000 +  // Minutes component
       now.getSeconds() * 1000 +          // Seconds component
       now.getMilliseconds());            // Milliseconds component for precision

    // Variable to store the interval ID so we can clear it on cleanup
    let intervalId;

    // Wait until the next even 2-minute boundary
    const timeoutId = setTimeout(() => {
      // Fetch at the exact 2-minute mark
      fetchData();

      // Now that we're synced, fetch every 2 minutes going forward
      intervalId = setInterval(fetchData, 120000);
    }, millisecondsUntilNextEvenMinute);

    // Cleanup function: clear both timeout and interval to prevent memory leaks
    return () => {
      clearTimeout(timeoutId);
      if (intervalId) clearInterval(intervalId);
    };
  }, [fetchData]); // Include fetchData in dependencies

  return <div>{data ? data : "Loading..."}</div>;
}

What is happening here

Initial delay calculation
I calculate how many milliseconds remain until the next even two minute mark.
Delayed first fetch
setTimeout ensures the first fetch happens exactly on that boundary.
Stable interval after sync
Once aligned, setInterval keeps all tabs fetching together every two minutes.

The result

Now every tab behaves the same way:

Open a tab at 12:01:29. It waits until 12:02:00, then fetches every two minutes.
Open another tab at 12:01:58. It waits two seconds, then fetches at 12:02:00 alongside the first tab.

Perfect sync, every time.

Final thoughts

This change looks small, but it dramatically improved consistency across tabs. The pattern behaves like a frontend cron job, anchored to real time rather than tab lifecycle.

When this approach makes sense

This is useful when:

Data needs to stay consistent across multiple open tabs.
Timing matters more than “fetch every X minutes from mount”.
A plain setInterval introduces drift you cannot afford.

Sometimes the difference between working code and reliable code is simply aligning with time instead of starting from zero.

Is "use client" Bad for SEO?

Israel Michael — Sun, 08 Feb 2026 15:18:35 +0000

If you've been working with Next.js lately, you've probably seen the use client directive pop up in components. It's just one line at the top of a file, but it raises an important question: does it affect SEO?

Short answer: No. Client components don't hurt SEO. Let me explain why.

What use client actually does

In Next.js 13 and above, components are server components by default. When you add use client to a component, you're telling Next.js this component needs client-side features like:

State (useState, useEffect)
Event handlers
Browser-only APIs (like window or localStorage)
Animations or heavy interactivity

Here's the key thing: Client components are still pre-rendered on the server and included in the initial HTML. Search engines see them immediately, exactly the same as server components.

The difference is that client components are also bundled and sent to the browser for hydration—making them interactive.

Why people think use client hurts SEO (and why they're wrong)

There's a common misconception that client components aren't server-rendered. This isn't true.

Both server components and client components appear in the initial HTML that gets sent to the browser. From a crawler's perspective, there's no difference. Google sees the content immediately either way.

So putting an <h1>, product description, or blog content in a client component is totally fine for SEO. The content is there in the HTML from the start.

What actually matters for SEO

While use client itself doesn't hurt SEO, there are two things that DO matter:

1. Don't hide content behind interactivity

This is the real SEO risk. If content only appears after a user clicks a button, opens a tab, or submits a form, crawlers won't see it.

Crawlers load the page and run JavaScript, but they don't interact with it. They don't click buttons or switch tabs.

Bad for SEO:

Product details hidden behind a "Read More" button
Pricing shown only after selecting a tab
Content that requires form submission to view

Fine for SEO:

Interactive components that render content immediately
Client components with state that shows content on load
Animations that don't hide initial content

2. Be mindful of performance

Client components increase your JavaScript bundle size. If you're overusing use client across your entire app, you can end up with a bloated bundle that slows down your site.

Performance affects SEO indirectly through Core Web Vitals and page speed rankings. But this is a holistic concern about your app's architecture, not a per-component decision.

You shouldn't avoid putting an <h1> in a client component just because it's an <h1>. If that component needs interactivity, use use client. The performance cost comes from the component being in the bundle, not from what content it contains.

The actual decision tree

When deciding between server and client components, ask yourself:

Does this component need client-side features?

State management?
Event handlers?
Browser APIs?
Interactivity after page load?

Yes? → Use use client

No? → Keep it as a server component

That's it. It's about functionality, not SEO.

How to use use client correctly

DO use use client for:

Forms with validation
Interactive widgets
Modals and dialogs
Tabs (as long as content is visible on initial render)
Animations
Any component that needs state or browser APIs

DON'T worry about:

Whether the component contains an <h1> or important text
Search engine indexing—crawlers see client components just fine
Per-component performance decisions based on content type

DO worry about:

Hiding content behind clicks, tabs, or interactions
Overall bundle size if you're using use client everywhere
Whether you actually need client features or just defaulted to use client out of habit

The bottom line

use client doesn't hurt SEO. Both client and server components appear in the initial HTML that crawlers see.

The choice between them should be based on whether you need client-side features, not whether the content is important for SEO.

The real SEO concerns are:

Hiding content behind interactivity that requires user action
Overall app performance from excessive JavaScript bundles

Get those right, and you can use client components wherever you need them without worrying about SEO.

Note: An earlier version of this post incorrectly stated that client components aren't server-rendered and recommended against putting SEO-important content in them. That was wrong. Thanks to the Vercel and Next.js team for the corrections.

Stop Using Redux for Request-Response Management – It’s Making Your Life Harder

Israel Michael — Sun, 08 Feb 2026 15:11:35 +0000

Let me be blunt: if you’re still using Redux to manage API requests, you’re making your life harder than it needs to be.

Redux has had a legendary run. For years, it was the default state management choice for React apps. Many of us learned it early, shipped production apps with it, and defended it in code reviews. But here’s the part that often gets ignored: Redux was never designed to manage server state.

Yet somehow, it became the go-to tool for handling API requests, responses, loading states, caching, retries, and everything in between. And if you’ve ever felt like that setup is exhausting, frustrating, or unnecessarily complex, you’re not imagining things. It really is that bad.

The good news is that it doesn’t have to be this way. There’s a tool that actually understands server state, and that tool is React Query.

Why Redux Falls Apart With API Calls

Using Redux for request-response data feels a bit like forcing a tool to do a job it was never built for. Yes, it can work, but the friction is constant.

First, there’s the boilerplate. For a single API call, you define request, success, and failure action types. Then you write action creators. Then reducers. Then middleware like thunk or saga just to make async logic possible. After all that, you still have to manually track loading states, error states, caching behavior, and refetch logic in your UI.

All of this effort just to fetch data and display it.

Second, Redux has no concept of stale data. Server data changes over time, but Redux doesn’t know that. If you want fresh data, you have to explicitly tell it when to refetch. That means more logic for pagination, refetch-on-focus, refetch-on-mount, background updates, and avoiding duplicate requests. Miss one edge case, and suddenly your users are looking at outdated data.

Then there’s the bigger design issue: not all API data belongs in global state. Many API responses are temporary, screen-specific, or tied to a single user flow. Redux forces everything into a global store, which makes debugging harder and bloats your state with data that doesn’t need to live there long-term.

At some point, you step back and realize you’re fighting the tool instead of using it.

Where React Query Changes Everything

React Query flips the entire approach. Instead of treating server data like client state, it treats it as what it really is: data that comes from the server and needs to stay in sync with it.

There’s no boilerplate circus. You write a query, get your data, loading state, and errors from a hook, and move on. No actions. No reducers. No middleware. Just data.

Caching is automatic. React Query knows when data is fresh, when it’s stale, and when it should refetch. It updates data when users revisit a page, when the browser regains focus, or when a mutation changes something on the server. You don’t write extra logic for this. It just happens.

Mutations are where the difference really shows. Things like optimistic updates, retries, and error handling that are painful in Redux become straightforward. You describe what should happen, and React Query handles the mechanics.

The result is code that’s easier to read, easier to reason about, and far less fragile.

Does This Mean Redux Is Dead?

Not at all. Redux is still useful for client state. UI state, authentication state, feature flags, theme settings, and other global concerns still fit nicely there.

But server state is a different problem space. Treating it like client state is the mistake. Once you separate the two, things click into place very quickly.

The Takeaway

If you’re using Redux for API requests because “that’s how it’s always been done,” it might be time to reassess. There’s no prize for maintaining 500 lines of boilerplate just to fetch data.

React Query exists because this problem needed a better solution. Less code. Fewer bugs. Better performance. Saner defaults.

Your future self will appreciate the switch.