DEV Community: Muhammad Hamid Raza

Why Most Developers Love Dark Mode (And It's Not Just a Vibe)

Muhammad Hamid Raza — Sat, 09 May 2026 10:45:22 +0000

You open your laptop at 11 PM to fix "just one bug." The screen blasts you with a wall of white light. Your eyes feel like they're being interrogated. Sound familiar? 😅

Dark mode has quietly become the unofficial uniform of the developer world. Open any code editor, terminal, browser dev tool, or GitHub repo — chances are it's dressed in dark. But why exactly? Is it just aesthetic? Is it a productivity thing? Or are developers just wired to love the night?

Let's dig into the real reasons why most developers swear by dark mode, and whether it actually deserves all the love it gets.

What Is Dark Mode?

Dark mode is a display setting that flips the default color scheme of an interface. Instead of dark text on a white background, you get light text on a dark (usually near-black or deep gray) background.

It's available in almost every modern OS, browser, app, and code editor today — from VS Code and JetBrains IDEs to GitHub, Twitter, Discord, and even Google Docs.

Think of it like switching from a fluorescent office room to a cozy desk lamp setup. Same work. Very different vibe — and for many, very different comfort.

Why Dark Mode Matters for Developers

Developers don't just stare at screens occasionally. They stare at screens all day. Sometimes all night too.

When your job involves reading thousands of lines of code, debugging complex logic, and switching between dozens of tabs — how your screen looks isn't a minor detail. It directly affects how long you can work comfortably, how quickly your eyes tire, and even how focused you feel.

That's exactly why dark mode isn't just a trend for developers. For many, it's a genuine quality-of-life upgrade.

Real Reasons Developers Love Dark Mode

1. 🔧 It Reduces Eye Strain During Long Sessions

This is the big one. Staring at a bright white screen for 8+ hours is genuinely tiring. Dark mode reduces the overall amount of light your screen emits, which can reduce the strain on your eyes — especially in dim or nighttime environments.

It's not a magic cure, but many developers notice real relief after switching. Fewer headaches. Less of that burning sensation by 6 PM.

2. 💡 Code Just Looks Better on Dark Backgrounds

Syntax highlighting — the colorful way editors display different parts of your code — pops brilliantly against dark backgrounds. Keywords in blue, strings in green, comments in gray — they stand out clearly and make code much easier to scan.

On a white background, those same colors feel flatter and harder to distinguish at a glance. If you want your code to feel alive, dark mode is where syntax highlighting truly shines.

3. 🌙 It Matches the Developer's Natural Habitat

Developers often work late. Deadlines don't care about time zones. When everyone else is asleep and you're still pushing commits, a pitch-black terminal on a black background feels less aggressive on your environment — and on your mood.

Dark mode also reduces how much light your screen throws into the room, which is genuinely considerate if you're sharing a space with someone sleeping nearby.

4. ⚡ It Saves Battery on OLED and AMOLED Screens

On OLED and AMOLED displays — which are common on modern laptops and phones — true black pixels are literally turned off. Dark mode means fewer lit pixels, which means less power consumption.

For developers who code on their laptops without a charger, dark mode can genuinely squeeze extra time out of a battery. Practical and stylish.

5. 👀 It Creates a Focused, Distraction-Free Atmosphere

There's a psychological side too. A dark interface naturally draws your attention toward the content — the code, the text, the task at hand — rather than the white space around it.

Many developers describe dark mode as creating a sort of "tunnel vision" that helps them stay focused. It's the coding equivalent of noise-canceling headphones.

6. 🚀 It Looks Professional and Clean

Let's be honest — dark mode just looks good. There's a reason tech companies, dev tools, and portfolio sites often default to dark themes. It signals sophistication, technical seriousness, and modern design taste.

If you're screensharing your code in a presentation or live streaming your workflow, a dark IDE immediately looks polished. First impressions matter, even in code.

Dark Mode vs Light Mode: A Balanced Look

This is one of those debates where both sides have real points. Here's an honest breakdown:

Situation	Better Choice
Long coding sessions at night	Dark Mode ✅
Reading long documentation	Light Mode ✅
Working in a bright room or sunlight	Light Mode ✅
Working in a dim room or late hours	Dark Mode ✅
OLED laptop on battery	Dark Mode ✅
Users with certain visual impairments	Light Mode ✅
Screensharing code in presentations	Dark Mode ✅
Proofreading written content	Light Mode ✅

The honest truth? Neither is universally superior. Dark mode wins in low-light coding environments. Light mode often wins for reading heavy text in bright conditions. Many experienced developers actually toggle between the two depending on context.

Best Tips for Dark Mode Users

Choose your dark theme carefully. Pure pitch black (#000000) can actually create too much contrast with white text. Deep dark grays like #1a1a2e or #121212 are often easier on the eyes.
Match your terminal, editor, and browser to the same dark theme family for a consistent, less jarring experience.
Use a good font. On dark backgrounds, fonts like JetBrains Mono, Fira Code, or Cascadia Code are legible and look clean.
Enable OS-level dark mode so your apps and system UI stay consistent, not just your IDE.
Don't go full dark mode everywhere without thinking. Some apps just aren't optimized for it and end up looking weird or broken.
Adjust your screen brightness. Dark mode doesn't mean you need max brightness. Tone it down — your eyes will thank you.

Common Mistakes Developers Make With Dark Mode

Picking a theme that's all contrast, no comfort.
Maximum black with maximum white text looks sharp for screenshots but is brutal for 4-hour sessions. Find a theme that balances contrast with warmth. Popular ones like One Dark Pro, Dracula, and Tokyo Night are popular for a reason — they've been tuned over time.

Ignoring external lighting.
Dark mode helps most in low-light rooms. If you're working in a bright office, dark mode can actually make the screen harder to read because the ambient light creates glare on a dark surface.

Assuming dark mode fixes all eye strain.
Dark mode helps, but it doesn't replace proper habits. Take screen breaks. Follow the 20-20-20 rule (every 20 minutes, look at something 20 feet away for 20 seconds). Blink. Adjust your monitor height. No color scheme fixes poor ergonomics.

Forcing dark mode on every site using browser extensions.
Some websites are genuinely not built for dark mode. Forcing it can invert images, make colors muddy, or break layouts. Use it where it works natively when possible.

Never trying light mode again.
If you've been on dark mode for years and always feel like reading documentation is painful — try switching to a clean light theme for a week. Sometimes the brain just needs a different kind of contrast for reading-heavy work.

Conclusion

Dark mode isn't just aesthetic rebellion or developer fashion. For many developers, it's a genuine comfort upgrade that reduces eye strain, extends battery life, improves focus, and makes code easier to read — especially during those long late-night sessions that are basically a rite of passage in this profession.

That said, it's not a one-size-fits-all solution. Knowing when to use dark mode and when to switch is the real skill. The best developers stay flexible and optimize their environment for actual comfort, not just looks.

If you're not on dark mode yet, give it a serious two-week trial with a well-designed theme like Dracula or One Dark Pro. If you are on dark mode — welcome to the club. You're in good company. 🌙

Want to read more practical developer content like this? Head over to hamidrazadev.com for more articles, tips, and tutorials built for real developers.

If this post helped you or made you think differently about your setup, share it with a dev friend who's still squinting at a white screen. 😊

What Is a CMS? A Friendly Guide for Beginners and Developers 🚀

Muhammad Hamid Raza — Wed, 06 May 2026 10:52:03 +0000

Ever tried updating a small typo on a website by editing raw HTML, and ended up breaking the entire layout? 😅 If yes, welcome to the club. That tiny moment of panic is exactly why CMS platforms exist.

Today, websites are everywhere — blogs, online stores, school portals, news sites, portfolios. But not everyone wants to write code every time they need to add a blog post or update a banner. That's where a CMS quietly saves the day.

So let's break it down in plain English: what is a CMS, why do developers and non-developers love it, and when should you actually use one?

What Is a CMS?

CMS stands for Content Management System.

In simple words, a CMS is a software tool that helps you create, edit, organize, and publish content on a website — without needing to write code for every single change.

Think of it like Google Docs, but for your website. You log in, type your content, click publish, and it appears online. The CMS handles the boring technical parts behind the scenes — storing your text, managing images, organizing pages, and showing them to visitors.

A quick analogy for younger readers: imagine a school notice board. The principal doesn't rebuild the board every time there's a new notice. They just pin a new paper on it. A CMS is that notice board for your website. 📌

Popular examples you may have heard of include WordPress, Drupal, Joomla, Ghost, Strapi, Contentful, and Sanity.

Why a CMS Matters

Here's the honest truth: most website owners are not developers. They are writers, teachers, shop owners, marketers, and small business folks who just want their content online.

A CMS matters because it:

Lets non-technical people manage a website on their own.
Saves developers from updating content manually every week.
Speeds up website building since common features (login, comments, media library) come built-in.
Keeps content organized in one place so nothing gets lost.

If you're a developer, a CMS frees you to focus on the fun parts — design, performance, custom features — instead of pushing tiny content updates for clients at midnight.

And if you're a beginner learning web development, understanding CMS concepts is a huge career booster. A massive part of the web runs on CMS platforms, especially WordPress.

Benefits of Using a CMS (with Real Examples)

Here are the real, practical benefits — not just buzzwords:

No coding for everyday updates 💡

Example: A bakery owner can add a new cake to the menu without calling a developer. They just log in, upload a photo, type the price, and click publish.
Built-in user roles

Example: On a news website, editors can write articles, but only the admin can publish them. A CMS handles these permissions out of the box.
Media management made easy 🖼️

Example: Uploading 50 product images becomes a drag-and-drop task instead of an FTP nightmare.
Templates and themes

Example: A student building a portfolio can pick a clean theme in WordPress and have a working site in an afternoon.
Plugins and extensions 🔧

Example: Want a contact form, SEO tools, or an online shop? Install a plugin instead of building it from scratch.
SEO-friendly structure

Example: Most CMS platforms generate clean URLs, sitemaps, and meta tags automatically, which helps your content show up on Google.
Scales with your needs

Example: A personal blog can grow into a full magazine or e-commerce store without rebuilding the whole site.

Traditional CMS vs Headless CMS (Quick Comparison)

This is one comparison that genuinely helps, especially for developers.

Traditional CMS (like WordPress)

Frontend and backend are tightly connected.
Easier to set up for non-developers.
Great for blogs, small business sites, and portfolios.
Less flexible if you want to use modern frameworks like React or Next.js directly.

Headless CMS (like Strapi, Sanity, Contentful)

Only handles the backend (the content).
You build the frontend with any framework you like.
Perfect for apps, multi-platform projects (web + mobile), and modern stacks.
Requires more developer involvement to set up.

Easy rule of thumb:

If your client just wants a website, a traditional CMS is usually enough. If you're building a custom app or delivering content to multiple platforms, go headless. ⚡

Best Tips: Do's and Don'ts

Do's ✅

Pick a CMS that matches your project's size. Don't use a hammer for a thumbtack.
Keep your CMS and plugins updated to avoid security issues.
Take regular backups. Future-you will thank present-you.
Use strong passwords and two-factor authentication for admin accounts.
Learn the basics of how the CMS stores data — it helps when something breaks.

Don'ts ❌

Don't install dozens of plugins "just in case." Each one adds weight and risk.
Don't edit core CMS files directly. Updates will overwrite your changes.
Don't ignore performance. A slow CMS site loses visitors fast.
Don't pick a CMS just because it's trendy. Pick one that fits the project.

Common Mistakes People Make

Even experienced developers slip up here. A few mistakes I see often:

Choosing the wrong CMS. People grab WordPress for everything, even when a static site generator or headless CMS would be simpler and faster.
Skipping security basics. Default admin usernames, weak passwords, and outdated plugins are an open invitation for attackers.
Overloading the site with plugins. Each plugin is extra code running on your site. Too many plugins = slow site + more bugs.
Forgetting backups. One bad update can wipe out months of work. Backups are not optional.
Ignoring the editor experience. If your client struggles to add a blog post, the CMS setup failed — no matter how clean your code is.

These mistakes happen because CMS platforms feel "easy" at first, so people skip the planning step. A few minutes of thinking ahead saves days of fixing later.

Final Thoughts

A CMS is simply a tool that makes managing website content easier for everyone — from a teenager starting their first blog to a full development team running a global news platform.

If you're a beginner, start with something like WordPress to feel the magic of publishing without coding. If you're a developer, explore headless CMS options to combine clean backends with modern frontends. Either way, you're learning a skill the web genuinely runs on. 🌍

If this guide helped clear things up, share it with a friend who's still scared of editing their website. And if you enjoyed the writing style, you'll find more friendly developer guides on hamidrazadev.com.

Drop a comment with the CMS you use — I'm always curious to hear what works for other devs. 😊

Happy building!

Why DNS Was Introduced and How It Replaced Raw IP Addresses

Muhammad Hamid Raza — Tue, 05 May 2026 08:57:35 +0000

Have you ever wondered what actually happens when you type google.com into your browser and press Enter? 🤔

Behind the scenes, a quiet but brilliant system kicks into action — one that most people use thousands of times a day without ever thinking about it. That system is DNS, the Domain Name System.

Before DNS existed, accessing a website meant memorizing long strings of numbers. We're talking things like 192.168.1.1 but for every single website on the internet. Sounds exhausting, right?

This post explains why DNS was introduced, how it replaced raw IP addresses, and why understanding it makes you a sharper developer, a better debugger, and honestly just a more informed person on the internet.

What Is an IP Address?

Before we can appreciate DNS, we need to understand what it replaced.

Every device connected to the internet — your laptop, your phone, the server hosting your favorite website — has an IP address. Think of it like a home address. If you want to send a letter, you need to know where the house is. If your browser wants to load a website, it needs to know the server's address.

An IPv4 address looks like this: 142.250.190.78
An IPv6 address looks like this: 2607:f8b0:4004:c09::64

These numbers are how machines identify and talk to each other. Accurate? Yes. Human-friendly? Absolutely not.

What Is DNS?

DNS stands for Domain Name System.

It is essentially the internet's phonebook. Instead of memorizing a number, you remember a name — like google.com or github.com — and DNS quietly translates that name into the correct IP address behind the scenes.

Here is a simple analogy. Imagine you want to call your friend Ayesha. You don't memorize her phone number. You just search "Ayesha" in your contacts and your phone finds the number for you. DNS does exactly that — but for websites.

You type a human-friendly name → DNS finds the IP address → your browser connects to the right server.

Simple. Elegant. And completely invisible when it works correctly.

Why Was DNS Introduced? The Real Story

DNS did not appear out of nowhere. It was born out of a very real and growing problem.

The Early Internet and the HOSTS.TXT File

In the early days of the internet (the ARPANET era, late 1960s to early 1980s), the network was tiny. There were only a few hundred computers connected to it — mostly at universities and research labs.

Back then, every computer had a file called HOSTS.TXT. This plain text file listed every hostname and its matching IP address on the entire network.

It looked something like this:

192.0.0.1    stanford
192.0.0.2    mit
192.0.0.3    ucla

When you wanted to connect to another machine, your computer looked up the name in this file and got the IP. Simple enough — when the internet was small.

There was one central copy of HOSTS.TXT maintained by Stanford Research Institute. Every network connected to ARPANET would download this file periodically to stay updated.

The Problem That Made HOSTS.TXT Impossible to Scale

As the internet grew through the late 1970s and early 1980s, this system started to break down fast. Here is why:

The file grew too large. With hundreds and then thousands of machines, HOSTS.TXT became huge and slow to process.
Updates were too slow. It took days for changes to spread across the network. New hostnames would not appear immediately everywhere.
Name conflicts were a nightmare. Two organizations might register the same hostname because there was no central authority to prevent it.
Bandwidth was being wasted. Every machine had to download the full file constantly to stay current.
Human memory still had limits. Even with the file doing the lookup, administrators had to manage it manually.

The internet was growing, and HOSTS.TXT simply could not keep up.

Enter Paul Mockapetris

In 1983, computer scientist Paul Mockapetris designed and published the DNS specification in RFC 882 and RFC 883. His solution was both smart and scalable.

Instead of one giant file maintained in one place, DNS would be a distributed, hierarchical database spread across thousands of servers around the world. No single server would know everything. But together, they would be able to answer any hostname query on the planet.

This was the turning point. DNS replaced HOSTS.TXT, and it has been running the internet ever since.

Why This Matters for Developers

You might be thinking, "Okay, interesting history — but why should I care as a developer?"

Fair question. Here is why DNS knowledge is actually useful day-to-day:

1. Debugging Network Issues

When your app cannot connect to an external API or your domain is not loading, DNS is often the first thing to check. Understanding how DNS works helps you debug faster instead of staring blankly at a timeout error.

2. Deploying Apps and Configuring Domains

When you deploy a Next.js app to Vercel or a server on DigitalOcean, you always have to update DNS records — A records, CNAME records, TXT records. Knowing what these mean saves you hours of confusion.

3. Setting Up Email

Configuring a custom email domain requires DNS records like MX and SPF. Without understanding DNS basics, this feels like dark magic.

4. Performance and Caching

DNS responses are cached for a period defined by TTL (Time to Live). If you update a DNS record and it does not take effect immediately, that is TTL doing its job. Knowing this prevents unnecessary panic.

5. Security

DNS-based attacks like DNS spoofing and DNS hijacking are real threats. Developers and sysadmins who understand DNS are better equipped to protect their infrastructure.

How DNS Actually Works: A Step-by-Step Breakdown

Let's trace what happens when you type hamidrazadev.com into your browser.

Step 1 — Check the local cache
Your browser first checks if it has recently resolved this domain. If yes, it uses the cached IP and skips the rest.

Step 2 — Ask the Recursive Resolver
If not cached, your device contacts a recursive resolver — usually provided by your ISP or a public DNS service like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare).

Step 3 — Ask the Root Name Server
The resolver asks a Root Name Server where to find information about .com domains. There are 13 root server clusters around the world (operated by organizations like ICANN, NASA, and Verisign).

Step 4 — Ask the TLD Name Server
The root server points the resolver to the TLD (Top-Level Domain) Name Server responsible for .com.

Step 5 — Ask the Authoritative Name Server
The TLD server points to the Authoritative Name Server for hamidrazadev.com specifically — this is the server that actually knows the IP address.

Step 6 — Get the IP address
The authoritative server returns the IP address. The resolver caches it and sends it to your browser.

Step 7 — Your browser connects
Your browser now has the IP address and makes a request to the server. The website loads. 🚀

This entire process typically completes in milliseconds.

DNS vs. Raw IP Addresses: A Quick Comparison

Feature	Raw IP Address	DNS
Human-readable	❌ No	✅ Yes
Easy to remember	❌ Very hard	✅ Simple names
Scales with internet growth	❌ No	✅ Distributed system
Supports changes	❌ Hard to update	✅ Update DNS records anytime
Required for email/SSL setup	❌ Insufficient	✅ Essential

Using raw IPs still works in certain scenarios — like internal networks or hardcoded server calls. But for public-facing services, DNS is non-negotiable.

Common DNS Record Types You Should Know

Here is a quick reference for the records developers deal with most often:

A Record — Maps a domain to an IPv4 address. This is the most common record.
AAAA Record — Maps a domain to an IPv6 address.
CNAME Record — Points one domain to another domain (alias). Used a lot in Vercel and Netlify deployments.
MX Record — Specifies the mail server for a domain. Needed for email.
TXT Record — Stores arbitrary text. Used for domain verification and SPF/DKIM email authentication.
NS Record — Identifies which name servers are authoritative for a domain.

Best Tips for Working with DNS

✅ Do's

Lower your TTL before making changes. Before you update a DNS record, lower the TTL to something like 300 seconds (5 minutes). This makes changes propagate faster. Once stable, you can raise it back.
Use a reliable DNS provider. Cloudflare DNS (1.1.1.1) and Google DNS (8.8.8.8) are fast and trustworthy for resolvers.
Use nslookup or dig to debug. These command-line tools let you query DNS directly and are invaluable for troubleshooting.
Document your DNS records. Keep a simple spreadsheet or note of what each record does. Future-you will thank present-you.

❌ Don'ts

Don't expect instant propagation. DNS changes take time to spread globally — sometimes minutes, sometimes up to 48 hours depending on TTL values.
Don't delete records without checking dependencies. Removing an MX record will break your email. Removing a CNAME might break your subdomain.
Don't rely on IP addresses directly in production configs. If the server IP changes (which happens), you will have to update every hardcoded reference. Use domain names instead.

Common Mistakes People Make with DNS

Mistake 1: Panicking when changes don't apply immediately

DNS propagation is not instant. When you update a record and it doesn't work right away, that's normal. Wait for the TTL to expire. Use tools like whatsmydns.net to track propagation globally.

Mistake 2: Forgetting to renew a domain

Your domain is registered, not owned forever. When it expires, your DNS stops working and someone else can register it. Set auto-renewal and use a real email for domain alerts.

Mistake 3: Confusing CNAME and A records

A CNAME points to another domain name. An A record points to an IP address. Using a CNAME where an A record is needed (or vice versa) is a classic setup mistake that causes hours of confusion.

Mistake 4: Setting TTL too high during migration

If you are moving a website to a new server and your TTL is set to 86400 (24 hours), visitors may keep hitting the old server for an entire day. Always lower TTL in advance before migrations.

Mistake 5: Not testing locally before going live

Use dig or nslookup to confirm your DNS is pointing where you think it is before announcing a new deployment to the world.

Conclusion

DNS is one of those technologies that works so silently and reliably that most people forget it exists — until it breaks. 😄

What started as a simple text file on a handful of computers in the early internet became a distributed, global system that handles billions of queries every single day. It replaced raw IP addresses not by eliminating them, but by making them invisible to humans — and that invisibility is the point.

For developers, understanding DNS is not just academic knowledge. It is a practical skill that shows up in deployments, debugging sessions, email setups, domain migrations, and security decisions. The more comfortable you are with it, the less mysterious the internet becomes.

The big takeaway: IP addresses are how machines talk. DNS is how humans stay sane while that's happening.

If you found this post helpful, feel free to share it with a fellow developer or student who is just starting to explore how the internet works. 😊

For more developer content, tutorials, and deep dives like this one, visit hamidrazadev.com — new posts go up regularly and cover topics from frontend development to networking concepts like this one.

Drop a comment if you have questions, or share this post if it cleared something up for you. Happy coding! 🚀

VS Code 1.118 Is Here — And It's All About Smarter Agents, Faster Code, and Less Token Waste

Muhammad Hamid Raza — Mon, 04 May 2026 13:42:55 +0000

You updated VS Code, glanced at the changelog, and thought, "Cool, more Copilot stuff." Then you closed it and moved on.

But wait — this release is actually worth a proper look. 👀

VS Code 1.118 (released April 29, 2026) is packed with features that genuinely change how you work with AI agents, search your codebase, manage chat history, and even keep your token usage from quietly draining your budget. Whether you're using Copilot daily or just exploring AI-assisted coding, there's something real here for you.

So let's break it down in plain English — no corporate fluff, just the stuff that matters.

What Is VS Code 1.118?

VS Code 1.118 is the latest monthly release of Visual Studio Code — Microsoft's free, open-source code editor that millions of developers use every day.

Each release ships new features, bug fixes, and improvements. This one focuses heavily on the agent experience, which basically means making Copilot smarter, faster, and cheaper to run.

If you're not familiar with agents: think of them as AI that doesn't just answer questions — they act. They write code, run terminal commands, search your files, and loop through tasks until the job is done. This release makes all of that smoother and more efficient.

Why This Release Matters

Here's the honest truth: AI-assisted coding is no longer a gimmick. It's becoming part of the daily workflow for a lot of developers.

But more AI usage means more tokens. More tokens means higher costs — especially now that GitHub announced Copilot is moving to usage-based billing on June 1, 2026.

VS Code 1.118 directly addresses this. The team made serious engineering improvements to reduce how many tokens each request uses, without making Copilot worse. That's a meaningful change for anyone who relies on it.

Beyond cost, this release also:

Makes it easier to search across massive codebases
Lets you control Copilot sessions remotely, from your phone
Helps you revisit your chat history like a dev journal
Brings TypeScript 7 one step closer to everyone

That's not a small update. That's a solid month of real improvements.

Key Features with Real-Life Examples

🚀 Remote Control for Copilot CLI Sessions

Imagine you kick off a long agent task before lunch. While you're away, it hits a decision point and stops. Previously, you'd have to be back at your machine to continue.

With remote control, you can approve, steer, or check progress from your phone using the GitHub mobile app — while the session keeps running on your machine in the background.

Enable it with the github.copilot.chat.cli.remote.enabled setting and type /remote on in a Copilot CLI chat to get started.

🔍 Semantic Indexing for All Workspaces

Before 1.118, semantic search (which lets Copilot find code by meaning, not just exact words) only worked with GitHub or Azure DevOps repos.

Now it works for any workspace. So if you ask Copilot "where do we handle user authentication?", it can find code with terms like signIn, verifyCredentials, or OAuth token exchange — even if the word "authentication" never appears.

For local projects, it might take a few minutes to build the index initially. But once it's ready, Copilot understands your codebase much better.

💡 GitHub Text Search Across Repos and Orgs

Semantic search is great for fuzzy intent. But sometimes you need an exact match — like finding a specific error message or API name across your entire organization's codebase.

The new githubTextSearch agent tool does a grep-style search across any GitHub repo or organization, giving Copilot a much sharper way to look things up outside your current workspace.

⚡ Massive Token Efficiency Improvements

This is the one that affects your wallet directly. The team rolled out several changes:

Cache reuse across turns: Over 93% of each request is now served from cache in active agent sessions. For Anthropic models, cached tokens cost roughly 10x less.
Tool search tool: Instead of loading every possible tool schema on every request, VS Code now loads a small core set and fetches the rest only when needed. This alone saves up to 20% in token usage for Claude Sonnet 4.5+ users.
Agentic search and execution tools: Powered by smaller, cheaper models that handle specific tasks like codebase exploration and terminal commands. Early results show up to 20% additional token savings.

None of this changes how Copilot behaves — it just makes it cheaper to run.

📋 Chronicle — Your Chat History as a Dev Journal (Experimental)

Ever tried to write a standup report and completely blanked on what you did yesterday?

Chronicle tracks your Copilot chat sessions in a local SQLite database — recording which files you touched, which PRs you referenced, and what you were working on. Then you can ask it things like:

/chronicle:standup → Generates a standup report from the last 24 hours
/chronicle:tips → Gives you personalized prompting tips based on your usage
/chronicle what files did I edit yesterday? → Free-form natural language queries

Enable it with github.copilot.chat.localIndex.enabled. It's experimental, but genuinely useful.

🛠️ TypeScript 7.0 Beta Support

TypeScript 7 is a full rewrite in native code. The performance difference is wild — VS Code's own build time dropped from 60 seconds to 10 seconds just by switching to TS 7 for type checking.

You can try it today by installing the TypeScript Native preview extension. It's still beta, so it's not for production, but it's worth testing.

🖥️ VS Code Agents App (Insiders)

If you're on VS Code Insiders, the Agents app now integrates more tightly:

Launch it directly from the title bar
Access it from the browser at insiders.vscode.dev/agents (requires a Dev Tunnel)
Use the Claude Agent alongside Copilot and other agents
Tabs persist across sessions, so your browser doesn't refresh when you switch context

It's still in preview, but it's shaping up into a genuinely useful parallel workflow tool.

Before vs. After: How Token Usage Has Changed

Area	Before 1.118	After 1.118
Cache reuse per request	Variable	93%+ in active sessions
Tool schema loading	All tools every turn	Core set + on-demand loading
Terminal command handling	Main model	Smaller, dedicated execution tool
Codebase search	Main model	Smaller, dedicated search tool
Estimated token savings	Baseline	Up to ~20-40% in agent workflows

This doesn't mean Copilot suddenly becomes free — but for heavy users, the cumulative difference will be noticeable.

Best Tips for Getting the Most Out of VS Code 1.118

✅ Do:

Enable github.copilot.chat.localIndex.enabled to try Chronicle — your future self will thank you at standup
Run Build Codebase semantic index manually if Copilot seems off on local projects
Try /remote on in Copilot CLI before leaving your desk for long agent tasks
Install the TypeScript Native preview extension in a non-production project to test TS 7 performance

❌ Don't:

Expect remote control to work without enabling the github.copilot.chat.cli.remote.enabled setting first
Assume TS 7 is production-ready — it's still beta
Ignore the Chronicle feature just because it's experimental; it's genuinely useful for tracking work

Common Mistakes to Avoid

Skipping experimental features entirely. A lot of the best stuff in 1.118 is behind experimental flags. That's not a warning sign — it's a chance to try genuinely useful features before they're stable. Just use them in non-critical projects first.

Forgetting to build the semantic index. If you're on a local workspace (not GitHub/ADO), Copilot won't have semantic search until the index is ready. Run the build command manually if you want it available right away.

Ignoring the token efficiency changes. If you're on a usage-based plan, these improvements aren't just nice to have — they affect your bill. Make sure you're on Claude Sonnet 4.5+ or GPT-5.4/5.5 to benefit from the tool search savings.

Not checking for updates manually. VS Code 1.118 is rolling out gradually. If you haven't seen it yet, go to Help → Check for Updates to get it right away.

Wrapping Up

VS Code 1.118 is a focused, well-executed release. It doesn't add flashy gimmicks — it makes the AI-assisted workflow more reliable, more efficient, and cheaper to run.

Remote control for CLI sessions, semantic search everywhere, Chronicle for tracking your work, and serious token savings across the board — these are practical improvements that affect your daily workflow.

If you're a developer who uses Copilot regularly, this update is worth enabling the experimental features and exploring properly.

Check for the update, enable Chronicle, test the remote control — and enjoy paying a little less in token costs. 🎉

Want more VS Code breakdowns, dev tools, and web development content? Head over to *hamidrazadev.com** for more practical articles written by a developer, for developers.*

If this post saved you time or taught you something new, share it with your team or drop a comment below — it helps more than you know. 🙌

WiFi vs Cellular Data: Why WiFi Often Wins for Daily Internet Use 🌐

Muhammad Hamid Raza — Mon, 04 May 2026 10:26:25 +0000

We've all been there. You're downloading a big update, watching a tutorial, or pushing code to GitHub, and suddenly your mobile data vanishes faster than free pizza at a developer meetup. 🍕

Then you connect to WiFi, and everything just… works. Smoother. Faster. No panic about your data balance.

But why does WiFi usually feel better than cellular data? Is it always the right choice? And when should you actually stick with mobile data instead?

Let's break it down in simple words, without any tech-jargon overload. Ready to finally understand the difference?

What Is WiFi and What Is Cellular Data?

Before we compare them, let's keep things super simple.

WiFi is internet that comes from a nearby router. The router is connected to a wired internet line (fiber, cable, DSL, or similar), and it shares that connection wirelessly with devices around it, usually inside a home, office, café, or airport.

Cellular data is internet that comes from mobile network towers. Your SIM card connects your phone to those towers, and the tower sends data to your device through radio signals. This is what powers 3G, 4G LTE, and 5G.

Think of it like this:

WiFi is like drinking water from a tap at home. 🚰
Cellular data is like buying bottled water on the go. 💧

Both give you water. But one is cheaper at home, and the other is convenient when you're traveling.

Why This Topic Matters

Internet is no longer optional. It's how we learn, work, build apps, attend meetings, watch tutorials, and stay connected with people we care about.

For developers and students, the choice between WiFi and cellular data affects:

How much money you spend each month
How fast you can download tools, packages, and updates
Whether your video calls freeze during a client demo
How safely you connect to the internet

A small choice, but a big impact on your daily routine.

So the question is simple: why do most people prefer WiFi when it's available? Let's get into the real reasons.

Benefits of WiFi Over Cellular Data (with Real-Life Examples)

Here are the practical reasons WiFi often beats cellular data for most everyday tasks.

1. Usually Cheaper for Heavy Use 💰

Most home and office WiFi plans are unlimited or have very high data limits. Cellular plans, especially prepaid ones, often charge more per GB.

Example: Downloading a 5 GB Android Studio update on mobile data could eat your whole weekly package. On WiFi, it's just… a download.

2. Better for Large Downloads and Uploads

Pushing a Docker image, cloning a big repo, or uploading video content? WiFi is usually more comfortable for that kind of work because routers are built to handle long, heavy sessions without throttling.

Example: A YouTuber uploading a 4K video will almost always pick WiFi to avoid burning through their mobile data plan.

3. More Stable for Video Calls and Meetings

WiFi tends to give a steadier connection inside buildings where cellular signals can drop. If your office is on the 7th floor with thick walls, mobile signals might struggle, but the WiFi router right next to you won't.

Example: During a Zoom standup, WiFi often keeps your video sharp while cellular data can get jittery indoors.

4. Multiple Devices, One Connection

A single WiFi router can serve your laptop, phone, tablet, smart TV, and even your smart bulb at the same time. With cellular data, every SIM is a separate plan (unless you use hotspot, which drains your phone battery fast).

Example: A family of four streaming, gaming, and working from home on a single WiFi plan is much cheaper than four separate mobile data plans.

5. No Stress About Daily or Monthly Limits

Many cellular packages have strict caps. Once you cross them, speed drops or extra charges kick in. Most home WiFi plans either don't have limits or have very generous ones.

Example: Binge-watching a coding course on Udemy at night? WiFi handles it without sweat.

6. Often Faster Where Coverage Is Weak

If you live in an area with weak mobile signal, WiFi (powered by a wired connection) can give you better speeds than cellular ever could in that location.

7. Better Battery Life

This one surprises many people. Phones generally use less battery on WiFi than on cellular, especially when the cellular signal is weak and the phone is constantly searching for a tower.

Example: Ever notice your phone heats up and drains fast in low-signal areas? That's your phone working overtime to stay connected.

WiFi vs Cellular Data: A Quick Comparison

Both have their place. Here's an honest, balanced look.

Feature	WiFi	Cellular Data
Cost for heavy use	Usually cheaper	Often more expensive per GB
Mobility	Works in a fixed area	Works almost anywhere with signal
Speed	Depends on the router and plan	Depends on tower, network, and location
Stability indoors	Generally better	Can drop behind walls
Setup needed	Router required	Just a SIM and signal
Security	Safer on private networks, risky on public ones	Generally encrypted by the carrier
Battery use	Lower	Higher, especially on weak signal
Best for	Home, office, study, big downloads	Travel, commute, emergencies, outdoors

So WiFi isn't always better. It's better for the right situation, which is usually most of our day.

Pros and Cons in Plain Words

Pros of WiFi

Cheaper for heavy and long usage
More stable for indoor work
Supports many devices at once
Lower battery drain
Great for big downloads and video calls

Cons of WiFi

Tied to one location (you can't take your home router to the park)
Public WiFi can be unsafe without a VPN
Needs hardware (router, modem) and setup
If the router or internet line fails, the whole network goes down

Pros of Cellular Data

Works almost anywhere with signal
No setup, just insert a SIM
Good for travel, road trips, and outdoor work
Useful as a backup when WiFi fails

Cons of Cellular Data

Usually pricier per GB
Speeds can drop during peak hours or in crowded areas
Drains battery faster
Hits data caps quickly with heavy usage

The honest truth? Most people don't have to pick one. They use WiFi at home and work, and cellular data on the move. That combo wins almost every time.

Best Tips and Practical Do's & Don'ts

A few habits I've personally found useful as a developer:

Do:

Use WiFi for big tasks: OS updates, IDE downloads, package installs, Docker pulls, and Zoom calls.
Keep mobile data on standby for when WiFi fails (which always happens 5 minutes before a deadline 😅).
Use a VPN on public WiFi, especially in airports, cafés, and hotels.
Set "WiFi only" mode for app updates, cloud backups, and large media downloads.
Restart your router every few weeks. It really does help.

Don't:

Don't log into banking or work accounts on open public WiFi without a VPN.
Don't waste mobile data on auto-playing videos. Turn off autoplay in YouTube, Instagram, and similar apps.
Don't stand right next to the microwave while complaining about slow WiFi. (Yes, microwaves can interfere with 2.4 GHz networks.) 🔧
Don't forget to turn off your hotspot. It silently drains your phone for hours.

Common Mistakes People Make

Even tech-savvy folks slip up here. A few I see often:

1. Trusting any "Free WiFi" sign.
Free WiFi is great, but some networks are set up to capture data. If the network has no password and no login page from a known brand, be careful.

2. Forgetting that "Unlimited" isn't always unlimited.
Many cellular "unlimited" plans slow you down after a certain amount of data. Read the fine print before relying on it for work.

3. Using mobile hotspot as a long-term solution.
Hotspot is a lifesaver in emergencies, but using it daily for hours hurts your phone battery, heats up the device, and burns through data fast.

4. Ignoring router placement.
A router stuffed inside a closet behind a TV will give weak signals. Place it in an open area, ideally in the center of your home or workspace.

5. Not securing the home WiFi.
Leaving your home network with the default password is a small but real security risk. Change it once, and forget about it.

6. Blaming the internet for everything.
Sometimes it's not WiFi or cellular at fault. It's the website, the server, or that one Chrome tab eating all your RAM. 👀

Final Thoughts

WiFi and cellular data aren't enemies. They're teammates. WiFi is your reliable home base, great for heavy work, study, and long sessions. Cellular data is your portable backup, ready whenever you step outside.

For most developers, students, and everyday users, WiFi handles 80% of daily internet needs more cheaply and comfortably, while cellular data steps in for the remaining 20% on the go.

The smartest move isn't picking one. It's knowing when to use which. Once you understand that, you stop wasting money, save battery, and avoid those frustrating "buffering" moments during important calls.

If this article helped clear things up, share it with a friend who keeps blowing through their data plan. 🚀

For more easy-to-follow tech blogs, visit hamidrazadev.com, drop a comment if you have a tip I missed, and let me know your own WiFi-vs-data story. I'd genuinely love to read it. 😊

Happy coding, and may your connection always be stable.

How Web Browsers Work — The Phenomenon Behind Every Web Experience

Muhammad Hamid Raza — Sun, 03 May 2026 11:27:31 +0000

Every time you type a URL and hit Enter, a small miracle unfolds in milliseconds. Most people never think twice about it. Developers should.

1. Introduction — More Than a Window

Open Chrome. Type a URL. Press Enter. A page appears.

Simple, right?

Not even close.

Behind that instant result is one of the most complex pieces of software ever written. A modern web browser is simultaneously a network client, a rendering engine, a JavaScript runtime, a security sandbox, and a mini operating system — all working in perfect coordination, every single time you browse.

Google Chrome has over 35 million lines of code. Firefox has been actively developed for more than two decades. These aren't simple apps — they're engineering marvels disguised as everyday tools.

In this post, we're going to pull back the curtain completely. From the moment you hit Enter to the pixel appearing on your screen — this is how browsers actually work.

2. Step One — Finding the Server (DNS Resolution)

Before anything loads, the browser needs to answer one question: Where is this website?

Computers don't understand domain names like hamidrazadev.com. They speak in IP addresses like 104.21.45.78. The system that translates between the two is called DNS — Domain Name System.

Here's the lookup chain:

Browser Cache — Has it visited this domain recently? If yes, use the saved IP.
OS Cache — Ask the operating system's own DNS cache.
Router Cache — Ask the local network router.
ISP DNS Resolver — Ask your internet provider's DNS server.
Root → TLD → Authoritative Nameserver — A recursive query through the global DNS hierarchy until the correct IP is returned.

This entire process often completes in under 20 milliseconds — but it's the invisible foundation of every page load.

Connecting to the Server — TCP Handshake

With the IP address in hand, the browser opens a TCP connection using a three-way handshake:

Client  →  SYN         →  Server   (I want to connect)
Client  ←  SYN-ACK     ←  Server   (Acknowledged, go ahead)
Client  →  ACK         →  Server   (Connection established)

For https:// sites (which is basically everything today), a TLS handshake follows immediately after — exchanging cryptographic certificates, verifying the server's identity, and establishing an encrypted channel. This is what puts the padlock in your address bar.

Only after all of this does the browser send the actual request:

GET / HTTP/1.1
Host: hamidrazadev.com
Accept: text/html,application/xhtml+xml
Accept-Encoding: gzip, deflate, br

3. Step Two — The Server Responds

The server processes the request and sends back an HTTP response. This includes:

Status Code — 200 OK, 301 Redirect, 404 Not Found, 500 Server Error
Response Headers — Content type, caching rules, security policies, cookies
Response Body — The actual HTML markup

One of the most important things to understand here: the browser does not wait for the full HTML to download before it starts working. It reads the response as a stream, processing bytes as they arrive over the network. This is called streaming parsing — and it's the reason you sometimes see a page begin rendering before it's fully loaded.

Modern browsers also take advantage of HTTP/2 and HTTP/3, which allow multiple resources (HTML, CSS, JS, images) to be fetched over a single connection simultaneously — a massive leap over HTTP/1.1's one-request-at-a-time model.

4. Step Three — Parsing HTML into the DOM

As HTML bytes arrive, the browser's HTML Parser gets to work. Its job is to convert raw markup text into a structured, in-memory data structure called the DOM — Document Object Model.

Think of it as a tree:

Document
└── <html>
    ├── <head>
    │   ├── <title>My Site</title>
    │   └── <link rel="stylesheet" href="styles.css">
    └── <body>
        ├── <header>
        │   └── <nav>...</nav>
        ├── <main>
        │   └── <article>...</article>
        └── <footer>...</footer>

Every HTML element becomes a node. Every node has a parent, zero or more children, and sibling relationships. This tree is what JavaScript manipulates at runtime — adding, removing, and modifying nodes to create dynamic UIs.

Parser Blocking — The Hidden Performance Trap

Parsing is not always a straight line. The HTML parser can get blocked:

<link rel="stylesheet"> — Triggers a CSS file fetch. Rendering is blocked until CSS is downloaded and parsed (to avoid a flash of unstyled content).
<script> (without async/defer) — The parser stops completely to download and execute the JavaScript before continuing.
<img>, <video> — Non-blocking; parallel fetches are fired off but don't halt the parser.

This is exactly why developers are told to put <script> tags at the bottom of the body, or use defer — to avoid stalling the parser mid-document.

5. Step Four — Building the CSSOM

While the HTML parser builds the DOM, a parallel process handles your CSS — constructing the CSSOM (CSS Object Model).

Every style rule, from every source (<style> tags, external stylesheets, inline styles) is parsed and organized into its own tree. The browser then applies the cascade algorithm to determine which styles actually apply to each element, resolving conflicts using:

Origin — Browser defaults vs. developer styles vs. user overrides
Specificity — #id > .class > element selector
Order of appearance — Later rules override earlier ones at equal specificity
Inheritance — Some properties (like font-family) inherit from parent to child automatically

Once both the DOM and CSSOM are complete, the browser merges them into the Render Tree — a new tree containing only the visible elements, each annotated with their final computed styles.

Elements with display: none are excluded entirely. Elements with visibility: hidden remain in the tree (they still occupy space) but are painted transparently.

6. Step Five — The Rendering Pipeline

With the render tree ready, the browser enters the rendering pipeline — the process of turning data into actual pixels. This happens in four distinct stages:

1. Layout (Reflow)

The browser calculates the exact position and dimensions of every element on the page. This involves:

Box model calculations (margin, border, padding, content width/height)
Flexbox and CSS Grid algorithms
Text wrapping and line-breaking
Relative and absolute positioning

Layout is computed from the root of the render tree downward. Changing a single element's size can trigger a reflow of its descendants and siblings — which is why layout-thrashing in JavaScript is a serious performance concern.

2. Paint

The browser walks the render tree and records paint operations — drawing text, colors, borders, box shadows, images — layer by layer. This stage produces a list of draw calls, not actual pixels yet.

Modern browsers split the page into multiple layers (think: transparent sheets stacked together). Elements that animate or change frequently are promoted to their own layer so they can be updated independently without repainting the rest of the page.

3. Rasterization

Paint commands are converted to actual pixels — either on the CPU or, more commonly, the GPU. The page is broken into tiles and rasterized in parallel for speed.

4. Composite

The GPU combines all rasterized layers into the final frame displayed on screen. CSS properties like transform and opacity are handled entirely at this stage — which is why they're the gold standard for performant animations. They skip Layout and Paint entirely.

The full pipeline looks like this:

JavaScript → Style Recalc → Layout → Paint → Composite
     ↑                                              ↓
  DOM/CSSOM Changes                         Frame on Screen

Browsers target 60 frames per second — that's one frame every 16.67ms. Miss that budget, and you get visible jank.

7. Step Six — JavaScript Execution

No browser discussion is complete without the JavaScript engine — arguably the most complex component of all.

Different browsers ship different engines:

V8 — Chrome, Edge, Node.js
SpiderMonkey — Firefox
JavaScriptCore (Nitro) — Safari

They all follow a similar pipeline:

Source Code → AST → Bytecode → JIT Machine Code

Parsing — JS source is parsed into an Abstract Syntax Tree (AST)
Bytecode Compilation — The AST is compiled to bytecode by an interpreter (e.g., V8's Ignition)
JIT Optimization — Frequently-executed ("hot") code paths are recompiled to highly optimized native machine code (e.g., V8's TurboFan)
Deoptimization — If assumptions change (e.g., a variable's type changes), the JIT compiler throws away optimized code and falls back to bytecode
Garbage Collection — Unreachable memory is automatically freed using a generational GC algorithm

The Event Loop — Why JS Doesn't Freeze

JavaScript is single-threaded — one call stack, one execution context at a time. Yet it handles async operations (network requests, timers, events) without blocking. How?

The Event Loop:

Call Stack → empty? → Check Microtask Queue → Check Macrotask Queue → Push callback → Repeat

Long-running browser operations (fetch, setTimeout, DOM events) are handled by Web APIs in C++ — outside the JS thread.
When they complete, their callbacks enter a queue.
The event loop picks callbacks off the queue and pushes them onto the call stack only when it's empty.

This is why async/await and Promises don't block the UI — they defer callbacks until the call stack is free.

8. The Bigger Picture — Security, Caching & Performance

Process Isolation & The Sandbox

Modern browsers run each tab in its own sandboxed OS process. Even if malicious JavaScript runs in one tab, it cannot access:

Another tab's DOM or data
Your file system
OS-level resources

This is enforced at the OS level — not just by browser rules. A crashed tab crashes its process, not the entire browser.

Key security mechanisms include:

Same-Origin Policy (SOP) — JavaScript on site-a.com cannot read data from site-b.com
Content Security Policy (CSP) — Server-defined rules about which scripts and resources are allowed to load
HTTPS + HSTS — Enforces encrypted connections and prevents downgrade attacks
Cross-Origin Resource Sharing (CORS) — Controlled exceptions to SOP for trusted cross-origin requests

Caching — Speed Through Memory

Browsers cache aggressively to eliminate redundant work:

Cache Type	Lifetime	Speed
Memory Cache	Tab session	Instant
Disk Cache	Controlled by HTTP headers	Fast
Service Worker Cache	Programmatic / Persistent	Flexible

The Cache-Control, ETag, and Last-Modified headers give servers fine-grained control over how long resources are cached and when they expire.

Modern Performance Techniques

<link rel="preload"> — Fetch critical resources (fonts, hero images) before the parser discovers them
<link rel="dns-prefetch"> — Resolve third-party domains early
loading="lazy" — Defer off-screen image/iframe loads
async / defer on scripts — Avoid parser blocking
HTTP/3 + QUIC — Faster connection establishment, especially on lossy mobile networks
Brotli Compression — Smaller transfer sizes than gzip for text-based assets

Final Thoughts — Know Your Runtime

Every page load you've ever experienced — every click, every scroll, every animation — was the product of this entire pipeline running in perfect orchestration, usually in under a second.

As a developer, understanding this isn't just trivia. It's leverage.

It's the difference between a 4-second load and a 0.9-second one. Between janky scroll and buttery 60fps. Between an XSS vulnerability and a hardened app. Between a developer who writes code and one who understands the system their code runs in.

The browser is your runtime. Respect it. Understand it. And build for it with intention.

Run Powerful AI Models Offline on Your Phone with Google AI Edge Gallery (Android & iOS)

Muhammad Hamid Raza — Fri, 01 May 2026 10:24:13 +0000

Have you ever wished you could use a powerful AI assistant without burning through your mobile data — or worrying about your private conversations being sent to some server halfway around the world?

That wish just became reality. 🚀

Google's AI Edge Gallery app lets you download and run real open-source large language models (LLMs) directly on your iPhone or Android phone. No internet. No cloud. No data leaving your device. Just raw AI power running straight from your hardware.

But wait — how good can phone AI actually be? Better than you'd expect. Let's dig in.

What Is Google AI Edge Gallery?

AI Edge Gallery is a free, open-source app built by Google's Research team — available on both Android and iPhone.

Instead of sending your questions to a remote server like most AI apps do, it downloads AI models directly onto your device and runs them locally using your phone's CPU and GPU.

Think of it as a mini AI computer in your pocket — one that works even in airplane mode.

The app supports multiple open-source models, including Google's own Gemma 4 family, and gives you tools for chatting, image analysis, voice transcription, and even simple device automation — all completely offline.

Why This Actually Matters

Most AI tools today are cloud-dependent. That means:

Your prompts travel to remote servers
You need a stable internet connection
Slow networks mean slow responses
You have zero control over what happens to your data

AI Edge Gallery flips all of that. Everything runs on-device, which means your data never leaves your phone. For developers, students, journalists, or anyone handling sensitive information, that's a big deal.

There's also the offline angle. If you're traveling, in a low-connectivity area, or just don't want to burn through your data plan, local AI is incredibly useful.

How to Download It

For Android:
Search for "AI Edge Gallery" on the Google Play Store (by Research at Google). Requires Android 12 or higher. App size: ~23 MB.

For iPhone:
Search for "Google AI Edge Gallery" on the Apple App Store, or visit:
apps.apple.com/us/app/google-ai-edge-gallery/id6749645337
App size: ~68 MB. Requires iOS 13+. Rated 4.0 stars with 1,000+ ratings.

Key Features Worth Knowing 💡

🗨️ AI Chat with Thinking Mode

Have multi-turn conversations with the model just like any AI chat app. The really interesting part? You can toggle Thinking Mode to see the model's step-by-step reasoning before it gives you an answer. It's like watching the AI think out loud — incredibly useful for learning or understanding complex responses.

(Thinking Mode currently works with supported models, starting with the Gemma 4 family.)

🖼️ Ask Image (Multimodal AI)

Point your camera at something — a math problem on a whiteboard, a plant in your garden, a broken error message on your screen — and ask the AI about it. It uses your device's camera or photo gallery to give you visual, detailed answers.

🎙️ Audio Scribe

Speak into your phone and the app transcribes your voice to text in real time. It handles translation too. All of it happens on-device with no audio ever being sent to a server.

🧪 Prompt Lab

This is the developer's favorite corner of the app. You get a dedicated workspace to test prompts with full control over model parameters like temperature and top-k. Perfect for experimenting, learning, and fine-tuning your prompting skills.

🤖 Agent Skills

This takes the app beyond simple chatting. You can add tools like Wikipedia lookups, interactive maps, and rich visual summary cards to make the AI more capable and grounded. You can even load custom skills from a URL or browse community contributions on GitHub.

📱 Mobile Actions

On both platforms, the app can control certain device functions and automate simple tasks — powered by a lightweight fine-tuned model called FunctionGemma 270m, running entirely offline. On iOS, features like controlling the flashlight work well, though more advanced actions like creating calendar events are still limited.

🌱 Tiny Garden

A fun little bonus — a mini-game where you use natural language to plant and harvest a virtual garden. It's experimental and powered by FunctionGemma 270m. Quirky, but genuinely impressive as a demo of what small models can do.

📊 Model Management & Benchmarking

Download models from a curated list or load your own custom models. Run benchmark tests to see exactly how fast each model runs on your specific hardware. Results vary a lot between devices, so this is worth doing before you dive in.

Step-by-Step: Getting Started

Step 1 — Install the App

Download from the Google Play Store (Android) or the Apple App Store (iPhone) and open it.

Step 2 — Download a Model

You'll see a list of available models. Tap one and download it. The models are larger files — usually several hundred MB to a few GB — so download on Wi-Fi.

The home screen features the Gemma 4 family prominently. Start with a smaller variant (like Gemma 4 2B) if you have a mid-range device with limited RAM.

Step 3 — Pick a Feature

Once your model is downloaded, choose what you want to do:

AI Chat for conversation and multi-turn dialogue
Prompt Lab for controlled testing and experimentation
Ask Image for visual queries using your camera
Audio Scribe for voice-to-text transcription
Agent Skills for tool-augmented AI responses

Step 4 — Enable Thinking Mode (Optional but Fascinating)

In the AI Chat screen with a Gemma 4 model loaded, tap the Thinking Mode toggle. Ask a complex question — like "How many R's are in strawberry?" — and watch the model break down its reasoning step by step before answering.

Step 5 — Run a Benchmark

Head to Model Management and run a benchmark test. You'll get real performance numbers for your device. It takes under a minute and helps you understand your hardware's actual capabilities before downloading heavier models.

On-Device AI vs Cloud AI: Quick Comparison

	On-Device (AI Edge Gallery)	Cloud AI (ChatGPT, Gemini Web, etc.)
Internet required	❌ No	✅ Yes
Data privacy	✅ Fully local	⚠️ Sent to servers
Speed	Depends on hardware	Depends on connection
Model size	Limited by device RAM	Very large models
Cost	Free	Often subscription-based
Latest models	Open-source only	Proprietary + cutting-edge
Custom model support	✅ Load your own	❌ Limited
Works offline	✅ Always	❌ Never

The honest take: Cloud AI models like GPT-4o or Gemini 1.5 Pro are still more capable for complex tasks. On-device AI is the best choice for privacy-sensitive use cases, offline situations, learning about AI behavior, and low or no connectivity scenarios.

Tips for the Best Experience 🔧

✅ Do this:

Download models over Wi-Fi — they're large files
Start with smaller models (2B–3B parameters) on mid-range phones
Use Prompt Lab to understand how temperature and top-k affect model output
Try Agent Skills to add Wikipedia, maps, and visual tools to your AI
Run a benchmark first before downloading heavier models

❌ Avoid this:

Don't expect cloud-level accuracy from a model running on phone hardware
Don't run very large models on devices with under 6GB RAM — they'll struggle
Don't skip the benchmark — it gives you genuinely useful data about your device
Don't give up after one slow response — performance improves once the model is fully loaded into memory

Common Mistakes People Make

Downloading the biggest model first

Bigger parameters doesn't always mean better performance on your device. A very large model might run slowly or even crash on phones with limited RAM. Start small, benchmark, then scale up.

Expecting the same output quality as GPT-4 or Gemini Ultra

On-device models are improving rapidly, but they're optimized for size and speed, not maximum intelligence. Go in expecting a capable, private, offline assistant — and you'll genuinely be impressed. Go in expecting a match for the largest cloud models — and you'll be let down.

Ignoring which models are optimized for your chip

Android users on Qualcomm Snapdragon devices now have Gemma 3 1B NPU support, meaning the model runs on the neural processing unit for much faster inference. Always check model details before downloading to pick the best-optimized version for your hardware.

Not trying Agent Skills

Many users stick to basic chat and miss the real power of the app. Agent Skills — Wikipedia grounding, interactive maps, visual summaries — make the AI dramatically more useful. Spend five minutes here and you'll see the difference.

Final Thoughts

Google AI Edge Gallery is one of the most exciting things happening in mobile AI right now. It brings real, powerful open-source models to your Android or iPhone — offline, private, and completely free.

Is it going to replace your cloud AI subscription tomorrow? Probably not for complex tasks. But as a developer tool, a privacy-focused assistant, a learning sandbox, and a reliable offline companion, it's genuinely impressive and improving with every update.

The open-source, community-driven nature makes it even more interesting. Developers are already building and sharing custom Agent Skills, contributing models, and constantly pushing what a phone can do.

Download it, try a small Gemma 4 model, toggle Thinking Mode, and see what your phone is actually capable of. You might be surprised. 😊

For more dev tools, AI guides, and practical developer content, visit hamidrazadev.com. If this post was helpful, share it with a developer or tech friend who'd appreciate it!

10 Tips to Use Claude for Best Performance (Stop Wasting Tokens)

Muhammad Hamid Raza — Thu, 30 Apr 2026 10:51:22 +0000

You open Claude, type a quick message, get a mediocre response, tweak it, re-send it, get a slightly better one, tweak it again… and suddenly you have burned through half your daily message limit trying to get one decent paragraph.

Sound familiar? 😅

Most people treat Claude like a search engine — type something vague, hope for the best, then complain when the output misses the mark. But Claude is not a search engine. It is a reasoning model. And the better your input, the better your output. Every time.

So the real question is: are you getting the most out of every single prompt, or are you silently wasting tokens on back-and-forth you could have avoided?

Here are 10 practical tips that will help you get sharp, accurate, useful results from Claude — without burning through your token budget for nothing.

What Are Tokens, and Why Should You Care?

Before we dive into the tips, let us get one thing straight.

A token is roughly a word or part of a word. When you send a message to Claude — and when Claude responds — both sides use tokens. If you are on a usage-limited plan, tokens are essentially your budget. Waste them on unclear prompts and long back-and-forths, and you hit your limit faster without getting the quality you needed.

Even if tokens are not a concern for you right now, efficient prompting saves time, reduces confusion, and gets you better results. That is always worth it.

Why Prompting Style Actually Matters

Claude is powerful, but it is not a mind reader.

It works best when you give it clear context, clear instructions, and a clear goal. When you leave those things out, Claude has to guess — and even a well-trained AI guessing about your intent is still just guessing.

Better prompts mean fewer re-tries. Fewer re-tries mean fewer tokens spent. And better responses mean less frustration. It is a win on every side.

10 Tips to Get the Best Performance from Claude

1. 🎯 Be Specific About What You Want

Vague prompts produce vague answers. If you type "explain JavaScript", you could get anything from a 500-word intro to a full history of the language.

Instead, say: "Explain JavaScript closures in simple terms with one short example. Keep it under 200 words."

Specificity is your best friend. Tell Claude what topic, what depth, what format, and what length. That one habit alone will improve your results dramatically.

2. 🧑‍💼 Give Claude a Role

Claude performs better when it knows what persona to take on.

Start your prompt with something like:

"You are a senior React developer..."
"You are a friendly teacher explaining this to a 12-year-old..."
"You are a technical writer creating documentation..."

This small change shapes the tone, depth, and style of the entire response. It saves you multiple follow-up messages trying to adjust the voice.

3. 📋 Provide Context Upfront

Claude has no memory of what you did in a previous conversation unless you tell it. Jumping straight into a complex question without context forces Claude to make assumptions — and assumptions lead to mismatched answers.

Before asking your main question, give Claude the background it needs:

"I am building a Next.js app with TypeScript. I am using Supabase for authentication. I have this error in my sign-in function: [paste error]. What could be causing it?"

A bit more setup upfront = a much more useful answer on the first try.

4. ✂️ Use Clear, Short Sentences

Long, winding prompts confuse priorities. When a prompt has ten different ideas crammed into one paragraph, Claude has to figure out what you actually want most — and it might pick the wrong priority.

Keep your prompts clean and structured. Break big requests into clear points if needed. Short sentences are easier to follow for both humans and AI.

5. 📐 Specify the Format You Need

Do you want bullet points? A numbered list? A code block? A paragraph? A table?

Claude will pick a default format if you do not say anything. Sometimes that works. Sometimes it does not. Rather than sending a follow-up message asking for a reformat, just include it in your original prompt:

"Give me the answer as a numbered list."
"Respond only in a code block with comments."
"Write this as a short paragraph, not bullet points."

One sentence of format instruction can save you two or three re-prompts.

6. 🔢 Set a Length Expectation

Claude can write two sentences or two thousand words. Without guidance, it picks somewhere in the middle — which is often not what you needed.

If you want a quick summary, say "Keep it under 100 words."
If you want depth, say "Write a detailed explanation with examples."

Controlling length is one of the easiest ways to get cleaner, more useful responses without any wasted words — on either side.

7. ⛔ Tell Claude What NOT to Do

This one is underrated.

Negative instructions are just as useful as positive ones. If you do not want Claude to add a conclusion, say so. If you do not want technical jargon, mention it. If you do not want a list when you specifically need prose, be clear.

Examples:

"Do not add an introduction. Start directly with the steps."
"Do not include any code. Just explain the concept in plain English."
"Do not suggest alternatives. Just fix what I gave you."

These small guardrails stop Claude from going in a direction you did not want — which means no wasted tokens correcting it.

8. 🔁 Use Follow-Up Prompts Smartly

Even with a great first prompt, sometimes you will want a tweak. That is totally normal. But there is a right way to do follow-ups.

Instead of:
"Change it."

Say:
"Make the tone more casual and remove the second paragraph."

Vague follow-ups force Claude to guess again. Specific follow-ups land on the first try. The goal is fewer rounds of back-and-forth, not more.

9. 🗂️ Break Big Tasks into Smaller Steps

Asking Claude to "build me a full e-commerce website" in one prompt is a recipe for a bloated, half-right response that you then spend ages correcting.

For big or complex tasks, break them into steps:

"First, write the product listing component in React."
"Now write the cart logic."
"Now connect the cart to the listing component."

This gives you better control, cleaner output, and easier debugging if something goes wrong. Smaller tasks also use context more efficiently.

10. 💾 Reuse Prompts That Work

When you find a prompt structure that consistently gives you great results, save it. Seriously — keep a small notes file or a Notion doc with your best-performing prompts.

Whether it is a prompt for writing blog outlines, debugging code, summarizing documentation, or generating component ideas — a saved prompt you can reuse is a token-efficient shortcut for every future task.

Good prompts are assets. Treat them like one.

Quick Comparison: Weak Prompt vs Strong Prompt

	Weak Prompt	Strong Prompt
Topic	Vague or missing	Clearly stated
Context	None given	Background provided
Format	Not specified	Requested explicitly
Length	Not mentioned	Defined
Role	Default	Assigned persona
Result	Hit or miss	Consistently useful

The difference between these two columns is not talent. It is just habit.

Common Mistakes People Make with Claude

1. Treating Claude like Google.
Claude is not for searching. It is for reasoning, writing, explaining, and generating. Use it for what it is good at.

2. Sending one giant wall of text.
Unstructured prompts produce unstructured answers. Format your input so Claude can follow it clearly.

3. Not iterating smartly.
Sending the exact same prompt again after a bad response will not help. Change something — the format, the framing, the context — and it will respond differently.

4. Assuming Claude remembers previous chats.
By default, each conversation starts fresh. If your task depends on past context, include a brief summary at the start.

5. Asking for everything at once.
Big prompts with ten different goals rarely produce ten great outputs. Chunk your work. You will thank yourself later.

Best Practices at a Glance ✅

✅ Be specific about topic, format, tone, and length
✅ Assign a role when the task has a clear persona
✅ Give context before jumping into the question
✅ Use negative instructions to set boundaries
✅ Break large tasks into smaller, clean steps
✅ Save prompt templates that work well for you
❌ Do not be vague and expect great results
❌ Do not skip context and hope Claude figures it out
❌ Do not ask Claude to redo something without telling it what to change

Conclusion

Claude is a genuinely powerful tool — but only when you give it what it needs to perform. Most people leave a lot of quality on the table simply because of unclear or incomplete prompts.

You do not need to be a prompt engineering expert. You just need to be clear, specific, and intentional. Follow these 10 tips and you will get faster, sharper, and more accurate responses — with far fewer re-tries.

Less re-prompting. Less wasted tokens. More results. That is the goal.

If this helped you, check out more developer tips and guides on hamidrazadev.com 🚀

Share this with a fellow developer who is still sending one-liner prompts and wondering why the output is not great. They will appreciate you for it. 😊

VS Code 1.118 Is Here — And It's All About Working Smarter with Copilot 🚀

Muhammad Hamid Raza — Wed, 29 Apr 2026 11:24:49 +0000

Released April 29, 2026 — VS Code keeps leveling up, and this one's packed.

You open VS Code, kick off a Copilot agent task, step away from your desk, and come back to find… it's been waiting for your approval the whole time. Frustrating, right?

VS Code 1.118 is basically Microsoft reading that frustration and going, "Okay, okay, we got you." This release is laser-focused on making your Copilot workflow faster, smarter, and less tethered to your physical machine. Let's dig in. 👇

🎮 Remote Control for Copilot CLI Sessions

This is the headline feature — and it genuinely changes how you run long agent tasks.

Previously, if your Copilot CLI session hit a pause (waiting for an approval, asking a question), you had to physically be at your machine to respond. Not anymore.

With remote control, you can monitor and steer active Copilot CLI sessions from GitHub.com or the GitHub mobile app — while the session keeps running in the background on your dev machine. Check progress, respond to approvals, redirect the agent… all from your phone or another device.

To try it out:

Enable the github.copilot.chat.cli.remote.enabled setting
Type /remote on in a Copilot CLI chat
That's it — you're now in control from anywhere

This is a big deal for anyone running heavy multi-step agent workflows. No more babysitting your terminal.

🔍 Smarter Codebase Search — Now for Everyone

Search in Copilot just got a serious upgrade on two fronts.

Semantic indexing is now available in ALL workspaces — not just GitHub/ADO repos. So when you ask Copilot something like "where do we handle user authentication?", it searches by meaning, not just literal text. It'll surface files using signIn, verifyCredentials, OAuth token exchange, etc., even if the word "authentication" never appears. The index builds automatically, though non-GitHub workspaces may need a few minutes on first run. You can also trigger it manually with Build Codebase semantic index.

GitHub text search across repos and orgs is the second addition. When you need a precise grep-style match — an exact API name, an error string — semantic search isn't ideal. The new githubTextSearch agent tool handles exactly that: regex-style search across any GitHub repo or your entire organization. Pair it with the existing githubRepo semantic tool and Copilot now has a seriously comprehensive understanding of code it hasn't even opened yet.

⚡ Token Efficiency — Your Wallet Will Thank You

With GitHub Copilot moving to usage-based billing on June 1, 2026, this section is arguably the most practically important of the entire release.

The team has shipped multiple improvements to get more done with fewer tokens:

Prompt caching is now way more efficient. Cache breakpoints are now strategically placed at stable boundaries — end of system prompt, end of tools, end of the most recent tool turn. The result? Over 93% of each request is reused from cache instead of billed as fresh input. That's massive for long, multi-turn agent workflows.

The Tool Search Tool splits the agent's toolset into two groups: a compact always-available core (~30 tools covering 88% of calls), and deferred tools loaded only on demand. Already showing up to 20% token savings for Anthropic models, and now rolling out to supported OpenAI models too.

New Agentic Search and Execution tools are powered by smaller, purpose-built models that cost significantly less to run. The search tool handles codebase exploration independently. The execution tool handles terminal commands (capped at 10 calls per invocation so it can't loop forever) and strips verbose terminal output down to only what the coding agent actually needs. Together: up to 20% more token savings over a month of testing.

If you're on a Copilot plan, these changes are already quietly saving you budget in the background. Nice.

📚 Chronicle — Your Chat History, Actually Useful

Ever tried scrolling back through 3 weeks of Copilot chat sessions trying to remember what you worked on? It's chaos.

Chronicle (experimental, behind github.copilot.chat.localIndex.enabled) fixes this by storing your chat activity in a local SQLite database. Every session logs: branch, repo, timestamps, files touched, and external references like PRs, issues, and commits.

Then you get three handy slash commands:

/chronicle:standup — Auto-generates a standup report from the last 24 hours, grouped by feature/branch, with summaries and PR links 🙌
/chronicle:tips — Analyzes 7 days of your usage and gives you personalized tips to improve prompting and tool usage
/chronicle [query] — Free-form natural language queries like "what files did I edit yesterday?"

The standup one alone might justify enabling this feature. No more "uh... I worked on some stuff" moments in your daily sync.

🛡️ Enterprise Controls & Security Tightening

A couple of notable changes on the trust and security front.

Approved Account Organizations Policy lets enterprises gate all AI feature access behind approved GitHub organization membership. Features simply don't activate until the signed-in account belongs to an approved org and the policy clears. Fail-closed behavior — nothing shows until eligibility is confirmed.

Sandbox read permissions are now tighter by default. Previously, commands running in the sandbox had automatic read access to everything under $HOME. Now, read permissions are scoped strictly to the executing command's needs. Workspace folders still get access, but arbitrary $HOME paths are denied by default. A quiet but meaningful security improvement.

🧪 TypeScript 7.0 Beta + Other Dev Goodies

TypeScript 7 is a full rewrite in native code, and VS Code 1.118 is making it easier than ever to try the beta.

For the VS Code team itself, the switch to TS 7 for development builds has been dramatic: full type-checking of ~6,000 files dropped from ~60 seconds to ~10 seconds. The entire build + typecheck cycle now takes around 30 seconds total. That's not just impressive — that's life-changing for contributor DX.

You can try TS 7.0 Beta right now by installing the TypeScript Native Preview extension. Switching back to stable TS 6 is just as easy.

A few other notable additions this release:

WebSockets for OpenAI models — persistent connections instead of new HTTP requests per turn, making OpenAI models about 12% faster in agent workflows
Dev Container lockfile enabled by default — pins Feature versions and checksums to protect against supply chain attacks
Optimized large resource loading in webviews — file contents now stream in chunks instead of loading entirely into memory, which matters a lot when you're loading big video files in a notebook

🎯 Wrap-Up — The Efficiency Update

VS Code 1.118 isn't about flashy new UI tricks. It's about efficiency — token efficiency, workflow efficiency, and making the AI-assisted development experience genuinely less friction-y.

Remote CLI control, smarter search, Chronicle for history, tighter sandbox security, and TypeScript 7 performance improvements all point to the same theme: VS Code is getting out of your way and letting you move faster.

The token efficiency work especially deserves recognition — the team shipped real, measurable savings right before usage-based billing kicks in. That's not an accident.

Update today via Help → Check for Updates, or grab the VS Code Insiders build to get bleeding-edge features the moment they drop.

Happy Coding! 💻

📌 Quick Reference — Key Features at a Glance

Feature	Status	Setting / Command
Remote Copilot CLI control	Experimental	`github.copilot.chat.cli.remote.enabled`
Semantic indexing (all repos)	✅ Live for everyone	Auto / `Build Codebase semantic index`
GitHub text search (orgs)	✅ Live	Built-in `githubTextSearch` tool
Tool Search Tool (OpenAI)	Rolling out	`github.copilot.chat.responsesApi.toolSearchTool.enabled`
Chronicle (chat history)	Experimental	`github.copilot.chat.localIndex.enabled`
TypeScript 7.0 Beta	Preview	Install TypeScript Native Preview extension
Dev Container lockfile	✅ Default ON	`dev.containers.lockfile`

Found this useful? Drop a reaction and share it with your dev squad. More VS Code deep-dives coming soon. 🔔

How to Build a Drag-and-Drop File Dropzone in React & Next.js (With Tailwind CSS) — Line by Line

Muhammad Hamid Raza — Wed, 29 Apr 2026 07:33:04 +0000

Ever tried to upload a file on a website and the experience felt like dragging a suitcase up a broken escalator? 😅 A clunky <input type="file"> button just doesn't cut it anymore. Users expect a smooth, modern drag-and-drop experience — and as a developer, you should know how to build one.

In this post, we're going to build a fully functional, reusable Dropzone component in React (works in Next.js too) styled beautifully with Tailwind CSS. Every single line of code will be explained so you know exactly what's happening and why.

Ready to make file uploading feel like a superpower? Let's go. 🚀

What Is a Dropzone?

A Dropzone is a UI area where users can either drag and drop files or click to browse files from their device. Think of it like a designated landing pad — you either drop the package from above or walk up and hand it in.

Instead of just clicking a tiny "Choose File" button, users can grab a file from their desktop and drop it directly into a highlighted area on the page. It's more intuitive, more visual, and honestly just looks much better.

Why Build Your Own Dropzone?

You might be thinking: "Can't I just use react-dropzone?"

You absolutely can. But knowing how to build one from scratch means:

You understand the browser's Drag-and-Drop API deeply
You're not adding unnecessary npm packages for simple use cases
You can customize every pixel and every behavior
You can extend it however you need — file previews, progress bars, validations

And honestly, after this post, using any library will make even more sense because you'll understand what's happening under the hood.

Why This Matters for Real Projects

Here are situations where a good Dropzone actually matters:

Profile picture uploads — Instagram-style image selection
Document upload portals — legal, medical, or HR apps
Portfolio builders — drag project screenshots in
Form builders — attach files to a contact or support form
AI tools — let users upload images or PDFs to analyze

A broken or ugly file upload experience kills trust fast. A smooth one builds it.

Benefits of a Custom Dropzone Component

✅ Reusable — Build once, use everywhere in your project
✅ Fully controlled — You decide what file types are accepted
✅ Visual feedback — Users see drag state, file name, errors
✅ No extra dependencies — Pure React + Tailwind
✅ Accessible — Works with click too, not just drag
✅ Next.js compatible — Just add "use client" and you're good

The Complete Copy-Paste Component

Before we explain everything line by line, here's the complete component you can copy-paste directly into your project. Just drop it in your components/ folder as Dropzone.jsx (or Dropzone.tsx for TypeScript users).

"use client"; // Required in Next.js App Router to enable React hooks

import { useState, useRef, useCallback } from "react";

export default function Dropzone({ onFilesSelected, accept = "*", multiple = false }) {
  const [isDragging, setIsDragging] = useState(false);
  const [droppedFiles, setDroppedFiles] = useState([]);
  const [error, setError] = useState("");
  const inputRef = useRef(null);

  const validateFiles = useCallback(
    (files) => {
      if (!multiple && files.length > 1) {
        setError("Only one file is allowed.");
        return false;
      }
      if (accept !== "*") {
        const allowedTypes = accept.split(",").map((t) => t.trim());
        const allValid = Array.from(files).every((file) =>
          allowedTypes.some((type) => file.type === type || file.name.endsWith(type))
        );
        if (!allValid) {
          setError(`Invalid file type. Allowed: ${accept}`);
          return false;
        }
      }
      setError("");
      return true;
    },
    [accept, multiple]
  );

  const handleFiles = useCallback(
    (files) => {
      const fileArray = Array.from(files);
      if (!validateFiles(fileArray)) return;
      setDroppedFiles(fileArray);
      if (onFilesSelected) onFilesSelected(fileArray);
    },
    [validateFiles, onFilesSelected]
  );

  const handleDragOver = (e) => {
    e.preventDefault();
    e.stopPropagation();
    setIsDragging(true);
  };

  const handleDragLeave = (e) => {
    e.preventDefault();
    e.stopPropagation();
    setIsDragging(false);
  };

  const handleDrop = (e) => {
    e.preventDefault();
    e.stopPropagation();
    setIsDragging(false);
    const files = e.dataTransfer.files;
    if (files && files.length > 0) {
      handleFiles(files);
    }
  };

  const handleClick = () => {
    inputRef.current?.click();
  };

  const handleInputChange = (e) => {
    const files = e.target.files;
    if (files && files.length > 0) {
      handleFiles(files);
    }
  };

  const handleRemoveFile = (index) => {
    const updated = droppedFiles.filter((_, i) => i !== index);
    setDroppedFiles(updated);
    if (onFilesSelected) onFilesSelected(updated);
  };

  return (
    <div className="w-full max-w-xl mx-auto">
      {/* Dropzone Area */}
      <div
        onDragOver={handleDragOver}
        onDragLeave={handleDragLeave}
        onDrop={handleDrop}
        onClick={handleClick}
        className={`
          flex flex-col items-center justify-center
          border-2 border-dashed rounded-2xl
          p-10 cursor-pointer transition-all duration-300
          ${isDragging
            ? "border-orange-400 bg-orange-50 scale-[1.02]"
            : "border-gray-300 bg-gray-50 hover:border-orange-300 hover:bg-orange-50"
          }
        `}
      >
        {/* Icon */}
        <div className="mb-4 text-5xl select-none">
          {isDragging ? "📂" : "📁"}
        </div>

        {/* Text */}
        <p className="text-gray-600 text-base font-medium text-center">
          {isDragging
            ? "Release to drop your files here!"
            : "Drag & drop files here, or click to browse"}
        </p>
        <p className="text-gray-400 text-sm mt-1 text-center">
          {accept === "*" ? "All file types accepted" : `Accepted: ${accept}`}
        </p>

        {/* Hidden File Input */}
        <input
          ref={inputRef}
          type="file"
          accept={accept}
          multiple={multiple}
          className="hidden"
          onChange={handleInputChange}
        />
      </div>

      {/* Error Message */}
      {error && (
        <p className="mt-3 text-sm text-red-500 font-medium text-center">
          ⚠️ {error}
        </p>
      )}

      {/* File List */}
      {droppedFiles.length > 0 && (
        <ul className="mt-4 space-y-2">
          {droppedFiles.map((file, index) => (
            <li
              key={index}
              className="flex items-center justify-between bg-white border border-gray-200 rounded-xl px-4 py-3 shadow-sm"
            >
              <div className="flex items-center gap-3 overflow-hidden">
                <span className="text-xl">📄</span>
                <div className="overflow-hidden">
                  <p className="text-sm font-medium text-gray-700 truncate">{file.name}</p>
                  <p className="text-xs text-gray-400">{(file.size / 1024).toFixed(1)} KB</p>
                </div>
              </div>
              <button
                onClick={(e) => {
                  e.stopPropagation();
                  handleRemoveFile(index);
                }}
                className="ml-4 text-gray-400 hover:text-red-500 transition-colors text-lg font-bold"
                aria-label="Remove file"
              >
                ×
              </button>
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

How to Use the Component

Paste this wherever you want in your page or form:

// pages/index.jsx or app/page.jsx

import Dropzone from "@/components/Dropzone";

export default function Home() {
  const handleFiles = (files) => {
    console.log("Selected files:", files);
    // Send to server, preview, etc.
  };

  return (
    <main className="min-h-screen flex items-center justify-center bg-gray-100 p-6">
      <Dropzone
        onFilesSelected={handleFiles}
        accept="image/png, image/jpeg, image/webp"
        multiple={true}
      />
    </main>
  );
}

That's it. Drop images in — you'll see them listed below the zone. 🎉

Line-by-Line Code Explanation

Now let's break down every important part of the component so you understand the "why" behind each line.

1. `"use client"`

"use client";

This is Next.js App Router specific. It tells Next.js that this component runs in the browser, not on the server. You need this because we use React hooks like useState and event listeners. If you're using Next.js Pages Router or plain React, you can remove this line — it's not needed there.

2. Importing Hooks

import { useState, useRef, useCallback } from "react";

useState — manages state: is the user dragging? what files are dropped? any errors?
useRef — creates a direct reference to the hidden <input type="file"> element so we can trigger it programmatically when the user clicks anywhere on the dropzone
useCallback — wraps functions so they don't get recreated on every re-render, which is important when those functions are used as dependencies in other hooks

3. Component Props

export default function Dropzone({ onFilesSelected, accept = "*", multiple = false })

onFilesSelected — a callback function the parent passes in to receive the selected files. Think of it like handing a delivery to the right address.
accept — which file types are allowed. Defaults to "*" meaning anything goes. You can pass "image/png, image/jpeg" to restrict to images.
multiple — if true, user can select multiple files. Default is false (single file only).

4. State Variables

const [isDragging, setIsDragging] = useState(false);
const [droppedFiles, setDroppedFiles] = useState([]);
const [error, setError] = useState("");
const inputRef = useRef(null);

isDragging — tracks whether a file is currently being dragged over the dropzone. Used to change the visual appearance dynamically.
droppedFiles — stores the list of files the user has dropped or selected. This is what gets shown in the file list below.
error — stores any validation error message (like "wrong file type").
inputRef — points directly to the hidden <input> element. When the user clicks the dropzone, we call inputRef.current.click() to open the file picker — even though the input itself is invisible.

5. The `validateFiles` Function

const validateFiles = useCallback(
  (files) => {
    if (!multiple && files.length > 1) {
      setError("Only one file is allowed.");
      return false;
    }
    if (accept !== "*") {
      const allowedTypes = accept.split(",").map((t) => t.trim());
      const allValid = Array.from(files).every((file) =>
        allowedTypes.some((type) => file.type === type || file.name.endsWith(type))
      );
      if (!allValid) {
        setError(`Invalid file type. Allowed: ${accept}`);
        return false;
      }
    }
    setError("");
    return true;
  },
  [accept, multiple]
);

This is your security guard. 🔒

If multiple is false but the user dropped 3 files, it rejects immediately with an error message.
Then it checks file types. It splits the accept string (e.g., "image/png, image/jpeg") into an array and checks whether each file matches.
The .every() means all files must pass. One bad apple ruins the whole batch.
file.type checks the MIME type (e.g., "image/png"). file.name.endsWith(type) is a fallback for checking extensions (e.g., .pdf).
If everything's fine, it clears the error and returns true.

6. The `handleFiles` Function

const handleFiles = useCallback(
  (files) => {
    const fileArray = Array.from(files);
    if (!validateFiles(fileArray)) return;
    setDroppedFiles(fileArray);
    if (onFilesSelected) onFilesSelected(fileArray);
  },
  [validateFiles, onFilesSelected]
);

This is the central dispatcher for all file activity — whether the user drags, drops, or clicks to pick files.

Array.from(files) converts the native FileList object (what the browser gives you) into a regular JavaScript array. FileList is not an array, so you can't use .map() or .filter() on it directly.
It runs validation first. If validation fails, it stops right there — return exits the function.
If files pass validation, it saves them in state and calls the parent's onFilesSelected callback so the parent knows what files were selected.

7. `handleDragOver`

const handleDragOver = (e) => {
  e.preventDefault();
  e.stopPropagation();
  setIsDragging(true);
};

This fires continuously as the user hovers a file over the dropzone.

e.preventDefault() is critical. Without it, the browser would open the file itself (imagine dropping a PDF and suddenly the browser navigates to a PDF viewer). This stops that default behavior.
e.stopPropagation() prevents the event from bubbling up to parent elements, which could cause unexpected behavior.
setIsDragging(true) activates the "active drag" visual state.

8. `handleDragLeave`

const handleDragLeave = (e) => {
  e.preventDefault();
  e.stopPropagation();
  setIsDragging(false);
};

Fires when the user's dragged file leaves the dropzone area. Sets isDragging back to false so the highlighted state disappears. Simple but necessary.

9. `handleDrop`

const handleDrop = (e) => {
  e.preventDefault();
  e.stopPropagation();
  setIsDragging(false);
  const files = e.dataTransfer.files;
  if (files && files.length > 0) {
    handleFiles(files);
  }
};

This fires when the user releases the file over the dropzone.

Again, e.preventDefault() prevents the browser from opening the file.
e.dataTransfer.files is where the browser stores the dropped files. dataTransfer is the native browser API specifically for drag-and-drop data.
We check that files exist and are not empty, then pass them to handleFiles.

10. `handleClick` and `handleInputChange`

const handleClick = () => {
  inputRef.current?.click();
};

const handleInputChange = (e) => {
  const files = e.target.files;
  if (files && files.length > 0) {
    handleFiles(files);
  }
};

handleClick programmatically triggers a click on the hidden <input type="file">. The ?. is optional chaining — just in case the ref hasn't attached yet.
handleInputChange handles files selected through the file picker dialog. e.target.files gives us the FileList from the native input.

Both paths — drag-drop and click-to-browse — eventually call the same handleFiles function. Single source of truth. ✅

11. `handleRemoveFile`

const handleRemoveFile = (index) => {
  const updated = droppedFiles.filter((_, i) => i !== index);
  setDroppedFiles(updated);
  if (onFilesSelected) onFilesSelected(updated);
};

Removes a file from the list by index. The filter creates a new array excluding the file at the given index. We also notify the parent with the updated list via onFilesSelected.

12. The JSX — Dropzone Area

<div
  onDragOver={handleDragOver}
  onDragLeave={handleDragLeave}
  onDrop={handleDrop}
  onClick={handleClick}
  className={`
    flex flex-col items-center justify-center
    border-2 border-dashed rounded-2xl
    p-10 cursor-pointer transition-all duration-300
    ${isDragging
      ? "border-orange-400 bg-orange-50 scale-[1.02]"
      : "border-gray-300 bg-gray-50 hover:border-orange-300 hover:bg-orange-50"
    }
  `}
>

This div is the entire interactive surface.

Four event listeners handle dragging, leaving, dropping, and clicking.
flex flex-col items-center justify-center — centers everything inside vertically and horizontally.
border-2 border-dashed — the classic dropzone dashed border look.
rounded-2xl — smooth, modern rounded corners.
cursor-pointer — signals to the user that this area is clickable.
transition-all duration-300 — smooth visual transitions when state changes.
The conditional class: when isDragging is true, the border goes orange, the background gets a soft orange tint, and the box subtly scales up (scale-[1.02]). It gives satisfying visual feedback that "yes, you can drop here."

13. The Hidden Input

<input
  ref={inputRef}
  type="file"
  accept={accept}
  multiple={multiple}
  className="hidden"
  onChange={handleInputChange}
/>

ref={inputRef} — connects this element to our inputRef so we can trigger it from handleClick.
type="file" — standard HTML file input.
accept and multiple are passed from props, controlling what's allowed.
className="hidden" — the input is invisible. The div above acts as the visual replacement.
onChange — fires when the user selects files via the file picker dialog.

14. File List

{droppedFiles.map((file, index) => (
  <li key={index} className="flex items-center justify-between bg-white border border-gray-200 rounded-xl px-4 py-3 shadow-sm">
    ...
    <p className="text-sm font-medium text-gray-700 truncate">{file.name}</p>
    <p className="text-xs text-gray-400">{(file.size / 1024).toFixed(1)} KB</p>
    ...
  </li>
))}

We loop over droppedFiles and render each one as a list item.
file.name gives the original filename.
file.size is in bytes, so we divide by 1024 to convert to KB and use .toFixed(1) to show one decimal place.
truncate is a Tailwind class that adds text-overflow: ellipsis — long filenames won't break the layout.

15. The Remove Button

<button
  onClick={(e) => {
    e.stopPropagation();
    handleRemoveFile(index);
  }}
  ...
>
  ×
</button>

e.stopPropagation() here is important. Without it, clicking the remove button would also trigger the parent div's onClick, which would open the file picker. We stop the click from bubbling up.

Comparison: Native Input vs Custom Dropzone

Feature	`<input type="file">`	Custom Dropzone
Drag & Drop	❌	✅
Visual feedback	❌	✅
File preview	❌	✅
Custom styling	Very limited	Fully customizable
Remove individual files	❌	✅
File type validation	Basic	Custom & detailed
UX quality	Basic	Modern & polished

Best Tips — Do's & Don'ts

✅ Do's:

Always call e.preventDefault() on dragover and drop. Without it, the browser does its own thing.
Convert FileList to an array before doing anything useful with it.
Give clear visual feedback when the user is dragging over the zone.
Always notify the parent component via a callback so it can handle uploads.
Use e.stopPropagation() on nested click handlers to prevent accidental triggers.

❌ Don'ts:

Don't forget "use client" in Next.js App Router. Hooks won't work without it.
Don't rely only on file.type for validation — it can be spoofed. Always validate on the server too.
Don't skip the multiple prop logic if your backend only accepts one file.
Don't make the dropzone too small — users need room to drop.

Common Mistakes People Make

1. Forgetting e.preventDefault() on dragover

This is the most common mistake. If you skip it, the drop event will never fire because the browser cancels it. Every drag-and-drop implementation needs this.

2. Not converting FileList to an Array

FileList is a browser-native object. It looks like an array but it's not. Calling .map() or .filter() directly on it will throw an error. Always use Array.from(files) first.

3. Skipping the stopPropagation on the remove button

If the remove button click bubbles up to the parent div, it also triggers the file picker. Very confusing for users. Always stop it.

4. Only supporting drag-and-drop but not click

Some users (especially on trackpads) find drag-and-drop annoying or harder. Always support both interactions. Our component does this — clicking anywhere on the zone opens the file picker.

5. Doing validation only on the frontend

Frontend validation is for UX. Server-side validation is for security. Never trust a file just because the browser said it was valid. Always re-validate on the backend.

Conclusion

Building a custom Dropzone component from scratch is one of those things that teaches you a lot in a short amount of time. You learn about the browser's Drag-and-Drop API, React state management, refs, callbacks, and Tailwind styling — all in one component. 🎯

Here's what we covered:

How drag-and-drop events work in the browser
How to build a reusable Dropzone component with clean props
How Tailwind classes make visual state changes effortless
How to validate files, remove them, and pass them to the parent
What every single line is doing and why it's there

Now you have a clean, copy-paste-ready Dropzone component that you can drop into any React or Next.js project and customize to your heart's content.

Want more practical React and Next.js tutorials like this one? Head over to hamidrazadev.com — there's a lot more waiting for you there. 💡

If this post saved you time or cleared up confusion, share it with a dev friend or your team. They'll thank you for it. 😊

How Pagination Works — And Why Every Developer Needs to Understand It 📄

Muhammad Hamid Raza — Tue, 28 Apr 2026 09:47:04 +0000

You open an app. It loads 10,000 records all at once. Your browser freezes. Your users leave. 😬

Sound familiar? That's the pagination problem in reverse — what happens when you don't use it. Pagination is one of those concepts that looks simple on the surface but quietly powers almost every real-world app you've ever used: Google Search, Twitter feeds, product listings, admin dashboards, and more.

So how does it actually work? And how do you build it? Let's break it all down from scratch — with a real React component at the end.

What Is Pagination?

Imagine you walk into a library and ask the librarian for every book they have. She stares at you. There are 50,000 books. You clearly can't carry them all at once.

So instead, she says: "I'll bring you 10 books at a time. Tell me which shelf to start from."

That's pagination.

In software, pagination is the process of splitting a large dataset into smaller chunks (pages) and delivering one chunk at a time. Instead of loading 10,000 rows from your database into the browser at once, you load page 1 (rows 1–10), then page 2 (rows 11–20), and so on — only when the user asks.

The user controls which "shelf" they want. The server (or your frontend) delivers just that shelf.

Why Pagination Matters

Without pagination, your app has a few serious problems:

Performance tanks. Fetching thousands of records at once is slow. Rendering them is even slower. The browser has to process, paint, and hold all of that in memory — for data the user probably won't even scroll to.

APIs get overwhelmed. Your backend server has to query the entire database, serialize everything, and send it over the network. For large datasets, this can take seconds or even crash the server.

UX suffers. A page that loads slowly or shows an endless wall of data is a bad experience. Users bounce. They don't stay.

Costs go up. If you're using a cloud database or API with metered billing, loading unnecessary data wastes money directly.

Pagination solves all of this by asking a simple question on every data request: "Which page? How many items per page?"

Benefits of Pagination — With Real Examples

⚡ Faster load times — An e-commerce store showing 50,000 products loads the first 20 instantly instead of stalling for 10 seconds. Users can start browsing right away.
📉 Lower server load — A SELECT * FROM orders query on a 2-million-row table is painful. SELECT * FROM orders LIMIT 20 OFFSET 0 is fast and surgical.
💾 Lower memory usage — Your React component doesn't need to store 10,000 items in state. It stores 10 or 20 at a time — clean and efficient.
🔍 Better UX — Users know where they are ("Page 3 of 47"). They can navigate, go back, bookmark a page, and share a specific page URL — like Google search results.
📊 Easier debugging — When your data is paginated, you can isolate a specific page during testing instead of scrolling through thousands of rows.
🔗 Shareable URLs — With query-based pagination like ?page=3, users can share a direct link to a specific page. That's huge for support teams, admins, and product listings.

Types of Pagination

Not all pagination works the same way. There are three common approaches:

1. Offset-Based Pagination (Classic)

This is the most common and beginner-friendly method. You specify a page number and a limit.

GET /api/posts?page=2&limit=10

On the backend, this translates to:

SELECT * FROM posts LIMIT 10 OFFSET 10

OFFSET = (page - 1) × limit

Simple, predictable, and easy to implement. This is what most tutorials (and this post) use.

Downsides: If new items are inserted while a user is paginating, they might skip or see duplicate items. For most apps, this is fine.

2. Cursor-Based Pagination

Instead of a page number, you use a "cursor" — usually the ID of the last item you saw.

GET /api/posts?after=post_id_99&limit=10

This is what Twitter, Instagram, and most social feeds use. It's more stable for real-time data because it doesn't break when new items are added.

Downsides: Users can't jump to "page 5" directly. It's sequential — next/previous only.

3. Frontend (Client-Side) Pagination

All the data is fetched at once, but the display is split into pages on the frontend using JavaScript. This works well for small datasets (under a few hundred items) where a full API call is acceptable.

No backend changes needed — just slice the array.

const currentPageData = allData.slice(startIndex, endIndex);

This is the approach we'll use in the component below.

Offset Pagination vs Cursor Pagination

Feature	Offset Pagination	Cursor Pagination
Jump to any page	✅ Yes	❌ No
Works with real-time data	⚠️ Not ideal	✅ Yes
Easy to implement	✅ Very	⚠️ More complex
Good for static datasets	✅ Great	✅ Also fine
Common in admin panels	✅ Very common	Rare
Common in social feeds	Rare	✅ Very common

Rule of thumb: Use offset pagination for dashboards, admin panels, and product listings. Use cursor pagination for live feeds and real-time data.

How to Build a Pagination Component in React

Let's build a clean, reusable pagination component with fake data — no external library needed. Just React and a little logic.

The logic behind it

Given:

totalItems — total number of records
itemsPerPage — how many to show per page
currentPage — the active page

You can calculate:

const totalPages = Math.ceil(totalItems / itemsPerPage);
const startIndex = (currentPage - 1) * itemsPerPage;
const endIndex = startIndex + itemsPerPage;
const currentData = data.slice(startIndex, endIndex);

Simple math. That's the whole engine.

Full Pagination Component

import { useState } from "react";

// --- Fake data to simulate a list of blog posts ---
const generatePosts = () =>
  Array.from({ length: 47 }, (_, i) => ({
    id: i + 1,
    title: `Blog Post #${i + 1}`,
    category: ["React", "CSS", "JavaScript", "Next.js", "Node.js"][i % 5],
    date: `April ${(i % 28) + 1}, 2025`,
  }));

const ITEMS_PER_PAGE = 5;

// --- Pagination Controls Component ---
function PaginationControls({ currentPage, totalPages, onPageChange }) {
  const pages = Array.from({ length: totalPages }, (_, i) => i + 1);

  return (
    <div style={{ display: "flex", gap: "8px", alignItems: "center", flexWrap: "wrap", marginTop: "24px" }}>
      <button
        onClick={() => onPageChange(currentPage - 1)}
        disabled={currentPage === 1}
        style={btnStyle(currentPage === 1)}
      >
        ← Prev
      </button>

      {pages.map((page) => (
        <button
          key={page}
          onClick={() => onPageChange(page)}
          style={btnStyle(false, page === currentPage)}
        >
          {page}
        </button>
      ))}

      <button
        onClick={() => onPageChange(currentPage + 1)}
        disabled={currentPage === totalPages}
        style={btnStyle(currentPage === totalPages)}
      >
        Next →
      </button>
    </div>
  );
}

// --- Button styles helper ---
function btnStyle(disabled = false, active = false) {
  return {
    padding: "8px 14px",
    borderRadius: "6px",
    border: "1px solid #ddd",
    cursor: disabled ? "not-allowed" : "pointer",
    backgroundColor: active ? "#fd6e4e" : disabled ? "#f0f0f0" : "#fff",
    color: active ? "#fff" : disabled ? "#aaa" : "#333",
    fontWeight: active ? "bold" : "normal",
    transition: "all 0.2s",
  };
}

// --- Main App ---
export default function PaginatedList() {
  const [currentPage, setCurrentPage] = useState(1);
  const allPosts = generatePosts();
  const totalPages = Math.ceil(allPosts.length / ITEMS_PER_PAGE);

  const startIndex = (currentPage - 1) * ITEMS_PER_PAGE;
  const currentPosts = allPosts.slice(startIndex, startIndex + ITEMS_PER_PAGE);

  const handlePageChange = (page) => {
    if (page >= 1 && page <= totalPages) {
      setCurrentPage(page);
    }
  };

  return (
    <div style={{ maxWidth: "640px", margin: "40px auto", fontFamily: "sans-serif", padding: "0 16px" }}>
      <h2 style={{ marginBottom: "4px" }}>📚 Blog Posts</h2>
      <p style={{ color: "#666", fontSize: "14px", marginBottom: "20px" }}>
        Showing {startIndex + 1}–{Math.min(startIndex + ITEMS_PER_PAGE, allPosts.length)} of {allPosts.length} posts
      </p>

      {currentPosts.map((post) => (
        <div
          key={post.id}
          style={{
            padding: "16px",
            marginBottom: "12px",
            border: "1px solid #eee",
            borderRadius: "10px",
            display: "flex",
            justifyContent: "space-between",
            alignItems: "center",
          }}
        >
          <div>
            <strong>{post.title}</strong>
            <p style={{ margin: "4px 0 0", fontSize: "13px", color: "#888" }}>{post.date}</p>
          </div>
          <span
            style={{
              background: "#fff3ee",
              color: "#fd6e4e",
              padding: "4px 10px",
              borderRadius: "20px",
              fontSize: "12px",
              fontWeight: "bold",
            }}
          >
            {post.category}
          </span>
        </div>
      ))}

      <PaginationControls
        currentPage={currentPage}
        totalPages={totalPages}
        onPageChange={handlePageChange}
      />

      <p style={{ marginTop: "16px", fontSize: "13px", color: "#999" }}>
        Page {currentPage} of {totalPages}
      </p>
    </div>
  );
}

What's happening here?

generatePosts() creates 47 fake blog posts — simulating real data from an API.
ITEMS_PER_PAGE = 5 controls how many items appear per page. Change it to 10 or 20 and it just works.
slice(startIndex, endIndex) cuts the array to only the current page's data — classic client-side pagination.
PaginationControls is a reusable component. Pass it any currentPage, totalPages, and onPageChange — it works with any dataset.
Prev/Next buttons are disabled at boundaries so users can't go below page 1 or above the last page.
The active page button highlights with your brand color #fd6e4e. 🎨

Best Tips for Pagination

✅ Always show the user where they are. "Page 3 of 12" or "Showing 21–30 of 120 results" gives real context.

✅ Disable Prev/Next at boundaries. Don't let users click into a page that doesn't exist.

✅ Keep items per page reasonable. 10–25 is the sweet spot for most apps. Too few = too many page clicks. Too many = overload.

✅ Use query params for server-side pagination. ?page=3 makes pages bookmarkable and shareable.

✅ Add a loading indicator when fetching from an API. Users should know data is on the way.

✅ Reset to page 1 when filters change. If a user is on page 6 and applies a filter that returns only 3 results, jumping back to page 1 automatically prevents confusion.

Common Mistakes to Avoid

❌ Forgetting to reset page on filter/search changes. This is the #1 pagination bug. Your users filter by "React" and land on page 8 — which is empty because the filtered result only has 20 items. Always reset currentPage to 1 when search or filter state changes.

❌ Hardcoding item count. Avoid Math.ceil(47 / 5) in your component. Your data length will change. Always compute totalPages dynamically from the actual data or the API response.

❌ Building your own pagination for large datasets. Client-side pagination is great for small datasets. For 10,000+ rows, use server-side pagination — always. Slicing a 10,000-item array in the browser is still loading 10,000 items into memory.

❌ No "out of bounds" guard. What if someone manually types ?page=9999 in the URL and your app has only 10 pages? Guard against this. Redirect or clamp to the last valid page.

❌ Skipping accessibility. Your pagination buttons should have proper aria-label values and keyboard navigation support. aria-label="Go to page 5" goes a long way.

Conclusion

Pagination isn't glamorous. Nobody gives awards for a well-paginated list. But it's one of those foundational patterns that quietly makes your apps faster, cheaper to run, and genuinely better to use.

Once you understand the core idea — split big data into small, navigable chunks — the rest is just implementation details. Whether you're slicing an array on the frontend, passing LIMIT and OFFSET to a SQL query, or using cursor-based pagination for a real-time feed, the goal is always the same: give the user only what they need, exactly when they need it.

Build the component above, play with ITEMS_PER_PAGE, and see how the pages shift. That hands-on click is worth more than any explanation.

For more practical frontend guides like this one, visit 👉 hamidrazadev.com — and if this post saved you from loading 10,000 rows at once, share it with a fellow dev who might need it. 😄

pnpm vs npm vs yarn: Which Package Manager Should You Actually Use in 2026?

Muhammad Hamid Raza — Mon, 27 Apr 2026 09:57:39 +0000

You've been there. You clone a new repo, hit npm install, and watch the cursor blink. And blink. And blink. Meanwhile, your node_modules folder quietly becomes the heaviest object in the known universe.

Package managers are one of those tools developers use every single day — yet most of us just pick one and never look back. That's fine, until you're debugging a phantom dependency, waiting forever for CI to finish, or discovering your disk has 40 copies of lodash sitting around doing nothing useful.

So which one should you actually use in 2026 — npm, yarn, or pnpm? Let's break it down honestly. 🚀

What Is a Package Manager, Anyway?

Think of a package manager like an app store for your code project. Instead of manually downloading and setting up libraries, you just say "I need React" or "I need Lodash" — and the package manager handles everything: downloading, versioning, and organizing.

When you run npm install express, you're telling your package manager: "Go find this package, grab the right version, and put it in my project."

All three tools — npm, yarn, and pnpm — do this job. The difference is how they do it, and that's where it gets interesting.

A Quick Introduction to Each

npm — The OG

npm (Node Package Manager) has been around since 2009. It comes bundled with Node.js, which means if you have Node installed, you already have npm. No extra setup. No extra thinking.

Current version: npm 11.x
Lockfile: package-lock.json
Install command: npm install

npm powers the largest JavaScript registry in the world — over 2 million packages. That's both its greatest strength and its biggest flex.

yarn — The Speed Challenger

Yarn was created by Facebook in 2016 specifically to fix npm's pain points at the time: slow installs, unreliable dependency resolution, and no lockfile. It shipped fast, it shipped with yarn.lock, and developers loved it.

Today there are two very different versions of Yarn:

Yarn Classic (v1): The original. Entered maintenance mode in 2020. Still used in many projects, but no longer actively developed.
Yarn Berry (v2, v3, v4): A complete rewrite. Introduces Plug'n'Play (PnP), which gets rid of node_modules entirely. Powerful, but also divisive.
Current version: Yarn 4.x (Berry)
Lockfile: yarn.lock
Install command: yarn install

pnpm — The Efficient One

pnpm (Performant npm) launched in 2017 and took a completely different approach to storing packages. Instead of copying every dependency into each project's node_modules, pnpm stores packages once in a global content-addressable store and uses hard links.

The result? Blazing fast installs and massively less disk usage.

Current version: pnpm 10.x (pnpm 11 RC just landed in April 2026)
Lockfile: pnpm-lock.yaml
Install command: pnpm install

Why Does It Actually Matter?

You might be thinking: "They all install packages. Who cares?"

Here's why you should care:

Your CI/CD pipeline runs npm install on every push. If that takes 3 minutes with npm but 45 seconds with pnpm, you're wasting real time and real money every single day.
Your disk space is getting eaten by duplicate copies of the same packages across 10 different projects.
Your team might be hitting phantom dependency bugs — using packages that aren't in package.json but happen to be installed anyway.
Security is a real concern in 2026. Package supply chain attacks are happening, and your package manager is the first line of defense.

These aren't abstract problems. They affect your daily workflow.

Benefits and Real-World Examples

✅ npm — Simplicity Wins Sometimes

Zero setup required. Start a new Node project, and npm is already there. Perfect for beginners and solo projects where you don't want to think about tooling.
Maximum compatibility. Every npm package, every tutorial, every CI/CD template assumes you're using npm. Nothing breaks.
Workspaces support. npm v7+ added workspaces, so monorepos are supported. It's not as powerful as the alternatives, but it works.

Real example: You're building a quick prototype for a client demo. You fire up npm init and start coding in minutes. No extra installation. No configuration. Just works.

✅ yarn — When PnP Makes Sense

Zero-installs. Yarn Berry's biggest trick: commit your dependency cache to Git. Your team or CI server never runs yarn install again — everything is already there.
Plugin architecture. Yarn Berry has a modular plugin system, and as of the latest v4 releases, official plugins are now bundled by default, so you don't need to run yarn plugin import for official ones anymore.
Portable shell scripts. Yarn uses a bash-compatible shell to make package.json scripts run consistently across Windows, Linux, and macOS.

Real example: A team commits their Yarn cache to Git. New developers join, clone the repo, and immediately run the app without installing anything. CI becomes near-instant.

✅ pnpm — Efficiency at Scale

Disk space savings. pnpm's content-addressable global store means if 10 of your projects use React 19, there's only one copy of React 19 on your disk. This can save 70–80% of disk space compared to npm.
Strict dependency isolation. pnpm prevents phantom dependencies at the filesystem level. A package can only access what's listed in its own package.json. npm and yarn don't enforce this.
Blazing fast installs. pnpm consistently outperforms npm in benchmarks, especially for cached installs and monorepo setups.
Security by default (v10+). pnpm v10 introduced a game-changing security model: lifecycle scripts (postinstall, preinstall) are no longer run by default — a huge reduction in supply chain attack risk. The new minimumReleaseAge setting (defaulting to 1 day in v11) blocks newly published packages for 24 hours, giving the community time to spot compromised versions.
Monorepo powerhouse. Commands like pnpm --filter and pnpm -r (recursive) make working with multi-package repos clean and fast.

Real example: You manage 15 React projects on your machine. With npm, you have 15 separate copies of React sitting on disk. With pnpm, you have one — hard-linked to all 15 projects. Your disk breathes again. 😊

Head-to-Head Comparison

Feature	npm	yarn (Berry)	pnpm
Comes with Node.js	✅ Yes	❌ Install separately	❌ Install separately
Speed (cold install)	🐢 Slowest	⚡ Fast (PnP mode)	⚡ Fast
Speed (cached)	🐢 Slower	⚡ Very fast	⚡ Very fast
Disk efficiency	❌ Many copies	✅ Good (PnP/ZIP)	✅ Best (global store)
Monorepo support	⚠️ Basic	✅ Strong	✅ Excellent
Phantom dependencies	❌ Allowed	⚠️ Depends on mode	✅ Prevented
Security defaults	⚠️ Standard	⚠️ Standard	✅ Strictest (v10+)
Learning curve	✅ Lowest	❌ High (Berry/PnP)	✅ Low
Ecosystem compatibility	✅ Maximum	⚠️ PnP can break things	✅ High
Lockfile	`package-lock.json`	`yarn.lock`	`pnpm-lock.yaml`

Best Tips: Do's and Don'ts

Do's ✅

Do use pnpm for any new project where you care about speed and disk efficiency. The learning curve is minimal — most commands are identical to npm.
Do use npm if you're teaching beginners. The zero-configuration setup removes unnecessary friction.
Do use Yarn Berry if your team is already invested in PnP and zero-installs. If your whole toolchain supports it, the workflow is genuinely fast.
Do commit a lockfile in every project, no matter which manager you use. This ensures consistent installs across your team and CI.
Do stick to one package manager per project. Mixing npm and pnpm in the same repo causes weird issues. Use the packageManager field in package.json to enforce this.

Don'ts ❌

Don't use Yarn Classic (v1) for new projects. It's been in maintenance mode since 2020 and only gets security fixes.
Don't npm install and pnpm install in the same repo. You'll get two different lockfiles, two different node_modules structures, and one very confused team.
Don't delete node_modules and reinstall as your first debug step every time. Learn what your lockfile is telling you first.
Don't ignore security defaults. If you're on pnpm v10+, the allowBuilds setting matters. Take a few minutes to understand which packages need build scripts.

Common Mistakes Developers Make

1. Treating all three as identical

They're not. pnpm's node_modules structure looks different from npm's, because it uses symlinks. Some poorly written packages that access the filesystem directly might behave unexpectedly. Always test when switching.

2. Mixing package managers in a monorepo

This is more common than you'd think. One developer uses yarn, another uses npm — and suddenly the lockfile is a mess and installs are inconsistent. Add a packageManager field to your root package.json and use Corepack to enforce it:

{
  "packageManager": "pnpm@10.33.0"
}

3. Jumping straight to Yarn Berry without checking PnP compatibility

Yarn PnP is powerful, but it changes how Node resolves modules. Some tools — older Jest configs, certain Webpack plugins, some IDE extensions — need extra setup to work properly. Don't assume it'll "just work."

4. Never updating the package manager itself

You probably update your dependencies regularly. But when's the last time you updated npm, yarn, or pnpm? pnpm v10 alone shipped massive security improvements over v9. Keep your tools updated too.

# Update npm
npm install -g npm@latest

# Update yarn
yarn set version stable

# Update pnpm
pnpm self-update

5. Ignoring the lockfile in `.gitignore`

Your lockfile is not optional. It's what ensures reproducible installs. If you see package-lock.json or pnpm-lock.yaml in your .gitignore, that's a problem — commit it.

So, Which One Should You Actually Use?

Here's the honest, no-fluff answer:

Use npm if:

You're a beginner just getting started with Node.js
You're building a simple project where speed and disk usage aren't a concern
You want maximum compatibility with every tutorial and tool out there

Use yarn (Berry) if:

Your team is already using it and you have PnP working well
You want zero-installs for a CI/CD speed boost
You're working on a monorepo and your toolchain fully supports PnP

Use pnpm if:

You're starting a new project and want the best balance of speed, disk efficiency, and compatibility
You're working on a monorepo with multiple packages
You care about security and want stricter dependency isolation out of the box
You manage many projects on the same machine and your disk is screaming

For most developers reading this in 2026, pnpm is the practical upgrade — it's fast, it's efficient, its commands are nearly identical to npm, and pnpm v10's security-first approach is genuinely impressive. You won't regret it.

Wrapping Up

The package manager debate isn't about picking the "coolest" tool. It's about understanding what each tool actually does, and choosing the right one for your situation.

npm is reliable, universally supported, and perfect for getting started
yarn brought speed and innovation to the ecosystem, and Yarn Berry continues to push boundaries
pnpm delivers the best combination of speed, disk efficiency, and modern security defaults for production use

If you haven't tried pnpm yet, it takes about 5 minutes to switch and a single command to install:

npm install -g pnpm

Give it a week. You might not go back. 💡

Want more hands-on dev content like this? Head over to hamidrazadev.com — there's a lot more where this came from. If this article saved you some confusion (or some disk space), share it with a fellow developer who's still on the npm default. They'll thank you later. 🔧