How React ES6 Syntax Differs From ES5 (In Real React Code)

I still remember the first time I inherited a React codebase that mixed three eras at once: old-school CommonJS require(), class components with manual bind(this), and modern function components with Hooks. The app worked, but the code felt like it was speaking multiple dialects of JavaScript. That’s the practical reason ES6 vs ES5 matters in React: React itself doesn’t demand ES6, but the way you express components, state updates, event handlers, and module boundaries changes dramatically with ES6 syntax.\n\nIf you’ve only seen ES6-style React (imports, arrow functions, destructuring, classes or Hooks), ES5 React can feel verbose and a little “ceremonial.” If you’ve only seen ES5 patterns, ES6 can look like magic—especially around this, modules, and object/array handling.\n\nI’ll walk through the differences that actually show up in day-to-day React work: modules, variables and scope, functions and this, component definitions, and the ES6 object/array features that make JSX code smaller and easier to reason about. I’ll also add 2026-era guidance on tooling and safe migration so you can modernize without breaking behavior.\n\n## React feels ES6-first (even when the runtime is ES5)\nReact runs anywhere JavaScript runs. But the React ecosystem strongly gravitates toward ES6+ syntax because modern bundlers and transpilers let you write newer JavaScript while shipping broadly compatible output.\n\nA key mental model: ES6 vs ES5 is a language and module-syntax discussion, while React is a UI library. The “React ES6 style” you see in most repos is really “React code written with ES6+ syntax, then compiled.” That compilation step is the bridge.\n\nIn 2026, a typical stack looks like:\n\n- You write modern JS/TS + JSX (ES6+ features are fair game).\n- A tool like Vite/webpack/Rspack (plus Babel or a fast compiler) transforms it.\n- The browser gets code that matches your target environments.\n\nSo when you compare “React ES5” and “React ES6,” you’re mostly comparing authoring style.\n\nOne more correction I see frequently: Symbol is not an ES5 primitive. ES5 has primitives like string, number, boolean, null, and undefined (plus objects). Symbol arrived with ES6. That detail doesn’t change React patterns much, but it’s a good reminder that ES6 added real language features, not just shorter syntax.\n\n## Modules: require/module.exports vs import/export\nReact projects live and die by modules: how you split components, share utilities, and keep dependencies clear.\n\nIn ES5-era Node tooling, CommonJS was the default:\n\njavascript\n// ES5 (CommonJS)\nvar React = require(‘react‘);\nvar ReactDOM = require(‘react-dom‘);\n\nvar Button = require(‘./Button‘);\n\nmodule.exports = Button;\n\n\nES6 introduced standard module syntax (ES Modules / ESM):\n\njavascript\n// ES6 (ES Modules)\nimport React from ‘react‘;\nimport ReactDOM from ‘react-dom/client‘;\n\nimport Button from ‘./Button.jsx‘;\n\nexport default Button;\n\n\nHere’s what changes in React code structure:\n\n- Default vs named exports become clearer. You’ll commonly export a component as default (export default function SettingsPage() { ... }) and export helpers as named (export function formatCurrency() { ... }).\n- Tooling can reason better about imports. Modern bundlers can more reliably remove unused exports and split code based on import().\n- Syntax is less “dynamic.” CommonJS require() can be used inside conditions. ESM imports are meant to be static at the top level, which makes builds more predictable.\n\nTraditional vs modern module patterns:\n\n

Topic

ES5 (CommonJS)

ES6 (ES Modules)

—

Import

var x = require(‘x‘)

import x from ‘x‘

Export

module.exports = X

export default X / export { X }

Named exports

Awkward conventions

First-class syntax

Code splitting

Tooling-specific tricks

import(‘./chunk‘) is standard

\n\nA few React-specific module notes I’ve learned the hard way:\n\n- Default exports are convenient, but named exports scale better. In a component library, named exports make refactors easier (renaming symbols is less disruptive), and they reduce confusion like import Button from ‘./Card‘.\n- Circular dependencies are easier to create with barrel files. ES6 doesn’t cause circular deps, but the common pattern of index.js re-exporting lots of components makes it easier to accidentally reference A → B → A. When that happens, the symptoms show up as undefined imports and weird runtime ordering.\n- Lazy loading becomes idiomatic. In modern React, splitting routes or heavy components via dynamic import() plays nicely with React.lazy() and Suspense:\n\njavascript\nimport React, { Suspense } from ‘react‘;\n\nconst AdminPanel = React.lazy(() => import(‘./AdminPanel‘));\n\nexport default function App() {\n return (\n <Suspense fallback={


Loading…

}>\n \n \n );\n}\n\n\nIf you’re maintaining React code today, I recommend writing new code in ESM even if you still run some CommonJS in tooling scripts. The React app layer benefits immediately from the clarity.\n\n## Variables and scope: var vs let/const (and why React cares)\nReact UIs are full of closures: callbacks inside map(), event handlers, effects, async calls. ES5’s var is function-scoped, not block-scoped, which can produce subtle bugs.\n\n### The classic ES5 problem: var in loops\nConsider a quick example that attaches click handlers:\n\njavascript\n// ES5-style\nfunction buildHandlers(ids) {\n var handlers = [];\n\n for (var i = 0; i < ids.length; i++) {\n var id = ids[i];\n handlers.push(function onClick() {\n // BUG: id ends up being the last value after the loop.\n console.log(‘Clicked:‘, id);\n });\n }\n\n return handlers;\n}\n\n\nYou can work around this in ES5 with an IIFE (immediately-invoked function expression):\n\njavascript\n// ES5 fix with IIFE\nfunction buildHandlers(ids) {\n var handlers = [];\n\n for (var i = 0; i < ids.length; i++) {\n (function (id) {\n handlers.push(function onClick() {\n console.log('Clicked:', id);\n });\n })(ids[i]);\n }\n\n return handlers;\n}\n\n\nES6 makes this straightforward with block scoping:\n\njavascript\n// ES6 fix with let\nfunction buildHandlers(ids) {\n const handlers = [];\n\n for (let i = 0; i {\n console.log(‘Clicked:‘, id);\n });\n }\n\n return handlers;\n}\n\n\n### Why this matters in React\nReact code is packed with patterns like:\n\n- Rendering lists: items.map(item => )\n- Event handlers: onClick={() => doSomething(item.id)}\n- Async logic: fetch().then(...) or await\n\nUsing const by default (and let when you truly reassign) communicates intent and avoids accidental mutation.\n\nA React-flavored example:\n\njavascript\n// ES6 React component: block-scoped variables and clear intent\nfunction OrderList({ orders }) {\n const totalOrders = orders.length;\n\n return (\n

\n      
Orders ({totalOrders})
\n

\n {orders.map((order) => {\n const label =

;\n          return 
{label}
;\n        })}\n

\n

\n );\n}\n\n\nWith ES5 var, it’s easier to accidentally reuse variables across blocks and make the render logic harder to scan.\n\nOne more practical React angle: const doesn’t mean immutable; it means not reassignable. You can still mutate a const object. That’s why ESLint rules like no-param-reassign and patterns like immutable updates matter even in ES6 code.\n\n## Functions and this: the ES5 pain point that ES6 softened\nIf you’ve ever had a React click handler crash because this was undefined, you’ve met the ES5 reality: this is determined by how a function is called, not where it’s declared.\n\n### ES5 function expressions\nES5 uses function everywhere:\n\njavascript\n// ES5\nvar sum = function (x, y) {\n return x + y;\n};\n\n\nThat’s fine—until you place methods on objects or classes and pass them around.\n\n### ES6 arrow functions\nArrow functions capture this from the surrounding scope:\n\njavascript\n// ES6\nconst sum = (x, y) => x + y;\n\n\nIn React class components, this changes the ergonomics a lot.\n\n### ES5-style class component binding (manual)\njavascript\nimport React from ‘react‘;\n\nclass Counter extends React.Component {\n constructor(props) {\n super(props);\n this.state = { count: 0 };\n\n // ES5-era pattern: bind methods so this works in callbacks\n this.increase = this.increase.bind(this);\n this.decrease = this.decrease.bind(this);\n }\n\n increase() {\n this.setState({ count: this.state.count + 1 });\n }\n\n decrease() {\n this.setState({ count: this.state.count - 1 });\n }\n\n render() {\n return (\n


\n        \n        
Count: {this.state.count}
\n        \n

\n );\n }\n}\n\nexport default Counter;\n\n\n### ES6 class fields + arrow methods (less ceremony)\nWith class fields (supported by modern toolchains), you often see:\n\njavascript\nimport React from ‘react‘;\n\nclass Counter extends React.Component {\n state = { count: 0 };\n\n increase = () => {\n this.setState((prev) => ({ count: prev.count + 1 }));\n };\n\n decrease = () => {\n this.setState((prev) => ({ count: prev.count - 1 }));\n };\n\n render() {\n return (\n


\n        \n        
Count: {this.state.count}
\n        \n

\n );\n }\n}\n\nexport default Counter;\n\n\nTwo React-specific notes I always point out:\n\n- When state updates rely on the previous state, prefer the functional form: setState(prev => ...).\n- Arrow methods can create new function instances per component instance; in most apps this is fine, but for extremely large lists you might care. In real UI terms, you’re typically talking about small per-item costs rather than a single dramatic slowdown.\n\nIf you’re writing new React in 2026, you’re usually not writing class components at all—you’re writing function components with Hooks. But understanding the this story helps when you maintain older code.\n\n## Component definitions: createReactClass → ES6 classes → function components + Hooks\nThis is where ES6 changes React code the most.\n\n### ES5-style components with createReactClass\nOlder React code used React.createClass() (later replaced by the create-react-class package). It included auto-binding and getInitialState():\n\njavascript\n// App.jsx\nimport React from ‘react‘;\nimport createReactClass from ‘create-react-class‘;\n\nconst Counter = createReactClass({\n getInitialState: function () {\n return { count: 0 };\n },\n\n increase: function () {\n this.setState({ count: this.state.count + 1 });\n },\n\n decrease: function () {\n this.setState({ count: this.state.count - 1 });\n },\n\n render: function () {\n return (\n


\n        \n        
Count: {this.state.count}
\n        \n      
\n    );\n  },\n});\n\nexport default function App() {\n  return (\n    
\n      
Counter (createReactClass)
\n      \n    
\n  );\n}\n

\n\nThis is “ES5 React style” mainly because:\n\n- You pass an object full of functions.\n- Those functions are written with the function keyword.\n- State starts in getInitialState().\n- Methods are auto-bound.\n\n### ES6 class components\nThe next step was ES6 classes:\n\n

javascript\n// App.jsx\nimport React from ‘react‘;\n\nclass Counter extends React.Component {\n  constructor(props) {\n    super(props);\n    this.state = { count: 0 };\n  }\n\n  increase = () => {\n    this.setState((prev) => ({ count: prev.count + 1 }));\n  };\n\n  decrease = () => {\n    this.setState((prev) => ({ count: prev.count - 1 }));\n  };\n\n  render() {\n    return (\n      
\n        \n        
Count: {this.state.count}
\n        \n      
\n    );\n  }\n}\n\nexport default function App() {\n  return (\n    
\n      
Counter (class)
\n      \n    
\n  );\n}\n

\n\n### Modern React: ES6+ function components with Hooks\nToday, the default is:\n\n

javascript\n// App.jsx\nimport React, { useState } from ‘react‘;\n\nfunction Counter() {\n  const [count, setCount] = useState(0);\n\n  const increase = () => setCount((c) => c + 1);\n  const decrease = () => setCount((c) => c - 1);\n\n  return (\n    
\n      \n      
Count: {count}
\n      \n    
\n  );\n}\n\nexport default function App() {\n  return (\n    
\n      
Counter (Hooks)
\n      \n    
\n  );\n}\n

\n\nThis is where ES6+ syntax shines:\n\n- No this at all.\n- Closures are natural.\n- Imports are clean (import { useState } from ‘react‘).\n- You rely on const, arrow functions, and destructuring constantly.\n\nTraditional vs modern React component styles:\n\n

Concern

ES5 createReactClass

ES6 class

ES6+ function + Hooks

—

State init

getInitialState()

this.state in constructor

useState()

this issues

Rare (auto-bound)

Common unless you bind

None

Reuse logic

Mixins (legacy)

HOCs / render props (older)

Hooks

Current default

Legacy

Maintenance mode in many repos

Primary choice

\n\nIf you’re working on a modern React app, you can usually treat “ES6 React” as “function components + Hooks + ESM,” even though those are technically separate ideas.\n\n## Destructuring, spread, and friends: ES6 features that reshape JSX\nA lot of React code is just transforming data into UI. ES6 gave us syntactic tools that make those transformations smaller and less error-prone.\n\n### Destructuring props\nES5:\n\njavascript\nfunction UserBadge(props) {\n var user = props.user;\n var isOnline = props.isOnline;\n\n return (\n


\n      {user.displayName}\n      {isOnline ? ‘Online‘ : ‘Offline‘}\n

\n );\n}\n\n\nES6:\n\njavascript\nfunction UserBadge({ user, isOnline }) {\n return (\n


\n      {user.displayName}\n      {isOnline ? ‘Online‘ : ‘Offline‘}\n

\n );\n}\n\n\nWhen I review React code, destructuring at the boundary (function params) is one of the fastest ways to make a component easier to scan.\n\n### Destructuring state and nested values\njavascript\nfunction CheckoutSummary({ order }) {\n const {\n id,\n pricing: { subtotal, shipping, tax, total },\n } = order;\n\n return (\n


\n      
Order {id}
\n      
\n        
Subtotal
\n        
${subtotal}
\n        
Shipping
\n        
${shipping}
\n        
Tax
\n        
${tax}
\n        
Total
\n        
${total}
\n      
\n

\n );\n}\n\n\nOne edge case I watch for: if order can be null while data loads, this destructuring will throw. In ES5, you’d probably do more defensive checks. In ES6+ style React, you either guard early:\n\njavascript\nfunction CheckoutSummary({ order }) {\n if (!order) return


Loading…
;\n  // safe to destructure now\n  const { id, pricing } = order;\n  return 
Order {id}: ${pricing.total}

;\n}\n\n\nOr you keep destructuring shallow and rely on explicit access. The punchline is the same: destructuring is great, but it encourages you to assume data is present—React apps often deal with “not present yet.”\n\n### Spread for props\nA very React-y ES6 pattern:\n\njavascript\nfunction TextInput(props) {\n return ;\n}\n\nexport default function ProfileForm() {\n const shared = {\n className: ‘field‘,\n autoComplete: ‘off‘,\n };\n\n return (\n \n \n Display name\n \n \n \n Website\n \n \n \n );\n}\n\n\nIn ES5 you’d typically use Object.assign() or manual copying. Spread syntax makes intent obvious: “take these props and pass them through.”\n\nTwo practical warnings I add to most teams’ style guides:\n\n- Prop spreading can leak things onto the DOM. If your TextInput is actually a wrapper around a native input, and you pass custom props like isInvalid, React may warn about unknown attributes. A good pattern is to explicitly pick what you forward.\n- Order matters. In JSX, will let name=‘x‘ win. But would let shared.name override your explicit name. That can become a head-scratcher during refactors.\n\n### Spread for immutable updates\nReact state updates often require copying objects/arrays rather than mutating them.\n\nES5-style (more verbose):\n\njavascript\nfunction addItemES5(state, newItem) {\n return Object.assign({}, state, {\n items: state.items.concat([newItem]),\n });\n}\n\n\nES6-style:\n\njavascript\nfunction addItemES6(state, newItem) {\n return {\n ...state,\n items: [...state.items, newItem],\n };\n}\n\n\nThis isn’t about speed in a micro-benchmark (in most apps, either is “fast enough”); it’s about reducing the chance that you accidentally mutate existing state.\n\nBut here’s the biggest edge case: spread is a shallow copy. If you do this:\n\njavascript\nconst next = { ...state };\nnext.user.profile.displayName = ‘New‘;\n\n\nYou just mutated the nested object shared with the old state. In React terms, you can get:\n\n- stale UI because shallow equality checks don’t see changes where you expect\n- bugs where previous state “mysteriously” changes\n- memoized components failing to re-render or re-rendering incorrectly\n\nFor deep updates, you either copy each nested layer explicitly, or you use a helper (many teams use Immer) so your intent stays clear.\n\n## JSX compilation: the ES5 reality hiding under ES6 syntax\nOne reason ES6 can feel like magic in React is that you’re usually using two layers of transformation: ES6+ → older JS, and JSX → function calls. Seeing the “ES5-ish” output once makes everything click.\n\nWhen you write JSX like this:\n\njavascript\nfunction Hello({ name }) {\n return


Hello, {name}

;\n}\n\n\nIt becomes something conceptually like this (simplified):\n\njavascript\nfunction Hello(props) {\n return React.createElement(‘h1‘, null, ‘Hello, ‘, props.name);\n}\n\n\nThat’s why people say React doesn’t require ES6. Even if you authored with arrow functions and destructuring, the runtime call is just React.createElement (or the newer JSX runtime) with plain JavaScript objects.\n\nPractical value: when you’re debugging weird JSX behavior, it helps to remember that:\n\n- {condition && } is just conditional logic producing either an element object or a falsy value\n- props are just a plain object being passed as an argument\n- your component is just a function returning a value\n\nES6 doesn’t change those fundamentals; it changes how pleasant it is to express them.\n\n## Template literals: better strings, better JSX readability\nES5 string building often looks like this:\n\njavascript\nvar label = ‘Order #‘ + order.id + ‘ (‘ + order.status + ‘)‘;\n\n\nES6 template literals improve both readability and refactor safety:\n\njavascript\nconst label = Order #${order.id} (${order.status});\n\n\nIn React, this shows up constantly in className, aria-label, test IDs, titles, and human-friendly labels.\n\nA practical component example where template literals make JSX less cluttered:\n\njavascript\nfunction StatusPill({ status }) {\n const className = pill pill–${status};\n return {status};\n}\n\n\nES5 can do it, but it’s noisier, and the noise adds up across a component tree.\n\nEdge case to watch: template literals make it easy to accidentally inject undefined into strings (for example, pill--${status} when status is missing). In practice I either provide a default (status = ‘unknown‘) or I assert early and render a fallback.\n\n## Default parameters and rest parameters: cleaner component signatures\nES5 defaulting often looks like this:\n\njavascript\nfunction Button(props) {\n var variant = props.variant


 ‘primary‘;\n  var size = props.size 
 ‘md‘;\n  // ...\n}\n

\n\nThat’s a bug magnet because

treats many valid values as “empty” (like ‘‘ or 0). ES6 default parameters are more precise:\n\njavascript\nfunction Button({ variant = ‘primary‘, size = ‘md‘, disabled = false }) {\n // ...\n}\n\n\nThis is one of those differences that feels cosmetic until you hit a real case like tabIndex={0} or an empty string that is intentionally empty.\n\nRest parameters also clean up React utility functions. ES5 used arguments or manual slicing; ES6 gives you ...rest:\n\n

javascript\nfunction cx() {\n  return Array.prototype.join.call(arguments, ‘ ‘);\n}\n\n// ES6\nfunction cx(...parts) {\n  return parts.filter(Boolean).join(‘ ‘);\n}\n

\n\nThat kind of helper shows up all over React code, especially for composing className values.\n\n## Enhanced object literals: React state and action objects get simpler\nES6 didn’t just add new syntax; it also made object creation less repetitive. In React, you create objects constantly: style objects, state objects, props objects, action payloads, query variables.\n\n### Shorthand properties\nES5:\n\njavascript\nvar userId = props.userId;\nvar payload = { userId: userId, source: ‘profile‘ };\n\n\nES6:\n\njavascript\nconst { userId } = props;\nconst payload = { userId, source: ‘profile‘ };\n\n\n### Computed property names (great for forms)\nForm state updates are a perfect ES6 example. ES5 tends to be verbose and imperative; ES6 lets you express intent succinctly.\n\n

javascript\nfunction reducer(state, action) {\n  switch (action.type) {\n    case ‘fieldChanged‘: {\n      const { name, value } = action;\n      return {\n        ...state,\n        [name]: value,\n      };\n    }\n    default:\n      return state;\n  }\n}\n

\n\nIn ES5, you’d need to build an object and assign the dynamic key manually. In a React reducer (whether Redux or useReducer), computed keys show up constantly.\n\n## Array methods vs imperative loops: React rendering becomes more declarative\nA lot of “React ES6 style” is really “functional style JavaScript,” enabled by arrow functions and array methods.\n\nES5 often looks like this:\n\n

javascript\nfunction Menu(props) {\n  var items = [];\n  for (var i = 0; i < props.links.length; i++) {\n    var link = props.links[i];\n    items.push(
{link.label}
);\n  }\n  return 
{items}

;\n}\n\n\nES6 tends to become:\n\njavascript\nfunction Menu({ links }) {\n return (\n


\n      {links.map((link) => (\n        
\n          {link.label}\n        
\n      ))}\n

\n );\n}\n\n\nThis matters because it changes how you debug. In the ES6 version:\n\n- the render output is local to the JSX\n- there’s less mutable intermediate state (items.push(...))\n- it’s easier to insert filters (links.filter(...)) and transforms\n\nA very practical pattern is filter-then-map for conditional rendering, which reads like English:\n\njavascript\n{links\n .filter((l) => !l.hidden)\n .map((l) => )}\n\n\nES5 can do it, but ES6 makes it the path of least resistance.\n\n## Promises vs async/await: effects and event handlers get clearer\nES6 introduced Promises; later JavaScript versions introduced async/await (not ES6 strictly, but it’s part of the “modern syntax” people mean in React). React apps deal with async constantly: fetching data, saving forms, loading routes.\n\nES5-style async often becomes nested callbacks or Promise chains that are correct but harder to read in UI code.\n\nHere’s a realistic React example: loading data in an effect, handling loading state, cancellation, and errors. I’m intentionally showing it in a way that avoids the common foot-guns.\n\njavascript\nimport React, { useEffect, useState } from ‘react‘;\n\nfunction UserProfile({ userId }) {\n const [state, setState] = useState({\n status: ‘idle‘,\n user: null,\n error: null,\n });\n\n useEffect(() => {\n let cancelled = false;\n\n async function run() {\n setState({ status: ‘loading‘, user: null, error: null });\n try {\n const res = await fetch(/api/users/${userId});\n if (!res.ok) throw new Error(HTTP ${res.status});\n const user = await res.json();\n if (!cancelled) setState({ status: ‘success‘, user, error: null });\n } catch (err) {\n if (!cancelled) setState({ status: ‘error‘, user: null, error: err });\n }\n }\n\n run();\n return () => {\n cancelled = true;\n };\n }, [userId]);\n\n if (state.status === ‘loading‘) return


Loading…
;\n  if (state.status === ‘error‘) return 
Failed: {String(state.error)}
;\n  if (!state.user) return null;\n\n  return (\n    
\n      
{state.user.displayName}
\n      
@{state.user.handle}
\n

\n );\n}\n\n\nWhy I include this in an ES6 vs ES5 discussion: once you have const, destructuring, arrow functions, and async/await, UI async code becomes linear and less error-prone. Without those features, you tend to create extra variables, extra helper functions, or deeply nested logic.\n\nA key pitfall (and it’s not “syntax,” but it shows up in modern syntax-heavy code): stale closures. If you write an effect that reads a value but forget to include it in the dependency array, ES6 syntax won’t save you. Modern React code is shorter, but the correctness rules are stricter because it’s easy to “look right.”\n\n## Performance considerations: where ES6 helps, and where it doesn’t\nI’ve watched teams argue about ES6 syntax as if arrow functions were “slow” or destructuring was “expensive.” In React, the performance story is more nuanced.\n\n### Arrow functions in render\nThis pattern is common:\n\njavascript\n\n\n\nIt creates a new function each render. For most UIs, that’s fine. But if you render thousands of items and pass handlers deep into memoized children, those new function identities can defeat memoization and cause extra renders.\n\nThe alternative is usually to pass stable callbacks (via useCallback) or restructure props so you don’t pass new functions down the tree. That’s not “ES6 vs ES5” exactly, but ES6 makes it easy to write inline closures, so it’s worth acknowledging the trade-off.\n\n### Spread and immutability\nSpread makes immutable updates concise, but you still need to be careful about how much you copy. Copying a huge object on every keystroke can be wasteful. The practical fix is not “go back to ES5”; it’s to keep state minimal and localized, normalize large collections, or use reducers that only update what changed.\n\nIf you want a simple rule of thumb I use:\n\n- optimize for clarity first (...state, [...items])\n- when profiling shows it matters, optimize the state shape or memoization boundaries\n\nES6 gives you clarity cheaply; don’t throw that away prematurely.\n\n## Common pitfalls: modern syntax can hide real bugs\nES6 makes React code shorter, but shorter code can hide assumptions. Here are the bugs I see most often during ES5 → ES6 migrations.\n\n### Pitfall 1: Destructuring undefined\njavascript\nfunction Card({ user: { displayName } }) {\n return


{displayName}

;\n}\n\n\nIf user is ever null while loading, this throws immediately. ES5 code often did if (!props.user) return null; out of habit. In modern React, that guard is still necessary unless your data is truly guaranteed.\n\nSafer pattern:\n\njavascript\nfunction Card({ user }) {\n if (!user) return null;\n return


{user.displayName}

;\n}\n\n\n### Pitfall 2: Confusing default exports with named exports\nIf you migrate modules gradually, you can end up with mismatches like:\n\n- file exports default: export default Button\n- consumer imports named: import { Button } from ‘./Button‘\n\nThat results in Button being undefined and errors like “Element type is invalid.” The fix is simple, but the debugging is annoying because React errors show up at render time, not import time.\n\n### Pitfall 3: Object spread order mistakes\njavascript\nconst props = { disabled: true };\nreturn ;\n\n\nThis button will be disabled because props.disabled wins. I’ve seen this cause “why is this input read-only?” bugs that waste hours. Pick an order convention and stick to it.\n\n### Pitfall 4: Assuming class fields are “ES6”\nPeople casually say “ES6 class component,” but many ergonomic class patterns (state = ..., method = () => ...) are not ES6 itself; they’re newer proposals that tools compile. That’s fine—nearly every React toolchain supports them—but it matters when you’re debugging build config or targeting odd environments.\n\n### Pitfall 5: var surviving in the corners\nEven in “modern” repos, you sometimes find var in older utility files. If you mix var and closures with React patterns like setTimeout, debounced handlers, or event listeners, you can end up with surprising behavior. A quick win during migration is to ban var at the lint level.\n\n## Alternative approaches: ES5 can still be clean (but it takes discipline)\nI don’t want to pretend ES5 automatically means “bad code.” You can write excellent ES5 React; it’s just harder to sustain at scale. If you’re stuck in ES5 (older embedded browsers, constraints, legacy build), these patterns help:\n\n- Prefer small pure functions over large classes or big objects full of methods\n- Use Object.assign consistently for immutable updates\n- Create a consistent convention for module exports (module.exports vs exports.foo)\n- Avoid clever IIFE tricks unless they’re contained and documented\n- Write more tests than you think you need (because the language won’t help you as much)\n\nES6 removes some of the “discipline tax.” That’s the real difference: modern syntax makes the clean path easier.\n\n## Modern tooling and migration guidance (2026): how to upgrade without breaking behavior\nIf you’re modernizing an ES5-ish React codebase, I treat it like a product change, not a syntax cleanup. The goal is to change how code is written without changing what it does.\n\nHere’s the migration sequence I’ve seen work best.\n\n### 1) Lock down behavior first\nBefore you touch syntax, make sure you can detect breakage:\n\n- get unit tests passing (or add a minimal set around critical flows)\n- add a smoke test page that renders key routes\n- capture a few screenshot diffs if you have a visual regression setup\n\nSyntax migrations are notorious for “it compiled, shipped, and broke a corner.” You want alarms.\n\n### 2) Convert modules incrementally\nMove from CommonJS to ESM in leaf modules first (utilities, isolated components), then work your way inward. Watch for default vs named export mismatches as you go.\n\n### 3) Replace var with const/let\nThis is low-risk if you do it systematically. My personal rule:\n\n- use const by default\n- use let only if reassignment happens\n- do not use var\n\nIt improves readability and catches accidental reassignments quickly.\n\n### 4) Tackle this hot spots\nIf you have class components with manual binding, class fields + arrow methods reduce ceremony. But don’t convert everything at once. Focus on components you’re already touching for features or bug fixes.\n\n### 5) Introduce destructuring and spread carefully\nDestructuring at function boundaries is usually safe and improves clarity. Deep destructuring is where runtime errors appear. Spread is great for immutability, but confirm you’re not relying on mutation side effects (some older code accidentally did).\n\n### 6) Consider converting classes to function components opportunistically\nHooks aren’t “ES6,” but the move to function components usually happens alongside ES6 modernization because the code becomes simpler when you remove this. That said, I don’t recommend a big-bang rewrite unless you have time and tests.\n\nA simple heuristic:\n\n- if a class is stable and rarely touched, leave it\n- if you’re modifying the component anyway, consider converting it\n\n## When to use ES6 features—and when not to\nA practical guide I use in reviews:\n\n### Use ES6 features when they clarify intent\n- destructure props when you use a few fields\n- use template literals for labels and class names\n- use const and arrow functions for small callbacks\n- use object/array spread for immutable updates\n- use ESM imports/exports for predictable structure\n\n### Avoid ES6 features when they reduce clarity\n- avoid massive parameter destructuring that hides where values come from\n- avoid prop spreading onto DOM elements unless you’ve filtered safe props\n- avoid clever one-liners that make debugging harder\n- avoid creating new objects/functions in hot render paths when memoization matters\n\nES6 is a toolbox, not a scorecard. The best React code I’ve seen uses modern syntax to reduce noise, not to show off language features.\n\n## Quick reference: ES5 vs ES6 differences you’ll actually feel in React\n

Area

ES5 feel in React

ES6 feel in React

Why it matters

—

Modules

require, module.exports

import, export

clearer dependencies, better tooling

Scope

var quirks

let/const

fewer closure bugs, clearer intent

Callbacks

function () {}

() => {}

less ceremony, easier composition

this

binding issues

lexical this with arrows

fewer runtime surprises in classes

Props handling

verbose props.x

destructuring

components read like signatures

Immutable updates

Object.assign, concat

spread ...

shorter, easier to audit for mutation

Rendering lists

loops + pushes

map in JSX

more declarative UI code

\n\n## Expansion Strategy\nAdd new sections or deepen existing ones with:\n- Deeper code examples: More complete, real-world implementations\n- Edge cases: What breaks and how to handle it\n- Practical scenarios: When to use vs when NOT to use\n- Performance considerations: Before/after comparisons (use ranges, not exact numbers)\n- Common pitfalls: Mistakes developers make and how to avoid them\n- Alternative approaches: Different ways to solve the same problem\n\n## If Relevant to Topic\n- Modern tooling and AI-assisted workflows (for infrastructure/framework topics)\n- Comparison tables for Traditional vs Modern approaches\n- Production considerations: deployment, monitoring, scaling\n\nIf you take nothing else away: ES6 didn’t make React “possible,” but it made React pleasant. It reduces the accidental complexity—especially around modules, this, and immutable updates—so you can spend your time on UI behavior instead of fighting the language.

Orders ({totalOrders})

Counter (createReactClass)

Counter (class)

Counter (Hooks)

Order {id}

Hello, {name}

{state.user.displayName}

You maybe like,

Related Posts