Work with Shubham
Available for senior engineering roles, technical consulting, and product advisory. I specialise in React, Next.js, and full-stack architecture for global-scale platforms.
Start a project
They start with the wrong question. What framework should I learn? The real question is: do I actually understand what's happening on the screen? Most tutorials drop you into React on day one. You copy code, it runs, and you move on without knowing why it worked.
I've seen this pattern repeatedly — developers who can build features but freeze when something breaks at the DOM level, because they skipped the part that explains what the DOM actually is. The sequence below is the order I wish I'd learned in.
There's a fix for that. It starts with a product card, a plain JavaScript function, and ends with that same card as a React component. Six concepts, in one specific order, each making the next click into place. By the time you write the React version, you won't just know how to write it. You'll know why every single line is there.
JavaScript is what makes web pages do things: maps that move, content that updates without a reload, buttons that respond. Before you touch the DOM or write a component, you need to think like a programmer, which is different from knowing syntax.
The focus here isn't memorization. It's learning to ask why code behaves the way it does.
A good early example — why does this function return nothing?
// Why does this print "undefined"?
function getProduct() {
const name = "Laptop"
}
console.log(getProduct()) // undefined — no return statement
// Fixed:
function getProduct() {
const name = "Laptop"
return name
}
console.log(getProduct()) // "Laptop"
Seems obvious once you see it. Most beginners spend weeks hitting this wall in different forms because they never stopped to ask the question. Getting into the habit of asking it is most of what this section is about.
The section works through variables, types, functions, objects, arrays, and conditionals, then goes deeper into scope, the call stack, and debugging. Those last three aren't advanced topics. They're what separates developers who can read error messages from developers who can't.
HTML is the structure of a web page, the part browsers parse before anything else runs. Get it wrong and nothing else works right, no matter how good your JavaScript is.
The key concept is the Document Object Model: browsers read HTML into a tree of nodes, and that tree is what JavaScript actually operates on. Knowing what the document object is, how querySelector works, and how to attach event listeners turns DOM errors from mysterious into something you can actually fix.
// Select the product list container from the HTML
const list = document.querySelector("#product-list")
// Listen for a click on any card inside it
list.addEventListener("click", (event) => {
if (event.target.tagName === "BUTTON") {
console.log("Add to cart clicked")
}
})
An app that looks broken feels broken, even if it works perfectly. CSS is what turns a functional prototype into something people trust enough to use.
The two layout systems worth learning first are flexbox and grid. Not because they're trendy, but because they replaced a decade of float hacks and table abuse, and they're what every modern UI is actually built with.
Here's flexbox laying out the product grid:
/* Product grid layout */
.product-list {
display: flex;
flex-wrap: wrap;
justify-content: center;
gap: 1.5rem;
padding: 2rem;
}
.product-card {
display: flex;
flex-direction: column;
align-items: flex-start;
width: 280px;
border: 1px solid #e2e8f0;
border-radius: 8px;
padding: 1.25rem;
}
Two properties and your grid wraps and centers itself at any screen size. Before flexbox, that required a painful combination of floats, clearfixes, and prayers. Now that the card looks right, the next question is how to make it respond to a click, which is where JavaScript and HTML have to work together.
React, Vue, Angular — they're all solving the same problem: wiring JavaScript to HTML without making a mess of it. But before you use a tool that does this for you, it's worth seeing what it actually does.
Most developers who say they're comfortable with React have never written a createElement call, which is exactly why their debugging stops at the component boundary. Here's the manual version, no framework, no build step:
// No framework, no build step — just JS and the DOM
function renderProduct(product) {
const card = document.createElement("div")
card.className = "product-card"
card.innerHTML = `
<h2>${product.name}</h2>
<p>$${product.price}</p>
<button>Add to cart</button>
`
document.getElementById("product-list").appendChild(card)
}
renderProduct({ name: "Wireless Headphones", price: 49.99 })
Every React component you write later is a cleaner version of this. Writing it manually first is what makes the abstraction feel earned rather than arbitrary.
This section builds a minimal version of what React does: creating nodes, updating them dynamically, and splitting logic into modules using both ES and CommonJS syntax. Writing it by hand once is worth more than reading about it ten times.
Most beginners skip straight to deploying without knowing what deployment actually means, which is why they spend hours debugging production issues that a five-minute mental model would have prevented. When you type a URL into a browser, your computer sends a request to a remote server, which sends back files. That's it.
Node.js lets you run JavaScript on that server. Vite takes your JavaScript, potentially dozens of files, and bundles it into something a browser can load efficiently. Unbundled JavaScript has a ceiling most beginners don't notice until they hit it hard.
Scaffolding a new project with Vite takes one command:
npm create vite@latest my-app -- --template react
cd my-app && npm install && npm run dev
Two seconds later you have a local dev server with hot module replacement, meaning the browser updates the exact component you edited without a full page reload. That's what makes front-end development fast to iterate on. Understanding that Vite is assembling and serving those files is what makes debugging it possible.
React is a JavaScript library for building UIs. What makes it useful is that it handles DOM updates for you: describe what the UI should look like given some state, and React figures out the minimum changes needed to get there.
The same product card from Section 4, now as a React component:
// ProductCard.jsx
import { useState } from "react"
function ProductCard({ name, price }) {
const [added, setAdded] = useState(false)
return (
<div className="product-card">
<h2>{name}</h2>
<p>${price}</p>
<button onClick={() => setAdded(true)}>{added ? "✓ Added" : "Add to cart"}</button>
</div>
)
}
export default ProductCard
Same output. Less code. The button updates without touching the DOM directly because React tracks the state change and handles the re-render.
React components, JSX, hooks, state, reactivity, the component lifecycle — each one makes more sense because you've already seen what it replaces.
Web development has a lot of layers. Most guides hide that by dropping you into the top one. The order here is deliberate: each section exists because the next one needs it. Once the React fundamentals click, the next question is performance — Next.js Core Web Vitals 2026 shows what slows real production apps down, and it's usually not what beginners expect.
Once this foundation is solid, the next step is learning which React and Next.js patterns matter at a production level — mastering React and Next.js in 2026 maps the resources worth investing in at each stage.
Want to see how these concepts come together in a real product? Browse my projects or reach out — happy to talk through what you're building.
Learn them in this order: JavaScript fundamentals first (variables, functions, arrays, objects), then HTML structure, then CSS layout and styling, then DOM manipulation with vanilla JS, then a build tool like npm, then React. Most courses start with HTML and CSS because they're visual, but without JS fundamentals you won't understand why React exists or what it's actually doing. If you understand functions and data before you write a component, every React concept lands on something solid instead of floating in air.
Before React, you need: JavaScript functions, arrays (map, filter), objects and destructuring, and how the DOM works conceptually. You don't need to be a CSS expert, but you should understand the box model and how elements stack. The most important prerequisite is understanding what a function returns — because a React component is a function that returns UI. If 'const Card = () => <div>Hello</div>' reads as magic rather than 'a function returning markup', spend more time on JS functions before React.
Three ways. Inline styles: pass a JavaScript object to the style prop — <div style={{ color: 'red', fontSize: '16px' }}>. Note double braces: outer for JSX expression, inner for the object. CSS Modules: create a Card.module.css file and import styles from './Card.module.css', then use className={styles.card} — scoped to that component, no name collisions. Tailwind CSS: add utility classes directly in className, which is what most React projects use in 2026. Unlike HTML, use className not class, and camelCase for CSS properties in style objects (backgroundColor not background-color).
npm stands for Node Package Manager. It's how you install React itself and every library your project uses. When you run 'npm install react', npm downloads React from the npm registry and adds it to a node_modules folder. 'npm run dev' runs a script defined in package.json — usually starting a local dev server. You don't need to understand npm deeply to start, but knowing that it manages dependencies (the external code your project relies on) and runs build scripts is enough to unblock yourself when tutorials say 'run npm install'.
In HTML you write static markup in .html files and manually update the DOM with JavaScript when data changes. In React you write components — JavaScript functions that return markup — and React handles DOM updates when your data changes. The mental shift: instead of 'find this element and change its text', you write 'this component displays this data' and re-render when the data updates. A plain HTML product card becomes a React component when you replace the hardcoded values with props: function ProductCard({ name, price }) { return <div><h2>{name}</h2><p>{price}</p></div> }. The markup looks similar; the difference is it's now reusable and data-driven.
just-js refers to learning plain JavaScript without any framework — vanilla JS, no React, no build tools. It's a valid and underrated approach for beginners. Understanding how to manipulate the DOM with querySelector and addEventListener, how fetch works, and how events bubble gives you a foundation that makes framework behavior transparent rather than magical. The risk is getting stuck in 'vanilla JS land' and never building the kind of UI that React makes practical. The right balance: spend enough time with plain JS to understand what React is abstracting, then move to React before you try to rebuild component systems yourself.
Published: Fri Mar 20 2026