DEV Community: Sotheara

7 VS Code Settings That Actually Make You Faster

Sotheara — Thu, 16 Apr 2026 09:28:31 +0000

Most "VS Code tips" articles are really extension lists. This one isn't.

Extensions are great, but the built-in settings in VS Code are where most of the real productivity wins live — and most developers never touch them. They install VS Code, maybe change the theme, and use the defaults forever.

Here are seven settings that I turn on in every fresh VS Code install. Each one takes about 10 seconds to enable, and together they've saved me more time than any extension I've ever installed.

Where to find these: open Settings with Cmd + , (Mac) or Ctrl + , (Windows/Linux). You can either use the UI search bar at the top, or click the little {} icon in the top-right to edit settings.json directly. I'll give you the JSON version for each one because it's faster to copy.

1. Format on Save

"editor.formatOnSave": true

What it does: Every time you save a file, VS Code automatically formats it using your configured formatter (Prettier, Black, gofmt, whatever).

Why it's a big deal: You stop thinking about formatting entirely. No more half-indented blocks, no more inconsistent quotes, no more "oh I forgot a semicolon." Save the file and it's clean.

If you're working on a team, this also kills the most common source of noisy git diffs — formatting drift between contributors.

2. Auto Save

"files.autoSave": "onFocusChange"

What it does: Automatically saves your file when you click away from it (to the terminal, another file, your browser, anywhere).

Why it's a big deal: The tab-switch-to-browser-refresh-see-no-changes-go-back-and-save dance is one of those small frustrations you only notice once it's gone. With this on, you flip to your browser and the changes are already there.

I prefer onFocusChange over afterDelay because saves happen at predictable moments instead of randomly while you're mid-thought.

3. Bracket Pair Colorization

"editor.bracketPairColorization.enabled": true,
"editor.guides.bracketPairs": "active"

What it does: Matches brackets by color, so nested {}, [], and () stand out visually. The second setting adds a subtle vertical guide connecting each bracket pair.

Why it's a big deal: Reading deeply nested JavaScript or JSON becomes dramatically easier. You can tell at a glance whether you're inside the right block. This used to require an extension (Bracket Pair Colorizer), but VS Code now ships it natively.

4. Sticky Scroll

"editor.stickyScroll.enabled": true

What it does: Pins the current scope (function name, class, if block) to the top of the editor as you scroll.

Why it's a big deal: Ever scrolled 80 lines into a long function and forgotten which function you're in? This fixes that completely. The containing function name stays visible at the top of your editor, so context is always one glance away.

This is one of those settings you'll wonder how you lived without.

5. Word Wrap

"editor.wordWrap": "on"

What it does: Long lines wrap to the next visible line instead of scrolling horizontally.

Why it's a big deal: Horizontal scrolling is one of the worst inventions in software. With word wrap on, you can see all your code without reaching for your mouse. Some developers hate this on aesthetic grounds — try it for a week before deciding.

If you prefer wrapping only very long lines, use "editor.wordWrap": "bounded" with "editor.wordWrapColumn": 120.

6. Smart Renaming Across Files

"editor.linkedEditing": true

What it does: When you rename an opening HTML/JSX tag, the closing tag updates automatically in real time.

Why it's a big deal: Tiny, but you'll notice it constantly if you write React or HTML. Rename <div> to <section> and the closing tag changes as you type. No more forgotten mismatched tags.

Bonus: For actual symbol renaming across files (like renaming a function that's imported in 12 places), press F2 on the symbol. VS Code will rename every reference across your entire project. This has been in VS Code forever, and I meet senior developers who don't know about it.

7. Files You Actually Care About

"files.exclude": {
  "**/.git": true,
  "**/.DS_Store": true,
  "**/node_modules": true,
  "**/dist": true,
  "**/.next": true,
  "**/coverage": true
}

What it does: Hides these folders from the file explorer sidebar.

Why it's a big deal: Your file tree stops being 80% build artifacts and 20% your actual code. node_modules especially — if you've ever accidentally expanded it in the sidebar and watched VS Code freeze, you know why this matters.

Files are still there on disk. They just don't clutter your view.

Bonus: Two More Worth Knowing

These didn't make the top seven because they're more opinionated, but they're worth trying:

Render whitespace characters (helpful when debugging weird indentation issues):

"editor.renderWhitespace": "boundary"

Minimap off (more code, less distraction):

"editor.minimap.enabled": false

How to Apply All of These at Once

Open your settings.json (Cmd + Shift + P → "Preferences: Open User Settings (JSON)") and paste:

{
  "editor.formatOnSave": true,
  "files.autoSave": "onFocusChange",
  "editor.bracketPairColorization.enabled": true,
  "editor.guides.bracketPairs": "active",
  "editor.stickyScroll.enabled": true,
  "editor.wordWrap": "on",
  "editor.linkedEditing": true,
  "files.exclude": {
    "**/.git": true,
    "**/.DS_Store": true,
    "**/node_modules": true,
    "**/dist": true,
    "**/.next": true,
    "**/coverage": true
  }
}

Save the file. Done. Your VS Code is now measurably more pleasant to use.

The Takeaway

Productivity gains from tools are usually overstated — no editor setting will turn you into a 10x developer. But these aren't about being 10x faster. They're about removing the small, constant friction that adds up over a workday: forgotten saves, mismatched tags, scrolling to figure out what function you're in, staring at node_modules.

Remove enough small friction and you end the day with more energy for the actual hard problems.

Try these for a week. If any of them don't click for you, turn them off — no loyalty required. But I'd bet most of them end up permanent.

What's your go-to VS Code setting that didn't make my list? I'm always looking for new ones — drop yours in the comments.

var vs let vs const: Which Should You Actually Use in 2026?

Sotheara — Thu, 16 Apr 2026 09:15:48 +0000

If you've been learning JavaScript recently, you've probably seen all three of these in different tutorials:

var name = "Alice";
let name = "Alice";
const name = "Alice";

They all look like they do the same thing. They don't — and picking the wrong one can introduce bugs that are genuinely hard to track down.

Here's the short version, followed by the reasoning so you actually remember it:

Use const by default. Use let when you need to reassign. Never use var.

That's it. That's the rule. If you stop reading here and just follow it, your code will be better than about 60% of the JavaScript I see in the wild.

But let's look at why, because understanding the reasoning is how you stop second-guessing yourself at 2 a.m. debugging a scope bug.

What's Different About These Three?

Two things: scope and reassignability.

Scope

var is function-scoped. let and const are block-scoped.

This sounds like jargon until you see it bite:

function example() {
  if (true) {
    var x = 1;
    let y = 2;
  }
  console.log(x); // 1  — var leaks out of the if block
  console.log(y); // ReferenceError — let stays inside
}

var doesn't care about { } blocks. It only cares about functions. So variables declared with var inside an if, for, or while block leak out into the surrounding function. This is almost never what you want.

let and const respect { } blocks. They only exist inside the block they were declared in. This matches how every other modern language works, and how your brain probably already expects variables to work.

Reassignability

var and let can be reassigned. const cannot.

let count = 0;
count = 1; // fine

const PI = 3.14;
PI = 3.14159; // TypeError: Assignment to constant variable

This is the main reason people reach for let — "I need to change the value later." Fair. But most of the time, you actually don't.

Why `const` Should Be Your Default

Here's a habit that will quietly improve your code: assume const until proven otherwise.

Start with const. If you hit a moment where you genuinely need to reassign, change it to let. Most of the time, you won't need to.

Why this works:

1. const makes your code easier to read.

When I read const user = getUser(), I know that user refers to the same thing for the rest of this block. I don't have to scan the next 40 lines checking whether someone reassigned it. That's mental overhead I don't have to carry.

2. It catches bugs at write-time, not run-time.

If you try to reassign a const, your editor yells at you immediately. If you accidentally reassign a let somewhere, you don't find out until the program misbehaves.

3. It forces better function design.

A function that reassigns variables often wants to be broken into smaller functions that return values. Defaulting to const nudges you in that direction without you having to think about it.

"But const Doesn't Really Mean Constant, Right?"

Right — and this is the one gotcha worth mentioning.

const means the variable binding can't be reassigned. It does not mean the value is frozen.

const user = { name: "Alice" };
user.name = "Bob";     // works fine — we're mutating, not reassigning
user = { name: "Bob" }; // TypeError — this is reassignment

For objects and arrays, const only prevents you from pointing the variable at a different object. You can still modify the object's internals.

If you need true immutability, use Object.freeze() — but in 99% of day-to-day code, const does exactly what you want.

When to Actually Use `let`

There are legitimate cases. The most common ones:

1. Counters in loops (when not using for...of):

for (let i = 0; i < items.length; i++) {
  // i gets reassigned each iteration
}

2. Values that change based on conditions:

let message;
if (user.isAdmin) {
  message = "Welcome, admin";
} else {
  message = "Welcome";
}

Though honestly, even this example is cleaner as a ternary or a function:

const message = user.isAdmin ? "Welcome, admin" : "Welcome";

3. Accumulators in loops (though reduce is often better):

let total = 0;
for (const item of cart) {
  total += item.price;
}

That's about it. If you find yourself reaching for let frequently, it's worth pausing to ask whether a const with a cleaner expression would work.

Why Never `var`?

A few reasons, any of which is disqualifying on its own:

1. It leaks out of blocks (as we saw above)

2. It gets hoisted as undefined:

console.log(x); // undefined, not an error
var x = 5;

Compare to:

console.log(y); // ReferenceError — much better
let y = 5;

The let version fails loudly. The var version fails silently, and undefined propagates through your program until it causes a weird bug somewhere else.

3. You can redeclare it without errors:

var name = "Alice";
var name = "Bob"; // no error — fine

This means typos and copy-paste mistakes go undetected. let and const throw an error if you try to redeclare.

The only reason to ever write var today is if you're maintaining old code that already uses it. Even then, many teams run refactors to replace it.

A Quick Decision Flowchart

Next time you're about to declare a variable, ask yourself:

Will this value be reassigned? → If no, use const. (This will be true most of the time.)
Does it need to exist in this scope only? → Yes, use let.
Am I thinking about var? → Don't.

The One-Line Summary

Default to const. Reach for let when you need to reassign. Treat var as deprecated.

If you apply that single rule consistently for a week, you'll stop thinking about this question entirely — and your code will get cleaner as a side effect.

If you have a case where let or var is genuinely the right call and my rule of thumb breaks down, I'd love to hear about it in the comments. Those edge cases are usually where the most interesting JavaScript lives.

Understanding async/await in JavaScript: A Beginner's Guide With Real Examples

Sotheara — Thu, 16 Apr 2026 08:55:53 +0000

If you've been writing JavaScript for more than a few weeks, you've probably run into code that looks something like this:

getUser(userId, (err, user) => {
  if (err) return handleError(err);
  getPosts(user.id, (err, posts) => {
    if (err) return handleError(err);
    getComments(posts[0].id, (err, comments) => {
      if (err) return handleError(err);
      console.log(comments);
    });
  });
});

This is the infamous "callback hell" — and it's exactly the kind of code async/await was designed to replace.

In this guide, I'll walk through what async/await actually does, how to use it properly, and the pitfalls I kept running into when I was learning it. No theory dumps — just working code you can run.

What You'll Learn

What async and await actually do under the hood
How they compare to promises and callbacks
Five real examples you'll use in actual projects
The three mistakes that trip up almost every beginner

Prerequisites: you should know what a Promise is (roughly — "an object that represents a value that will exist later"). If you don't, read the first two paragraphs of MDN's Promise page and come back.

The Short Version

async/await is syntactic sugar over Promises. It doesn't add new capabilities to JavaScript — it just lets you write asynchronous code that looks synchronous.

Here's the callback mess from above, rewritten with async/await:

async function showComments(userId) {
  try {
    const user = await getUser(userId);
    const posts = await getPosts(user.id);
    const comments = await getComments(posts[0].id);
    console.log(comments);
  } catch (err) {
    handleError(err);
  }
}

Same logic, half the lines, readable top-to-bottom. That's the whole pitch.

How It Actually Works

Two keywords, two simple rules:

async — when you put this in front of a function, that function automatically returns a Promise. Even if you return 5, the caller receives Promise<5>.

await — you can only use this inside an async function. It pauses execution until the Promise on its right resolves, then gives you the resolved value.

async function getGreeting() {
  return "hello"; // This is actually Promise<"hello">
}

async function main() {
  const greeting = await getGreeting(); // Unwraps the promise
  console.log(greeting); // "hello"
}

main();

That's genuinely most of what you need to know. The rest is practice.

Example 1: Fetching Data From an API

This is where most people first encounter async/await. Here's a clean fetch call:

async function getUser(id) {
  const response = await fetch(`https://api.example.com/users/${id}`);

  if (!response.ok) {
    throw new Error(`Failed to fetch user: ${response.status}`);
  }

  const user = await response.json();
  return user;
}

// Using it:
async function main() {
  try {
    const user = await getUser(42);
    console.log(user.name);
  } catch (err) {
    console.error("Something went wrong:", err.message);
  }
}

main();

Notice await appears twice — once for the fetch itself (which returns a Promise of a Response), and once for .json() (which also returns a Promise). Both are promises, both need awaiting.

Example 2: Running Things in Parallel

Here's a mistake I made for months. Compare these two versions:

// Slow version — runs sequentially
async function getAllDataSlow() {
  const users = await fetchUsers();      // waits 1 second
  const posts = await fetchPosts();      // then waits another second
  const comments = await fetchComments(); // then waits another second
  return { users, posts, comments };      // total: ~3 seconds
}

// Fast version — runs in parallel
async function getAllDataFast() {
  const [users, posts, comments] = await Promise.all([
    fetchUsers(),
    fetchPosts(),
    fetchComments()
  ]);
  return { users, posts, comments }; // total: ~1 second
}

Rule of thumb: if the results don't depend on each other, use Promise.all. Using await on consecutive lines forces your code to wait unnecessarily.

Example 3: Handling Errors Properly

try/catch works with await exactly like it works with regular synchronous code, which is one of the best things about it:

async function saveUser(userData) {
  try {
    const validated = await validateUser(userData);
    const saved = await db.users.insert(validated);
    await sendWelcomeEmail(saved.email);
    return saved;
  } catch (err) {
    // This catches errors from ANY of the three awaits above
    console.error("Failed to save user:", err);
    throw err; // rethrow if the caller should handle it
  }
}

One catch block catches errors from any await inside the try. You don't need .catch() chains anymore.

Example 4: Awaiting in a Loop

This one trips up everyone. Say you want to process an array of items, calling an async function on each:

// This does NOT work the way you'd expect
async function processItems(items) {
  items.forEach(async (item) => {
    await processOne(item); // runs all at once, in no guaranteed order
  });
  console.log("Done!"); // this logs BEFORE any item finishes
}

forEach doesn't know about promises. It fires all the async callbacks without waiting. Use a regular for...of loop instead:

// Sequential — one at a time, in order
async function processItems(items) {
  for (const item of items) {
    await processOne(item);
  }
  console.log("Done!"); // now this logs after everything finishes
}

Or if order doesn't matter and you want speed:

// Parallel — all at once, wait for all to finish
async function processItems(items) {
  await Promise.all(items.map(item => processOne(item)));
  console.log("Done!");
}

Example 5: Mixing async/await with Regular Promises

You don't have to choose. These two do the same thing:

// Using await
async function getUserName(id) {
  const user = await getUser(id);
  return user.name;
}

// Using .then()
function getUserName(id) {
  return getUser(id).then(user => user.name);
}

Both return a Promise, both work fine. Use whichever is clearer for the situation. .then() is often nicer for a single transformation; await wins once you have two or more steps.

Three Mistakes I Kept Making

1. Forgetting await

async function main() {
  const user = getUser(1); // ❌ forgot await
  console.log(user.name);   // undefined — user is a Promise, not a user
}

If something is "undefined" when it shouldn't be, check for missing awaits first.

2. Using await outside an async function

function main() {
  const user = await getUser(1); // ❌ SyntaxError
}

await only works inside async functions. (Modern environments support top-level await in ES modules, but inside a regular function, you need async.)

3. Making every function async when it doesn't need to be

async function add(a, b) {
  return a + b; // ❌ no async needed — nothing is awaited
}

This works, but it wraps the result in a Promise for no reason. Only use async when you're actually awaiting something.

When to Use async/await vs. Promises

Honestly? Almost always use async/await now. It's cleaner, easier to debug (stack traces are more helpful), and the try/catch error handling is much more readable than .catch() chains.

Stick with .then() only when:

You're doing a single transformation and don't want the overhead of a function wrapper
You need Promise combinators like Promise.all, Promise.race, Promise.any (though these work fine with await too)

Wrapping Up

async/await looks intimidating, but once you understand the two rules — async functions return Promises, await unwraps them — most of the syntax falls into place.

The best way to learn it is to rewrite some of your callback or .then()-based code using async/await. You'll almost always end up with cleaner code, and the exercise makes the mental model stick.

A couple of things I didn't cover that are worth exploring next:

Top-level await in ES modules
AsyncIterators and for await...of for streaming data
AbortController for cancelling in-flight async operations

If you found this useful, I'm writing more pieces like this on JavaScript fundamentals. The best way to learn is to try the examples — copy any of the snippets above into your browser's console and play with them.

Thanks for reading. If you spotted an error or have a follow-up question, I'd love to hear it in the comments.