Forem: Vinitpal Singh Arora

Shift from React to Next.js and Remix

Vinitpal Singh Arora — Wed, 25 Jun 2025 13:36:10 +0000

1️⃣ Introduction: The Evolution of React Apps

Following my previous blog, we saw how React dominated frontend development for years, introducing concepts like Component-based Architecture, Virtual DOM for performance optimization, and a Declarative Programming Model.

React introduced the era of Single Page Applications (SPAs), bringing both advantages and drawbacks:

Pros of React SPAs:

Smooth UX: Fast, app-like navigation by avoiding full page reloads.
Efficient Development: Component-based architecture promotes reusability and maintainability.
Rich Interactivity: Client-side rendering enables dynamic, responsive interfaces.

2️⃣ The Pain Points That Led to Next.js & Remix

SEO Challenges:

Client-Side Rendering (CSR): Difficult for search engines to index.
Meta Tag Management: Complex without tools like React Helmet.

Performance Issues:

Initial Load Time: Large JavaScript bundles delayed rendering.
Hydration Overhead: Resource-intensive event listener attachment.

Routing and Analytics:

Dynamic Routing: Confused crawlers and analytics tools.
URL Management: Required extra setup for crawlable URLs.

Client-side Data Fetching:

Loading States and Waterfall Effect: Sequential data fetching delays rendering.
Complexity Managing States: Increased code complexity handling various states.

Need for Better DX (Developer Experience):

File-Based Routing: Manual configurations became unwieldy.
Server-side Logic: Separate backend setups needed even for small API changes.

3️⃣ Enter Next.js: React, but Smarter

Next.js, introduced by Vercel in 2016, enhanced React by addressing limitations in SEO, performance, and developer experience.

Key Next.js Innovations:

Multiple Rendering Strategies:
- Server-Side Rendering (SSR): React rendered on servers for instant content visibility and better SEO.
- Static Site Generation (SSG): Pre-generating static HTML pages at build time for faster performance.
- Incremental Static Regeneration (ISR): Updates static pages incrementally after deployment, balancing dynamic content with static speed.
Full-Stack Capabilities:
- Built-in API routes under pages/api/, removing the need for separate backend setups.
- Edge Functions: Run lightweight serverless functions at global edge locations for faster responses.
App Router (Next.js 13+):
- Supports React Server Components, drastically reducing client-side JavaScript.
- Enables HTML streaming and Suspense for quicker load times.
- Server Actions: Simplify form submissions and server-side interactions directly in components.

Next.js became widely adopted by platforms like TikTok and Netflix, especially due to seamless deployment via Vercel.

4️⃣ Remix: Back to Web Fundamentals

Remix emerged in late 2021, emphasizing traditional web principles alongside React’s UI strengths.

Key Remix Innovations:

Nested Routing:
- Hierarchical, independent data fetching routes, improving UI updates without full-page reloads.
Web Fundamentals & Progressive Enhancement:
- Uses native browser behaviors (, standard HTTP requests), ensuring functionality even without JavaScript.
- Leveraging native web APIs (Fetch, FormData), reducing the learning curve and improving compatibility.
Loaders and Actions:
- Loaders: Server-side data fetching, eliminating client-side waterfalls and simplifying state management.
- Actions: Direct server-side handling of form submissions, smoothly blending server and client experiences.
Full-Stack Simplicity:
- Integrated routing, data fetching, mutations, and error handling in one cohesive framework.
- Adaptable across multiple deployment platforms (Node.js, Cloudflare Workers, etc.).

I liked Remix for creating highly interactive applications prioritizing accessibility and resilience.

5️⃣ Is React "Just a Library" Now?

React began as just a UI library. Now, the ecosystem favors frameworks like Next.js and Remix.

React Core Team officially deprecated Create React App (CRA) in 2025.
Frameworks provide built-in solutions (routing, SEO, server-rendering).
React continues evolving, powering frameworks with advanced features.

Learning core React concepts first remains valuable, but frameworks are essential for modern development.

6️⃣ When to Choose Next.js vs. Remix

Next.js if:

You need flexible static and dynamic rendering (blogs, marketing sites, e-commerce).
You prioritize extensive community support, integrations, and scalability.
Your project fits nicely within the Vercel deployment ecosystem.

Remix if:

Your app requires rich interactivity, frequent user interactions, and real-time experiences (dashboards, social media platforms).
Progressive enhancement, resilience, and native browser standards matter to you.
You prefer server-first development and want deployment flexibility (Node.js, edge environments).

Both frameworks are capable. Choose based on project priorities.

7️⃣ Conclusion:

Should developers learn React first, or jump straight into frameworks?

My two cents. Learn core React first.

The React team deprecated CRA on February 14, 2025, pushing developers toward frameworks. Understanding fundamentals (components, props, hooks) empowers smooth transition to frameworks.

My favorite?

I personally prefer Remix 💖. Its server-first approach, intuitive nested routing, and progressive enhancement elegantly blend modern capabilities with traditional web simplicity. Remix handles both JS-enabled and no-JS scenarios beautifully, with fast loader/action patterns and built-in error handling.

P.S. Have you tried Remix? Share your experiences in the comments! 👇

5 Common React Mistakes

Vinitpal Singh Arora — Sun, 27 Apr 2025 18:28:43 +0000

So I had the opportunity to give a talk at IIIT Raipur
There I addressed common mistakes freshers and experienced devs both make in React.

Since React is most widely used library, these subtle issues can hurt performance, maintainability, or scalability if left unchecked.

Below are some code examples of common React mistakes and their fixes.

1. Using Array Index as Key in Lists vs Unique IDs

I know it has been addressed to you many times, but still its the #1 issue I see in any react repo.

Using the array index as a React list key, this is a lazy shortcut that can break ordering and cause inefficient updates. React’s diff algorithm relies on stable keys; using indexes can confuse the diff, leading to unexpected UI behavior and more re-renders.

In the example below, moving or removing list items would mess up React’s tracking.

// 🚫 Before: Index as key (bad practice)
function BadList() {
  const fruits = ['Apple', 'Banana', 'Cherry'];
  return (
    <ul>
      {fruits.map((fruit, index) => (
        <li key={index}>{fruit}</li>  {/* Index used as key */}
      ))}
    </ul>
  );
}

Use a unique identifier for each list item’s key. Here, use an id property for each fruit. This makes the UI stable on updates, as React can reliably identify items. No more phantom re-renders or out-of-sync list items.

// ✅ After: Unique ID as key (good practice)
function GoodList() {
  const fruits = [
    { id: 'a1', name: 'Apple' },
    { id: 'b2', name: 'Banana' },
    { id: 'c3', name: 'Cherry' }
  ];

  return (
    <ul>
      {fruits.map(fruit => (
        <li key={fruit.id}>{fruit.name}</li>  {/* Stable unique key */}
      ))}
    </ul>
  );
}

2. Deriving State with `useEffect` vs Computing on the Fly

This component filters a list based on a search term and mistakenly uses useEffect + useState to store the filtered list. Every time searchTerm changes, an effect runs to update filteredFruits state.

This indirection is overkill, it introduces extra state and complexity, and can even cause timing issues (the UI updates after the effect)

// 🚫 Before: Unnecessary effect and state for derived data
function FruitList() {
  const [searchTerm, setSearchTerm] = useState('');
  const [filteredFruits, setFilteredFruits] = useState(fruits);

  useEffect(() => {
    // Filter list whenever searchTerm changes
    setFilteredFruits(
      fruits.filter(fruit =>
        fruit.toLowerCase().includes(searchTerm.toLowerCase())
      )
    );
  }, [searchTerm]);

  return (
    <>
      <input 
        value={searchTerm}
        onChange={e => setSearchTerm(e.target.value)}
        placeholder="Search..."
      />
      <ul>
        {filteredFruits.map(item => <li key={item}>{item}</li>)}
      </ul>
    </>
  );
}

Instead of this, Calculate the filtered list directly during render, based on the current state. Remove the filteredFruits state and the effect entirely. Now filteredFruits is a simple variable recomputed on each render. This is simpler, immediately up-to-date, and less error-prone

// ✅ After: Derive filtered list directly, no extra state
function FruitList() {
  const [searchTerm, setSearchTerm] = useState('');
  const filteredFruits = fruits.filter(fruit =>
    fruit.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <>
      <input 
        value={searchTerm}
        onChange={e => setSearchTerm(e.target.value)}
        placeholder="Search..."
      />
      <ul>
        {filteredFruits.map(item => <li key={item}>{item}</li>)}
      </ul>
    </>
  );
}

3. Unmemoized Callback Causing Re-renders vs `useCallback` Memoization

In this parent-child setup, the parent passes an inline callback prop to the child. Each time the parent re-renders (e.g. when count changes), it creates a new function for handleClick. Even if the child is wrapped in React.memo, that new function prop forces the child to re-render every time.

In short, the child can’t take advantage of memoization because the prop reference is unstable:

// 🚫 Before: New handleClick function on every render
const Child = React.memo(({ onClick }) => (
  <button onClick={onClick}>Click me</button>
));

function Parent() {
  const [count, setCount] = useState(0);
  // This function is re-created on every Parent render:
  const handleClick = () => {
    console.log('Clicked');
  };

  return (
    <div>
      <Child onClick={handleClick} />
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

Use useCallback to memoize the handler function. Now handleClick will stay the same reference between renders (it only re-creates if its dependencies change). With a stable function prop, the memoized child no longer re-renders when the parent’s other state (count) updates. This prevents needless child renders and improves performance:

// ✅ After: useCallback to preserve function identity
const Child = React.memo(({ onClick }) => (
  <button onClick={onClick}>Click me</button>
));

function Parent() {
  const [count, setCount] = useState(0);

  // Memoize handleClick so it isn't recreated each render:
  const handleClick = useCallback(() => {
    console.log('Clicked');
  }, []);  // no dependencies -> same function every time

  return (
    <div>
      <Child onClick={handleClick} />
      <button onClick={() => setCount(count + 1)}>Increment</button>
    </div>
  );
}

I know its confusing, To explain this even more:

In the original, every render made a brand new handleClick function, so React treated the <Child>’s prop as changed on each render. The child re-rendered constantly (defeating React.memo and wasting time).

The updated code wraps handleClick in useCallback, which caches the function so that React sees the same function instance on each render. As a result, the child component doesn’t re-render unless it actually needs to.

4. Monolithic Component vs Modular Component Architecture

This component tries to do everything at once, it fetches user data and renders the UI. It violates separation of concerns and will become hard to maintain or extend. Before you know it, this file will increase to more than 3000 lines. Completely unmanageable.

In this UserList example below, the component both loads data in an effect and renders the list. This tightly coupled approach doesn’t scale; the component is doing multiple jobs:

// 🚫 Before: Single component doing data-fetching and UI
function UserList() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetchUsers().then(data => {
      setUsers(data);
    });
  }, []);

  return (
    <div>
      <h1>User List</h1>
      <ul>
        {users.map(user => (
          <UserItem user={user} key={user.id} />
        ))}
      </ul>
    </div>
  );
}

Always Split the logic into a container component and a presentational component. In the below snippet.

UserListContainer handles fetching data and state, then renders UserList (presentational) purely with props. UserList becomes a simple, stateless UI component. This modular approach is more scalable – each piece has a single responsibility. We avoid deeply nested or bloated components by dividing the work:

// ✅ After: Separate container (data logic) and presentational (UI) components
function UserListContainer() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetchUsers().then(data => {
      setUsers(data);
    });
  }, []);

  return <UserList users={users} />;  // hand off data to UI component
}

function UserList({ users }) {
  return (
    <div>
      <h1>User List</h1>
      <ul>
        {users.map(user => (
          <UserItem user={user} key={user.id} />
        ))}
      </ul>
    </div>
  );
}

5. Ignoring Errors in Async Calls vs Proper Error Handling

This React effect fetches data but completely ignores errors. If the network request fails or returns an error status, the code does nothing, no catch, no user feedback.

The app could silently break or just never show anything, leaving both developers and users in the dark. For example, below we fetch data and set state, but any failure is uncaught (a rejected promise will likely log an error to console, but our UI/state won’t respond):

// 🚫 Before: No error handling for fetch
useEffect(() => {
  fetch('/api/data')
    .then(res => res.json())
    .then(data => setData(data));
    // .catch(...) is missing – errors are ignored
}, []);

Always handle errors from async calls. Here we wrap the fetch in a try/catch (using async/await for clarity). If an error occurs (network failure or non-OK response), we catch it and update an error state. In a real app, you’d also set a loading state and probably show a message to the user. The key is that errors are not swallowed, we handle them gracefully:

// ✅ After: Handle errors with try/catch and state
useEffect(() => {
  const fetchData = async () => {
    try {
      const res = await fetch('/api/data');

      if (!res.ok) {
        throw new Error(`Request failed with ${res.status}`);
      }

      const data = await res.json();
      setData(data);
    } catch (err) {
      setError(err);  // capture the error in state
    }
  };

  fetchData();
}, []);

The original code naively assumes the fetch will always succeed. In reality, network or server errors happen, and failing to handle them is irresponsible. If the request failed, the before code would just do nothing, the user would see a loading spinner forever or an empty UI, and no error message.

That's why, we should at least update the UI (for example, stop a spinner and show an error message, or add a contact support button so customer can report to you) instead of hanging. In short, always handle promise rejections or thrown errors from async calls; your users (and your future self) will thank you when things go wrong.

At the end, I just want to say, none of these mistakes alone will break your app. But together, they quickly pile up technical debt. Fixing these patterns early saves you from future headaches and helps you build a codebase that’s actually worth scaling.

Thanks a lot for reading this far!

Feel free to connect with me on LinkedIn. 😄

A question for you

Have you seen (or made 👀) any of these mistakes before?
Which one cost you the most pain later?
Share your experiences in the comments below!

History of web dev

Vinitpal Singh Arora — Fri, 28 Mar 2025 20:11:32 +0000

It's crazy how web development has changed from past 35 years. In every 10yrs, multiple changes happened and many things became obsolete so fast.

I was having this talk with a friend last week and I thought why not start with this as my first blog post.

After a reaaally long procrastination. Here is my brief rundown on how web development has changed over the time.

Foundation Era (1990 - 1995) Birth of WWW

Picture this: It’s 1990. Tim Berners-Lee and Robert Cailliau are cooking up something in the CERN labs that would change the world forever. the World Wide Web.
By the end of the year, they had built:

The first web browser
HTML to structure pages
HTTP to transfer those pages
The first web server, hosted on a NeXT computer with a handwritten label screaming: 👉 "This machine is a server. DO NOT POWER IT DOWN!!"

Developers wrote raw HTML in basic text editors without syntax highlighting or autocompletion. There were only 18 HTML tags to play with, and styling? Forget it! CSS wasn’t even a thing yet.

Deployment was manual. Developers uploaded files via FTP and prayed they looked okay in the browser. Content, presentation, and logic were all jumbled together, and version control was… making backup copies with dates in the file names. 😅

But things started looking up in 1994 when CSS was proposed, giving hope for separating content from design. Then, in 1995, Brendan Eich gave us JavaScript, which brought basic interactivity to the web. Game-changer!

Fun Fact: Brendan Eich created JavaScript for Netscape Navigator 2. Initially developed in just ten days and originally called Mocha (later LiveScript, then JavaScript).

The Enhancement Era (1996-2005): Dynamic Content and Design Control

As the web matured into its second half-decade, things got more dynamic and interactive.

CSS gained traction, allowing developers to move away from ugly table-based layouts.
PHP, ASP, and CGI scripts made server-side programming possible, allowing for user authentication, database connections, and dynamic content.
But, cross-browser compatibility? A nightmare! Developers had to write different code for Internet Explorer, Netscape, and others, a frustrating time for sure.

The Framework Revolution (2006-2015): JavaScript Ascendance

By the mid-2000s, developers were tired of browser quirks and clunky interfaces. Enter jQuery in 2006, with its motto:

👉 “Write less, do more.”

It simplified DOM manipulation and abstracted away browser inconsistencies. Life was good!

Then after 2008, many big players entered:

V8 Engine (2008): Google’s lightning-fast JS engine changed the game, enabling JavaScript to run on servers via Node.js.
AngularJS (2010): Introduced concepts like two-way data binding and dependency injection, making complex front-end apps possible.
React (2013): Facebook’s answer to the chaos, bringing component-based architecture and virtual DOM magic.
Vue.js (2014): Struck a balance between simplicity and power, attracting devs who wanted something less complex than Angular or React.

Developer tools also leveled up, with Chrome DevTools making it easier to debug JavaScript and analyze performance. Life as a web developer finally felt a bit more manageable!

The Modern Component Era (2016-2025): Specialization and Optimization

From 2016 onward, web development entered a phase where component-based architectures became the undisputed king. This era wasn’t just about building cool UIs. It was about specialization and optimization to tame the growing complexity of modern apps.

In 2016, Angular 2 dropped, and it was a complete rewrite. Angular ditched the old-school AngularJS vibes and fully embraced TypeScript with a more modular, component-driven approach.

React and Vue didn’t just sit around either. They matured like fine wine, with better tooling, bigger communities, and rock-solid ecosystem support. React Hooks (2019) shook things up by offering a more functional, elegant way to manage state and side effects. It was a game-changer that made class components feel ancient overnight.

Svelte (2019) threw the virtual DOM out the window and went for a compile-time approach to reactivity. Smaller bundles, faster runtime — it was like the cool kid who didn’t follow the usual rules but still aced the game.

By 2020, frameworks like Solid and HTMX started exploring fresh approaches to interactivity, pushing the boundaries of what web apps could do. These innovations weren’t just alternatives — they were rewriting the rules of frontend development.

This era also saw build tools level up. Webpack became the go-to bundler, not just for JavaScript but for CSS, images, and everything in between.

Babel made sure devs could write modern JS without worrying about compatibility, seamlessly transpiling ES6+ to older browser-friendly versions.

But the real MVP was TypeScript. It exploded in popularity, helping devs catch errors early and making large codebases far easier to manage. Static typing became a must-have rather than a nice-to-have.

Web development didn’t stop at code. It embraced DevOps head-on.

Docker made it possible to run apps consistently across dev, testing, and production.
Kubernetes handled scaling and managing containerized apps like a boss.
CI/CD pipelines became the industry norm, automating testing and deployments with tools like GitHub Actions, GitLab CI, and Jenkins.

This automation meant fewer deployment errors and faster, more reliable releases. Teams could iterate and push updates without sweating about breaking production.

By the 2020s, JAMstack (JavaScript, APIs, and Markup) and serverless architectures flipped the web development game yet again. JAMstack apps combined the speed and security of static sites with the power of APIs and client-side JavaScript.

Static site generators like Next.js, Gatsby, and Nuxt.js made it possible to build blazing-fast apps that could still handle dynamic functionality through APIs. The best of both worlds!

Conclusion: Reflections on 35 Years of Web Development

After three and a half decades of web development, we’ve gone from basic HTML pages to mind-blowing interactive web apps that rival native app experiences. But through all the chaos and change, some things never budged:

HTML, CSS, and JavaScript remain the backbone of the web.
Cross-browser issues, performance optimization, and security challenges? Still here, but with fancier tools to manage them.
The developer experience went from editing plain text files to using integrated environments packed with real-time feedback, automated testing, and powerful debugging tools.

The biggest transformation?

We’ve moved from document-centric websites that just displayed information to application-centric web apps that deliver rich, interactive experiences.

Modern web apps don’t just show data, they think, react, and adapt to users like never before.

As we look back, one thing is clear: web development is a never-ending cycle of innovation. The principles of progressive enhancement, separation of concerns, and component-based architectures have stood the test of time.

So much has happened so quickly that I’m sure I’ve missed a lot of details.

And I can’t help but wonder, the devs who actually lived through those drastic changes must have a completely different perspective. So, if you were part of that wild ride, what was your favorite part? Drop your thoughts below! 😃👇