Until now, whenever we wanted to load environment variables from a .env file in a Node.js project, the popular dotenv package was the go-to solution. It's simple, reliable, and widely used across thousands of projects.

But with the release of Node.js 20, that changes forever.

The New Native Way to Load .env Files

Node.js 20 introduces native support for loading environment variables directly from .env files — no external packages required.

All you need to do is run your Node.js app with this flag:

node --env-file=.env index.js

That’s it. No more installing dotenv, no more extra imports.

Why This Matters?

One less dependency — your project becomes cleaner.
Faster startup — no need for runtime config loading via code.
Built-in, maintained by Node.js — no reliance on third-party packages.
Simpler environment handling for small apps, CLIs, scripts.

But There’s a Catch…

If you try this on Node.js 18 or below, it won’t work.

That’s because this feature was introduced in Node.js 20, so projects running older versions still need the good old dotenv package (or another solution).

Quick Example:

# Node.js 20+
node --env-file=.env index.js

// index.js
console.log(process.env.MY_SECRET);

Watch It In Action 🎥

I’ve covered this in detail with a version-by-version demo on my YouTube channel.
👉 Watch the video here: https://youtube.com/shorts/AQGAClfzl9o

Wrapping Up

Node.js 20 gives you a reason to ditch dotenv for good, at least for new projects or where version upgrades are possible.

If you found this useful, drop a comment and share how you manage environment variables in your Node.js apps. 👇

I sit down to write, and instead of staring into the familiar discomfort of a blank page, I open a chat window. I type a prompt. In seconds, the ideas are flowing. It’s smooth. Efficient. Helpful, even beautiful sometimes.

But then comes a pause — subtle, quiet.
A tiny voice in me asks, Did I even show up for this?

The Slow Unraveling

It didn’t happen all at once. That’s the tricky part.

I started using AI the way most of us do: to speed things up. To overcome friction. To fill in the awkward gaps. “Just help me get started,” I told it. “Give me a skeleton. I’ll add the flesh.”

And I did, for a while.

But slowly, I noticed something shifting. The work was still good. But it didn’t feel like mine anymore. It was polished, sure — but missing something raw. Something human.
Something like me.

The Parts We Used to Keep

I miss the fumbling.

The 45 minutes I’d spend turning over one messy idea until something clicked. The way I’d circle around a sentence because I felt something I couldn’t yet name. The panic of “Is this garbage?” followed by the rush of “No — this is it.”

That tension — the self-doubt, the weird metaphors, the failed attempts — used to bring me closer to myself.

Now? It’s easy to bypass it all. Just ask the AI. Get an answer. Move on.
But the price of that ease is presence. And presence is the soil where meaning grows.

Asking for Less… From Ourselves

Lately, I’ve noticed how much more I've come to rely on the machine. Not just tasks. But thoughts. Emotions. Even instincts.

I used to walk over to a teammate and say, “Can you look at this? I’m stuck.”
Now, I run it through a model.

I used to journal through my confusion. Now, I feed it a summary and ask for clarity.

It’s faster. Cleaner. Safer. But it’s lonelier.

I didn’t realize how many of those small, clumsy interactions — the questions, the sharing, the vulnerable moments — were actually tiny threads tying me to people, and to myself.

Now I wonder how many of those threads I’ve quietly cut.

The Disappearing Artist

I’m scared, a little, of becoming a curator of my own work — someone who oversees the output but no longer touches the clay.

And I see it happening around me too:

• Designers tweaking AI mockups instead of dreaming on paper.
• Writers editing drafts that sound right but feel hollow.
• Developers pasting code that works but never solving the puzzle.

A quiet giving up of the parts we once fought for, the parts that used to spark joy.

Holding Onto the Spark

I’m not anti-AI. God, no.

Some days, it’s helped me become more myself — clarifying what I value, giving me a running start, reflecting back insights I couldn’t quite form alone.

But I’ve also caught myself nodding too quickly. Clicking “send” before asking, Is this still me?

So I’ve started building little rituals back in:

• Writing a rough paragraph by hand before I prompt.
• Asking a friend, not just the machine, for feedback.
• Leaving room for doubt, silence, and slow thinking.

Because the truth is, meaning isn’t efficient.
Connection isn’t scalable.
And sometimes, feeling lost is the only way to find your voice.

A Quiet Check-In

Before I finish anything now, I ask myself:

• Does this feel like something only I could say?
• Did I show up for this, or just sign off on it?
• Did it move me?

If the answer is no — I go back in. I make a mess. I wander.
Because I’d rather wrestle with something real than perfect something hollow.

Final Thought

Maybe we don’t need to fear AI.

Maybe we just need to stay awake inside it.

Because the moment we stop showing up — not just physically, but emotionally, soulfully — we lose the part of us that made the work worth doing in the first place.

So, before you close this tab, take a moment. Ask yourself !

“What have I started outsourcing… that I used to love?”

And if the answer stings a little, good.
That means there’s still something in you that wants to come back.

Let it.

State updates in custom hooks can trigger re-renders in your components — even if you’re not using the values they return.

Let’s break this down with a simple example, explore why it’s a problem, and learn how to fix it in an easy, practical way.

The Problem: A Custom Hook That Bites Back

Imagine you’re building a React app and you want to track the window’s width. You decide to create a custom hook called useWindowSize to handle this. Here’s what it might look like:

const useWindowSize = () => {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return null; // We’re not even returning the width!
};

const App = () => {
  useWindowSize(); // Just calling the hook
  return <p>App Component</p>;
};

At first glance, this looks fine. The hook listens for window resize events, updates the width state, and… that’s it. The App component calls useWindowSize() but doesn’t use its return value (which is null anyway). So, no harm done, right?

Wrong. Here’s the catch: every time you resize the window, the setWidth call updates the state inside useWindowSize. Since App component used the hook, React considers the App dependent on it. The entire App component re-renders on every resize, even though it doesn’t care about the width value. That’s a performance hit you didn’t sign up for!

Why Does This Happen?

In React, when a hook updates its internal state (like calling setWidth), it tells any component using that hook: “Hey, something changed — time to re-render!” This happens regardless of whether the component actually uses the hook’s returned value. It’s just how React’s dependency tracking works. In our example, App component re-renders unnecessarily because it’s “tied” to useWindowSize, even though it doesn’t need the width.

This might not seem like a big deal in a small app, but imagine App is a complex component with lots of child elements. All that re-rendering could slow things down, making your app feel sluggish.

Issues

• Resizing the window triggers a state update inside useWindowSize.
• Since App uses useWindowSizeIt re-renders every time the window resizes, even though it doesn't use the width.

The Fix: Swap the Hook for a Component

So, how do we stop this madness? The simplest solution is to ditch the custom hook and move the logic into a dedicated component instead. Here’s how:

const WindowSizeComponent = () => {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener("resize", handleResize);
    return () => window.removeEventListener("resize", handleResize);
  }, []);

  return <p>Window width: {width}</p>;
};

const App = () => {
  return (
    <div>
      <WindowSizeComponent />
    </div>
  );
};

Now, the width state and the resize logic live inside WindowSizeComponent. When the window resizes, only WindowSizeComponent re-renders — App component stays untouched. This keeps your app performant because React only updates the part of the UI that actually needs to change.

When to Use Hooks vs. Components

Custom hooks are awesome when you need reusable logic that components actually use — like fetching data or managing form state. But if the logic involves state updates that don’t need to be shared or consumed elsewhere (like our window resize example), a component might be the better choice. It’s all about keeping re-renders under control.

Takeaway

React custom hooks are powerful, but they come with a dark side:

State updates can trigger re-renders in unexpected places. If your hook’s return value isn’t being used, those updates might still haunt your app’s performance. Next time you’re tempted to throw state into a custom hook “just because,” pause and ask: Would a component work better here? Your app — and your users — will thank you for it.

I’ve been working with React, Node, and TypeScript for the past 5+ years, gaining valuable insights from numerous projects. Now, I want to share everything I’ve learned along the way.

“This is just a glimpse! I’m currently writing a book ‘You Don’t Know React Yet!’ — Stay tuned for more updates.” 🚀

Want to support me? Consider buy me a coffee! ☕💙
👉 buymeacoffee.com/amandeepkochhar

Tailwind CSS and Vite are excellent for building modern, fast, and highly customizable web applications. Tailwind provides utility-first styling, while Vite offers a lightning-fast development experience with instant hot module replacement (HMR).

In this article, we’ll walk through setting up Tailwind CSS with Vite step by step.

Step 1: Set Up a Vite Project

First, install Vite globally if you haven’t already:

npm install -g vite

Now, create a new Vite project by running:

npm create vite@latest

The following prompt will appear:

Give a project name, For example i have given vite-starter as the project name. In case of if you have already created a folder you can give dot (.) to tell vite to put boilerplate code in the same folder. Like i have already created vite-starter folder. I will name dot(.) as the project name.

Then it will prompt you to Select a framework. Choose a framework that you want to work with. I will choose React as i am initialising the React Application.

Finally, in case of React, it will ask to choose a variant, Here i will go for the Typescript as the variant and hit Enter.

Now the project initialisation is done and will will see the final screen.

Step 2: Install Dependencies

Once inside your project, install the required dependencies:

npm install

Now, install Tailwind CSS along with its Vite plugin as dev dependency:

npm install --save-dev tailwindcss @tailwindcss/vite

Step 3: Configure Vite to Use Tailwind

To integrate Tailwind with Vite, modify the vite.config.ts file (or create one if it doesn’t exist):

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [tailwindcss(), react()],
});

Step 4: Import Tailwind in Your Styles

Create or update index.css (or global.css) and import Tailwind’s base styles:

@import "tailwindcss";

Step 5: Start Your Development Server

Run the following command to start the Vite development server:

npm run dev

Now, open your browser at the given local URL, and you’re ready to use Tailwind with Vite!

Additional Notes

• If Tailwind CSS class autocompletion isn’t working, try reloading the window in VS Code or closing and reopening the project.
• If you want to set the server to run on a specific port, you can add the following to the server object. This will set the server to run on port 3000. You can replace 3000 with any port number you prefer. To open the app immediately in the browser, you can use open: true

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";

export default defineConfig({
  plugins: [react(), tailwindcss()],
  server: {
    port: 3000, // replace with your desired port
    open: true, // automatically open the app in the browser
  },
});

• Use — host flag to enable the app to be accessed and run from other devices on the same network like below:

"scripts": {
  "dev": "vite",
  "online": "vite --host", // run using npm run online or yarn online
  "build": "tsc -b && vite build",
  "lint": "eslint .",
  "preview": "vite preview"
}

Now the application will be accessible from the http://192.168.29.110:3000 from all the devices connected to your local network.

• To visualise the bundle size we can use rollup-plugin-visualize plugin. So install it as a dev dependency

npm install --save-dev rollup-plugin-visualizer

Then import it inside the vite.config.ts Remember to put the file as the last one in the plugins array. Whenever you execute npm run build command, the report will automatically open.

import { defineConfig, type PluginOption } from "vite";
import react from "@vitejs/plugin-react";
import tailwindcss from "@tailwindcss/vite";
import { visualizer } from "rollup-plugin-visualizer";

export default defineConfig({
  plugins: [
    react(),
    tailwindcss(),
    visualizer({
      filename: "bundle.html", // output file name
      template: "treemap", // options: "flamegraph" | "sunburst" | "network" | "treemap" | "raw-data" | "list"
      open: true, // Automatically open the report in the browser
    }) as PluginOption,
  ],
  server: {
    port: 3000, // replace with your desired port
    open: true, // automatically open the app in the browser
  },
});

If you enjoyed this article and found it helpful, give it a clap!

I’ve been working with React, Node, and TypeScript for the past 5+ years, gaining valuable insights from numerous projects. Now, I want to share everything I’ve learned along the way.

“This is just a glimpse! I’m currently writing a book ‘You Don’t Know React Yet!’ — Stay tuned for more updates.” 🚀

Want to support me? Consider buy me a coffee! ☕💙
👉 buymeacoffee.com/amandeepkochhar

event.currentTarget Points to element, to which the Event Listener is attached to.

Confused?

Let’s consider this example, where a button is nested inside a paragraph and both button and paragraph having click event.

When we click on the paragraph the event.target and event.currentTarget points to the same element i.e paragraph. Because, element which triggers the event and element where event listener is attached are the same.

Now, what happens when we click on the Button, Click listener of the button get executed, event.target and event.currentTarget for this button again remains same.

But

Event also bubbled up to the parent element i.e Paragraph, Here the scenario is like this.
event.target points to the Button since button is the one who triggers the click event, but event.currentTarget points to the Paragraph and not button, since paragraph is the one where event listener is attached to.

Hoping now the difference between the event.target and event.currentTarget is cleared.

Cheers!

As our server has multiple API endpoints, our need for creating routes increases, along with increased demand of creating these routing files.

Traditionally, we were importing every single file that pertains to a specific route, to the root file as a middle ware. This can however be cumbersome if we have hundreds of routes.

To resolve this issue, let me show you a trick we can apply to auto-reload the express routes easily, so that you don't have to worry about importing them one by one in the root file of your Node JS application.

We can achieve it using the following line of code:

In the above example what i am doing is requiring all the files i have created in the routes folder using an iteration.

Hopefully you liked this little trick, any improvement in this method is welcomed as comments.

A clap and a follow will encourage me to write more about my coding journey :)

Before Node version 13, we were using the esm npm package and run our app.js using the commandnode -r esm app.js

With recent updates of Node, this is natively supported now. There are two ways we can achieve it

• Save the file with .mjs extension.
• Add { "type": "module" } in the nearest package.json.

Note that we only have to do one thing from the above mentioned.

If we are using Node.js version 8–12, save the file with ES6 modules with .mjs extension and run it like:

node --experimental-modules app.mjs

Leaving a clap will motivate me to write more useful tips related to JS.

Output —

Largest Word — occurring

Smallest Word — a

Try on your own and leave a reply containing your way of doing so!

Solution — Used Decoder (an Android app) to create this solution because I was lazy enough to not to turn on the laptop 😁

Explanation:

Step 1: Declare two variables to store largest and smallest word. Here assign the first word to the smallest variable because we want to make a comparison between words going forward (I have used array.split(‘ ‘) and picked word lying at the 0th index)

Step 2: Loop through each word and compare the length current iterating word with the initial word we are using (Remember we can find the length of string using .length just like we do for arrays)

For finding smallest word we are using currentWord.length < initialWord.length and for largest we are using currentWord.length > initialWord.length

Step 2: Reassign the word depending upon the Iterating word has smaller or larger length than the last Assigned Word length.

There maybe other far more optimised ways to achieve the same thing. I just shared my approach.

Do leave a comment how you should have gone for the solution.

Input — [2, 3,4,5]

Output — [60, 40,30,24]

Try on your own and leave a reply containing your way of doing so!

Solution — Used Decoder (an Android app) to create this solution because I was lazy enough to not to turn on the laptop 😁

Explanation:

Step 1: Loop through the entire Array using map and not forEach. As I need to return an array (Remember, map() in JavaScript always returns an array and forEach doesn’t)

Step 2: Create a copy of the array for each iteration (Here I have used the Array.slice() but you can use Modern Spread Operator too). Copy of the array is needed as I am going to splice out the current Traversed element which will remove the element from the Given array!

Step 3: use the Index we took out from the second argument from map() and remove the current traversed element.

Step 4: Loop through the remaining elements of the array and start multiplying them and return the result!

There maybe other far more optimised ways to achieve the same thing. I just shared my approach.

Do leave a comment how you should have gone for the solution.