DEV Community: kavya1205

JavaScript Bundling Explained — From Zero to Optimised

kavya1205 — Mon, 22 Jun 2026 08:19:58 +0000

Here's your Dev.to article:

Title: JavaScript Bundling Explained — From Zero to Optimised

Tags: javascript webdev performance beginners

You write your React or Angular app across dozens of files. Components, services, utilities, third party libraries — all split up neatly.

But here's the thing. The browser doesn't care about your neat folder structure. Loading 200 separate files means 200 separate network requests. That's slow. Really slow.

This is exactly the problem bundlers solve.

What is bundling?

A bundler takes all your files your code, your imports, your node_modules and combines them into one (or a few) optimised files that the browser can load efficiently.

Think of it like packing for a trip. Instead of carrying 50 small bags, you pack everything into one suitcase. Same stuff, much easier to carry.

That's bundling.

What else does a bundler do?

Combining files is just the start. Modern bundlers also:

Minification — removes whitespace, comments, and shortens variable names. Your readable userName becomes a. Same logic, way smaller file.

Tree shaking — removes code you imported but never actually used. If you imported a utility library but only used one function, the bundler strips the rest out automatically.

Code splitting — instead of one giant bundle, splits your code into smaller chunks. Only load what the user actually needs right now.

All of this = smaller files = faster app.

Webpack vs Vite — what's the difference?

Both are bundlers but they take very different approaches.

Webpack came first. It bundles your entire app upfront before serving it — even in development. That means every time you make a change, it rebundles everything. Powerful and highly configurable, but can feel slow in large projects.

Vite is the modern alternative. During development, it doesn't bundle at all it serves your files directly using native ES modules in the browser. Only the file you changed gets updated instantly. The result? Near instant hot reload no matter how big your project is.

For production, Vite uses Rollup under the hood to create optimised bundles.

	Webpack	Vite
Dev speed	Slower	Extremely fast
Config	Complex but flexible	Simple out of the box
Ecosystem	Very mature	Growing fast
Best for	Large legacy projects	New modern projects

Most new projects today use Vite. If you're creating a new project go with Vite.

How bundlers work internally

At a high level, every bundler does the same 3 things:

1. Build a dependency graph

Starting from your entry file (usually main.js or main.ts), the bundler follows every import and maps out which file depends on which. This is called the dependency graph.

2. Transform the code

Each file gets transformed TypeScript gets compiled to JavaScript, JSX gets converted to plain JS, modern syntax gets converted for older browsers.

3. Output the bundle

Everything gets combined, minified, and written to an output folder usually /dist. That's what gets deployed.

Bundle size optimisation tips

A bloated bundle = slow app. Here's how to keep it lean:

Lazy loading — don't load everything upfront. Load components only when the user navigates to them.

// React lazy loading
const Dashboard = lazy(() => import('./Dashboard'));

Avoid importing entire libraries

// ❌ Imports the entire lodash library
import _ from 'lodash';

// ✅ Import only what you need
import debounce from 'lodash/debounce';

Analyse your bundle

Use tools like webpack-bundle-analyzer or Vite's rollup-plugin-visualizer to see exactly what's taking up space.

Use production builds

Always deploy the production build. Development builds include debugging tools that add significant size.

# React
npm run build

# Angular
ng build --configuration production

Wrapping up

Bundling isn't magic it's a practical solution to a real problem. The browser needs fewer, smaller files. Bundlers make that happen automatically.

Start with Vite for new projects. Keep an eye on your bundle size as your app grows. And use lazy loading early — it's one of the easiest wins in frontend performance.

We Need to Talk About How We're Using AI for Development

kavya1205 — Thu, 18 Jun 2026 04:39:14 +0000

Something weird is happening in the developer community.

Developers are opening their IDEs, hitting a problem, and immediately asking AI before spending even 30 seconds thinking about it.

Not Googling.

Not reading the documentation.

Not debugging.

Not thinking.

Straight to AI.

And honestly, it's starting to show.

The Shortcut That Costs You

AI gives you an answer instantly. That feels great in the moment.

But something important happens when you wrestle with a problem yourself even for just five minutes.

Your brain builds a mental map.

You start understanding why a solution works, not just what the solution is.

When AI gives you the answer immediately, you skip that map building process entirely.

You got the output.

But you didn't get the understanding.

When It Becomes a Problem

At first, it doesn't feel like a problem.

Everything works.

You're shipping features faster.

Life is good.

Then one day something breaks in production.

Not a simple bug. Something strange. Something that requires understanding how the system actually works under the hood.

No prompt can save you because the issue isn't about generating code it's about reasoning through complexity.

And that's when you realize something uncomfortable:

You've been on autopilot for months.

That's when it becomes a problem.

AI Is Genuinely Great: For the Right Things

Let's be clear: AI is not the enemy.

It's an incredible tool.

It's great for:

Boilerplate and repetitive code
Looking up syntax you rarely use
Generating test cases
Rubber duck debugging
Exploring alternative approaches
Speeding up tasks you already understand

That last point is the important one.

Tasks you already understand.

AI is a multiplier.

But you need something to multiply first.

Where I Draw the Line

A simple rule has helped me:

If you don't understand the problem yet, think first. AI second.

Spend 5–10 minutes genuinely attempting the problem yourself.

Read the documentation.

Search for related issues.

Experiment.

Fail.

Then, if you're still stuck, bring in AI.

Now you'll actually understand the answer because you have context.

The difference is huge.

Fundamentals Don't Expire

Frameworks change.

Libraries come and go.

AI tools will continue evolving.

But fundamentals don't expire.

JavaScript fundamentals
Data structures and algorithms
Browser internals
Networking and APIs
Debugging techniques
System design principles

No AI tool can build those foundations for you.

They come from repetition, curiosity, mistakes, and experience.

The developers who remain valuable over the long term won't be the ones who use AI instead of thinking.

They'll be the ones who have strong fundamentals and use AI on top of them.

A Small Challenge

The next time you hit a problem, give yourself 10 minutes before opening AI.

Just 10 minutes.

Think.

Try.

Fail if needed.

Then use AI.

You'll notice the difference immediately.

Instead of copying the answer, you'll actually understand it.

And that's where real growth happens.

What about you?

Do you think developers are reaching for AI too quickly, or is this simply the new way of working?

I'd love to hear where you draw the line.

User Double Clicked a Button — Now You Have 2 API Calls. How Do You Fix It?

kavya1205 — Fri, 12 Jun 2026 06:41:39 +0000

Approach 1 — Disable the button (simplest)
Set a loading flag. Disable the button the moment the first click fires.

When to use: Form submissions, payment buttons, any action that should fire exactly once.
Limitation: If the user navigates away and back — the state resets. Use a ref for more reliability.

Approach 2 — Debounce
Wait for the user to “stop clicking” before firing the request.

Double click within 300ms? Only the last click fires.
When to use: Search inputs, filter buttons, anything where you want the “last intent” to win.
Limitation: Adds a 300ms delay not suitable for instant actions like payments.

Approach 3 — AbortController (most powerful)
Cancel the previous in-flight request when a new one fires.

Previous request gets cancelled at the network level. Only the latest request completes.
When to use: Search-as-you-type, filter changes, any scenario where only the latest result matters.

Quick decision guide

Form submit / Payment: Disable button
Search input: Debounce or AbortController
Rapid filter changes: AbortController
General safety net: Disable button (always safe default)

Lastly,
The disable button approach covers 80% of real-world cases it’s the right default. Add AbortController when you’re dealing with fast repeated requests like search.
Next time you see a duplicate entry in your database you know exactly where to look.

Drop a reaction if this helped. More real-world frontend fixes every week 🚀

How Does Amazon Stop Two People from Booking the Same Seat?

kavya1205 — Wed, 10 Jun 2026 05:19:08 +0000

You're on BookMyShow or Amazon. You see 1 seat left. You click it. Someone else clicks it at the exact same moment.
The Problem
Imagine 1000 people are staring at the same "1 seat left" screen. When multiple people click Book Now at the same time, the server receives all those requests together.
Without any protection — all of them could "successfully" book the same seat. That's a disaster.

How it's actually solved:-

Locking the seat temporarily (Optimistic / Pessimistic Lock) When you click a seat, the system locks it for you for ~10 minutes.

"Seat 12A is reserved for this session. Complete payment in 9:45"

You've seen this countdown on BookMyShow. That's a temporary lock in the database. No one else can book it while you're paying.
If you don't complete payment → lock expires → seat goes back to available.

Database-level constraint The database has a rule:

"Only ONE booking record can exist per seat per show."

Even if 500 requests hit the server at the same time, the database only allows one of them to win. The rest get an error — and the user sees "Sorry, seat just got booked."
This is called a unique constraint.

Queue the requests Instead of handling 1000 requests at the same time, Amazon puts them in a line (queue). First come, first served. Each request is processed one at a time for that seat. Simple and fair.

🎯 Real world analogy
Think of it like a token system at a restaurant

You take token #47
Only token #47 is called at the counter at a time
No two people handle the same counter simultaneously

Same idea.
🔑 Key terms
Pessimistic Lock : Lock the seat the moment someone clicks it
Optimistic Lock: Allow clicks, but only first one wins at save time
Unique Constraint: Database rule — no duplicates allowed
Queue: Process one request at a time, in order

Wrapping up
Next time you see that countdown timer on a booking site — you know exactly what's happening behind the scenes. The system locked that seat just for you, and is racing against your payment.
Pretty cool, right?

Javascript Coding Problem 1: Chunk an Array into N size

kavya1205 — Sat, 28 Jun 2025 07:35:04 +0000

Chunk an Array into Size N

let arr = [1,2,3,4,5]
let n = 3

function chunkArray(arr, n){
    let res=[]
    for(let i=0;i<arr.length;i+=n){
        res.push(arr.slice(i, i+n))
    }
    return res;
}
const d = chunkArray(arr, n)
console.log(d)

Batch API Calls in Javascript

kavya1205 — Sat, 28 Jun 2025 07:20:55 +0000

Hi Everyone,
This was one of the javascript question that was asked during an interview - Batch api call

const urls = [
  'https://jsonplaceholder.typicode.com/posts/1',
  'https://jsonplaceholder.typicode.com/posts/2',
  'https://jsonplaceholder.typicode.com/posts/3',
  'https://jsonplaceholder.typicode.com/posts/4',
  'https://jsonplaceholder.typicode.com/posts/5',
  'https://jsonplaceholder.typicode.com/posts/6',
  'https://jsonplaceholder.typicode.com/posts/7',
  'https://jsonplaceholder.typicode.com/posts/8',
  'https://jsonplaceholder.typicode.com/posts/9',
  'https://jsonplaceholder.typicode.com/posts/10'
];


async function limitAPICalls(urls, limit = 3) {
  for (let i = 0; i < urls.length; i += limit) {
    const batch = urls.slice(i, i + limit);

    const responses = await Promise.all(
      batch.map(url => fetch(url).then(res => res.json()))
    );

    responses.forEach((res, index) => {
      console.log(`Response ${i + index + 1}:`, res);
    });
  }
}
const limitApis = limitAPICalls(urls)