DEV Community: Muhammad Hamid Raza

VS Code Tips and Tricks That Will Seriously Boost Your Developer Experience

Muhammad Hamid Raza — Sat, 18 Apr 2026 17:05:31 +0000

You open VS Code, stare at your editor, and start typing. Same workflow, same shortcuts, same frustration when something takes longer than it should. Sound familiar? 😅

VS Code is probably the most popular code editor on the planet right now — and for good reason. It's fast, flexible, and packed with features. But most developers only use maybe 20% of what it actually offers. The other 80%? It's just sitting there, waiting to save you hours every week.

Whether you've been using VS Code for years or just installed it last week, there are always small tweaks and hidden features that make the experience feel smoother, faster, and honestly — a lot more enjoyable.

So here's the question: what if your editor could work for you instead of just being a window you type code into?

What Is "Developer Experience" in VS Code?

Developer experience (DX) is exactly what it sounds like — how enjoyable, efficient, and smooth your day-to-day coding feels.

Think of it like a kitchen. A good kitchen has everything in the right place. Your tools are sharp, the layout makes sense, and you can cook without bumping into stuff. A bad kitchen? You're hunting for utensils, the stove is too far from the sink, and somehow you always burn the pasta.

VS Code is your kitchen. The tips in this post help you organize it so everything is right where you need it.

Why This Matters for Everyday Development

Bad DX kills momentum. When your editor slows you down — slow search, messy file navigation, no snippets, zero shortcuts — you break your flow constantly.

And flow is everything in development. Once you lose it, getting it back takes time.

Improving your VS Code setup is not about being fancy. It's about removing friction. When your editor feels natural and responsive, you write better code, debug faster, and ship more confidently.

The Tips and Tricks That Actually Help 🚀

1. Master the Command Palette

Press Ctrl + Shift + P (or Cmd + Shift + P on Mac). That's it. That's your superpower.

The Command Palette gives you access to literally every VS Code feature — without touching your mouse. You can open settings, install extensions, run tasks, change themes, and more. If you're not using this daily, you're leaving speed on the table.

2. Use Multi-Cursor Editing

Need to rename the same variable in five places at once? Don't do it one by one like it's 2005.

Alt + Click (or Option + Click on Mac) to place multiple cursors wherever you want.
Ctrl + D to select the next occurrence of the highlighted word and edit them all at once.

This one trick alone can shave serious time off repetitive edits.

3. Open Files Instantly with Quick Open

Press Ctrl + P and start typing the filename. VS Code fuzzy-searches your project and opens it almost instantly.

No folder-diving. No sidebar scrolling. Just type and go. ⚡

4. Set Up a Good Font and Theme

This sounds cosmetic, but it genuinely affects how long you can comfortably code.

Fira Code and JetBrains Mono are developer favorites with built-in ligatures (those little symbols where => and !== look cleaner).
A good dark theme like One Dark Pro, Catppuccin, or Dracula Official reduces eye strain during long sessions.

Go to settings and enable "editor.fontLigatures": true if your font supports it.

5. Create and Use Code Snippets

If you type the same boilerplate code every day, it's time to automate it.

VS Code lets you create custom snippets. For example, you can type rfc and have it expand into a full React functional component skeleton instantly.

Go to File → Preferences → Configure User Snippets, pick your language, and add your own. It takes ten minutes to set up and saves you hours over time.

6. Split Editor and Work in Parallel

Press Ctrl + \ to split your editor into two panels. Now you can have your component file on the left and its CSS on the right. Or your frontend code and API response side by side.

This is one of those things that sounds small until you actually start using it every day. 👀

7. Use the Integrated Terminal Properly

You don't need to leave VS Code to run your commands. Press Ctrl + ` to open the integrated terminal.

Better yet — you can open multiple terminals at once using the + button in the terminal panel. One for your dev server, one for Git, one for npm commands. No more Alt-Tabbing between windows.

8. Enable Auto Save

Go to File → Auto Save and turn it on. Done.

You will never again lose changes because you forgot to hit Ctrl + S. It's one of the simplest but most underrated quality-of-life improvements in VS Code.

9. Use Peek Definition Instead of Jumping Around

Instead of opening a new file to check a function definition, press Alt + F12. VS Code shows the definition right inline without leaving your current file.

Use F12 if you actually want to navigate to it. Use Ctrl + Click for the same. But Peek is perfect when you just want a quick look.

10. Customize Keyboard Shortcuts

VS Code lets you remap any shortcut to whatever feels natural to you.

Go to File → Preferences → Keyboard Shortcuts and search for any action. If the default shortcut feels awkward, change it. Your setup should match you, not the other way around.

11. Use GitLens Extension for Better Git Workflows

GitLens is a free extension that supercharges the built-in Git features. It shows you who changed a line and when — right inside the editor, inline.

No more guessing who wrote that mysterious block of code. You'll know exactly when it was added and why (if the commit message was decent 😄).

12. Turn on Bracket Pair Colorization

Deeply nested code is hard to read. VS Code has a built-in feature that colors matching brackets differently so you can instantly see which bracket belongs to which block.

Enable it in settings:

"editor.bracketPairColorization.enabled": true

It's a small visual tweak that makes a real difference in readability.

13. Use Workspaces for Multi-Project Work

If you're working on multiple related repos, a VS Code Workspace lets you open all of them together in one window with shared settings.

Go to File → Save Workspace As and configure your folders. It keeps everything organized without opening a dozen separate windows.

14. Zen Mode for Deep Focus

Press Ctrl + K Z to enter Zen Mode. Everything disappears — sidebar, status bar, tabs. Just you and your code.

When you need to focus on a tricky problem without distractions, this mode is genuinely helpful.

Quick Comparison: Without vs. With These Tips

Situation	Without the Tips	With the Tips
Opening a file	Clicking through the sidebar	`Ctrl + P` and done in 1 second
Renaming a variable in 10 places	Edit one by one	Multi-cursor in seconds
Running terminal commands	Alt-Tab to a separate terminal	Integrated terminal in the same window
Checking a function definition	Navigating to a different file	Peek Definition inline
Tracking code changes	Guessing or checking Git log	GitLens shows it inline

Best Tips / Do's and Don'ts ✅

Do:

Take 10 minutes to set up custom snippets for your most-used code patterns.
Learn at least five keyboard shortcuts this week. Just five.
Install only the extensions you actually need. Don't hoard them.
Use the Command Palette when you don't know a shortcut — it teaches you shortcuts over time.
Keep your settings synced across machines using VS Code's built-in Settings Sync.

Don't:

Don't install 30 extensions and wonder why VS Code is slow.
Don't ignore the built-in features just because you haven't explored them.
Don't use your mouse for things a shortcut can do in one keystroke.
Don't skip font and theme setup — your eyes will thank you during late-night sessions.

Common Mistakes Developers Make with VS Code

Installing too many extensions
This is the number one performance killer. Every extension adds a little overhead. Install only what you use regularly. Review and uninstall the ones you haven't touched in months.

Never touching the settings
VS Code's default settings are okay, but they're not optimized for you. Spending 15 minutes in settings.json can dramatically improve your experience. Things like tab size, word wrap, format on save — these matter daily.

Ignoring keyboard shortcuts
Developers who rely entirely on their mouse spend significantly more time on repetitive tasks. You don't need to memorize every shortcut. Start with the ten most useful ones and build from there.

Not using version control inside VS Code
The built-in Source Control panel is actually great. Many beginners jump out to a separate Git client when VS Code already handles staging, committing, and branching quite well.

Not syncing settings across devices
If you work on multiple machines and you're not using Settings Sync, you're setting up VS Code from scratch every time. Turn it on under Accounts → Settings Sync and save yourself the hassle.

Wrapping Up 💡

VS Code is already a great editor. But with the right setup, it becomes your editor — one that matches how you think and work.

You don't need to implement all of these today. Pick three things from this list, try them for a week, and see how they feel. Then add more when you're ready.

The goal isn't to become a VS Code power user overnight. The goal is to slowly remove the little friction points that interrupt your flow — until coding feels genuinely smooth and enjoyable.

Because when your tools feel good, your work feels good too.

If you found this helpful, there's a lot more where this came from. Check out more dev tips, tools breakdowns, and tutorials at hamidrazadev.com — a blog built specifically for developers who want to keep leveling up.

Share this post with a developer friend who's still clicking through their sidebar one folder at a time 😄. And if you've got a VS Code tip that changed your workflow, drop it in the comments — let's build the list together.

From BSOD to Dev Workstation: How I Rebuilt My PC the Right Way (And Learned a Ton Doing It)

Muhammad Hamid Raza — Fri, 17 Apr 2026 04:53:22 +0000

You know that feeling when your computer is stuck in a loop, crashing over and over, and you're sitting there thinking "why does this exist"? 😤

Yeah. That was me. Blue screen. Reboot. Blue screen. Reboot. A cycle of pure suffering.

But here's the thing — that disaster turned into one of the best learning experiences I've had as a developer. I went from crying over a broken machine to understanding system architecture, disk management, and package management like a proper engineer.

If you've ever been in that situation — or if you just want to know how to set up a clean, resilient developer workstation from scratch — this one's for you.

What Actually Happened (Phase 1: The Patched Nightmare)

My HP Compaq was stuck in a BSOD loop. The culprit? A "patched" version of Windows 11 that someone had modified to bypass hardware checks.

It seemed smart at the time. Skip the TPM requirements, skip the Secure Boot checks, save time. Right?

Wrong.

Every install attempt crashed with ACPI.sys errors. Then came the real gut punch: error 0x80070570 — which basically means the install files themselves were corrupt. The "shortcut" version of Windows was actually a ticking time bomb.

Here's the lesson I didn't know I needed:

Patched or modified Windows installers are not shortcuts. They are the longest, most painful road to failure.

The files are corrupt. The registry gets messy. Drivers behave weirdly. And you will spend 10x more time debugging than you would have spent just doing it right from the start.

The Turning Point (Phase 2: The Senior Dev Rebuild)

We stopped chasing quick fixes and decided to do it properly. This is where things actually started moving forward.

Step 1: Get a legitimate Windows ISO

Downloaded a clean Windows 11 ISO directly from Microsoft. No torrents. No "activator" versions. Just the real thing.

Step 2: Use Rufus the right way

Rufus is a free tool that creates bootable USB drives. But the real magic? It can bypass TPM 2.0 and Secure Boot requirements for older machines — legally and cleanly, without touching the installer itself.

For older hardware like HP Compaq machines, this is a lifesaver. Rufus handles the bypass at the image level, so the installed Windows stays clean and stable.

Step 3: The nuclear option — diskpart

This was the most important step. Before installing Windows, I booted into the installer, opened Command Prompt with Shift + F10, and ran:

diskpart
list disk
select disk 0
clean

The clean command wiped everything off the SSD. Every partition. Every trace of the patched version.

Starting with a completely clean disk meant no leftover corrupt files, no ghost partitions, no weird driver conflicts. It felt scary at first, but it was exactly the right call.

Why a Clean Install Matters More Than You Think

A lot of people upgrade Windows over an existing install, or they let a patched version "update" itself. Here's why that's a problem:

Corrupt files carry over. Old errors don't disappear — they just hide.
Driver conflicts build up. Especially on HP machines with specific hardware.
The registry becomes a mess. Unused entries stack up and slow everything down.
Security holes stay open. Patched installs often disable Windows Defender and other protections silently.

A clean slate isn't just about speed. It's about having a system you can actually trust.

Victory and Optimization (Phase 3: Building the Dev Setup)

Once Windows was installed cleanly, the real work began. A fresh Windows install is just a starting point — not a workstation.

🖥️ Drivers: Do It Manually

The first instinct after a fresh install is to grab something like Driver Booster and let it "auto-install everything." Don't.

Third-party driver tools are notorious for installing outdated or generic drivers that cause more problems than they solve. Instead:

Find your exact hardware model (HP Compaq with Intel HD Graphics 2500 in this case).
Go to Intel's official website or the HP support page.
Download the exact driver for your hardware and Windows version.

After installing the correct Intel HD Graphics 2500 driver manually, the GPU correctly recognized 1.7GB of shared memory — which matters a lot for design work and running modern web UIs smoothly.

⚡ PowerShell 7 + Chocolatey

This is where things got genuinely fun.

PowerShell 7 is a massive upgrade from the default Windows PowerShell. It's cross-platform, faster, and far more capable.

Chocolatey (choco) is a package manager for Windows — think of it like apt on Linux or brew on macOS. Instead of clicking through installer wizards, you install software with a single command:

choco install nodejs-lts
choco install git
choco install vscode

Done. Clean. No random checkboxes offering you browser toolbars. No manual updates. Just software installed the way developers like it.

This is one of those tools that, once you start using it, you wonder how you ever lived without it.

✅ Official Installs Only

VS Code and Chrome were installed through their official installers (or Chocolatey), not through sketchy third-party sites. This keeps the Windows registry clean and ensures you're getting the actual software without bundled garbage.

The Recovery Plan: Lahore-Proofing Your Machine 🛡️

Here's something nobody talks about in Western developer tutorials: load shedding is real, and it will corrupt your Windows install if you're not careful.

A sudden power cut during a Windows update, a driver install, or even just heavy disk activity can corrupt system files. I've seen it happen. So we built a three-layer protection plan.

Layer 1: System Restore Point

A System Restore Point is your "Undo" button. If something breaks after a driver install or a Windows update, you can roll back to this exact moment without losing your files.

How to create one:

Search for "Create a restore point" in the Start menu.
Select your C: drive and click "Configure" → "Turn on system protection."
Click "Create" and give it a name like "Fresh Setup - Clean Install."

Do this right after every major change to your system.

Layer 2: System Image Backup

A System Restore Point is great for small issues. But if your SSD completely fails or gets corrupted beyond repair, you need a full backup.

A System Image copies your entire C: drive — Windows, drivers, installed software, settings — onto another drive. Think of it as your "Insurance Policy."

How to create one:

Go to Control Panel → Backup and Restore (Windows 7).
Click "Create a system image."
Save it to your 250GB HDD (external or secondary drive).

If disaster strikes, you can restore the entire system from this image in minutes instead of hours.

Layer 3: Cloud and GitHub Sync

No matter how good your local backups are, they're useless if the whole machine is stolen, flooded, or physically destroyed.

For a Next.js developer with active projects:

GitHub for all code. Push regularly. Use private repos for sensitive projects.
Google Drive or OneDrive for ICS notes, PDFs, and documents.
VS Code Settings Sync (built-in) to back up your extensions and editor config.

These three layers mean you can lose the entire machine and be back to full productivity within an hour.

Key Lessons That Actually Stick

Let's be honest — the best lessons come from the worst experiences. Here's what this whole journey taught me:

💡 Shortcuts usually cost you more time, not less. The patched Windows was supposed to save 20 minutes. It cost days of debugging.

💡 Clean installs are non-negotiable. If something is deeply broken, wipe it and start fresh. Fighting corrupt systems is a losing battle.

💡 Manual driver installs beat auto-driver tools. Know your hardware. Install only what you need, from the official source.

💡 Package managers are a superpower. Once you start managing software through Chocolatey (or winget), you'll never go back to clicking through wizard installers.

💡 Backups are not optional. Especially if you're working in an area with unstable power. One bad outage can ruin weeks of work.

💡 The "right way" isn't the hard way. It just feels harder at the start because it's unfamiliar. But it saves you from exponentially bigger problems later.

Common Mistakes People Make During Windows Setup

These are the traps that catch most beginners — and some experienced people too:

❌ Using modified or "lite" Windows ISOs. They corrupt easily, disable security features, and cause random driver issues. Always use official ISOs.

❌ Skipping the disk clean before install. Leftover partitions and old files cause weird conflicts. Use diskpart clean for a true fresh start.

❌ Installing every driver with Driver Booster or similar tools. These tools inject outdated and generic drivers. Install manually from official sources.

❌ Skipping system backups because "nothing has gone wrong yet." That's exactly when disasters happen — before you're prepared.

❌ Installing random software from unverified sites. Your registry fills up, startup times increase, and security risks multiply. Use Chocolatey, winget, or official sites only.

❌ Not setting up cloud sync for active projects. Local backups are great, but they don't protect against hardware failure or theft. GitHub is free. Use it.

Conclusion

What started as a total disaster — a BSOD loop, corrupt files, and a lot of frustrated emojis — turned into a genuinely valuable learning experience.

The machine that once couldn't even boot is now a clean, fast, developer-ready workstation. It has proper drivers, a modern terminal, a package manager, and three layers of backup protection built specifically for the power grid realities of Lahore.

More importantly, the process taught something that no tutorial can rush: understanding why each step matters, not just following instructions blindly.

If your machine is acting up, or if you just want to set up a clean developer environment from scratch, follow the process above. It's not glamorous, but it works — and you'll understand your own system far better for it. 🔧

Want more practical, no-fluff developer content? Check out hamidrazadev.com for more posts like this. And if this helped you, feel free to share it — there's definitely another developer out there stuck in a BSOD loop who needs it. 🚀

OpenRouter vs Hugging Face: Which One Should You Actually Use?

Muhammad Hamid Raza — Mon, 13 Apr 2026 07:53:31 +0000

So you've been exploring AI tools, and now you're staring at two names that keep showing up everywhere — OpenRouter and Hugging Face. Both sound important. Both involve AI models. And both have enough features to make your head spin if you try to compare them too fast.

Here's the thing though: asking "which one is better" is like asking whether a highway is better than a factory. They're not really competing — they're doing different jobs. But once you understand what each one does, the choice becomes obvious. 😊

Let's break it all down.

What Is OpenRouter?

OpenRouter is essentially a universal API gateway for AI models. Think of it like a single remote control that works with every TV in the house.

Instead of signing up for OpenAI, then Anthropic, then Google, then managing three different API keys, three billing dashboards, and three different code setups — you just use OpenRouter. One API key. One endpoint. Access to models from all of them.

It uses an OpenAI-compatible API format, which means if you've already written code for GPT-4, switching to Claude or Gemini is just a one-line change.

It also has a handy Playground where you can send the same prompt to multiple models at once and compare their responses side by side in real time. That alone saves hours of manual testing.

What Is Hugging Face?

Hugging Face is something much bigger — it's the GitHub of AI models.

It hosts hundreds of thousands of pre-trained models for text, images, audio, and more. It has community discussions, leaderboards, trending models, research papers, and even compute options for running your own models. It's where developers go to find, explore, test, and download AI models.

It also provides tools like the Transformers library (one of the most popular ML libraries in the world), datasets, model training notebooks, and infrastructure for deploying your own models.

If you want to explore the open-source AI ecosystem — Llama variants, Qwen, DeepSeek, fine-tuned niche models — Hugging Face is where you go first.

Why This Comparison Actually Matters

If you're a developer building an AI-powered app, this decision affects three things directly:

How fast you ship — Managing multiple API integrations slows you down.
How much you spend — Model costs vary wildly across providers.
How much control you have — Some use cases need open-source models you can self-host.

Getting this right early saves you from painful refactors later. 🔧

Key Differences: OpenRouter vs Hugging Face

Feature	OpenRouter	Hugging Face
Primary purpose	Multi-model API gateway	Model hub & ML ecosystem
Model access	Frontier models (GPT, Claude, Gemini, etc.)	Open-source & community models
API support	Yes, OpenAI-compatible	Yes, Inference API + Endpoints
Free tier	Yes (limited credits)	Yes (free Inference API)
Self-hosting	No	Yes (download & run locally)
Community & research	No	Very active
Best for	App developers, API users	Researchers, ML engineers

Benefits With Real-Life Examples

✅ OpenRouter — Great for App Developers

One API for everything — Building a chatbot? You can start with a free open-source model, then upgrade to Claude or GPT-4 for production, all without touching your codebase.
Cost optimization — OpenRouter lets you route to the cheapest provider that meets your latency requirements. Great when you're running thousands of API calls per day.
Side-by-side model testing — Use the Playground to compare Claude 3 vs Gemini 1.5 vs Mistral on your exact use case before committing.
Minimal setup — If you already know the OpenAI SDK, you're basically already set up.

✅ Hugging Face — Great for ML Engineers & Researchers

Model discovery — Need a small, fast embedding model? A specialized medical NLP model? There are thousands of community-trained models waiting.
Open-source freedom — Download the model, run it on your own server, modify it, fine-tune it. Full control.
Transformers library — One of the most used libraries in ML. Works with PyTorch and TensorFlow. Makes loading and running models simple.
Inference Endpoints — Don't want to manage GPU servers yourself? Hugging Face lets you deploy a model with dedicated compute, priced per hour.

OpenRouter vs Hugging Face: When to Use Which

Here's the honest, practical breakdown:

Use OpenRouter when:

You're building an app and need quick, flexible access to frontier models
You want to switch between GPT, Claude, Gemini, and others without code changes
You want cost routing and don't want to manage multiple billing accounts
You just need a reliable API and don't care about the underlying infrastructure

Use Hugging Face when:

You want to explore or download open-source models
You're doing ML research or model fine-tuning
You need a specialized model (text classification, image captioning, speech-to-text, etc.)
You want full control over the model and your data
You're building ML pipelines using the Transformers or Datasets libraries

Use both when:

You want to browse and pick a model on Hugging Face, then deploy it via an Inference Endpoint or run it locally with Ollama — while also using OpenRouter to access frontier models in the same app.

This is actually a very common setup in 2026. They complement each other well.

Tips for Making the Right Choice

💡 Start with your use case, not the tool. Are you calling AI for text generation in an app? OpenRouter. Training or exploring models? Hugging Face.

💡 Don't overcomplicate early on. If you're building your first AI feature, OpenRouter's simplicity wins. Get the app working first.

💡 Check the free tiers first. Both platforms have free usage. Test before you commit money.

💡 Think about data privacy. If your data is sensitive, open-source models on Hugging Face (run locally) keep data off third-party servers. OpenRouter routes through provider APIs, so understand the data policies of each model.

💡 Use the Playground. OpenRouter's side-by-side model testing is genuinely useful when you're trying to pick the right model for a task.

Common Mistakes Developers Make

❌ Treating them as direct competitors
They're not. One is an API layer, the other is a model ecosystem. You can absolutely use both.

❌ Using Hugging Face's free Inference API in production
The free API tier on Hugging Face is for testing, not production workloads. It has rate limits and no uptime guarantees. If you're shipping a product, use Inference Endpoints or a proper provider.

❌ Assuming OpenRouter hosts its own models
It doesn't. OpenRouter is a routing layer — it sends your requests to the actual model providers (OpenAI, Anthropic, Google, etc.). The performance and output you get is from those underlying providers.

❌ Ignoring costs
Model pricing varies a lot across providers. OpenRouter makes this visible and comparable, which is genuinely useful. Always check the pricing page before picking a model for a high-volume use case.

❌ Not reading the model card on Hugging Face
Every model on Hugging Face has a model card explaining its intended use, limitations, and training data. Skipping it is a mistake, especially if you're picking a model for a specific industry or sensitive use case.

Final Verdict

So — which is better?

Neither. And both. It depends entirely on what you're trying to do.

OpenRouter is your best friend if you're a developer who wants fast, flexible, low-maintenance access to top AI models through a single API. It's clean, practical, and built for shipping.

Hugging Face is your best friend if you want to explore, experiment, research, or run open-source models with full control. It's the world's largest AI model community, and there's nothing else quite like it.

Most experienced developers end up using both — OpenRouter for production API calls, Hugging Face for model discovery and open-source experimentation.

Start with the one that fits your current project. You'll probably end up using both eventually. 🚀

If this helped you think more clearly about your AI tooling setup, check out more practical developer guides at hamidrazadev.com. There's always something useful brewing there. 😊

How to Use Claude Code with OpenRouter — Run Any AI Model for Free or Cheap 🚀

Muhammad Hamid Raza — Sun, 12 Apr 2026 07:37:25 +0000

Ever wished you could use Claude Code with models other than just the official Anthropic ones? Maybe you want to try a powerful free model, cut costs, or experiment with something new like NVIDIA's Nemotron?

Good news — it's totally possible. Claude Code supports custom API base URLs, which means you can point it to OpenRouter and instantly unlock access to dozens of AI models, including free ones. 💡

In this guide, I'll walk you through the complete setup on Windows, macOS, and Linux — step by step, no fluff.

What Is OpenRouter?

OpenRouter is a unified API gateway that gives you access to many AI models — from OpenAI and Anthropic to Google, Meta, Mistral, NVIDIA, and more — all through a single API endpoint.

Think of it like a TV remote that controls every streaming platform. Instead of managing separate API keys for each provider, you get one key that works everywhere.

Some models on OpenRouter are completely free. Others cost a fraction of what you'd pay directly. It's a great way to experiment without burning through credits.

Why Use Claude Code with OpenRouter?

Claude Code is a powerful AI coding assistant that runs in your terminal. By default, it talks directly to Anthropic's API. But since it supports environment variable overrides, you can redirect it to any OpenAI-compatible endpoint — including OpenRouter.

Reasons you might want to do this:

💸 You want to use a free model to save money
🧪 You want to experiment with different models for different tasks
🌐 You already have OpenRouter credits and don't want to maintain two separate accounts
⚡ You want to try newer open-source models like NVIDIA Nemotron, Llama, Qwen, etc.

What You'll Need

Before we start, make sure you have:

✅ Claude Code installed — via npm install -g @anthropic-ai/claude-code
✅ An OpenRouter account — sign up free at openrouter.ai
✅ Your OpenRouter API key — get it from the OpenRouter dashboard under "API Keys"
✅ A model name from OpenRouter you want to use (e.g., nvidia/nemotron-3-super-120b-a12b:free)

Where Is the Settings File?

Claude Code reads its configuration from a settings.json file. Here's where to find it depending on your OS:

Operating System	Settings File Path
Windows	`C:\Users\<YourUsername>\.claude\settings.json`
macOS	`~/.claude/settings.json`
Linux	`~/.claude/settings.json`

If the file doesn't exist yet, just create it. Claude Code will pick it up automatically.

Step-by-Step Setup

🪟 Windows

Step 1: Open File Explorer and navigate to:

C:\Users\<YourUsername>\.claude\

Replace <YourUsername> with your actual Windows username.

Step 2: If the .claude folder doesn't exist, create it manually.

Step 3: Inside that folder, open or create settings.json using Notepad or VS Code.

Step 4: Paste the following configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "your-openrouter-api-key-here",
    "ANTHROPIC_API_KEY": "",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "nvidia/nemotron-3-super-120b-a12b:free"
  }
}

Step 5: Replace your-openrouter-api-key-here with your actual OpenRouter API key.

Step 6: Save the file and open a new terminal. Run:

claude

You're done! 🎉

🍎 macOS

Step 1: Open Terminal.

Step 2: Navigate to the .claude folder:

cd ~/.claude

If it doesn't exist yet, create it:

mkdir -p ~/.claude

Step 3: Open or create the settings file using your preferred editor:

nano ~/.claude/settings.json
# or
code ~/.claude/settings.json

Step 4: Paste this configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "your-openrouter-api-key-here",
    "ANTHROPIC_API_KEY": "",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "nvidia/nemotron-3-super-120b-a12b:free"
  }
}

Step 5: Replace your-openrouter-api-key-here with your real key.

Step 6: Save and close. Then open a new terminal window and run:

claude

That's it for macOS! 🍏

🐧 Linux

Step 1: Open your terminal.

Step 2: Navigate to (or create) the .claude directory:

mkdir -p ~/.claude && cd ~/.claude

Step 3: Create or edit the settings file:

nano ~/.claude/settings.json
# or
vim ~/.claude/settings.json

Step 4: Paste the configuration:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
    "ANTHROPIC_AUTH_TOKEN": "your-openrouter-api-key-here",
    "ANTHROPIC_API_KEY": "",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "nvidia/nemotron-3-super-120b-a12b:free"
  }
}

Step 5: Replace the API key placeholder with your real OpenRouter key.

Step 6: Save the file. Open a fresh terminal session and run:

claude

Linux users, you're set! 🐧

Understanding the Configuration Fields

Here's what each field in the config actually does:

Field	Purpose
`ANTHROPIC_BASE_URL`	Tells Claude Code to use OpenRouter's API instead of Anthropic's
`ANTHROPIC_AUTH_TOKEN`	Your OpenRouter API key used for authentication
`ANTHROPIC_API_KEY`	Left empty intentionally — OpenRouter handles auth via the token
`ANTHROPIC_DEFAULT_SONNET_MODEL`	The model you want Claude Code to use by default

The ANTHROPIC_DEFAULT_SONNET_MODEL field is where the magic happens. Change this to any model ID from OpenRouter's model list and Claude Code will use it.

How to Find Model IDs on OpenRouter

Go to openrouter.ai/models
Browse or search for the model you want
Click on it to see the model ID
Copy the full model string (e.g., meta-llama/llama-3.3-70b-instruct:free)
Paste it as the value of ANTHROPIC_DEFAULT_SONNET_MODEL

Models with :free at the end are completely free to use — no credits needed. 👀

Pros and Cons

✅ Advantages of Using Claude Code with OpenRouter

Access to free models — great for learning and experimenting
One API key for many models
Flexibility to switch models without reinstalling anything
Works with open-source models that Anthropic doesn't offer
Useful if you're on a budget but still want powerful coding assistance

⚠️ Things to Be Aware Of

Not every OpenRouter model is as capable as Claude Sonnet or Opus
Free models sometimes have rate limits or slower response times
Some models may not follow Claude Code's system prompts as precisely
If the model doesn't support tool use well, Claude Code's agentic features may behave unexpectedly

Best Tips

✅ Do this:

Always test your setup with a simple prompt first before using it on a real project
Use free models for low-stakes tasks like drafting, explaining code, or answering questions
Keep your API key private — never commit settings.json to a public Git repo
Check the OpenRouter model card for context window size before using a model on large codebases

❌ Avoid this:

Don't leave your real API key in shared machines or public repositories
Don't assume every model will behave exactly like Claude — each model has its own strengths and quirks
Don't set ANTHROPIC_API_KEY to your actual Anthropic key when using OpenRouter — it's not needed and might cause confusion

Common Mistakes People Make

1. Wrong API base URL format

Some people accidentally set the URL to https://openrouter.ai/api/v1. The correct value is https://openrouter.ai/api — Claude Code appends /v1/messages automatically.

2. Leaving the model name blank or wrong

If ANTHROPIC_DEFAULT_SONNET_MODEL is missing or has a typo, Claude Code may fall back to an unexpected default or throw an error. Always double-check the model ID from OpenRouter's model list.

3. Using an expired or invalid API key

OpenRouter keys are easy to rotate. If Claude Code starts returning auth errors, go to your OpenRouter dashboard and create a fresh API key.

4. Not restarting the terminal

Settings are read when Claude Code starts. If you edit settings.json while Claude Code is running, the changes won't apply until you restart your terminal.

5. Committing the settings file to Git

This one hurts. Your settings.json contains your API key. Add .claude/ to your .gitignore to avoid accidentally pushing it to a public repository.

Conclusion

Setting up Claude Code with OpenRouter is genuinely simple once you know where the settings file lives. A few lines of JSON and you unlock access to a wide range of AI models — including free ones — all from your existing terminal workflow.

Whether you're on Windows, macOS, or Linux, the process is essentially the same: find the settings file, drop in the config, and you're good to go. 🔧

The best part? You can switch models anytime just by changing one line. That kind of flexibility is rare and genuinely useful for anyone who codes with AI tools regularly.

If this guide helped you, I'd love it if you shared it with a fellow developer who's been curious about Claude Code but didn't want to deal with API costs. And if you're looking for more practical dev guides like this, check out 👉 hamidrazadev.com — there's a lot more where this came from.

Happy coding! 😊

WSL Explained: Why Windows Developers Are Obsessed With It 🐧

Muhammad Hamid Raza — Fri, 10 Apr 2026 16:56:16 +0000

Have you ever been a Windows user who secretly envied Linux developers? You know — the ones who casually run a one-liner in the terminal and get everything working in seconds while you're still fighting with PATH variables and permission errors?

That was the daily reality for a lot of Windows developers. Until WSL came along and changed everything.

WSL — short for Windows Subsystem for Linux — is one of the most genuinely useful tools Microsoft has shipped in years. It lets you run a full Linux environment directly inside Windows, no dual-boot, no virtual machine, no hassle.

So what exactly is it? Why should you care? And is it really as helpful as people say?

Let's find out. 👇

What Is WSL?

Think of WSL as a translation layer built into Windows. It lets your Windows machine speak "Linux" fluently.

Here's a simple way to think about it: imagine you're in an English-speaking office, but your best collaborator speaks French. Instead of flying to France or hiring a full-time translator (that's a VM), you install a small translation app on your computer (that's WSL). Now you can communicate instantly without switching desks.

WSL does the same thing for your system. You can open a terminal, type Linux commands, run Linux tools, and work with Linux file systems — all without leaving Windows.

There are two versions:

WSL 1 — the original, which translates Linux calls into Windows calls
WSL 2 — the current version, which runs a real Linux kernel inside a lightweight virtual machine. It's faster, more compatible, and what most people use today

You can install popular distros like Ubuntu, Debian, Kali Linux, or Fedora directly from the Microsoft Store.

Why WSL Matters for Developers

Here's a real situation many Windows developers have faced:

You're following a tutorial. The instructor is on macOS or Linux. They run a command. It works perfectly. You try the same command on Windows. Error. You try the Windows equivalent. Different error. You spend 45 minutes on Stack Overflow. You feel like giving up.

WSL fixes that.

Most open-source tools, frameworks, and documentation are written with Linux/macOS in mind. Bash scripts, package managers like apt, native Node.js and Python setups, Docker, and backend development workflows all behave much more smoothly on Linux.

With WSL, you get that same smooth experience without leaving Windows. Your files, apps, and everything else stay exactly where they are.

Benefits of WSL with Real-Life Examples

✅ Run Linux Commands on Windows

Before WSL, running grep, sed, awk, or shell scripts on Windows required workarounds or third-party tools. Now you just open your Ubuntu terminal in WSL and type them directly.

Example: A developer automating file renaming across hundreds of files uses a simple Bash one-liner that would take a full PowerShell script to replicate.

✅ No Dual-Boot Headaches

Setting up dual boot is time-consuming, risky, and annoying to manage. You have to restart your machine every time you want to switch. WSL eliminates that entirely.

Example: A student learning Linux commands for a university course uses WSL on their Windows laptop without ever partitioning their hard drive.

✅ Use Linux Dev Tools Natively

Tools like make, gcc, curl, git, vim, and dozens of others work out of the box in WSL. No emulation, no compatibility layer workarounds.

Example: A backend developer compiles a C++ project using g++ inside WSL the same way it would work on a Linux server in production.

✅ Faster and Lighter Than a Virtual Machine

Running a full VM like VirtualBox or VMware takes a lot of RAM and CPU. WSL 2 uses a lightweight virtual machine that starts in seconds and uses a fraction of the resources.

Example: A developer on a mid-range laptop who previously crashed their VM regularly now runs WSL without any performance issues.

✅ Seamless File Access Between Windows and Linux

With WSL, you can access your Windows files from Linux and your Linux files from Windows Explorer. Both systems talk to each other comfortably.

Example: You write code in VS Code on Windows, and that code lives in your Linux file system via WSL. Both sides see it perfectly.

✅ Works Great With VS Code

With the Remote - WSL extension in VS Code, you can open a WSL folder in VS Code as if it were a native Linux environment. The editor runs on Windows but the code runs in Linux.

Example: A full-stack developer uses VS Code on Windows with a Node.js project inside WSL. It feels exactly like working on a Linux machine.

✅ Docker Integration

Docker Desktop on Windows integrates directly with WSL 2. This means containers run faster and more reliably compared to the old Hyper-V backend.

Example: A developer running a multi-container app with Docker Compose sees noticeably faster build times after switching to the WSL 2 backend.

WSL vs Full Virtual Machine — What's the Difference?

Feature	WSL 2	Full VM (VirtualBox / VMware)
Startup time	Seconds	Minutes
RAM usage	Low	High
File access	Shared with Windows	Separate disk
Installation	Simple (one command)	Manual setup needed
Performance	Near-native	Slower
GUI support	Supported (WSLg)	Full GUI always
Best for	Dev work, CLI tools	Full isolated environments

For most developers doing everyday development work, WSL 2 wins easily. A full VM is still useful when you need a completely isolated environment, but for coding, scripts, and tools, WSL is the better choice.

Best Tips for Using WSL

💡 Use WSL 2, not WSL 1. WSL 2 has better file I/O performance, full system call compatibility, and Docker support. Always prefer it.

💡 Store your project files inside the Linux file system. When you keep files at /home/yourname/projects instead of /mnt/c/Users/..., file operations are significantly faster.

💡 Install the VS Code Remote - WSL extension. It makes working inside WSL feel completely native and comfortable.

💡 Use Windows Terminal. It's clean, fast, and supports multiple tabs including WSL sessions alongside PowerShell and CMD.

💡 Learn basic Bash. Even a small amount of Bash knowledge unlocks a lot of productivity inside WSL.

💡 Do: Run your dev servers, scripts, and build tools inside WSL for better compatibility.

🚫 Don't: Edit files stored in WSL using Windows Explorer directly. Use a proper editor with WSL integration to avoid permission issues.

🚫 Don't: Install WSL 1 unless you have a very specific reason. WSL 2 is almost always the better option.

Common Mistakes People Make With WSL

1. Storing project files on the Windows side

Many beginners put their projects in C:\Users\... and then access them from WSL via /mnt/c/.... This works, but it's slow. The cross-filesystem access between Windows and Linux has overhead.

Fix: Move your projects into the Linux file system (/home/username/) for much better performance.

2. Forgetting to set WSL 2 as default

After installing WSL, some people skip setting the default version to WSL 2 and end up running WSL 1 without realizing it.

Fix: Run this command once after installation:

wsl --set-default-version 2

3. Running GUI-heavy workflows without WSLg

Before WSLg (the GUI support layer), Linux GUI apps didn't work inside WSL. Some people still expect this limitation and miss out.

Fix: WSL 2 on recent versions of Windows 11 supports GUI Linux apps natively via WSLg. Just make sure your Windows is up to date.

4. Not using Windows Terminal

Opening WSL through the old Command Prompt window is not a great experience. Some users stick with it and wonder why things feel clunky.

Fix: Install Windows Terminal from the Microsoft Store. It is free, fast, and makes the whole experience far more enjoyable.

5. Treating WSL like a toy

Some people install WSL, run a few commands, and then forget about it. They miss the real value.

Fix: Actually build something with it. Run a server, set up a project, use Docker. Once you feel the difference in your actual workflow, you won't go back.

Conclusion

WSL is one of the best tools a Windows developer can have in their setup today. It closes the gap between Windows and Linux development without making you choose between them.

You get Linux tools, Linux compatibility, and Linux performance — right inside your Windows machine. No dual boot. No heavy VM. No excuses.

Whether you're a student learning Linux basics, a frontend developer following tutorials, or a backend engineer running servers locally, WSL makes your workflow smoother, faster, and a lot less frustrating.

If you haven't tried it yet, give it a shot. You might be surprised how quickly it becomes part of your daily routine. 🚀

Want more developer tips and tools explained clearly?
Visit hamidrazadev.com for more practical blog posts on frontend development, developer productivity, and web tools.

If this helped you, share it with a fellow developer who's still fighting Windows terminal issues. 😊

VS Code 1.115: The Update That Makes Your Dev Workflow Feel Like Magic 🚀

Muhammad Hamid Raza — Wed, 08 Apr 2026 13:12:56 +0000

Ever updated VS Code, glanced at the release notes, and thought "okay that's cool" — but then kept coding without really digging in? Same. Most of us miss genuinely useful features because the changelog can feel like a wall of text.

So let's fix that.

VS Code 1.115 dropped on April 3, 2026, and this one has some really solid improvements — especially if you're working with AI agents, terminals, or remote machines. Whether you're a solo dev or part of a team, there's something in here worth knowing about.

Let's break it all down in plain English. 👀

What Is VS Code 1.115?

VS Code releases updates in rolling cycles, and version 1.115 covers changes made between March 31 and April 2, 2026. These aren't massive rewrites — they're focused, practical improvements that smooth out real developer pain points.

This release touches four main areas:

Terminal improvements
Agent and chat session upgrades
Remote SSH support
UI and browser polish

Why This Update Matters

If you're using VS Code's built-in AI agent features, background terminals, or SSH remotes, this update directly improves how you work. The team at Microsoft is clearly doubling down on making AI-assisted development feel less clunky and more natural.

Even if you're not deep into agents yet, the terminal paste fix alone is worth noting. How many times have you needed to paste an image into a terminal and had to find a workaround? No more.

What's New in VS Code 1.115

Let's go through each update, grouped by day.

🗓️ April 2, 2026

Test coverage in the minimap

You can now enable test coverage indicators directly in the minimap. This is a subtle but useful addition for anyone doing TDD or trying to get a quick visual sense of how well their codebase is covered — without needing to open a separate panel.

Paste files into the terminal

You can now paste files — including images — into the integrated terminal using Ctrl+V, drag-and-drop, or right-click paste. This is one of those small things that makes a big difference when you're trying to move fast.

Background terminal improvements for agents

This one is big for AI agent workflows. Background terminals now automatically notify the agent when a command finishes, including the exit code and output. Even better — if a background terminal is waiting for user input, VS Code detects that and surfaces it to you.

Before this, agents could kick off a terminal command and then just... not know what happened. Now there's a proper feedback loop.

Pinch-to-zoom in the integrated browser (Mac)

Mac users can now use pinch-to-zoom gestures inside the integrated browser. A small quality-of-life upgrade, but it brings the built-in browser experience closer to a real browser.

code serve-web CLI updates

The code serve-web command now supports three new options:

--disable-telemetry
--default-folder
--default-workspace

Useful for teams running VS Code in a web/server context who want more control over the default experience.

🗓️ April 1, 2026

Copilot session entitlements and usage info

The Copilot status bar now shows entitlement and usage information inside Sessions. If you've ever wondered how much of your Copilot quota you've used mid-session, this gives you visibility without leaving your editor.

SSH remote support with automatic CLI setup

This is a genuinely useful addition. VS Code can now connect to remote machines over SSH and automatically install the CLI and start it in agent host mode. Previously, you'd need to set things up manually on the remote side. Now it handles it for you.

For anyone doing remote development — whether on a server, a cloud VM, or a colleague's machine — this removes a real friction point.

File edit tracking and restoration in agent sessions

Agents can now track and restore file edits made during a session. This means you get proper diffs, undo/redo, and state restoration for any changes an agent made.

This is important. AI-assisted editing is only as trustworthy as your ability to review and reverse it. Now you have the tools to do both.

🗓️ March 31, 2026

Chat can track and link open browser tabs

Chat sessions can now track browser tabs that were opened or interacted with during a session. Agents can reference those open pages directly. If you asked an agent to open docs and then want it to pull info from them, this makes that flow work properly.

send_to_terminal tool for agents

A new send_to_terminal tool lets agents send commands to background terminals — with user confirmation. This fixes a known issue where run_in_terminal with a timeout would push terminals to the background and make them read-only. Now that scenario is handled cleanly.

Rename agent sessions from the client side

You can now rename agent sessions directly from the client, thanks to a new rename capability in the Agent Host Protocol. Helpful when you're juggling multiple sessions and need to stay organized.

Favicons in Go to File quick pick

Open web pages now display their favicons in the Go to File quick pick list. A small visual improvement that makes it easier to identify browser tabs at a glance.

Comparison: Before vs. After — Agent Terminal Workflow

Scenario	Before 1.115	After 1.115
Agent runs background command	No notification when done	Agent gets exit code + output
Background terminal needs input	Silently blocked	Detected and surfaced to user
Agent sends command to terminal	`run_in_terminal` timeout issues	Clean `send_to_terminal` with confirmation
SSH remote setup	Manual CLI install required	Auto-installs CLI + starts agent host

If you work with agents regularly, this table basically summarizes why 1.115 is a meaningful release.

Tips for Getting the Most Out of VS Code 1.115

✅ Do:

Enable test coverage in the minimap if you're writing tests — it's a fast visual cue
Try the SSH auto-install feature on your next remote dev session instead of setting things up manually
Review agent session diffs before accepting them — the new restoration feature makes this easier than ever
Rename your agent sessions so you can find them later

❌ Don't:

Ignore background terminal notifications — they're telling you something important
Skip reviewing file edits made by agents just because undo is now available
Forget to check your Copilot usage in the Sessions panel if you're on a limited plan

Common Mistakes People Make After a VS Code Update

Skipping the release notes entirely

Most developers install the update and move on. The result? They miss features that could save them hours. You don't need to read everything — but skimming the highlights takes three minutes.

Not testing new agent features with real workflows

It's easy to read about a feature and think "cool" without actually using it. The background terminal improvements in 1.115 are genuinely useful — but you'll only feel that benefit if you try them in an actual agent session.

Assuming remote SSH setup is still manual

Habits are hard to break. If you've been setting up VS Code CLI manually on every remote machine, you might keep doing it out of muscle memory. The auto-install feature is now available — use it.

Overlooking small UI changes

The favicon display in Go to File and the minimap coverage indicators seem minor. But they add up. A cleaner visual workspace means fewer context switches and less cognitive load over a full workday.

Wrapping Up

VS Code 1.115 is a focused, practical update. It doesn't reinvent the editor — it makes the things you already do smoother, faster, and more reliable.

The biggest wins here are for developers working with AI agents and remote machines. The background terminal improvements, file edit tracking, and SSH auto-setup are all genuinely useful additions that remove real friction from real workflows.

If you haven't updated yet, do it. And actually read through the release notes — even just once. You'll find at least one feature that makes you think "wait, that was always the problem I had." 💡

For more practical dev content, check out hamidrazadev.com — new posts every week on tools, tips, and web development.

If this post helped you, share it with a developer friend who might be sleeping on these updates. Drop a comment if you found a feature in 1.115 that I didn't cover! 😊

Intersection Observer in JavaScript: Detect When Elements Enter the Screen (Without Breaking a Sweat)

Muhammad Hamid Raza — Tue, 07 Apr 2026 13:14:50 +0000

Ever built a webpage and thought, "Wouldn't it be cool if this animation only triggered when the user actually scrolls to it?" Or maybe you've seen lazy-loaded images on big websites and wondered how they know exactly when to load? 🤔

That magic has a name: the Intersection Observer API.

If you've ever tried to detect element visibility using scroll events and getBoundingClientRect(), you already know the pain. It works — until your page starts lagging because the browser is calculating positions on every single scroll tick. Not fun.

Intersection Observer was built to solve exactly that problem. It's clean, efficient, and honestly pretty satisfying to use once it clicks. Let's break it down.

What Is the Intersection Observer API?

The Intersection Observer API is a built-in JavaScript browser API that lets you watch when an element enters or exits the viewport (or any scrollable container) — without using scroll events.

Think of it like a security guard standing at the entrance of a room. Instead of you constantly running to the door to check if someone arrived, the guard simply calls you the moment someone walks in. You don't have to do anything. You just wait for the call.

In code terms: you tell the browser "hey, watch this element for me", and the browser notifies you the moment it becomes visible or hidden. No polling. No performance headaches. Just a clean callback.

Why This Matters for Developers

Before Intersection Observer existed, developers used scroll event listeners combined with getBoundingClientRect() to track element positions. It worked, but it had real problems:

Performance issues — scroll events fire extremely fast, dozens of times per second. Running calculations inside them tanks performance on complex pages.
Forced reflows — calling getBoundingClientRect() forces the browser to recalculate layout, which is expensive.
Messy code — handling debouncing, cleanup, and edge cases made the code complicated fast.

Intersection Observer solves all of this. The browser handles the detection natively and efficiently, and your callback only runs when something actually changes. It's the right tool for the job.

Benefits with Real-Life Examples

Lazy loading images — Instead of loading all 80 product images on a page at once, you load them only when they're about to appear on screen. Faster initial load, less wasted bandwidth. ⚡
Scroll-triggered animations — Cards, text, or UI sections animate in only when the user scrolls to them. Feels polished, costs almost nothing extra.
Infinite scroll — When the last list item enters the viewport, trigger the next page fetch. This is exactly how Twitter and Instagram feeds work.
Sticky headers and nav highlights — Track which section is currently visible and highlight the matching navigation link automatically.
Analytics and ad visibility tracking — Know whether a user actually saw an ad or section, not just whether the page loaded.

Each of these used to require messy scroll handlers. Now they're clean, readable, and fast.

How to Use It: Basic Syntax

Here's the simplest form of Intersection Observer:

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      console.log('Element is visible!', entry.target);
    }
  });
});

const target = document.querySelector('.my-element');
observer.observe(target);

That's it for the basics. Let's understand what each part does.

The Callback

The callback receives an array of entries. Each entry represents an observed element and includes useful properties:

entry.isIntersecting — true if the element is currently visible in the viewport.
entry.target — the actual DOM element being observed.
entry.intersectionRatio — how much of the element is visible, from 0 to 1.
entry.boundingClientRect — the element's size and position.

The Options Object

You can pass an options object as the second argument to control behavior:

const options = {
  root: null,         // null = viewport; or pass a scrollable element
  rootMargin: '0px',  // expand or shrink the detection area
  threshold: 0.5      // trigger when 50% of the element is visible
};

const observer = new IntersectionObserver(callback, options);

root — The container to check against. null means the browser viewport.
rootMargin — Like CSS margin, it expands or shrinks the detection zone. "100px" would trigger 100px before the element actually enters the viewport — great for preloading.
threshold — A value (or array of values) between 0 and 1 defining when the callback fires. 0 = any pixel visible, 1 = fully visible.

Practical Example: Scroll-Triggered Animation

Here's a real, working example you can drop into any project:

HTML:

<div class="card fade-in">Hello, I animate in! 👋</div>
<div class="card fade-in">So do I!</div>
<div class="card fade-in">Me too!</div>

CSS:

.fade-in {
  opacity: 0;
  transform: translateY(30px);
  transition: opacity 0.6s ease, transform 0.6s ease;
}

.fade-in.visible {
  opacity: 1;
  transform: translateY(0);
}

JavaScript:

const observer = new IntersectionObserver((entries) => {
  entries.forEach((entry) => {
    if (entry.isIntersecting) {
      entry.target.classList.add('visible');
      observer.unobserve(entry.target); // stop watching after animation
    }
  });
}, { threshold: 0.1 });

document.querySelectorAll('.fade-in').forEach((el) => observer.observe(el));

The observer.unobserve() call on line 5 is key — once the animation fires, there's no reason to keep watching that element. This keeps things clean and memory-efficient.

Comparison: Scroll Event vs Intersection Observer

Feature	Scroll Event + getBoundingClientRect	Intersection Observer
Performance	Poor on complex pages	Excellent, native browser optimization
Ease of use	Complex, lots of boilerplate	Clean and minimal
Debouncing needed	Yes	No
Viewport detection	Manual calculation	Built-in
Multiple elements	Gets messy fast	Observe as many as you need
Browser support	Universal	All modern browsers ✅

The scroll event approach isn't wrong — but for visibility tracking, Intersection Observer is almost always the better choice.

Best Tips / Do's & Don'ts

✅ Do:

Always call observer.unobserve(entry.target) after a one-time action (like triggering an animation) to free up resources.
Use rootMargin for preloading — trigger things slightly before they enter the viewport for a smoother user experience.
Pass an array of thresholds like [0, 0.25, 0.5, 0.75, 1] if you need to track how much of an element is visible at different stages.
Store your observer in a variable so you can call observer.disconnect() when the component unmounts (especially important in React).

❌ Don't:

Don't use it for detecting exact pixel positions in real time — that's still scroll events territory.
Don't forget to call observer.disconnect() when you're done. Leaving observers running indefinitely wastes memory.
Don't set threshold: 1 for large elements that might never be 100% visible on small screens. Your callback will never fire.
Don't create a new observer instance for each element. One observer can watch many elements at once.

Common Mistakes People Make

1. Forgetting to unobserve or disconnect

This is the most common mistake. If you observe 50 elements on a page and never stop watching them, you're holding references and running callbacks unnecessarily. Always clean up.

2. Using threshold: 1 on tall elements

If your element is taller than the viewport, it will never be 100% visible — so a threshold of 1 means your callback never fires. Use 0.1 or 0.2 for tall sections.

3. Creating one observer per element

// ❌ Wrong way
elements.forEach((el) => {
  const obs = new IntersectionObserver(callback);
  obs.observe(el);
});

// ✅ Right way
const observer = new IntersectionObserver(callback);
elements.forEach((el) => observer.observe(el));

One observer, many targets. Cleaner and more efficient.

4. Not checking isIntersecting inside the callback

The callback fires both when elements enter and exit the viewport. If you don't check entry.isIntersecting, your logic runs in both cases — which often causes bugs.

5. Relying on it for critical layout logic without a fallback

Modern browser support is excellent, but if you're building something that needs to work in very old environments, check caniuse.com and consider a polyfill.

Conclusion

The Intersection Observer API is one of those browser features that once you learn, you start seeing use cases everywhere. Lazy loading, animations, infinite scroll, analytics — it handles them all cleanly and efficiently.

It replaces a whole category of scroll-event spaghetti with just a few lines of readable code. Your users get a smoother experience, your codebase stays clean, and your browser stops crying. Everyone wins. 🚀

The next time you need to detect element visibility on a page, reach for Intersection Observer first. It was literally built for this.

Want more practical JavaScript and frontend tips like this? Head over to hamidrazadev.com for more posts, tutorials, and guides. If this helped you, share it with a fellow developer — they'll thank you for it. 😊

Google Stitch: The AI Design Tool Developers Need to Know About in 2026

Muhammad Hamid Raza — Mon, 06 Apr 2026 12:22:39 +0000

You have an app idea. You know what it should do. You even know roughly what it should look like.

But then you open a blank Figma file and... nothing. The blank canvas paralysis hits. You spend two hours pushing boxes around, and the result still looks like a college assignment from 2009.

Sound familiar? 😅

That is exactly the problem Google Stitch was built to fix. It is a free AI-powered UI design tool from Google Labs that lets you describe your interface in plain English—and it generates a polished, production-ready design for you in seconds, complete with real frontend code.

Whether you are a developer who struggles with design, a designer who wants to move faster, or a founder who needs to prototype an idea without hiring an agency—Stitch might just become your new favorite tool.

What Is Google Stitch?

Google Stitch is an AI-powered UI design tool developed by Google Labs that transforms text prompts or uploaded wireframes into mobile and web user interface designs.

It leverages the multimodal power of Gemini 3 Flash and Gemini 3 Pro to create a fluid, integrated workflow between design and development.

Three Tools in One:

Design Generator: Describe your UI and it creates it visually.
Code Exporter: Get clean HTML, CSS, or React (TypeScript) code instantly.
Figma Bridge: Paste your design directly into Figma for further polish.

The best part? It’s fully web-based. All you need is a Google account—no installations or environment setup required.

Why Google Stitch Matters for Developers

Most developers are not designers. And that is completely fine—except when you need to ship a product fast and there is no designer on the team.

Stitch allows anyone to turn natural language into high-fidelity UI designs. For a solo dev, this means going from "I need a dashboard" to a functional layout in under five minutes.

The Impact:

Zero to Hero: No Figma expertise? No problem.
Instant Handoff: The "design" is already code.
Massive Speed: Cuts design time from days to minutes.

Key Features & Real-Life Examples

1. Turn Plain English into Full UI

Describe your application including details like color palettes or user experience.

Prompt: "A dark-themed mobile dashboard for a crypto tracking app with a navbar, portfolio card, and price chart using #0a0a0a and #22d3ee accents."

2. Upload Sketches and Wireframes

Have a whiteboard sketch or a rough screenshot? Upload it. Stitch processes the image to produce a corresponding digital UI, bridging the gap between a napkin sketch and a functional design.

3. Production-Ready Code

Stitch doesn't just "draw" boxes; it writes them. You can export:

Tailwind CSS + React
Standard HTML/CSS
TypeScript components

4. The "Wildcard" Variant Engine

Design is iterative. Use Stitch to generate multiple variants of a single screen instantly. Experiment with layouts, components, and styles without manual dragging and dropping.

Google Stitch vs. Traditional Workflow

Feature	Google Stitch (AI)	Traditional Figma Workflow
Design Speed	Seconds (Prompt-based)	Hours (Manual placement)
Skill Floor	Low (English proficiency)	High (Design principles/Figma)
Dev Handoff	Built-in (Code ready)	Manual (Inspection/Export)
Cost	Free (Labs)	Paid (Professional tiers)
Best For	Prototyping, Solo Devs	Full Design Systems, Large Teams

How to Use Google Stitch: Step-by-Step

Sign In: Visit stitch.withgoogle.com and log in with your Google account.
Pick Your Mode: * Standard (Gemini 3 Flash): Fast, lightweight exploration.
- Experimental (Gemini 3 Pro): High-fidelity, detailed complex designs.
Write a Clear Prompt: Include platform (Web/Mobile), core components (Navbar/Cards), and visual style (Minimal/Dark Mode).
Refine & Iterate: Use follow-up prompts to change one or two things at a time.
Export: Choose between "Paste to Figma" or "Download Code."

Best Tips for Success 💡

Be Specific: Vague prompts give vague results. Use hex codes and component names.
The One-Change Rule: Don't ask for a complete overhaul in one prompt. Change the navbar first, then the font, then the colors.
Use DESIGN.md: Export your design system as a .md file to keep branding consistent across multiple projects.
Test Standalone: Always run the exported code in a local browser before integrating it into a complex app.

Conclusion

Google Stitch genuinely changes how fast you can go from idea to interface. It’s a game-changer for developers who want to design without becoming a full-time designer.

It is free, browser-based, and integrates with the tools you already use. There is no reason not to give it a spin.

Try it today: stitch.withgoogle.com

If this guide was helpful, share it with a dev friend! For more practical tools and frontend guides, head over to hamidrazadev.com.

CSS Flexbox Explained: The Layout Superpower Every Developer Needs

Muhammad Hamid Raza — Sun, 05 Apr 2026 11:48:13 +0000

If you've ever tried to center a div and ended up Googling it for the fifth time this week — welcome, you're in the right place. 😄

CSS layouts used to be a bit of a nightmare. Floats, clearfixes, position: absolute hacks — developers had to jump through all sorts of hoops just to align a few boxes. Then Flexbox came along and changed everything.

Flexbox, short for Flexible Box Layout, is one of the most useful tools in modern CSS. Once you actually understand it — not just copy-paste it — layouts start feeling almost fun. So let's break it down from scratch and make it click.

What Is Flexbox?

Flexbox is a CSS layout model that helps you arrange elements inside a container — horizontally, vertically, or both — with much less effort than older methods.

Think of it like a shelf organizer. You have a shelf (the flex container), and you're placing books on it (the flex items). Flexbox lets you decide how those books are spaced out, aligned, and sized — all with a few CSS properties.

You activate Flexbox with one line:

.container {
  display: flex;
}

That's it. The moment you write that, every direct child of .container becomes a flex item, and Flexbox starts managing them.

Why Flexbox Matters

Before Flexbox, centering something vertically in CSS was genuinely painful. Developers used margins, transforms, and table-cell tricks just to get a div in the middle of the page.

Flexbox solved that. It also solved:

Making equal-height columns without JavaScript
Building responsive navigation bars
Distributing space evenly between elements
Reordering elements without touching the HTML

Today, Flexbox is supported in all modern browsers. It's a core skill for frontend developers, and you'll use it in almost every project you build.

Benefits with Real-Life Examples

1. Centering made easy ✅

Centering a div — both horizontally and vertically — used to be a meme in the dev community. With Flexbox:

.container {
  display: flex;
  justify-content: center;
  align-items: center;
}

That's genuinely all you need. Three lines and you're done.

2. Responsive navbars without pain

Building a navigation bar that spreads links across the full width? Flexbox handles it naturally with justify-content: space-between.

3. Equal-height cards automatically

In a blog or product listing, cards in the same row have equal height by default when using Flexbox — no extra CSS or JavaScript needed.

4. Control direction easily

Want items stacked vertically? Just change one property:

flex-direction: column;

This is incredibly useful for mobile layouts.

5. Reorder items without changing HTML

The order property lets you visually reorder flex items without touching the markup. Great for responsive design where you want a different layout on mobile vs desktop.

The Core Flexbox Properties You Need to Know

On the Container (Parent)

display: flex
Activates Flexbox on the container.

flex-direction
Controls which direction items flow.

row (default) — left to right
column — top to bottom
row-reverse and column-reverse — reversed directions

justify-content
Aligns items along the main axis (horizontal by default).

flex-start — all items pushed to the start
flex-end — all items pushed to the end
center — items centered
space-between — equal space between items, none on edges
space-around — equal space around each item
space-evenly — truly equal space everywhere

align-items
Aligns items along the cross axis (vertical by default).

flex-start, flex-end, center — same idea, but vertical
stretch (default) — items stretch to fill the container height
baseline — items align by their text baseline

flex-wrap
By default, flex items stay in one row even if they overflow. flex-wrap: wrap allows them to jump to the next line.

gap
Adds space between flex items. Much cleaner than using margins on each item.

.container {
  display: flex;
  gap: 16px;
}

On the Items (Children)

flex-grow
Defines how much a flex item should grow relative to others if there's extra space. A value of 1 means it will grow to fill available space.

flex-shrink
Controls how much an item shrinks when there's not enough space. Default is 1.

flex-basis
Sets the initial size of a flex item before growing or shrinking. Think of it as the "starting width."

flex (shorthand)
The shorthand for flex-grow, flex-shrink, and flex-basis combined.

.item {
  flex: 1; /* grow: 1, shrink: 1, basis: 0% */
}

Using flex: 1 on all items makes them equal width — super useful for grid-like layouts.

align-self
Overrides align-items for a single item. Want one card to align differently from the rest? This is your property.

order
Changes the visual order of a flex item. Default is 0. Lower values appear first.

Main Axis vs Cross Axis — The Key Concept

This is where many people get confused, and it's worth taking a moment here.

Flexbox has two axes:

The main axis runs in the direction of flex-direction
The cross axis runs perpendicular to it

If flex-direction is row (default), the main axis is horizontal and the cross axis is vertical.

justify-content always controls the main axis.
align-items always controls the cross axis.

Once you internalize this, the whole system makes sense. It's not about "horizontal" or "vertical" in absolute terms — it's about main and cross.

Flexbox vs CSS Grid — Which Should You Use?

This is a common question and the answer is: they complement each other, not compete.

Feature	Flexbox	CSS Grid
Best for	One-dimensional layouts (row OR column)	Two-dimensional layouts (rows AND columns)
Use case	Navbars, card rows, centering	Full page layouts, complex grids
Browser support	Excellent	Excellent
Complexity	Simpler to start with	More powerful for complex layouts

A practical rule: use Flexbox when you're working in one direction. Use CSS Grid when you need rows and columns at the same time. Often you'll use both on the same page.

Best Tips for Using Flexbox

✅ Use gap instead of margins between items
It's cleaner, easier to manage, and doesn't create edge-case spacing issues.

✅ Remember that justify-content and align-items depend on flex-direction
When you switch to flex-direction: column, the axes flip. Many beginners forget this.

✅ Use flex: 1 for equal-width items
Adding flex: 1 to all children in a flex container makes them share space equally — a quick way to create column layouts.

✅ Use flex-wrap: wrap for responsive layouts
Without it, items will squish or overflow on small screens. Adding wrap lets them flow naturally.

✅ Use browser DevTools to debug
Chrome and Firefox both have Flexbox inspector tools. They visualize your layout in real time and save a lot of guessing.

Common Mistakes People Make

❌ Applying flex properties to the wrong element

justify-content and align-items go on the container, not the items. Beginners often add them to the wrong element and wonder why nothing changes.

❌ Forgetting that axes flip with flex-direction: column

When you switch to column direction, justify-content controls vertical alignment and align-items controls horizontal. This is the most common source of confusion.

❌ Using width: 100% on flex items unnecessarily

When you set flex: 1 or use flex-grow, adding width: 100% can actually break the layout. Trust Flexbox to handle sizing.

❌ Overusing Flexbox for two-dimensional layouts

If you're fighting Flexbox to build a grid layout, CSS Grid is probably the better tool. Don't force a one-dimensional system to do two-dimensional work.

❌ Not using flex-wrap on responsive containers

A common issue — items overflow on mobile because flex-wrap wasn't set. Always consider wrapping when building for different screen sizes.

Quick Reference Cheat Sheet

/* Container */
.container {
  display: flex;
  flex-direction: row | column | row-reverse | column-reverse;
  justify-content: flex-start | flex-end | center | space-between | space-around | space-evenly;
  align-items: flex-start | flex-end | center | stretch | baseline;
  flex-wrap: nowrap | wrap | wrap-reverse;
  gap: 16px;
}

/* Items */
.item {
  flex: 1;              /* grow, shrink, basis shorthand */
  flex-grow: 1;
  flex-shrink: 1;
  flex-basis: 200px;
  align-self: center;
  order: 2;
}

Conclusion

Flexbox is one of those tools that feels tricky for the first hour and then becomes second nature forever. The moment it clicks — especially the main axis vs cross axis concept — you'll start seeing layouts differently.

Once you understand that display: flex on the parent, justify-content for the main axis, and align-items for the cross axis are the three core pillars, the rest falls into place naturally. Everything else is just extra control on top of that foundation.

Start small. Build a centered card. Then try a navbar. Then a card row that wraps on mobile. Each one teaches you something new.

And when you're ready to go deeper into CSS, React, Next.js, and modern frontend development, head over to hamidrazadev.com — there's a lot more waiting for you there. 🚀

If this helped you finally understand Flexbox, share it with a dev friend who's still cursing at their layout. They'll thank you later. 😊

Kali Linux 2026.1 Is Here — And It Brought a Time Machine 🚀

Muhammad Hamid Raza — Sat, 04 Apr 2026 12:27:34 +0000

Have you ever wished your terminal could look cooler and feel nostalgic at the same time? Kali Linux just made that happen.

Kali Linux 2026.1 has officially dropped, and this release is more exciting than your average quarterly update. We are talking a full visual overhaul, a nostalgic surprise for longtime fans, brand new tools, kernel upgrades, and some serious NetHunter improvements.

Whether you are a penetration tester, a cybersecurity student, or just someone who loves watching their Kali boot screen with a coffee in hand — this release has something for you. So let's break it all down. 👀

What Is Kali Linux 2026.1?

If you are new here: Kali Linux is a Debian-based Linux distribution built specifically for penetration testing, ethical hacking, digital forensics, and security research. It is maintained by OffSec and is one of the most widely used platforms in the cybersecurity world.

Every year, the Kali team drops a xx.1 release with a fresh visual theme, new tools, and improvements across the board. The 2026.1 release follows that same tradition — but this time, it comes with a very special birthday gift.

Kali Linux just turned 13. And BackTrack Linux, Kali's legendary predecessor, just turned 20.

That is a lot of anniversaries to celebrate. And the team absolutely delivered.

Why Kali Linux 2026.1 Matters

You might be thinking: "It is just a theme update and a few new tools. Why should I care?"

Fair question. But this release is more than cosmetic.

Here is why it matters for developers and security professionals:

The kernel has been bumped to 6.18, bringing better hardware support and performance improvements.
8 new tools have been added to the repositories — covering areas from XSS scanning to post-exploitation frameworks.
NetHunter improvements mean mobile pentesting just got more capable on more devices.
The BackTrack Mode is not just nostalgia — it shows how far the ecosystem has come and gives veteran users a reason to smile.
183 package updates and 25 new packages keep the toolset sharp and current.

If you are actively using Kali for security work, these are meaningful improvements worth upgrading for.

Key Features and What They Actually Do

🎨 2026 Theme Refresh

Every .1 release comes with a theme refresh, and 2026 is no exception.

The new theme touches everything: the boot animation, the GRUB menu, the graphical installer, the login screen, and the desktop wallpaper. Kali Purple also gets a matching refresh for those who prefer the purple variant.

One small but appreciated fix? The boot animation used to get stuck at the tail on live images. That is now fixed, and it loops smoothly if the boot process takes longer than expected. Not a major thing — but anyone who has stared at a frozen boot animation knows the relief.

🕹️ BackTrack Mode for Kali-Undercover

This is the most interesting addition in this release.

Kali-Undercover is an existing feature that makes your Kali desktop look like a regular Windows setup — great for working in public without drawing attention.

Now, Kali-Undercover has a new BackTrack Mode that transforms the desktop to look like BackTrack 5 — complete with the original wallpaper, colors, and window theme.

For those who do not know: BackTrack Linux was the go-to hacking distribution before Kali took over in 2013. It was legendary. Running BackTrack Mode in 2026 is like putting on a retro jersey — functional, stylish, and deeply nostalgic.

To activate it, you run:

kali-undercover --backtrack

Run it again to switch back. Simple and clean.

🛠️ 8 New Tools Added

Here is a quick look at what is new in the repositories:

AdaptixC2 — An extensible post-exploitation and adversarial emulation framework
Atomic-Operator — Runs Atomic Red Team tests across multiple operating systems
Fluxion — A security auditing and social-engineering research tool
GEF — A modern GDB experience with advanced debugging capabilities
MetasploitMCP — An MCP server for Metasploit
SSTImap — Automatic SSTI detection with an interactive interface
WPProbe — Fast WordPress plugin enumeration
XSStrike — An advanced XSS scanner

Whether you are testing web apps, running red team exercises, or debugging exploits, these additions cover a wide range of real security scenarios.

📱 Kali NetHunter Updates

Mobile pentesting is alive and well. This release brings:

Bug fixes including the WPS scan issue, HID permission check, and the back button problem
A new kernel for Redmi Note 8 (Ginkgo) supporting Android 16
A libnexmon patch for Samsung S10 series that finally gets reaver, bully, and kismet working properly
The first working QCACLD v3.0 injection patch — which could potentially unlock wireless injection on a huge number of Qualcomm-based phones

That last one is significant. If you have ever tried to do wireless testing on a Qualcomm phone and hit a wall, this is the patch you have been waiting for.

Pros and Cons of Upgrading to Kali 2026.1

✅ Pros	⚠️ Things to Know
Fresh theme and UI across the board	SDR tools (gr-air-modes, gqrx-sdr) are known to be broken in this release
Kernel 6.18 for better hardware support	The fix is expected in the next release
8 new tools added	Some packages removed (9 total)
BackTrack Mode for nostalgia fans	—
Significant NetHunter improvements	—
183 package updates	—

The main known issue is with the kali-tools-sdr metapackage. If you work with Software Defined Radio tools, it might be worth waiting for the next release or using workarounds in the meantime. The team has acknowledged it and expects a fix soon.

Best Tips for This Release

✅ Do's:

Update cleanly. If you are on an existing install, use the full upgrade command:

  sudo apt update && sudo apt -y full-upgrade

Copy the skel config after upgrading:

  cp -vrbi /etc/skel/. ~/

Check your kernel version after upgrading to confirm you are on 6.18.
Try BackTrack Mode — even if just for the experience. It is a fun piece of cybersecurity history.
Explore the new tools — especially XSStrike and SSTImap if you do web security testing.

❌ Don'ts:

Don't use the SDR metapackage if you depend on gqrx-sdr or gr-air-modes right now. Wait for the fix.
Don't report bugs on social media. The team specifically asks that bug reports go through the official bug tracker, not Twitter or Instagram.
Don't skip the skel copy step — it updates your config files to match the new theme properly.

Common Mistakes People Make When Updating Kali

1. Skipping the full-upgrade in favor of just upgrade

apt upgrade and apt full-upgrade are different. On Kali, you almost always want full-upgrade because it handles package replacements and removals. Skipping it can leave your system in a mixed state.

2. Not checking for broken packages after upgrading

After any major upgrade, running apt --fix-broken install is a good habit. It catches issues before they turn into bigger problems.

3. Forgetting to copy the skel files

This step updates your terminal profile, desktop config, and theme settings. Skipping it means your desktop might not reflect the new 2026 theme properly.

4. Expecting SDR tools to work in this release

The team was upfront about the GNU Radio ecosystem issue. If you depend on those tools, stay on 2025.4 for now or use a workaround. Patience here saves a lot of frustration.

5. Using weekly builds as if they are stable releases

Weekly builds are automated. They are great for getting the latest packages fast, but they skip the QA process that standard releases go through. Use them knowing that.

Conclusion

Kali Linux 2026.1 is a solid release that mixes polish with practicality. The 2026 theme refresh keeps the interface modern. The BackTrack Mode is a well-deserved nod to where it all started. The new tools expand the already impressive Kali arsenal. And the NetHunter updates push mobile pentesting forward in meaningful ways.

Yes, there is a known SDR issue. But the team was honest about it, and a fix is already expected in the next release. That kind of transparency is worth appreciating.

If you are a Kali user, update when you are ready. If you are new to the platform, this is a great time to start exploring.

Happy hacking. Stay ethical. And as always — learn something new today. 💡

👉 Want more content like this? Check out my developer blog at hamidrazadev.com for practical articles on tools, frameworks, and everything developers love to talk about. Share this post with a fellow security enthusiast if it helped you!

Why VS Code Is Still My Go-To IDE (After Trying Everything Else)

Muhammad Hamid Raza — Sat, 04 Apr 2026 12:16:15 +0000

I have tried a lot of editors. Sublime Text, Atom, WebStorm, Vim, Neovim, Zed, and even spent a week pretending I enjoyed writing code inside a terminal. Every few months someone tweets "VS Code is dead" or "I switched to X and my productivity tripled." And every time, I go check it out.

Then I come back to VS Code. 😅

If you have ever wondered why millions of developers keep choosing Visual Studio Code over every shiny new alternative, you are in the right place. Let me walk you through what makes it special — not with marketing fluff, but with honest, real reasons that actually matter when you are deep in a project at 11 PM.

What Is VS Code?

Visual Studio Code is a free, open-source code editor made by Microsoft. It was released in 2015 and has grown into one of the most popular development tools in the world.

But here is what makes it different from a full IDE like WebStorm or IntelliJ: VS Code starts as a lightweight editor and lets you decide how powerful to make it through extensions. Think of it like a plain room that you furnish however you like, versus a hotel room someone else already set up.

It runs on Windows, macOS, and Linux. And it supports pretty much every programming language you can think of.

Why VS Code Still Matters in 2025

You might think: "It's been around for a decade, surely something better exists by now."

Fair question. But the truth is VS Code has not been standing still. It gets updated every single month. The team ships real improvements regularly — not just bug fixes, but features developers actually asked for.

More importantly, the developer ecosystem has been built around it. Extensions, tutorials, YouTube videos, team configurations, .vscode folders in repos — everything assumes VS Code. Switching comes with a real cost.

And for frontend developers especially, VS Code just fits. The TypeScript support is excellent (Microsoft built both). The React and Tailwind CSS tooling works beautifully. The Git integration is clean and visual.

Why VS Code Keeps Winning 🚀

1. The Extension Marketplace Is Unmatched

No other editor comes close to the sheer number and quality of extensions available for VS Code.

Need Prettier for code formatting? One click. Want ESLint to catch your mistakes before you do? Done. Tailwind CSS IntelliSense that autocompletes class names as you type? It exists and it is genuinely great.

The marketplace has over 50,000 extensions. The community has already solved whatever problem you are facing.

2. It Starts Fast

VS Code opens in seconds. You are not waiting for an IDE to index your entire project before you can type a single line.

When you need to quickly open a config file, check a function, or write a small script, VS Code gets out of your way. That speed adds up over a whole workday.

3. The Built-In Git Integration Is Genuinely Good

The Source Control panel in VS Code is one of those features you do not appreciate until you have had to work without it.

You can stage individual lines, write commit messages, resolve merge conflicts side by side, and even see inline blame annotations — all without leaving the editor. No terminal commands needed unless you want them.

4. IntelliSense That Actually Helps

The code completion in VS Code is not just autocomplete. It understands your code. It reads your types, your imports, your function signatures, and gives you suggestions that make sense in context.

For JavaScript and TypeScript developers, this is huge. It catches typos, suggests the right method, and even shows you function documentation inline while you type.

5. The Terminal Is Right There

You do not need to switch windows to run your dev server or install a package. The integrated terminal lives at the bottom of your editor and supports multiple tabs and panels.

This sounds small but saves a surprising amount of mental switching cost throughout the day.

6. Remote Development and SSH Support

VS Code has an extension called Remote - SSH that lets you connect to a remote server and edit code as if the files were on your local machine. You get full IntelliSense, debugging, and terminal access over a remote connection.

This is genuinely powerful for developers who work with servers, containers, or cloud environments.

7. It Is Free. Always.

No subscription. No annual license. No "Pro plan required for this feature." VS Code is completely free and always has been.

VS Code vs. Other Editors: A Honest Look

Editor	Strengths	Weaknesses
VS Code	Speed, extensions, community, free	Can get heavy with too many extensions
WebStorm	Deep JS/TS analysis, built-in tools	Paid, heavier, slower startup
Zed	Very fast, modern design	Smaller extension ecosystem
Neovim	Ultra-fast, keyboard-driven	High learning curve
Sublime Text	Lightweight, snappy	Less active development

VS Code sits in a sweet spot. It is fast enough for quick tasks and powerful enough for large projects. The learning curve is low, and the ceiling is very high.

Tips for Getting the Most Out of VS Code 💡

Do these:

Install only the extensions you actually use. A bloated extension list slows things down.
Learn a few keyboard shortcuts. Ctrl+P for quick file switching and Ctrl+Shift+P for the command palette are game-changers.
Use workspaces when working on multiple related projects. It keeps things organized.
Enable auto-save (File > Auto Save). You will stop losing changes you forgot to commit.
Use the settings.json file for team-wide consistency. Commit your .vscode/settings.json to the repo.

Avoid these:

Do not install every popular extension you see in a YouTube video. Install what you need.
Do not ignore the Problems panel. It shows errors and warnings that can help you catch bugs early.
Do not overlook multi-cursor editing. Once you learn it, you will use it constantly.

Common Mistakes VS Code Users Make

Installing too many extensions and blaming VS Code for being slow

VS Code itself is not heavy. Thirty active extensions running in the background are. Audit your extensions occasionally and disable what you are not using.

Never changing the default font

This sounds shallow but it genuinely matters for daily comfort. Try a coding font like Fira Code or JetBrains Mono with ligatures enabled. Your eyes will thank you after a long session.

Not using Emmet

VS Code ships with Emmet built in for HTML and CSS. Typing div.container>ul>li*5 and pressing Tab gives you the full markup instantly. Most developers who have not discovered this are writing HTML much slower than they need to.

Ignoring the built-in debugger

Many developers still console.log everything instead of setting breakpoints and using the VS Code debugger. The built-in debugger supports Node.js, Chrome, and many other environments. It is worth learning.

Not syncing settings across machines

VS Code has a built-in Settings Sync feature that lets you sync your extensions, keybindings, and settings across devices using a GitHub or Microsoft account. Set it up once and you will never have to reconfigure VS Code on a new machine.

Conclusion

VS Code has earned its place at the top — not through hype, but through consistency. It is fast, free, deeply extensible, and backed by one of the strongest developer communities in the world.

Every year something new comes out promising to replace it, and every year VS Code users look up, nod, and go back to shipping their projects. That is not stubbornness. That is trust built through years of a tool doing its job exceptionally well. ✅

If you are already using VS Code, I hope this gave you a few things to explore. If you switched away and are curious, maybe it is worth a second look.

For more developer tips, practical guides, and honest opinions on tools and tech, check out my blog at hamidrazadev.com. New posts go up regularly and I keep them practical and to the point.

If this post helped you or gave you something to think about, feel free to share it with a dev friend. It means a lot. 🙌

Top 5 Best Open Source AI Models With Low Resource Usage

Muhammad Hamid Raza — Fri, 03 Apr 2026 05:05:41 +0000

You finally want to run an AI model locally. You fire up your terminal, pull a model, and… your laptop fan starts screaming like it's about to launch into orbit. 😅

Sound familiar?

Most AI models are powerful but hungry — they want your RAM, your GPU VRAM, your patience, and probably your electricity bill too. But what if you could run a capable, genuinely useful AI model on a basic laptop, an old PC, or even a Raspberry Pi?

Good news: you can. And you don't have to sacrifice much quality to do it.

Whether you're a developer building a local AI tool, a student experimenting with LLMs, or just someone curious about running AI without the cloud — this post is for you.

Let's look at the top 5 best open source AI models with low resource usage that actually work, actually perform, and won't melt your machine.

🤔 What Does "Low Resource Usage" Mean for AI Models?

Before we jump into the list, let's make sure we're on the same page.

An AI language model typically needs:

RAM – system memory your CPU uses
VRAM – memory on your GPU (if you have one)
Storage – to hold the model files on disk
CPU / GPU – to actually run the computations

A "low resource" model is one that can run well even when these are limited. That could mean it fits in 4–8 GB of RAM, runs smoothly without a dedicated GPU, or loads fast on a basic machine.

Smaller doesn't always mean dumb. Modern AI research has gotten very good at squeezing high performance out of compact model sizes. Quantization, pruning, and efficient architectures have changed the game completely.

💡 Why This Matters

Not everyone has a high-end gaming PC or a cloud server budget. A lot of real developers, learners, and builders are working on:

A mid-range laptop
An older workstation
A home server with limited RAM
An edge device or embedded system

Running AI locally also means better privacy — your prompts stay on your machine, not some company's server. It means no API costs, no internet dependency, and full control over the model.

If you've ever used a tool like Ollama to run models locally (we have a full blog post on that at hamidrazadev.com), you already know how empowering this is. The only bottleneck is picking the right model.

✅ Top 5 Open Source AI Models With Low Resource Usage

1. 🦙 Llama 3.2 (1B / 3B) — Meta

Minimum RAM: ~2–4 GB
Model size on disk: ~1–2 GB (quantized)

Meta's Llama 3.2 series brought something genuinely exciting: capable small models at 1B and 3B parameter sizes. These are not toys. For tasks like summarization, Q&A, code explanation, and basic text generation, they perform surprisingly well.

The 3B version especially punches above its weight. It's fast, lightweight, and easy to run locally with tools like Ollama.

Best for: Developers who want a fast, practical general-purpose model with minimal setup.

2. 🔷 Phi-3 Mini — Microsoft

Minimum RAM: ~2–4 GB
Model size on disk: ~2.3 GB (quantized)

Microsoft's Phi-3 Mini is a 3.8B parameter model trained with a strong focus on data quality over data quantity. The result? A model that feels smarter than its size suggests.

It handles reasoning, math, and code tasks well — areas where many small models struggle. Microsoft specifically designed Phi-3 to run on devices with limited hardware, which makes it a natural fit for local AI use cases.

Best for: Coding help, reasoning tasks, and educational use on modest hardware.

3. 💎 Gemma 2 (2B) — Google DeepMind

Minimum RAM: ~3–5 GB
Model size on disk: ~1.6 GB (quantized)

Google DeepMind's Gemma 2 2B is clean, well-documented, and genuinely capable for its size. It's built on techniques from Gemini and brings solid general-purpose performance to the lightweight category.

It handles chat, summarization, and instruction-following nicely. The 2B size means it loads fast and responds quickly even on CPU-only machines.

Best for: Developers wanting a Google-backed model with solid community support and good documentation.

4. ⚡ Qwen 2.5 (0.5B / 1.5B) — Alibaba Cloud

Minimum RAM: ~1–3 GB
Model size on disk: ~400 MB – 1 GB (quantized)

Qwen 2.5 is one of the most impressive low-resource options available today. The 0.5B and 1.5B versions are tiny in size but have been trained on an enormous, high-quality multilingual dataset — including strong support for English, Chinese, and code.

The 1.5B version especially delivers results that feel well above what you'd expect from a model this small. If you need something truly minimal that still gives useful answers, Qwen 2.5 is worth testing.

Best for: Edge devices, Raspberry Pi use cases, multilingual tasks, and situations where storage and RAM are extremely tight.

5. 🧬 Mistral 7B (Quantized) — Mistral AI

Minimum RAM: ~4–6 GB (with Q4 quantization)
Model size on disk: ~4 GB (Q4_K_M quantized)

Mistral 7B is technically a 7-billion parameter model, which sounds large — but with modern quantization (specifically Q4 or Q5 formats via llama.cpp or Ollama), it runs on machines with as little as 6 GB of RAM, and even on CPU-only setups with patience.

It's widely considered one of the best models for its size in terms of raw output quality. The community support around it is massive, and it handles code, writing, and reasoning tasks extremely well.

Best for: Developers who want the best quality-to-resource ratio and don't mind slightly higher RAM requirements.

📊 Quick Comparison Table

Model	Parameters	Approx. RAM Needed	Best Use Case
Llama 3.2 3B	3B	~4 GB	General purpose, fast
Phi-3 Mini	3.8B	~4 GB	Code, reasoning
Gemma 2 2B	2B	~3 GB	Chat, summarization
Qwen 2.5 1.5B	1.5B	~2 GB	Minimal hardware, multilingual
Mistral 7B (Q4)	7B	~5–6 GB	Best quality, local use

⚠️ RAM requirements depend on quantization level and the tool you use to run the model. These are approximate values for Q4-level quantization using tools like Ollama or llama.cpp.

🔧 Tips for Running These Models Efficiently

Use quantized versions. Q4_K_M or Q5_K_M formats offer the best balance of size, speed, and quality. Full-precision models use far more RAM for minimal real-world benefit in most tasks.

Use Ollama for easy local setup. It handles model downloads, quantization, and serving through a simple CLI and REST API. No complex configuration needed.

Don't run other heavy apps simultaneously. When you're on 8 GB RAM total and running a local LLM, Chrome with 40 tabs is not your friend. 😄

Try CPU-only mode first. Even without a GPU, many of these models respond within 1–5 seconds per token on a modern CPU. That's usable for most tasks.

Match the model to your task. Don't reach for Mistral 7B if a Phi-3 Mini can do the job. Smaller models respond faster and free up resources.

❌ Common Mistakes People Make

Skipping quantization. Downloading the full FP16 model when a Q4 quantized version would work just as well for most tasks. The full version might need 14+ GB of RAM instead of 4 GB — a painful difference.

Running on unsupported hardware without GPU offload settings. Some tools let you specify how many layers to offload to GPU vs CPU. Ignoring this setting leads to very slow inference or crashes.

Picking a model based on hype alone. A model with millions of GitHub stars isn't always the right fit for your hardware or use case. Test before committing.

Forgetting about context window limits. Small models often have smaller context windows. Feeding them a 10,000-word document expecting a perfect summary may not work as expected.

Not updating models. The open source AI space moves fast. A model that was the best option six months ago might have a significantly better updated version available now.

🏁 Conclusion

You don't need a $3,000 GPU setup or a cloud API subscription to use AI in your projects. The open source AI ecosystem has matured to a point where genuinely capable models fit in your pocket — or at least on your laptop.

To recap the top 5:

Llama 3.2 (3B) — Fast, general-purpose, great starting point
Phi-3 Mini — Smart for its size, great for code and reasoning
Gemma 2 (2B) — Clean and capable from Google DeepMind
Qwen 2.5 (1.5B) — Incredibly small, surprisingly strong
Mistral 7B (Q4) — Best quality-to-resource ratio overall

Start with Ollama, pick any model from this list, and see what you can build. 🚀

If you want to go deeper, check out more practical guides at hamidrazadev.com — we cover local AI, frontend tools, and real developer topics regularly.

If this post helped you, share it with a fellow developer who's been curious about running AI locally. It might save them a lot of RAM and frustration. 😊