DEV Community: Mohammed Farmaan.

Working with LLMs: A 50/50 Effort.

Mohammed Farmaan. — Mon, 05 Jan 2026 03:03:53 +0000

This article was originally published on my personal blog: https://farmaan.dev/writing/working-with-llms/

Hiee! Welcome to another post. This time, it’s not me ranting about things or people I don’t like, but about one of my favorite things: tech. I’m hoping to write a practical guide on working with LLMs.

And this post is not how a typical LinkedIn-AI-Grifter portrays working with AI looks like (getting 100 things done at once by running 25 agents in parallel or running 50 agents in the background to make a billion-dollar SaaS), which I know sounds ridiculous, but they've been doing this for a while now, just to farm engagement, of course.

This post is as real as it can be and is about working with Large Language Models every day as a software engineer. If put in a fancier way, it's about working with AI. So let's get going, shall we?

Okay, so it seems quite easy to work with LLMs, right? All you have to do is just prompt and it will get the job done. Well, that's true, but only if you want mediocre results.

A wise man once said: "A human can give you mediocre results, but a human using AI wrong can give you worse - me 2025"

Anyway, enough small talk. Let's see how we can actually work with LLMs the way God intended. I have a few topics in mind which I believe cover the entire arc of this post. So let's start with "prompting":

Prompting: Mediocre, Detailed & Refined.

Everything starts with a prompt when working with LLMs, and it shouldn't be a surprise that it's the prompt itself that can make or break the end result. And IMO, there are three types of prompting: "mediocre, detailed & refined." I'm not going to be extremely detailed about these because they're already descriptive enough.

Anyway, as the name suggests, a mediocre prompt is the most low-effort sentence that you can feed to an LLM, assuming it will just somehow read your mind and give you the right results. Here's an example of a mediocre prompt in the context of software engineering:

Add chat reactions in the chat section.

That's it. That's the prompt. You're basically telling the LLM to do the most out of these few words, which means it not only has to do the extra work of gathering the context, but also means an over-engineered, mediocre end result. You can argue that isn't the whole point of LLMs? Making the most out of as little effort as we can? Well, yes, but not in the context of software engineering.

The same can be true if it were a different context, such as writing an email for sick leave. It will do the job effortlessly because it doesn't need context there. It's a simple thing, and LLMs are already good at these.

Anyway, the next one is a "detailed" prompt. As the name suggests, these prompts are usually detailed. Not bragging, but since I also write in general, I'm pretty good at writing detailed prompts and I'm also well aware of how things work in my codebase. So I can almost always write a prompt that makes an "LLM feel at home," which is quite important because the last time I heard, they have feelings too, so please make them feel at home.

Here's an example of a detailed prompt:

Add chat reactions in the chat section. Here's the relevant context for you to work with: @app/chat @api/chat

The chat section is a React component that displays a list of messages. Each message has a timestamp, user avatar, and message content. I need to add a reactions feature that allows users to react to messages with emoji (like 👍, ❤️, 😂). The reactions should:

1. Be displayed below the message content
2. Show the count of each reaction type
3. Allow users to click to add/remove their reaction
4. Use the existing API endpoint POST `/api/messages/{id}/reactions`

Look at how the message component is structured and add the reactions UI alongside the existing reply button. Keep the styling consistent with the current design system (using Tailwind classes from the rest of the component).

Great difference right? Yea sure, but you know what? Sometimes even detailed prompts aren't good enough. And that's where the third type comes in: "refined" prompts. A refined prompt is basically a detailed prompt that has been fed back through an LLM to make it even more specific and clear. I know it sounds a bit weird, but here's how it works:

I'm just going to feed the same detailed prompt from above, and here's how the refined version looks:

Add emoji reactions to the chat section. Relevant modules: **@app/chat**, **@api/chat**.

The chat section is a React component that renders a list of messages. Each message currently includes a timestamp, user avatar, and message content. Extend the message UI to support **emoji reactions** (e.g., 👍 ❤️ 😂).

## Requirements

1. **Display reactions** directly below the message content, aligned with the existing layout.

2. Each reaction should show:
   * The emoji
   * A count of how many users selected it

3. Users should be able to **toggle** each reaction:
   * Clicking adds their reaction if not present
   * Clicking again removes their reaction

4. Use the existing API:
   * `POST /api/messages/{id}/reactions`
   * Request body should include the emoji/reaction type and user ID if required

5. Integrate reactions in the message component **next to the existing reply button**.

6. Follow the current design system:

7. Make sure the component:
   * Use Tailwind classes consistent with the surrounding component styles.
   * Updates optimistically on click
   * Handles reaction updates coming from the server (if applicable)

## Additional guidance

* Review the structure of the `Message` component to understand where to insert the reactions block.
* Ensure the reactions area is compact and visually consistent with the rest of the message UI.
* Use a small set of common emoji reactions (hardcoded list is fine unless otherwise configured).

See the difference? The refined version is way more specific about what the LLM needs to do, where it needs to look, etc. So that's how a refined prompt can make the LLM perform much better. Anyway, assuming the importance of prompting is now clear, let's move on to the next section "context":

Context: Manual vs. Automatic.

A wise man once said, "Context is King." Except this time, the wise man is not me. But anyway, if you're doing any serious work, context pretty much means everything when working with an LLM. Without it, you will just end up with half baked answers, overly confident wrong results, and a tangled mess.

While I have to say that LLMs have gotten pretty good at grepping context automatically, feeding them context manually still goes a long way. Especially when you want it to make fewer mistakes and create less mess which means more accurate results and reduced token usage. Manual context also makes the output more predictable, which matters a lot when you are building or making changes to real systems.

Since I'm writing this in the context of software engineering, there are multiple ways you can feed context to an LLM. The easiest way to do so is to just attach the relevant files, folders, or docs and let the LLM derive the context from it.

This works well because the LLM now has direct access to files and folders it needs to work with so it will give you much more accurate results. In this case, you are telling the LLM to bail out on guessing and focus solely on results based on the given context which means reducing the scope of the errors upfront.

The other way to feed context is mostly verbal. So instead of attaching relevant files and folders manually, we just verbally tell the LLM where and which parts of the codebase to look.

Now since LLMs are already good at grepping context automatically, your instructions help it further and helps it produce better results. This approach trades some certainty for speed and flexibility, and works well when you are still exploring or are not fully sure what matters yet.

The latter is what most vibe-coders use because they can't code or don't know what's in their codebase yet. In practice, you will almost always end up using a mix of both. Explicit context when correctness matters the most, and auto-discovery when you just want to get the job done without hand-holding the LLM on every step.

As an engineer, you should know that you can only get so far with only one of these, so it's always a good thing to use both depending on the context.

Behavior: Configuration + Steering.

Configuration

As the name suggests, this involves configuring an LLM using a config file. Don’t confuse this with configuring LLM inference parameters, which is a completely different kind of configuration that end users usually don’t touch.

The type of config I’m talking about is more like rules. These act as a middle layer and affect the LLM’s final output. They tell the model not to make changes based purely on its own conclusions, but to follow a defined set of guidelines whenever it needs to change something.

Now there are multiple ways this can be configured, and LLM providers have tried various approaches, including a markdown file that corresponds to their LLM, such as CLAUDE.md, GEMINI.md, AGENTS.md, and so on. If you're using an editor like Cursor, it has .cursor/rules/**.md. I'm just waiting for the day when we can all decide on a single format and call it a day.

I still believe AGENTS.md is the way to go, but for now let's focus on rules, which in the end is just a markdown file with a set of rules for the LLM to follow before it makes a change. This section is quite descriptive, so let's look at a simple example where we make an LLM perform the same task with and without the config.

Imagine you're working with a React codebase and you ask an LLM to add a new button component. Without any config, the LLM might create a button with inline styles, import unnecessary dependencies, and not follow your project's naming conventions. Here's what you might get:

// (Button.tsx) Without config - mediocre result
export const Button = ({ text }) => {
  return (
    <button style={{ padding: '10px', backgroundColor: '#007bff' }}>
      {text}
    </button>
  );
};

But if you have an AGENTS.md file that specifies your rules, like:

- Use Tailwind CSS for styling (never inline styles)
- Follow PascalCase for component names
- Use lowercase for filenames
- Use TypeScript with proper type definitions
- Use app's color scheme for styling default

The LLM will produce something much better:

// (button.tsx) With config - much better result
interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement> {
  children: React.ReactNode;
}

export const Button: React.FC<ButtonProps> = ({ children, ...props }) => {
  return (
    <button 
      className="px-4 py-2 bg-blue-600 hover:bg-blue-700 text-white rounded-lg"
      {...props}
    >
      {children}
    </button>
  );
};

This is not the greatest example, but you see the difference, right? It is significant. Proper TypeScript types, Tailwind classes, and adherence to your naming conventions. This is how behavioral configuration works in practice, and trust me, it makes a huge difference in your workflow and can save you a lot of headaches upfront.

My rule of thumb when configuring rules is to start with a minimal config file instead of creating a comprehensive file that you don't understand. Every time the LLM makes a decision you don't like, stop right there and edit the config file to include that rule so it doesn't repeat it next time.

This way, in no time you will have a good set of rules tailored to your codebase. You can store that in git and use it in other projects with a few changes here and there. But again, if you want the above method to work, you must know what good project and code defaults are. If you configure an LLM with mediocre rules, you will still end up with mediocre results.

Steering

This section exists because rules alone cannot give you great results. If config were a one-time thing like "set good rules and forget," we would not have this problem in the first place. The core issue is that LLMs are non-deterministic and can still deviate from their intended behavior even with rules in place.

This is where steering comes in, and don't worry, steering is not a technical term. In this context, I'm just using it as a general explanation. When an LLM starts deviating from what you expect, a human needs to step in and steer it toward the right behavior.

It's similar to driving a Tesla where you let Autopilot take over the wheel, but due to changing traffic and road conditions, it might still make a wrong decision unless you take the wheel back. The system exists to assist you, but ultimately, the responsibility still lies with the person driving.

The same concept applies when working with LLMs. Just like road and traffic conditions change constantly, an LLM operates in a non-deterministic environment. Steering means knowing when to pause it, correct assumptions, limit scope, or ask it to explain its reasoning before moving forward.

By doing this, you can almost always be certain of deriving better results from an LLM. This is how both steering and configuration together make working with LLMs much better.

Review, Refine, Ship.

Welcome to the final section of this post. Honestly, I’d be impressed if you read this far, because I personally wouldn’t, xD. Anyway, as the heading suggests, this is about the final checks you need to perform before you commit to an LLM’s result. No matter the rules and manual steering, in the end, when you look at what it has given you, it can still feel overwhelming and it might not be up to your standards.

In my usual workflow, this is where I break out of the agent loop. This part is completely OFF LLM. Now it is just me and the code the LLM has given me. And TBH, this is my favorite part of the entire session, because this is where I get to review and judge the LLM for what it has done.

At this stage, the LLM has made something I wanted work. Now I need to check if it has done it correctly. A wise man steps in again and says: Just because it works doesn’t mean it is right! And it is true, I agree with him, because again, I’m that wise man.

Unless you’re a bad engineer who accepts whatever an LLM throws at you, most of the time these results won’t look good enough. Because they usually aren’t. So this is where I review and refine things.

I first check if it has modified the relevant files. I check if it has created unnecessary files just for the sake of SOC (separation of concerns), even if they don’t really separate the concerns. I delete or move them to where they belong. I toggle my diff view and check side by side what it has written, how well it handled errors, messages, conditionals, etc. The general good code stuff. This cycle continues until I feel satisfied enough.

When I hit that stage, I test and commit the results. At this point, I have a fully working feature that adheres to my code standards, without putting in the writing effort myself.

When to not use an LLM

This is a short section to point out that LLMs are costly. They cost money to run, build, and use. You will make your spending much higher if you use them for simple tasks that don’t actually need an LLM, such as removing logs, minor style changes, one-word refactors, or adding and removing comments. You should almost always use your IDE for these things.

By doing this, you ensure you outsource the major writing part to the LLM, and keep fixing and refining to yourself, which completes the loop and keeps you satisfied with the end result.

Well, that’s all for this post. I hope you enjoyed reading it. See you in the next one. Have a great day!

Declutter Your JavaScript and TypeScript Projects.

Mohammed Farmaan. — Mon, 18 Aug 2025 01:50:55 +0000

This article was originally published on my personal blog on 2025/08/13

Hiee! Welcome to another post where I'm going to show you how we can use Knip to declutter our TypeScript and JavaScript projects.

What is Knip?

Knip is an amazing tool that aims to declutter your JavaScript and TypeScript projects. But what does decluttering mean? If you've ever worked on a project for a while that involves a bunch of people or even just yourself, you'll notice that unused code and dependencies tend to accumulate in the codebase over time. This is also known as Technical Debt.

What is Technical Debt?

Technical Debt is the mess no one on your team wants to touch. Oh wait, that sounds a bit too vague. Here's a better one: Technical Debt can be anything from legacy code that might just be hanging by a thread or might be craving for a refactor, or it could be unused code, dependencies, config files, and more.

A very practical example of how this technical debt builds up: we often remove features from our projects due to low traction, but we forget to clean up all the related code. Or we over-engineer solutions far too often, which leaves behind unused abstractions and helper functions.

This is even more relevant today because we blindly accept changes that an LLM makes to our codebase these days. Since most LLMs are trained on shitty code, you should always expect them to do the bare minimum and not the other way around. Which means even more unused & irrelevant code gets left behind.

Running Knip

Well, enough of what is what, and let's see how we can actually clean that mess up. This is where Knip comes into play. When you run Knip on your codebase, it gives you a nice summary of which files, components, exported functions, constants, etc. are currently unused in your codebase.

This is the moment you will realize how much of the mess has built up over time that went unnoticed. Unless you stick to extremely strict code standards and reviews, preventing this is close to impossible because the human brain can only keep track of so much.

Here's an example Knip summary from one of the projects that I ran Knip on: $ pnpx knip

Unused files (5)
app/components/cart.tsx
app/components/emoji-picker.tsx
app/components/media-dropzone.tsx
app/components/profile.tsx
app/components/select-image-modal.tsx

Unused dependencies (4)
@axiomhq/pino                              package.json:32:6
@hono/zod-validator                        package.json:36:6
@opentelemetry/auto-instrumentations-node  package.json:41:6
@tailwindcss/typography                    package.json:63:6

Unused exports (4)
CreatePost                             function  app/components/create-post.tsx:51:17
HappeningNowModal                      function  app/components/happening-now.tsx:755:17
ShareButton                            function  app/components/post.tsx:141:17
StickerPopover                         function  app/components/post.tsx:193:17
TipPostPopoverItem                     function  app/components/post.tsx:549:17

Unused exported enum members (5)
GUARANTEED  DistributionStrategy       app/enums.ts:41:3
CATEGORY    SanitySearchKeys           app/enums.ts:67:3
SLUG        SanitySearchKeys           app/enums.ts:68:3
TITLE       SanitySearchKeys           app/enums.ts:69:3
STICKERS    FocusCarouselResourceType  app/types.ts:526:3

Wow! All we did was run a single command, and now we can see everything that is not being used in our codebase. How great is that? Honestly, this is one of the best parts of Knip. It is almost config-less. Here's a quote from its docs: Knip has good defaults and aims for "zero config."

This might be hard to believe, but I was able to delete 12k+ lines of code across 100+ files using Knip—which I would not have been able to do otherwise by myself.

Using A Config File

But since every project is different, where you might want to run Knip can also change. You may want to run it on a fraction of a codebase—this is where the config file comes in.
Here's an example config file from the docs: knip.json

{
  "$schema": "https://unpkg.com/knip@5/schema.json",
  "entry": ["src/index.ts", "scripts/{build,create}.js"],
  "project": ["src/**/*.ts", "scripts/**/*.js"]
}

As you can see, you can customize where Knip runs, what it lints, etc. It has a lot of other config options too, and honestly, I'm not going to cover all of them. It would be too much. But these are the bare minimum and most likely suitable for the vast majority of projects.

Anyway, coming back to the summary that Knip gave us, what can we do here? For starters, you can just go to those files and remove all the suggested unused stuff manually. But wait, this doesn't sound like a very easy task, right? Yeah, because it isn't. It's pretty tough to go to every single file and delete things.

But don't worry, Knip has got us covered there too. Knip provides us with an auto-fixer knip --fix --allow-remove-files flag that goes ahead and removes the suggested deletions for you. Can you believe this tool is free? I can't, but here we are.

Alright, that sounds a bit dangerous, right? Letting a tool do file operations on our codebase? And yes, it should sound dangerous because it is, but what is git there for? As long as you check out to a new branch, you can do whatever you want with the copy of your codebase. You'll only need to worry if you're not using git, which I don't think is even possible in 2025.

The Next Steps

Great! We did everything we were supposed to do. Now all we need to do is review the changes that Knip made. But why do we need to review? Well, it is to make sure we did not accidentally remove anything that was being used. It is always good to check twice so that we don't end up breaking prod on a friday evening.

One of my favorite things about all of this is, if you're using TypeScript, you can just run the TypeScript typechecker tsc --noEmit, which will tell you if you accidentally removed anything that was being used somewhere. But if it doesn't complain, you have nothing to worry about. Go ahead and merge that PR. But if you're using JavaScript, first of all, I'm sorry you had to maintain a JS codebase; secondly, you can still probably get away with using a linter, so it should be fine.

Alright, that's it for this post. Hope you learned something. Run Knip on your codebase today, and you will thank yourself later. Happy deleting code.

Takeaways

While this may seem as simple as running a single command, it is not a do once and forget kind of thing. You should probably add this to your dev scripts or CI and make sure this runs frequently so you can keep clearing out the stuff as it comes.
Do not blindly accept changes from LLMs. They often over-engineer and add unnecessary things that are not even relevant to that particular task.
A lot of devs don't care about tech debt, but try being that person who cares—you will thank yourself later for taking that responsibility.

Simplifying Git: A Practical Guide for Everyday Use.

Mohammed Farmaan. — Mon, 18 Aug 2025 01:48:43 +0000

This article was originally published on my personal blog on 2025/06/14

Hie! Welcome to another post where I'm going to use my poor writing skills to simplify Git for you, XD.

The Problem

If you're reading this, I expect you to be already familiar with the basic Git workflow. Git is often portrayed as overly complex, which it is but only if you consider all the features it has to offer.

If you only consider the features that you need for everyday software development, it becomes much simpler to use in practice.

Having worked at various companies and multiple personal projects over the years, one thing that has been constant is Git. Your tech stack might change every year or so, but Git remains the same. Learn it once, and you can use it everywhere.

While I'm not an expert, I'll walk you through the most basic Git workflow I use—one that aligns with how most software is written. We'll explore one of the most popular Git workflows, known as Git Flow.

What is Git Flow?

Git Flow is a popular Git branching strategy aimed at simplifying release management, introduced by software developer Vincent Driessen in 2010. Fundamentally, Git Flow involves isolating your work into different types of Git branches - Source.

Git Flow defines specific branch types for different purposes:

main/master: Production-ready code.
development: Staging/development environments.
feature branches: Individual feature development.
release branches: Preparing new releases.
hotfix branches: Quick fixes to production.

For most projects, you'll primarily work with main (production), development (staging), and feature branches. The others are useful for larger teams with complex release cycles.

📌 Important Note

Before moving forward, I'd like to stop here and define some aliases that make working with Git much easier and fun. Paired with a Zsh framework such as Oh My Zsh, I don't think there is a better way to use Git from a CLI. These aliases are straight from my .zshrc config:

Git CLI

# Navigation & Branch Management

alias gb='git branch'           # List all local branches
alias gc='git checkout'         # Switch to an existing branch
alias gcb='git checkout -b'     # Create and switch to a new branch
alias gbd='git branch -d'       # Delete a local branch

# Push & Pull

alias gp='git push'                     # Push current changes to remote branch
alias gpl='git pull'                    # Pull latest changes from remote branch
alias gpo='git pull origin --no-edit'   # Pull without opening an editor for merge messages

# Commit & Add

alias gcm='git commit -m'             # Commit with message
alias gacp='git add . && git commit -m "uwu" && git push'  # Quick add/commit/push with default message. Works best when working on personal projects.

# Stash Management

alias gs='git stash'                  # Stash current changes
alias gsp='git stash pop'             # Apply and remove last stash
alias gsl='git stash list'            # Show all stashed changes

GitHub CLI

The GitHub CLI (gh) is GitHub-specific and provides easy integration with GitHub's features like pull requests, issues, and repositories. I use it for both personal projects and professional work.

But the Git CLI should be the same regardless of the code hosting provider you use.

alias gpr='gh pr create --base' # Create a PR by specifying a base branch ex: gpr main
alias gpm='gh pr merge' # Merge the current PR (run from the PR branch).

Now that we have these aliases set up, I'll use them throughout the rest of this article to demonstrate Git workflows. They'll make our examples much cleaner and more practical for real-world usage.

Working with Branches

If you ask me, branches are one of the coolest things about Git. They let you work on features independently without affecting the main codebase.

You can make multiple copies of the same code in multiple branches and test your changes in isolation. Here's how I typically work with branches using the aliases we set above:

Creating, Switching, & Deleting Branches

Always pull the changes from the remote before you create a branch. It will save you a lot of headaches with conflicts later.

# Create and switch to a new feature branch
gcb feat/user-authentication

# Switch to an existing branch
gc feat/user-chat

# Delete a local branch after it's been merged, not necessary unless you wanna create a fresh branch with same name.
gbd feat/user-authentication

# Force delete a local branch (even if not merged - use with caution)
gb -D feat/broken-feature

# Delete a remote branch
gp origin --delete feat/user-authentication

Adding and Committing

I personally use my editor to add and remove files because it's much easier and gives me a beautiful diff of the changes that I made so that I can be sure that I'm not pushing unintended changes.

The diffs also act as self code review because you can see if you have over-engineered something so you can go back and simplify it. This is far more relevant these days because people are straight up pushing LLM written slop. Please don't be that person.

If you think using the CLI to add files makes you look cool, good luck when you push something to prod without diffing it first.

Nonetheless, here are some examples of adding & removing files using the CLI:

# Add individual files
git add src/components/chat.ts
git add README.md

# Add multiple files
git add src/utils/auth.ts src/types/user.ts package.json

# Add all files in a directory
git add src/components/

# Add all TypeScript files
git add *.ts *.tsx

# Add everything (use when you're sure you have only changed the required files & make sure to run "git status" to see which files have been modified)
git add .

# Remove files from staging (if you added by mistake)
git reset src/components/chat.ts

And here's how I typically commit:

# Quick commit for personal projects
gacp    # Adds everything, commits with "uwu", and pushes

# Proper commit with custom message
gcm "Add http fallback to websockets"

Pulling and Pushing

These are the most basic operations to sync your local work with the remote repository. Always pull before you start working to avoid conflicts later.

Note: Git might ask you to configure how to handle divergent branches on your first pull. Just run git config pull.rebase false to use merge (the default). Rebase vs merge is a whole different topic—I just use merge and call it a day.

If you really wanna know how each one differs, you can read it here.

# Pull latest changes from remote
gpl

# Pull changes from a remote branch
gpo main

# Push current local changes
gp

Stash Operations

Stash is like a temporary clipboard for your uncommitted changes. Super useful when you need to quickly switch branches but aren't ready to commit yet.

# Save current changes temporarily
gs

# Restore last stashed changes
gsp

# See all stashed changes
gsl

Pull Requests (PRs)

PRs are basically how you say "Hey, I made some changes, can you review them?" They're super important for code review and collaboration, especially when working with other people.

These can also be used to keep track of the things that you have shipped.

Creating a PR

After you've pushed your feature branch, creating a PR is dead simple with the GitHub CLI:

gpr main  # Creates a PR against the main branch

The GitHub CLI will ask you for a title and description. Don't just write "fix stuff"—actually explain what you did and why. If not a description, at least make the title clear.

PR Best Practices

I've seen some terrible PRs, so here's what actually matters:

Write clear titles: "Add user authentication" not "fix stuff" or "updates."
Explain (optional): Don't just say what you changed, explain why you changed it. Not always, but when the changes touch a bunch of other files.
Keep PRs Simple: Nobody wants to review 50 files. Break big features into smaller PRs.
Test & lint your stuff: Please test & lint your changes ffs before you ask for a review.

Wrapping Up

Alright, that's pretty much everything you need to know about Git for day-to-day development. Honestly, Git can do a lot more than this, but trust me—you as an average developer will barely need that. Here are the takeaways:

Git Flow is nice but don't over-complicate it. For small & personal projects, just use main and feature branches.
Use aliases. Your fingers will thank you after typing gcb instead of git checkout -b for the 100th time.
Branch often. Create branches for everything, even tiny changes.
PRs are your friends. They catch bugs and make you and your code better. But only if you take criticism constructively.
Commit messages matter when you work with teams. Imagine trying to find the change that broke prod among 100 commits that all say "fixes."
When in doubt, stash the changes. It's much better than losing work.

That's about it for this post. See you in the next one! Happy Coding & have a good day!

Improving Performance of Async Operations in JavaScript.

Mohammed Farmaan. — Mon, 18 Aug 2025 01:46:53 +0000

This article was originally published on my personal blog on 2025/01/28

If you're reading this, you've probably worked with promises before. And when I say promises, I don't mean the ones made by your friend or partner. Most of the time, they're API calls on the client or database queries on the server—basically, anything async in JavaScript.

The Problem With Sequential Execution

I can’t fathom how many codebases out there are littered with code like this. Let’s look at an example that uses sequential execution to understand what the problem is. Here’s a function that gets the user data — it’s highly abstracted for simplicity.

async function getUserData(userId: string): Promise<UserData> {
  const posts = await getPosts(userId); // 1000ms
  const followers = await getFollowers(userId); // 1000ms
  const following = await getFollowing(userId); // 1000ms

  return { posts, followers, following };
}

const data = await getUserData(userId); // Time to get user data 3s

At first glance, it's tough to spot what's wrong here. And I'm pretty sure your codebase has a lot of code that looks like this. But let's keep that aside and get into the details.

Basically, each request here waits for the previous one to finish, which means the time it takes for each request to finish is adding up with the next one, which leads to unnecessary delays.

Unless your server responds within 100ms for each request across the globe, this delay could be even worse for people living far away from your infra. So, what can we do?

For starters, we could place more servers & databases closer to your users. But wait, that doesn't sound very practical—unless you have a lot of VC money to burn on infra.

The next thing we can do is quite simple actually. Guess what? Just read the docs. Yeah the docs about Promises. It has a hidden gem, and it's called Promise.all().

What is Promise.all()?

Promise.all() runs all your promises concurrently. Which means if you have multiple promises, such as above, they all can be fired concurrently instead of waiting for each one to complete. Here's a refactored example that uses Promise.all() to fire promises concurrently.

async function getUserData(userId: string): Promise<UserData> {
  const [posts, followers, following] = await Promise.all([
    getPosts(userId), // 1000ms
    getFollowers(userId), // 1000ms
    getFollowing(userId), // 1000ms
  ]);

  return { posts, followers, following };
}

const data = await getUserData(userId); // Time to get user data 1s

Hell yeah, that's 3 times faster than the original implementation. But wait, if everything about this is so nice, why don't we use it everywhere? Well, if you write software, you know it's a game of trade-offs. There's not one solution you can use for everything and call it a day. Here's why:

While Promise.all() works great for independent tasks, it's not the best fit for dependent ones. If the result of one promise is required for the next, sequential execution is still your best friend. Here's an example:

async function getOrderDetails(request: Request): Promise<OrderDetails> {
  const user = await getUser(request);
  const orders = await getOrders(user.id); // here, user.id is required so Promise.all() can't be used
  const orderDetails = await getOrderDetailsById(orders[0].id); // here, orders[0].id is required so Promise.all() can't be used

  return { user, orders, orderDetails };
}

const details = await getOrderDetails(userId);

In this case, each step depends on the previous one. Using Promise.all() here would result in errors since the dependent data wouldn't be available when needed.

For scenarios like above, firing them sequentially is still the best option. Here's a benchmark that shows the difference between firing them concurrently and sequentially.

Handling Errors with Promise.all()

One issue with Promise.all() is that it fails fast—if any promise rejects, the entire operation fails. You can handle this by wrapping each promise in a .catch() block:

async function getUserData(userId: string): Promise<UserData> {
  const [posts, followers, following] = await Promise.all([
    getPosts(userId).catch(() => []),
    getFollowers(userId).catch(() => []),
    getFollowing(userId).catch(() => []),
  ]);

  return { posts, followers, following };
}

This makes sure that a single failure doesn't disrupt the entire batch, and allows partial results to still be processed. But wait, that doesn't look very nice, right? I mean, just wrapping each promise in a catch block feels clunky and like a wasted opportunity to handle errors properly.

Enter Promise.allSettled() — a cleaner and more structured way to deal with multiple promises when you care about all the outcomes, not just the successful ones. It waits for every promise to settle (either fulfilled or rejected) and gives you a neat summary of what happened, so you can handle successes and failures in one go, without any try-catch gymnastics.

Takeaways

Using Promise.all() is a great way to improve the performance of async operations by running them concurrently. It's quite useful & can bring a lot of gains when the operations are independent of each other.
Handle errors gracefully with .catch() blocks or consider Promise.allSettled() for detailed error handling.
As I said before, it is not a silver bullet. Avoid it for dependent tasks where sequential execution is a must.

Endnote: Go to your project and replace all the unnecessary sequential calls with Promise.all() and let your async tasks perform better!

Reusability In React!

Mohammed Farmaan. — Sun, 19 Dec 2021 05:50:09 +0000

What is reusability?

Code that allows itself to be reused for different purposes without having to re-write different code for the same purpose is reusability.

Why reusability at all?

Well, I had the same question when I started learning React. Why do we even need Reusable components when we can straight up write some more code and create another component, right? Well, this goes against many ways. One of them being DRY.

Do not repeat yourself.

One of the key principles of Software Development.

Fun fact: When I Started React, I used to write every other component just like plain html without reusing the code anywhere at all. ( Only until I learned this ).

How can reusability be achieved?

Well there are many ways to achieve reusability. It just depends the type of code that you're writing. In this article I'm gonna show how you can build Reusable Button Component in React which you can reuse anywhere in your React projects.

Step 1:

Start with the idea: To have buttons as components without reusability you'd do something like this in your project:

DownloadButton.js
CancelButton.js
ShareButton.js and ...so on.

I guess you can already sense the problem here. Can't you? Well if you can't, here it is: Multiple files with similar/duplicate code for the same type of component. (Button).

Which means more complex and annoying file structure to maintain as the project grows.

So how can we solve this?

Well, make a component which can give you the result that you want with the data that's given to it. Let's do it.

Create a React project. I've used CRA here:

create-react-app reusable-components

Dependencies: react-icons (npm i react-icons)

Step 2:

Create a component called Button.js or with a name that you prefer.

Place the following code in it:

import React from "react";

export default ({ buttons }) => {
  const generatedButtons = buttons.map((button, index) => {
    const [icon, text, textColor, backgroundColor, buttonRadius, callback] = button;

    const Icon = icon;

    const styles = {
      receivedStyles: {
        color: textColor,
        background: backgroundColor,
        borderRadius: buttonRadius,
      },
      defaultStyles: {
        display: "flex",
        alignItems: "center",
        justifyContent: "center",
        border: "none",
        padding: "0.6em 1.2em",
        margin: "1em",
        fontSize: "0.9em",
      },
    };
    const { receivedStyles, defaultStyles } = styles;
    return (
      <button
        key={index}
        style={
          icon
            ? { ...receivedStyles, ...defaultStyles }
            : { ...receivedStyles, ...defaultStyles, padding: "1em 1.5em" }
        }
        onClick={callback || null}
      >
        {icon && <Icon style={{ margin: "0.3em", fontSize: "1.5em" }} />}
        {text && text}
      </button>
    );
  });

  return (
    <div>
      {generatedButtons}
    </div>
  );
};

The logic in above code is quite simple. We just map a Two Dimensional Array containing individual array data which maps to a different button. And with a bit of conditional rendering, we display them differently based on the data they're given.

How to use?

It's quite simple too.

import Button from "./Button";
import { IoMdDoneAll as DoneIcon } from "react-icons/io";
import {FaCloudDownloadAlt as CloudDownloadIcon, FaShareAlt as ShareIcon,} from "react-icons/fa";
import { MdCancel as CancelIcon } from "react-icons/md";

const styles = {
 height: "100vh",
 width: "100%",
 display: "flex",
 alignItems: "center",
 justifyContent: "center",
 background: "#242424",
};

function App() {
  return (
    <div style={styles}>
        <Button buttons={[
           [DoneIcon, "Done", "#fff", "#570C99", "6px", () => console.log("clicked: Done button")],
           [cloudDownloadIcon, "Download", "#fff","#009DAE", "100px",() => console.log("clicked: Download button") ],
           [CancelIcon, "Cancel", "#fff","#FF0000", "100px",() => console.log("clicked: Cancel button") ],
           [ShareIcon, "Share", "#fff", "#516BEB", null,() => console.log("clicked: Share button") ] ]}
    </div>
  );
}

export default App;

Finally, the result!

See how different buttons render? And all this from a single component? Well that's the magic of reusable code.

And their callbacks work perfectly too!

The end.

Hope you've learned something new. Thanks for reading. Happy coding!❤️

Revue-generator: React & Vue Component Generator.

Mohammed Farmaan. — Fri, 08 Oct 2021 17:26:46 +0000

I'm learning Node JS so I thought it'd be better to make some projects which will help me understand Node JS better. So I did.

Here it is:

Revue-gen: The React and Vue component generator.

If you've worked with React or Vue, you might have came across this situation where your app needs a lot of components and you have to create them all manually. It's a pain, right? So I thought why not make it a little easier. And I did. (Hopefully).

I built a Command line tool that makes this process easier. All you have to do is install it using NPM, cause it's an NPM package.

npm i -g revue-generator

run this using

npx revue-generator

and boom:

It just makes the process easier.
You can give it a try too:
https://www.npmjs.com/package/revue-generator

Weatherify: A Weather App built with React.💙

Mohammed Farmaan. — Sat, 22 May 2021 18:02:53 +0000

Hey there everyone! Hope you're all doing good.

So it's been a month since I started learning React, and I can say that I'm loving it so far. And to understand it even better, I decided to follow the project-based approach.

After thinking a lot I decided to make a weather app that can have dynamic backgrounds. So finally after a lot of ups and downs, here it is:
It's called Weatherify. This app gives the current weather details of most of the cities in the world.

I've used Open Weather Map API to fetch the weather data and Pexels API to get images and dynamically set them as backgrounds.

Here are its screenshots:

It gets a new background image after each search:

So here it is guys. I've hosted it on Firebase and made it Open-Source so that it'll help someone as a beginner-friendly project.

Here's the link to the live demo:
https://weatherify-react.web.app/

Here's the link to GitHub repo:
https://github.com/zxcodes/Weatherify-Web

Open to suggestions and feedback.😄

Weatherify: A Simple Weather App using Flutter.

Mohammed Farmaan. — Fri, 05 Mar 2021 03:27:23 +0000

Hey there everyone! I hope you're all doing good. It's been a while since I've posted anything. Today I'm announcing a simple Weather App built using FLutter & Open Weather API. It is called Weatherify and it gives the current weather info of all most all the cities in the world as soon as you enter the city name. I just started working with APIs & I decided to make an app to understand the concepts better. So I came up with this. And also I decided to go Open Source with this one because I thought it's a good idea unless I'm not revealing my API key.😛

I'm also distributing the APK with this one so that people can try it out and let me know if it's working as intended.

Here's the link to repo:

zxcodes / Weatherify

A simple Weather App to get the current weather of almost every city in the world. Built with Flutter.💙

Weatherify

A Weather app for fetching current weather details of any city in the world.
This App has been built using Flutter.
APK is attached in the release section. Give it a try.

Credits

Open Weather API. (https://openweathermap.org/api)
Some amazing people at stackoverflow for their answers when I was stuck. (https://stackoverflow.com/)

Screenshots

Default Homescreen
When a City is entered.
When a City is not found.
When no City is entered.
When there's no Internet.

Open to Suggesions & Contributions.

View on GitHub

Here's the link to APK release
https://github.com/zxcodes/Weatherify/releases/tag/v1.1
Thank you!😄

Simple Calculator with Dark Mode.

Mohammed Farmaan. — Wed, 08 Jul 2020 10:36:28 +0000

Here's a simple calculator built using HTML, CSS and obviously, JavaScript.

This calculator also has dark mode which looks really good. And here's how you can do that:

Here's the markup:

<!DOCTYPE html>
<html>

<head>
  <meta charset="utf-8" />
  <meta http-equiv="X-UA-Compatible" content="IE=edge" />
  <title>Calculator</title>
  <meta name="description" content="" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <link rel="stylesheet" href="light.css" id="theme" />
  <link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@300&display=swap" rel="stylesheet" />
</head>
<body>
  <center>
    <div class="container">
      <h1>Calculator</h1>
      <div class="first-row">
        <input type="text" name="result" class="result" id="result" value="" placeholder="Result" readonly />
        <input type="button" value="C" onclick="clearScreen()" class="clear" />
      </div>
      <div class="second-row">
        <input type="button" value="1" onclick="liveScreen(1)" id="one" />
        <input type="button" value="2" onclick="liveScreen(2)" id="two" />
        <input type="button" value="3" id="three" onclick="liveScreen(3)" />
        <input type="button" value="+" onclick="liveScreen('+')" />
      </div>
      <div class="third-row">
        <input type="button" value="4" id="four" onclick="liveScreen(4)" />
        <input type="button" value="5" id="five" onclick="liveScreen(5)" />
        <input type="button" value="6" id="six" onclick="liveScreen(6)" />
        <input type="button" value="-" onclick="liveScreen('-')" />
      </div>
      <div class="fourth-row">
        <input type="button" value="7" id="seven" onclick="liveScreen(7)" />
        <input type="button" value="8" id="eight" onclick="liveScreen(8)" />
        <input type="button" value="9" id="nine" onclick="liveScreen(9)" />
        <input type="button" value="x" onclick="liveScreen('*')" />
      </div>
      <div class="fifth-row">
        <input type="button" value="/" onclick="liveScreen('/')" />
 <input type="button" value="0" id="zero" onclick="liveScreen(0)" />
        <input type="button" value="." class="dot" onclick="liveScreen('.')" />
        <input type="button" value="=" onclick="result.value = eval(result.value)" />
      </div>
      <div class="bottom-buttons">
        <button>
          <i class="fab fa-github"></i>
          <a href="https://github.com/Mohammad-Farmaan/JavaScript-Calculator">GitHub</a>
        </button>
        <button onclick="switchTheme()" id="dark-mode">
          Dark Mode 🌙
        </button>
      </div>
    </div>
  </center>
  <script src="https://kit.fontawesome.com/f28b055962.js" crossorigin="anonymous"></script>
  <script src="script.js" async defer></script>
</body>
</html>

Here's the CSS for Light Mode:

* {
  box-sizing: border-box;
  padding: 0;
  margin: 0;
  font-family: "Open Sans", sans-serif;
  font-weight: bold;
}
body {
  background-color: rgb(28, 231, 221);
  transition: 0.8s;
  -webkit-transition: 0.8s;
  -moz-transition: 0.8s;
  -ms-transition: 0.8s;
  -o-transition: 0.8s;
}
h1 {
  margin-top: 25vh;
  text-align: center;
  margin-bottom: 1.5%;
  color: #fff;
}
.container {
  width: 370px;
}
.result {
  width: 59.1%;
}
input {
  padding: 25px;
  color: rgb(17, 16, 16);
  font-size: 1em;
  cursor: pointer;
  width: 70px;
  background-color: #fff;
  border: none;
  outline: none;
  border-radius: 4px;
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  -ms-border-radius: 4px;
  -o-border-radius: 4px;
}

.first-row,
.second-row,
.third-row,
.fourth-row,
.fifth-row {
  margin-bottom: 3px;
}
input[type="text"] {
  background-color: rgb(255, 255, 255);
}
input[type="button"]:hover {
  background-color: rgb(37, 35, 59);
  color: #fff;
}
.clear {
  color: #fff;
  background-color: rgb(255, 42, 42);
}
button {
  border: none;
  background-color: rgb(41, 38, 38);
  padding: 10px;
  color: white;
  margin: 2px;
  cursor: pointer;
  outline: none;
  border-radius: 4px;
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  -ms-border-radius: 4px;
  -o-border-radius: 4px;
}

button a {
  text-decoration: none;
  color: #fff;
}
.bottom-buttons {
  float: left;
  margin-left: 10%;
  margin-top: 0.7%;
}

@media (max-width: 640px) {
  h1 {
    margin-top: 15vh;
  }
}

Here's the CSS for Dark Mode:

* {
  box-sizing: border-box;
  padding: 0;
  margin: 0;
  font-family: "Open Sans", sans-serif;
  font-weight: bold;
}

body {
  background-color: rgb(20, 19, 19);
  transition: 0.8s;
  -webkit-transition: 0.8s;
  -moz-transition: 0.8s;
  -ms-transition: 0.8s;
  -o-transition: 0.8s;
}
h1 {
  margin-top: 25vh;
  text-align: center;
  margin-bottom: 1.5%;
  color: #fff;
}
.container {
  width: 370px;
}
.result {
  width: 59.1%;
}
input {
  padding: 25px;
  color: rgb(255, 255, 255);
  font-size: 1em;
  cursor: pointer;
  width: 70px;
  background-color: rgb(47, 51, 50);
  border: none;
  outline: none;
  border-radius: 4px;
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  -ms-border-radius: 4px;
  -o-border-radius: 4px;
}

.first-row,
.second-row,
.third-row,
.fourth-row,
.fifth-row {
  margin-bottom: 3px;
}
input[type="text"] {
  background-color: rgb(47, 51, 50);
}
input[type="button"]:hover {
  background-color: rgb(160, 160, 160);
  color: #fff;
}
.clear {
  color: #fff;
  background-color: rgb(255, 42, 42);
}
button {
  border: none;
  background-color: rgb(39, 36, 36);
  padding: 10px;
  color: white;
  margin: 2px;
  cursor: pointer;
  outline: none;
  border-radius: 4px;
  -webkit-border-radius: 4px;
  -moz-border-radius: 4px;
  -ms-border-radius: 4px;
  -o-border-radius: 4px;
}

button a {
  text-decoration: none;
  color: #fff;
}
.bottom-buttons {
  float: left;
  margin-left: 10%;
  margin-top: 0.7%;
}

@media (max-width: 640px) {
  h1 {
    margin-top: 15vh;
  }
}

And finally, here's the JavaScript:

// Clears the screen on click of C button.
function clearScreen() {
  document.getElementById("result").value = "";
}
// Displays the entered value on screen.
function liveScreen(value) {
  document.getElementById("result").value += value;
}
// Swaps the style sheet in order to  achieve dark mode.
function switchTheme() {
  let darkMode = document.getElementById("dark-mode");
  let theme = document.getElementById("theme");
  if (theme.getAttribute("href") == "light.css") {
    theme.href = "dark.css";
    darkMode.innerHTML = "Light Mode 🌙";
  } else {
    theme.href = "light.css";
    darkMode.innerHTML = "Dark Mode 🌙";
  }
}

That's it. Now we have a simple calculator with dark mode. Thanks for reading. Hope you like it!

Link to live demo:
https://zxcodes.github.io/Calculator

Here's the link to repo:

zxcodes / Calculator

A Calculator App built with HTML, CSS, and JavaScript. It also has a Dark Mode.

Calculator

A simple Calculator App built with HTML, CSS, and JavaScript. It also has a Dark Mode.

Favicon from: Freepik - Flaticon

View on GitHub

Did you know this JavaScript API?

Mohammed Farmaan. — Sun, 05 Jul 2020 02:32:34 +0000

JavaScript's onscroll event is great, but how many of you have got bored of it trying to implement Lazy Loading or styling the Navbar on scroll while making a pixel perfect website?

Telling the browser to constantly look for scroll changes might be bad for a site's performance cause the browser never stops looking for scroll changes. So what is the alternative?

This, right here:

The Intersection Observer API

This API is great for implementing the features such as Lazy Loading or Changing backgrounds on scroll. And this API is actually very easy to use without putting much effort and counting pixels.

Here's how it works:

The Intersection Observer API takes a single or multiple elements which of course you can iterate over each one of them, and it observes for it to intersect with the viewport. As soon as the element intersects with the viewport, the callback function is executed and the required task is done. Below is a demonstration showing how it works in action:
Scroll to see the changes:

Live Demo:
https://zxcodes.github.io/JavaScript-Intersection-Observer-API/

Link to the repo:

zxcodes / JS-Intersection-Observer-API

This example shows the working of Intersection Observer API on scroll.

JavaScript Intersection Observer API

This example shows the working of Intersection Observer API. Click the link for live demo.

View on GitHub

Thanks for reading. Hope you like this. Have a great day!

CSS Progress Bars!

Mohammed Farmaan. — Sat, 04 Jul 2020 16:44:14 +0000

For a number of reasons, HTML's standard progress bars are just not usable. They look ugly on different browsers and you'll always have to look at the alternative ones such as Bootstrap which is good but when we're building something from the scratch and do not wanna include any frameworks, it won't be the option anymore.

That's where you'll realize that CSS is much more than just coloring and positioning things. You can have some amazing looking progress bars with in a few minutes. As a beginner, I always try doing everything without any frameworks and this is no exception. I've created these progress bars without putting much effort, and they're responsive too. Below is the demonstration:

Here's the markup for it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>CSS Progress Bars</title>
    <link rel="stylesheet" href="style.css" />
  </head>
  <body>
    <h1>CSS Progress Bars</h1>
    <div class="bar-holder">
      <div class="bar-1">20%</div>
    </div>
    <div class="bar-holder">
      <div class="bar-2">40%</div>
    </div>
    <div class="bar-holder">
      <div class="bar-3">60%</div>
    </div>
    <div class="bar-holder">
      <div class="bar-4">80%</div>
    </div>
    <div class="bar-holder">
      <div class="bar-5">100%</div>
    </div>
  </body>
</html>

Here's the magic:

h1 {
  text-align: center;
  margin-top: 30vh;
  font-size: 2.3em;
}

/* INDIVIDUAL BAR HOLDER */

.bar-holder {
  width: 60%;
  background-color: rgb(231, 231, 231);
  border-radius: 20px;
  -webkit-border-radius: 20px;
  -moz-border-radius: 20px;
  -ms-border-radius: 20px;
  -o-border-radius: 20px;
  margin: 0 auto;
}

/* INDIVIDUAL BAR'S STYLING, SAME GOES WITH OTHER BARS */

.bar-2 {
  width: 20%;
  background-color: rgb(22, 21, 21);
  color: #fff;
  border-radius: 20px;
  -webkit-border-radius: 20px;
  -moz-border-radius: 20px;
  -ms-border-radius: 20px;
  -o-border-radius: 20px;
  text-align: center;
  margin-top: 15px;
  font-weight: 400;
}

/* HERE'S ONE WITH GRADIENT WHICH LOOKS SUPER COOL */

.bar-5 {
  width: 100%;
  color: #fff;
  border-radius: 20px;
  -webkit-border-radius: 20px;
  -moz-border-radius: 20px;
  -ms-border-radius: 20px;
  -o-border-radius: 20px;
  text-align: center;
  margin-top: 20px;
  font-weight: 400;
  background-image: linear-gradient(100deg, rgb(38, 0, 255), red, yellow);
}

I've used % unit for them to be responsive, so you can use other units according to your preference. Thanks for reading. Hope you like these.

The Best Way To Dark Mode Your Website In My Opinion.

Mohammed Farmaan. — Sat, 04 Jul 2020 03:54:33 +0000

Dark mode has been there for a while now. From apps to websites, its influence on the people has been really great. It's no wonder why everyone would love to have a switch to dark mode option in their Websites.

Now, you might have seen multiple ways of achieving the Dark mode for your website. Whether it be toggling a simple class to turn the background dark or using the Prefers color scheme to switch depending upon the user's system theme. Well, that's great. But people might not always have devices with support for a system wide dark mode. And also, toggling a class might not help a website with multiple colors. So what's the solution?

Here it is: It's actually pretty simple. The best way to achieve Dark Mode is by changing the entire Style Sheet when the user clicks the button for dark mode or toggles a switch.

This method not only gives you the freedom to style a complete dark version of your website but also helps if there are multiple elements which you want to color accordingly, which otherwise would be difficult to achieve by simply toggling a class. You can also have many other color themes for your website. So how do we do that? Enough of reading! Let's get into the code now.

Example:
Here's our HTML file:

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <title>Dark Mode Demo</title>
  <link rel="stylesheet" href="styles/light-mode.css" id="theme" />
</head>

<body>
  <div class="wrapper">
    <h1>Dark Mode by changing the style sheet.</h1>
    <button onclick="changeTheme()">Switch Theme</button>
  </div>
  <script src="scripts/script.js"></script>
</body>

</html>

Here's our light-mode.css file:

* {
  font-family: "Segoe UI";
  box-sizing: border-box;
  padding: 0;
  margin: 0;
}
body {
  transition: 1s;
}

h1 {
  text-align: center;
  font-weight: 300;
  color: #4d4d4d;
  padding: 20px;
}
.wrapper {
  height: 100vh;
  width: 100%;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
}
button {
  padding: 13px 10px;
  background-color: rgb(43, 43, 43);
  color: #fff;
  border: none;
  border-radius: 4px;
  font-size: 1em;
  outline: none;
  cursor: pointer;
}
button:hover {
  background: rgb(45, 50, 102);
  color: rgb(255, 255, 255);
}

Here's the dark-mode.css file:

* {
  font-family: "Segoe UI";
  box-sizing: border-box;
  padding: 0;
  margin: 0;
}
body {
  background: rgb(29, 29, 29);
  transition: 1s;
}
.wrapper {
  height: 100vh;
  width: 100%;
  display: flex;
  flex-direction: column;
  justify-content: center;
  align-items: center;
}
h1 {
  color: #fff;
  text-align: center;
  font-weight: 200;
  padding: 20px;
}

button {
  padding: 13px 10px;
  background-color: rgb(255, 255, 255);
  color: rgb(0, 0, 0);
  border: none;
  border-radius: 4px;
  font-size: 1em;
  outline: none;
  font-weight: 400;
  cursor: pointer;
}
button:hover {
  background: rgb(45, 50, 102);
  color: rgb(255, 255, 255);
}

Finally, here's the JavaScript for it:

// Function that swaps the stylesheet.
function changeTheme() {
  let theme = document.getElementById("theme");
  let lightTheme = "styles/light-mode.css";
  let darkTheme = "styles/dark-mode.css";
  // Checking what stylesheet the link tag has.
  if (theme.getAttribute("href") == lightTheme) {
    theme.href = darkTheme;
  } else {
    theme.href = lightTheme;
  }
}

In the above example, when the button is clicked, the function changeTheme() checks for the CSS file using the href attribute by the id we gave to the link tag. If light-mode.css exists, it replaces it with the dark-mode.css file. Else it switches it back to the light-mode.css file. That's it! Now you have the Dark Mode for your website without reloading the page at all. Thanks for reading. Hope it helped you. Have a great day!

Edit: I've changed title from "The best way to Dark Mode your Website." to "The best way to Dark Mode your Website in my opinion." Cause there might be other ways better than this, so in my opinion, this is the best.

Here's the link to repo:

zxcodes / Dark-Mode-For-Web

This example shows how you can achieve dark mode for your website by changing the entire style sheet on a click.

Dark Mode For Web

This example shows how you can achieve dark mode for your website by changing the entire style sheet on a click.

Original Article:

https://dev.to/zxcodes/the-best-way-to-dark-mode-your-website-1g7f

View on GitHub

Link to live demo:
https://zxcodes.github.io/Dark-Mode-For-Web/