DEV Community: D3Y4N

Want to refresh your knowledge on React Hooks, or even better - to learn few?

D3Y4N — Tue, 16 Sep 2025 11:20:38 +0000

D3Y4N

Sep 16 '25

🪝 The Ultimate React Hooks Cheat Sheet (2025 Edition)

#webdev #javascript #react #tutorial

Comments

7 min read

🪝 The Ultimate React Hooks Cheat Sheet (2025 Edition)

D3Y4N — Tue, 16 Sep 2025 10:33:01 +0000

React keeps adding crazy powerful hooks… and remembering them all feels like juggling flaming swords 🔥. I've been there before. This cheat sheet is your brain’s new best friend — just enough code to refresh your memory and keep you shipping like a pro. 🚀

📑 Table of Contents

Basic Hooks (must-know)
- useState - your mini storage box
- useEffect - side effect manager
- useContext - no more prop-drilling pain
Additional Hooks (for optimization & complex state)
- useReducer - the state machine
- useCallback - memorized functions
- useMemo - memorized values
- useRef - the persistent box
- useImperativeHandle - custom ref API
- useLayoutEffect - sync effect
- useDebugValue – dev tools helper
React 18+ Hooks (new & shiny)
- useId – unique IDs without headaches
- useTransition – smooth state updates
- useDeferredValue - defer slow updates
- useSyncExternalStore - safe external subscriptions
- useInsertionEffect – style injection before paint
Custom Hooks – your secret weapon
- useToggle example
- useLocalStorage example
Wrap-Up – your React Hooks cheat sheet

If you learn how to use all of these hooks perfectly the next time your PR get's reviewed the team lead's mouth would be dropped. Jokes aside, let's learn.

🟢 Basic Hooks (must-know)

`useState` - your mini storage box (or getters and setters without tons of boilerplate)

This is where it all starts. useState lets your component "remember" things between renderers. Think of it as a little box where you can store values.

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

<button onClick={() => setCount(count + 1)}>
  You clicked {count} times
</button>

Whe you call setCount, React re-renders the component with the new value.

Usage API:

const [value, setValue] = useState(initialValue);  // 💡 Tip: You can pass a function as initialValue for expensive calculations

value → current state
setValue → function to update it
initialValue → starting value

`useEffect` - sife effect manager.

At this point is where in almost all of the tutorials online you would hear "now this is where it gets a bit hacky", but don't worry, just with a bit of practice this hooks becomes like a second nature.
Want to fetch data, set up a subscription, or mess with document.title? That's useEffect. It runs after the component renders.

useEffect(() => {
  console.log("Component mounted or updated!");

  return () => {
    console.log("Cleanup before unmount or next run");
  };
}, [/* dependencies here */]);

Add dependencies in the array ([userId]) to control when it runs. Leave it empty ([]) if you want it only once on mount.

Usage API:

useEffect(() => {
  // side effect
  return () => { /* cleanup */ }
}, [dependencies]);

Runs after every render unless you control it with dependencies
Empty array ([]) → run only once
[dep1, dep2] → run when these change

`useContext` - no more prop-drilling pain

I've tought a lot whether should i place this hook here or in the "advanced" section, as I rarely see anybody use it in their personal projects. If you do - I'm really impressed by your React skills, if not - this hook would take you far.
Tired of passing props down three... four... five levels deep? useContext lets you read from a context directly.

const ThemeContext = React.createContext("light");

function App() {
  return (
    <ThemeContext.Provider value="dark">
      <Toolbar />
    </ThemeContext.Provider>
  );
}

function Toolbar() {
  const theme = useContext(ThemeContext);
  return <button className={theme}>I’m {theme} mode</button>;
}

Use it when multiple components need the same data (theme, user, language, etc.)

Usage API

const value = useContext(MyContext);

MyContext → the context object you created with React.createContext.
value → whatever the nearest Provider is giving you

⚡ Advanced Hooks (for optimization & complex state)

`useReducer` - the state machine

Now this is where the senior level react devs get separated from the juniors. Personally, whenever i see that somebody uses this hook i get goosebumps and give their repo a star. :D

When the state logic gets complicated, useReducer steps in. It's like useState but with superpowers. Perfect for forms, complex toggles, or anything with multiple actions.

function reducer(state, action) {
  switch (action.type) {
    case "increment": return { count: state.count + 1 };
    case "decrement": return { count: state.count - 1 };
    default: return state;
  }
}

const [state, dispatch] = useReducer(reducer, { count: 0 });

<button onClick={() => dispatch({ type: "increment" })}>
  {state.count}
</button>

Usage API:

const [state, dispatch] = useReducer(reducerFn, initialState);

state → current state
dispatch → function to send actions
reducerFn(state, action) → decides how state changes

`useCallback` - memorized functions

Please, please, I beg you - use this instead of going trough every single component in your project just to rename a function. 😭

If you keep passing the same function dodwn to child components and triggering re-renders, useCallback saves the day by memorizing it.

const memoizedHandler = useCallback(() => {
  console.log("Runs only when deps change");
}, [dependency]);

Usage API:

const memoizedFn = useCallback(fn, [dependencies]);

Returns the same function instance unless dependencies change
Great for performance tuning

`useMemo` - memorized values

Note: ts really helps with optimisations, dive even deeper into it, you won't regret - https://react.dev/reference/react/useMemo

Expensive calculations? Wrap them in useMemo so they don't run every render.

const expensiveValue = useMemo(() => heavyCalculation(data), [data]);

Usage API:

const memoizedValue = useMemo(calcFn, [dependencies]);

Only recalculates if dependencies change
Think of it as a cached result

`useRef` - the persistent box

ChatGPT's favourite hook when it comes to more eye-catching visuals :D

Need a value that sticks around but doesn't change re-renders? That's useRef. Perfect for acessing DOM elements or keeping track of mutable stuff.

const inputRef = useRef(null);

<input ref={inputRef} />
<button onClick={() => inputRef.current.focus()}>
  Focus input
</button>

Usage API:

const ref = useRef(initialValue);

ref.current → mutable value (DOM node or custom value)

`useImperativeHandle` - custom ref API

Sometimes you want a parent to call methods on a child. This hook lets you expose a custom API when using forwardRef.

useImperativeHandle(ref, () => ({
  focus: () => inputRef.current.focus()
}));

Usage API:

useImperativeHandle(ref, () => customObject, [dependencies]);

Used with forwardRef
Lets parents call methods like childRef.current.doSomething()

`useLayoutEffect` - sync effect

Like useEffect, but runs synchronously after DOM mutations (before the browser paints). Useful for measuring layout or scrolling.

useLayoutEffect(() => {
  console.log("DOM is ready, before paint");
}, []);

Usage API:

useLayoutEffect(effectFn, [dependencies]);

Blocks painting until it's done (⚠️ use carefully)

`useDebugValue` – dev tools helper

Used in custom hooks to label values in React DevTools. Not for production code, just debugging.

function useFriendStatus(friendID) {
  const isOnline = useSomeCustomHook(friendID);
  useDebugValue(isOnline ? "Online" : "Offline");
  return isOnline;
}

Usage API:

useDebugValue(value, formatFn?);

Shows extra info in React DevTools

These hooks are your toolbox for performance & advanced state. You won’t use all of them daily, but knowing they exist = huge time saver.

🧪 React 18+ Hooks (new & shiny)

`useId` – unique IDs without headaches

Needa stable ID for accessibility or forms? useId generates unique IDs that won't change across renders.

const id = useId();

<label htmlFor={id}>Name</label>
<input id={id} />

Usage API:

const id = useId();

Returns a stable, uniqe string
Perfect for accessibility (htmlFor, aria-* attributes)

`useTransition` – smooth state updates

Mark updates as "non-blocing" to keep the UI responsive during heavy renders.

const [isPending, startTransition] = useTransition();

startTransition(() => {
  setList(hugeNewList);
});

isPending && <Spinner />

Usage API:

const [isPending, startTransition] = useTransition();

isPending → true while transition is happening
startTransition(callback) → wrap updates that can be delayed

`useDeferredValue` - defer slow updates

Smooth out your UI by deferring non-critical updates.

const deferredSearch = useDeferredValue(searchQuery);

useEffect(() => {
  fetchData(deferredSearch);
}, [deferredSearch]);

Usage API:

const deferredValue = useDeferredValue(value);

Returns a slower-updating version of a value
Useful for large lists, autocomplete, or filtering

`useSyncExternalStore` - safe external subscriptions

Subscribe to external stores like Redux or custom stores safely, with React 18’s concurrent rendering.

const state = useSyncExternalStore(
  store.subscribe,
  store.getSnapshot
);

Usage API:

const state = useSyncExternalStore(subscribeFn, getSnapshotFn);

subscribeFn → called to listen for changes
getSnapshotFn → returns the current state
Handles concurrent updates safely

`useInsertionEffect` – style injection before paint

Mostly for CSS-in-JS libraries. Runs before DOM mutations, ensuring styles are applied before rendering.

useInsertionEffect(() => {
  injectStyles(".btn { color: red }");
}, []);

Usage API:

useInsertionEffect(effectFn, [dependencies]);

Runs synchronously before paint
Great for styling libraries that need to inject CSS

🛠️ Custom Hooks – your secret weapon

Custom hooks are basically functions that use other hooks. They let you reuse logic across components without repeating yourself. Think of them as mini React utilities that you can plug in anywhere.

function useToggle(initial = false) {
  const [value, setValue] = useState(initial);
  const toggle = () => setValue(v => !v);
  return [value, toggle];
}

// Usage in a component
function App() {
  const [isOpen, toggleOpen] = useToggle(false);
  return <button onClick={toggleOpen}>{isOpen ? "Open" : "Closed"}</button>;
}

Usage API:

const [value, toggle] = useToggle(initialValue);

value → current state
toggle() → flips state from true → false or false → true

Example: `useLocalStorage` – state that survives refreshes

function useLocalStorage(key, initialValue) {
  const [storedValue, setStoredValue] = useState(() => {
    return JSON.parse(localStorage.getItem(key)) ?? initialValue;
  });

  const setValue = (value) => {
    setStoredValue(value);
    localStorage.setItem(key, JSON.stringify(value));
  };

  return [storedValue, setValue];
}

// Usage
const [name, setName] = useLocalStorage("name", "Guest");

⬆ Back to top

Wrap-Up – your React Hooks cheat sheet

And that’s a wrap! 🎉

You’ve now got a one-stop reference for all React hooks — from the essentials to the shiny new toys in React 18+. Keep this page handy, because next time someone asks for a “React hook example,” you’ll just wink and say, “Already got it.” 😎

Remember:

Basic hooks = your everyday tools (useState, useEffect, useContext)
Advanced hooks = performance & complex state wizards (useReducer, useCallback, useMemo, useRef)
React 18+ hooks = concurrent rendering magic (useTransition, useDeferredValue, useSyncExternalStore)
Custom hooks = your secret weapons to reuse logic like a pro

If this cheat sheet saved you even a minute of Googling, consider buying me a coffee to keep the content flowing: ko-fi.com/deyan_sirakov ☕💖

Now go forth, hook like a hero, and never forget: React hooks are powerful, but your memory doesn’t have to be.

If anybody is struggling to get into opengl...

D3Y4N — Sun, 07 Sep 2025 23:11:31 +0000

D3Y4N

Sep 7 '25

The Definitive Guide to OpenGL VBOs, VAOs, and EBOs

#opengl #graphics #cpp #beginners

Comments 1

11 min read

The Definitive Guide to OpenGL VBOs, VAOs, and EBOs

D3Y4N — Sun, 07 Sep 2025 23:10:38 +0000

Many beginners hit a wall when they first encounter VAOs, VBOs, and EBOs. They seem abstract, confusing, and some give up. But mastering them is like learning the secret language of the GPU - suddenly, you control exactly how your data moves, how it's reused, and how efficiently it renders. Once you understand these, building your own rendering systems or game engines is no longer a guesswork.

In this guide, we'll break down each type of buffer, show how they interact, and provide clear code examples. By the end you won't just understand them - you'll be ready to wield them like a pro.

Why do VAOs, VBOs, and EBOs Exist? (A Bit of History)

If you've seen old OpenGL tutorials, you've probably come across code like this:

glBegin(GL_TRIANGLES);
glVertex3f(0.5f,  0.5f, 0.0f);
glVertex3f(0.5f, -0.5f, 0.0f);
glVertex3f(-0.5f, -0.5f, 0.0f);
glEnd();

This was called immediate mode (glBegin/glEnd). It was simple, but also incredibly inefficient:

Every frame, the CPU had to resend all vertex data to the GPU.
There was no way to reuse vertices between objects.
The GPU sat idle, waiting for the CPU to feed it more data.

As GPUs got faster and more parallel, this approach couldn't keep up. That's why modern OpenGL introduced buffer objects:

VBOs → Move vertex data to the GPU once, reuse it every frame.
VAOs → Store the "recipe" for how to interpret that data.
EBOs → Avoid duplicating vertices by reusing them with indices. In short: immediate mode was easy but slow. Buffer objects made things a bit more complex, but they unlocked the massive performance modern GPUs are capable of.

Vertex Buffer Objects (VBOs)

Let's start with the foundation: the Vertex Buffer Object (VBO). At its core, a VBO is simply a block of memory on the GPU where you store your vertex data - positions, colors, texture coordinates, normals, or anything else your vertices need. Instead of keeping this data on the CPU, where access would be slow, we upload it once into GPU memory, so the graphics card can fetch it directly when rendering.

Think of a VBO like a bookshelf where each book represents a vertex. The bookshelf itself doesn’t tell you how to read the books - it just stores them neatly. Later, we'll see how VAOs and EBOs tell the GPU how to interpret or reuse those books, but the VBO itself is just the storage space where they live.

To use a VBO in OpenGL, the first step is creating the buffer object. This is done with glGenBuffers(), which asks OpenGL to generate one or more buffer "handles" - unique IDs that reference GPU memory.

At this point, no memory is allocated yet; the handle is just a reference.

For example:

GLuint vbo;
glGenBuffers(1, &vbo); // this generates a single VBO handle

Think of this as getting a locker number at the gym. You have the key (the handle), but the locker (GPU memory) isn't ready yet.

The next step is binding the VBO to a target using glBindBuffer(). This tells OpenGL which purpose this buffer will serve.

glBindBuffer(GL_ARRAY_BUFFER, vbo);

The target GL_ARRAY_BUFFER indicates this buffer will hold vertex attributes (positions, colors, texture coordinates, etc.). Binding is like saying: "From now on, whenever we talk about GL_ARRAY_BUFFER, we mean this locker."

Once bound, we allocate and optionally fill the buffer using glBufferData():

float vertices[] = {
    0.5f,  0.5f, 0.0f,  // top right
    0.5f, -0.5f, 0.0f,  // bottom right
   -0.5f, -0.5f, 0.0f,  // bottom left
   -0.5f,  0.5f, 0.0f   // top left
};
glBufferData(GL_ARRAY_BUFFER, sizeof(vertices), vertices, GL_STATIC_DRAW);

Here's what happens under the hood: OpenGL allocates memory on the GPU large enough to hold your vertex data and copies the data from CPU memory to GPU memory. The usage hint you provide (like GL_STATIC_DRAW) informs the driver how you plan to use the buffer, which helps it optimize memory placement for performance.

Here’s a quick guide to the most common usage hints:

Hint	Frequency of change	Usage example
STREAM_DRAW	Rarely used	Streaming particles
STATIC_DRAW	Set once	Static meshes
DYNAMIC_DRAW	Changes often	Animated vertices

🔎 In a future article, we’ll go deeper into memory layouts — interleaved vs. separate buffers, alignment rules, and how they impact GPU performance. If you’ve ever wondered why some engines pack data differently, that’s where it gets interesting.

Why Binding Matters

Binding is how OpenGL keeps track of which buffer you're currently working with. Instead of passing the buffer handle to every function, you "bind" a buffer to a target, and OpenGL treats it as the active buffer for all subsequent operations. For example, when you call glBufferData() or glVertexAttribPointer(), OpenGL knows exactly which buffer you mean because it's bound.

This system lets you efficiently work with multiple buffers: you can rebind different buffers to the same target whenever you need to update or render different sets of vertex data.

It's important to remember: binding doesn't copy data - it just sets the active buffer. To prevent accidental changes, you can unbind a buffer with:

glBindBuffer(GL_ARRAY_BUFFER, 0);

When you're done with a buffer, glDeleteBuffers frees the GPU memory safely, even if the buffer is currently bound. OpenGL ensures that deletion won't crash your program.

Vertex Array Objects (VAOs)

So far we’ve got our vertex data sitting nicely in a VBO. But here’s the problem: the GPU doesn’t magically know what those numbers mean. Are they positions? Colors? Texture coordinates? How many floats make up a vertex? This is where the Vertex Array Object (VAO) steps in.

A VAO is like an instruction manual for your vertex data. While the VBO is just raw storage, the VAO tells OpenGL how to read that storage. It remembers:

Which VBOs to pull data from.
How to break that data into attributes (position, color, texture coords, etc.).
How much data to skip between vertices (stride).
Where each attribute starts inside the vertex (offset).

Think of a VAO like a table of contents for your bookshelf (the VBO). While the VBO holds all the books (vertices), the VAO tells the GPU how to read them and in what order.

Creating a VAO is simple:

GLuint vao;
glGenVertexArrays(1, &vao); // this generates a single vao handle
glBindVertexArray(vao);

After binding the VAO, we then bind our VBO and describe the layout of the data with glVertexAttribPointer():

glBindBuffer(GL_ARRAY_BUFFER, vbo);

// position attribute
glVertexAttribPointer(
    0,                  // attribute index (matches your vertex shader)
    3,                  // number of components (x, y, z)
    GL_FLOAT,           // data type
    GL_FALSE,           // should OpenGL normalize values?
    3 * sizeof(float),  // stride: total size of one vertex
    (void*)0            // offset: where this attribute starts
);
glEnableVertexAttribArray(0);

At first glance, this function looks like a monster — but let's break down the two most confusing parts: stride and offset.

Stride

The stride is the size of a single vertex in bytes. Imagine walking through your array one vertex at a time — the stride is how many bytes you step forward to reach the next vertex.

If each vertex only has a position (x, y, z) stored as 3 floats, the stride is 3 * sizeof(float).
If later you add colors (r, g, b) or texture coordinates (u, v), the stride gets bigger because each vertex stores more data.

Offset

The offset tells OpenGL where, inside a vertex, a particular attribute starts.

For the position attribute, it starts right at the beginning → (void*)0.
If your vertex looks like (x, y, z, r, g, b), the color attribute would have an offset of 3 * sizeof(float), because the first three floats are position, and the next three are color.

Memory Layout & Performance: Interleaved vs. Separate Buffers

So far, our vertices are packed as (x, y, z) or (x, y, z, r, g, b). But how you arrange data in memory actually affects performance.

There are two main strategies:

1. Interleaved attributes (common in real-time graphics)

// position (x,y,z) followed by color (r,g,b)
float vertices[] = {
   //   x,     y,    z,    r,   g,   b
    0.5f,  0.5f, 0.0f,  1.0f, 0.0f, 0.0f,
    0.5f, -0.5f, 0.0f,  0.0f, 1.0f, 0.0f,
   -0.5f, -0.5f, 0.0f,  0.0f, 0.0f, 1.0f,
   -0.5f,  0.5f, 0.0f,  1.0f, 1.0f, 1.0f
};

Pros: GPU can fetch a whole vertex (position + color) in one go → better cache usage, faster rendering.
Cons: Harder if you want to update only one attribute (e.g. colors) without touching positions.

2. Separate buffers per attribute (cleaner, flexible)

float positions[] = { ... };  
float colors[] = { ... };  

// bind positions to attribute 0
// bind colors to attribute 1

Pros: Easy to stream just one attribute (like updating only positions for animation)
Cons: More memory lookups, slightly worse cache performance.

👉 In practice, game engines often use interleaved layouts for efficiency, but it’s good to know both approaches.

Why Attributes?

Now, why do we even have to bother with attributes? Because modern OpenGL uses shaders, and shaders expect data to come in as attributes. Each attribute in your VAO maps directly to an in variable in your vertex shader.

For example:

layout (location = 0) in vec3 aPos;  // attribute 0 → position
layout (location = 1) in vec3 aColor; // attribute 1 → color

Without attributes, the GPU would just see a long soup of floats with no clue where one thing ends and another begins. Attributes are the labels that connect your raw data to your shader inputs.

Finally, once everything's set up, the beauty of VAOs is that you don't have to redo this configuration every time you draw. You just:

glBindVertexArray(vao);
glDrawArrays(GL_TRIANGLES, 0, 6);

And OpenGL already knows which data to use and how to use it.

VAO State Tracking Gotchas

One of the most common beginner bus with VAOs is forgetting when the state gets stored. A VAO remembers:

Which VBOs were bound at the time you called glVertexAttribPointer().
Which EBO was bound to GL_ELEMENT_ARRAY_BUFFER when the VAO was active.
Which attributes were enabled with glEnableVertexAttribArray(). That means:
If you set up your attributes without a VAO bound → nothing gets saved.
If you bind a different VAO and then configure attributes → the new VAO gets the settings. Debugging tip: If your object isn't rendering:
Check if you bound the VAO before calling glVertexAttribPointer().
Make sure you called glEnableVertexAttribArray() for every attribute.
Double-check that the layout (location = x) in your shader matches the attribute index you set in C++. This tiny detail trips up almost everyone at least once.

⚡ But VAOs also have some hidden “gotchas.” They remember more state than most people realize, and that can cause subtle bugs. We’ll cover VAO state tracking pitfalls in a follow-up guide.

Element Buffer Objects (EBOs)

Alright, we've got VBOs (raw data) and VAOs (the instruction manual). But what if you want to reuse some of that data instead of repeating yourself over and over? That's where the Element Buffer Object (EBO) comes in.

An EBO (also called Index Buffer) lets you store indices that reference vertices in your VBO. Instead of duplicating the same vertex data, you can just point to it multiple times. In our books analogy the EBO would be the order in which we have to read the books: eg. 1, 2, 3...

Another great example is using LEGOs:

The VBO is the pile of LEGO bricks (the actual vertices).
The EBO is the instruction sheet that says "Use brick #0, then #1, then #2, then #0 again to form a square."
This way you don't have to create four copies of the same corner brick - you just reuse it.

Why do we need EBOs?

Let's say you want to draw a rectangle using two triangles. Without an EBO, you'd need 6 vertices (because each triangle has 3 vertices)

Triangle 1: top right, bottom right, bottom left  
Triangle 2: top right, bottom left, top left

But notice: some vertices are repeated! With an EBO, you only store 4 unique vertices (the corners of the rectangle) in the VBO, and then let the EBO specify which ones to reuse.

Creating an EBO

Here's what it looks like in code:

unsigned int indices[] = {
    0, 1, 2,   // first triangle
    0, 2, 3    // second triangle
};

GLuint ebo;
glGenBuffers(1, &ebo);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo);
glBufferData(GL_ELEMENT_ARRAY_BUFFER, sizeof(indices), indices, GL_STATIC_DRAW);

This uploads the index data to the GPU, just like we did with the VBO. But notice something: we bind it to GL_ELEMENT_ARRAY_BUFFER, not GL_ARRAY_BUFFER.

The Magic of Binding EBOs and VAOs

Here's where EBOs really shine. When you bind an EBO while a VAO is active, the VAO remembers it. That means every time you bind the VAO later, the GPU knows which indices to use automatically.

glBindVertexArray(vao);
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ebo); // now VAO tracks the EBO

And when it's time to draw, you use glDrawElements() instead of glDrawArrays():

glBindVertexArray(vao);
glDrawElements(GL_TRIANGLES, 6, GL_UNSIGNED_INT, 0);

GL_TRIANGLES: draws triangles.
6: number of indices (not vertices!) to draw.
GL_UNSIGNED_INT: type of your indices.
0: starting offest in the index buffer.

Why EBOs matter

Memory savings - no need to duplicate vertex data.
Cleaner data - each unique vertex exists only once.
Easier updates - if you move one vertex, every triangle using it updates automatically.

🧩 And this is only the beginning — modern engines use multiple index buffers, different primitive types, and even GPU-driven rendering. We’ll dive into these advanced indexing techniques later on.

Without EBOs, you'd constantly waste space and bandwidth duplicating data. With EBOs, you're teaching the GPU how to reuse the building blocks you've already uploaded.

Common Mistakes & Myths

Even once you’ve read about VAOs, VBOs, and EBOs, there are a few traps almost everyone falls into:

❌ Mistake: Forgetting to enable attributes
- You might set up a glVertexAttribPointer, but forget glEnableVertexAttribArray. Result: nothing shows on screen, and you’ll waste hours debugging.
❌ Mistake: Mixing up stride and offset
- Stride is the total size of one vertex, not just the attribute. Offset is the position inside the vertex. Swapping them causes scrambled colors/geometry.
❌ Mistake: Binding order confusion
- Remember: the VAO must be bound before setting up your VBO and attributes. If you do it in the wrong order, the VAO won’t remember the configuration.
❌ Myth: You always need VAOs
- Technically, modern OpenGL core profile requires VAOs, but they don’t “store” vertex data. Beginners often think VAOs duplicate VBOs — they don’t. They only remember state.
❌ Myth: GL_STATIC_DRAW makes your data faster
- It’s just a hint to the driver, not a guarantee. Don’t stress over it in small projects.

Conclusion

VAOs, VBOs, and EBOs might look intimidating at first, but once you understand their roles, they fit together like puzzle pieces:

VBOs hold the raw vertex data.
VAOs describe how that data should be read and used in your shaders.
EBOs let you reuse vertices efficiently by storing indices.

Mastering these three isn't just about drawing a triangle - it's about learning how the GPU actually thinks. With this foundation, you're no longer blindly copying code from tutorials. You understand how the pieces interact, and that knowledge will carry over whether you're building a renderer, a game engine, or experimenting with advanced OpenGL features.

If this guide helped you and you'd like to support the deep research and hard work I put into simplifying complex material, you can buy me a coffee on Ko-fi. Every bit of support keeps me motivated to create more content like this. 🙌

Next Steps

Now that you understand VAOs, VBOs, and EBOs, you’ve unlocked the core building blocks of modern OpenGL. But don’t stop here:

Add colors – Expand your vertex data with (r, g, b) and see how attributes map to shaders.
Add texture coordinates – Learn how (u, v) pairs connect your mesh to images.
Render multiple objects – Practice creating multiple VAOs/VBOs, binding them in turn.
Experiment with dynamic data – Try GL_DYNAMIC_DRAW and update buffers with glBufferSubData or glMapBuffer.
Dive into performance – Research interleaved vs. separate attribute storage, or persistent mapping for real engines.

At this point, you’re not just following tutorials — you’re building the mental model you’ll need for rendering systems, game engines, and advanced OpenGL topics like instancing and UBOs.

DEV Community: D3Y4N

Want to refresh your knowledge on React Hooks, or even better - to learn few?

🪝 The Ultimate React Hooks Cheat Sheet (2025 Edition)

🪝 The Ultimate React Hooks Cheat Sheet (2025 Edition)

📑 Table of Contents

🟢 Basic Hooks (must-know)

useState - your mini storage box (or getters and setters without tons of boilerplate)

Usage API:

useEffect - sife effect manager.

Usage API:

useContext - no more prop-drilling pain

Usage API

⚡ Advanced Hooks (for optimization & complex state)

useReducer - the state machine

Usage API:

useCallback - memorized functions

Usage API:

useMemo - memorized values

Usage API:

useRef - the persistent box

Usage API:

useImperativeHandle - custom ref API

Usage API:

useLayoutEffect - sync effect

Usage API:

useDebugValue – dev tools helper

Usage API:

🧪 React 18+ Hooks (new & shiny)

useId – unique IDs without headaches

Usage API:

useTransition – smooth state updates

Usage API:

useDeferredValue - defer slow updates

Usage API:

useSyncExternalStore - safe external subscriptions

Usage API:

useInsertionEffect – style injection before paint

Usage API:

🛠️ Custom Hooks – your secret weapon

Usage API:

Example: useLocalStorage – state that survives refreshes

Wrap-Up – your React Hooks cheat sheet

If anybody is struggling to get into opengl...

The Definitive Guide to OpenGL VBOs, VAOs, and EBOs

The Definitive Guide to OpenGL VBOs, VAOs, and EBOs

Why do VAOs, VBOs, and EBOs Exist? (A Bit of History)

Vertex Buffer Objects (VBOs)

Why Binding Matters

Vertex Array Objects (VAOs)

Stride

Offset

Memory Layout & Performance: Interleaved vs. Separate Buffers

1. Interleaved attributes (common in real-time graphics)

2. Separate buffers per attribute (cleaner, flexible)

Why Attributes?

VAO State Tracking Gotchas

Element Buffer Objects (EBOs)

Why do we need EBOs?

Creating an EBO

The Magic of Binding EBOs and VAOs

Why EBOs matter

Common Mistakes & Myths

Conclusion

Next Steps

`useState` - your mini storage box (or getters and setters without tons of boilerplate)

`useEffect` - sife effect manager.

`useContext` - no more prop-drilling pain

`useReducer` - the state machine

`useCallback` - memorized functions

`useMemo` - memorized values

`useRef` - the persistent box

`useImperativeHandle` - custom ref API

`useLayoutEffect` - sync effect

`useDebugValue` – dev tools helper

`useId` – unique IDs without headaches

`useTransition` – smooth state updates

`useDeferredValue` - defer slow updates

`useSyncExternalStore` - safe external subscriptions

`useInsertionEffect` – style injection before paint

Example: `useLocalStorage` – state that survives refreshes