DEV Community: Jonathan Idioseph

Why Websites Feel Slow, And How I Fix It as a Frontend Developer

Jonathan Idioseph — Thu, 21 Aug 2025 11:54:38 +0000

1. Introduction

A few months ago, I clicked on a website that took 8 seconds to load on my phone.
Guess what? I closed it.

And I wasn’t alone, research shows that most users leave if a site doesn’t load in under 3 seconds.

This is why performance is one of the first things I think about when building. With tools like Next.js (and especially the new App Router), I’ve seen how much easier it is to build apps that feel fast by default.

2. Why Website Speed Matters

It’s not just about being “nice to have.” Website performance impacts the business directly:

People leave slow websites → Lost customers.
Google ranks faster websites higher → Better visibility.
Speed builds trust → Users stay longer and interact more.

A slow site isn’t just annoying. It’s expensive.

3. The Usual Suspects Behind Slow Websites

In my experience (working on projects like HotBuyMart, an E-commerce SaaS, and Intelcampus), these are the main causes:

🖼️ Unoptimized Images → Serving 5MB images when a 200KB version would do.
📦 Huge JavaScript Bundles → Loading code the user doesn’t even need right away.
🔄 No Caching/CDN → Every request goes back to the origin server instead of nearby edge servers.
⏳ Blocking Scripts → Code that “freezes” the browser before the page can render.

4. How I Fix It (Practical Approaches)

Here are some battle-tested techniques I use to make apps faster:

✅ Optimized Images

Instead of manually resizing, I use Next.js’ <Image> component. It automatically serves the right size and format depending on the device.

import Image from 'next/image'

<Image src="/product.jpg" width={600} height={400} alt="Product" />

Result → faster loads, fewer frustrated mobile users.

✅ Code Splitting & Lazy Loading

Not all code needs to load upfront. With dynamic imports, users only download what they need:

const Chart = dynamic(() => import('../components/Chart'), { ssr: false })

Result → Initial page loads quickly, heavy components load later.

✅ Static Site Generation (SSG)

Pages are pre-built at build time and served instantly from the CDN.

export async function generateStaticParams() {
  const products = await getProducts()
  return products.map(p => ({ id: p.id }))
}

Result → Near-instant loads.

✅ Caching

I configure caching headers and leverage edge networks so frequently accessed data doesn’t always hit the origin server.

Result → Users get content faster, especially across different regions.

5. How the Next.js App Router Supercharges This

When Next.js introduced the App Router (from v13+), it changed the game. Performance is no longer something you “add later”, it’s baked into how you structure your app.

Here’s why it’s a powerhouse:

Server Components → Heavy lifting is done on the server. Users download less JS.

Nested Layouts → Shared UI (like navbars/sidebars) doesn’t reload every time.

Streaming & Suspense → Parts of a page appear progressively instead of waiting for everything.

Server Actions → Handle form submissions and mutations without writing extra API routes.

Colocation → Routes, error states, and loading states live in the same folder → cleaner architecture.

Loading States (loading.tsx) → Even if something takes a few seconds, showing a loading state immediately makes users feel like the app is responsive.

Example:

// app/dashboard/loading.tsx
export default function Loading() {
  return <p>Loading dashboard...</p>
}

Whenever /dashboard is loading (like fetching data), this file automatically shows until the content is ready.

👉 It doesn’t literally make the server faster, but it makes the experience faster because users get instant feedback.

From my work at Billsalert → While redesigning the website, I used layouts and server components so the navigation never reloaded, but users could still see live pricing updates. The result? Pages felt instant, even with dynamic data.

6. Real-World Wins

Billsalert (Website Redesign)
→ Used SSG + optimized images + App Router layouts.
→ Reduced load times and improved the overall UX.

Intelcampus (Quiz Platform)
→ Leveraged caching + App Router streaming.
→ Allowed 1,000+ students to take quizzes simultaneously without lag.

7. Why This Matters for Businesses

✅ Faster apps → more conversions & sales.
✅ Better performance → stronger SEO rankings.
✅ Modern architecture → scalable apps that grow with your users.

8. Final Takeaway

A slow website isn’t just frustrating. It costs users, customers, and revenue.

By combining smart optimization practices with the Next.js App Router, I don’t just build apps. I build fast, scalable, and delightful experiences that users want to come back to.

Here is a Summary for your Notes:

Optimize images
Split code + lazy load heavy parts
Cache smartly
Use App Router features (server components, nested layouts, streaming, loading.tsx)

Everything You Need to Know About JavaScript’s this Keyword

Jonathan Idioseph — Wed, 20 Aug 2025 10:34:42 +0000

1. Why I Care About `this`

I once broke my app because I didn’t know what this pointed to.
Spoiler: it wasn’t my object.

If you’ve ever seen undefined or TypeError: cannot read property of undefined when using this, welcome to the club. Let’s break it down so you never have to guess again.

2. What is `this`?

👉 this is a special keyword automatically created when a function is called.

It’s not about where the function was written, it’s about who is calling it at that moment.

JavaScript created this so methods could easily refer back to their owner object without repeating the object’s name every time.

Think of it like pronouns in English:
Instead of saying:

“Jonathan is writing Jonathan’s article.”
We say:
“Jonathan is writing his article.”

Here, this is like “his”, a shortcut to the current owner.

3. `this` in Normal Functions

const person = {
  name: "Jonathan",
  greet: function () {
    console.log("Hello, my name is " + this.name);
  },
};

person.greet(); 
// "Hello, my name is Jonathan"

Here, the object person is calling greet, so inside the function, this = person.

4. `this` in Arrow Functions

This is where most developers get confused.
Arrow functions do not create their own this.

Instead, they “look up” and borrow this from the surrounding code (the lexical scope).

Example:

const person = {
  name: "Jonathan",
  greet: () => {
    console.log("Hello, my name is " + this.name);
  },
};

person.greet();
// "Hello, my name is undefined"

Why undefined?

The arrow function greet doesn’t bind its own this.
It borrows this from the environment where it was created, in this case, the global scope (not person).
In strict mode, global this is undefined.

✅ When should you use arrow functions then?

Great for callbacks (like inside setTimeout or map) where you want to use the this of the outer function.
Bad for object methods, because they won’t refer to the object itself.

So remember:
👉 Arrow functions = “use the this of where I live”
👉 Normal functions = “create my own this when called”

5. Common Situations Where `this` Trips You Up

❌ Lost `this` in Callbacks

const person = {
  name: "Jonathan",
  greet: function () {
    setTimeout(function () {
      console.log("Hello, " + this.name);
    }, 1000);
  },
};

person.greet(); 
// "Hello, undefined"

Why undefined?

The function inside setTimeout is a plain function.
Nobody “owns” that callback when it runs.
So this defaults to the global object (window in browsers) → which has no name.

✅ Fix with an arrow function:

greet: function () {
  setTimeout(() => {
    console.log("Hello, " + this.name);
  }, 1000);
}

Now, the arrow function borrows this from greet, which correctly points to person.

❌ Forgetting `bind`

const button = document.querySelector("button");

const app = {
  text: "Clicked!",
  handleClick: function () {
    console.log(this.text);
  },
};

button.addEventListener("click", app.handleClick);
// undefined

Why undefined?

When you pass app.handleClick directly, the function gets detached.
It’s called without an owner object.
So again, this defaults to global → no text found.

✅ Fix with .bind (glues this to app):

button.addEventListener("click", app.handleClick.bind(app));

✅ Or wrap it in an arrow function:

button.addEventListener("click", () => app.handleClick());

6. The Golden Rule

👉 this is not about where a function is written, but how it is called.

That’s the rule. Once you get that, everything clicks.

7. Quick Reference (Copy This!)

In methods → this = the object calling it
In functions (strict mode) → this = undefined
In functions (non-strict) → this = global object
In arrow functions → this = borrowed from surrounding scope
With .call/.apply/.bind → you manually set this

The this keyword isn’t broken or magical, it’s just contextual.
It was designed to make object methods simpler.

Once you remember: “this depends on how the function is called, not where it’s written”, the confusion melts away.

🍝 Spaghetti Code: Why Your App Breaks When You Touch One Line

Jonathan Idioseph — Sun, 17 Aug 2025 09:13:15 +0000

We’ve all been there.

You change one tiny line of code… and suddenly five other parts of your app explode. That’s not a feature. That’s spaghetti code.

But what exactly is spaghetti code, and how do we avoid writing it?

🍝 What is Spaghetti Code?

Spaghetti code is messy, tangled code where everything depends on everything else. Like a plate of spaghetti, it’s hard to know which strand leads where.

It often looks like this:

No clear structure or architecture
Functions doing too many things at once
Copy-pasted logic everywhere
Variables and state scattered across the codebase

🚨 Why It’s a Problem

Hard to debug: Change one function, break another.
Hard to scale: Adding new features feels like defusing a bomb.
Hard for teams: New developers get lost trying to understand the mess.

⚡ Real Examples

Example 1: Nested Conditionals

Spaghetti Version:

function processUser(user) {
  if (user.isAdmin) {
    if (user.isActive) {
      console.log("Admin active");
      // More logic...
    } else {
      console.log("Admin inactive");
    }
  } else {
    if (user.isActive) {
      console.log("User active");
    } else {
      console.log("User inactive");
    }
  }
}

Cleaner Version:

function processUser(user) {
  const role = user.isAdmin ? "Admin" : "User";
  const status = user.isActive ? "active" : "inactive";

  console.log(`${role} ${status}`);
}

Example 2: Inline Database Queries Everywhere

Spaghetti Version:

app.get("/users", (req, res) => {
  db.query("SELECT * FROM users", (err, users) => {
    if (err) throw err;
    res.send(users);
  });
});

app.post("/users", (req, res) => {
  db.query(
    `INSERT INTO users (name, email) VALUES ('${req.body.name}', '${req.body.email}')`,
    (err, result) => {
      if (err) throw err;
      res.send(result);
    }
  );
});

Business logic is mixed with DB logic — hard to test or maintain.

Cleaner Version (separating layers):

// services/userService.js
export function getUsers() {
  return db.query("SELECT * FROM users");
}
export function createUser(name, email) {
  return db.query("INSERT INTO users (name, email) VALUES (?, ?)", [name, email]);
}

// routes/userRoutes.js
app.get("/users", async (req, res) => {
  res.send(await getUsers());
});

app.post("/users", async (req, res) => {
  res.send(await createUser(req.body.name, req.body.email));
});

Example 3: React Components That Do Too Much

Spaghetti Version:

function Dashboard() {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    fetch("/api/users")
      .then(res => res.json())
      .then(setUsers);
  }, []);

  return (
    <div>
      <h1>Dashboard</h1>
      {users.map(u => (
        <div key={u.id}>{u.name}</div>
      ))}
    </div>
  );
}

Looks fine… until you add more features (loading states, error handling, pagination). It quickly becomes spaghetti.

Cleaner Version (separation of concerns):

function useUsers() {
  const [users, setUsers] = useState([]);
  useEffect(() => {
    fetch("/api/users").then(res => res.json()).then(setUsers);
  }, []);
  return users;
}

function UserList() {
  const users = useUsers();
  return users.map(u => <div key={u.id}>{u.name}</div>);
}

function Dashboard() {
  return (
    <div>
      <h1>Dashboard</h1>
      <UserList />
    </div>
  );
}

How to Avoid Spaghetti Code

Single Responsibility Principle → Each function does one thing well.
Modular Design → Break code into reusable components.
Consistent Naming → Future you (and teammates) will thank you.
Refactor Early → Don’t wait until your codebase is a jungle.
Tests → They catch bugs before spaghetti spreads.

Spaghetti code isn’t just a meme, It’s the Number 1 reason why small projects turn into nightmares.

The good news? With a little discipline (and some clean coding practices), you can turn that tangled bowl of noodles into a well-organized recipe.

Next time you’re coding, ask yourself:
👉 “Am I cooking clean code, or serving spaghetti?”

Mastering the App Router in Next.js 15: The Powerhouse Behind Its Full Feature Set

Jonathan Idioseph — Fri, 15 Aug 2025 11:26:04 +0000

1. Introduction

When Next.js 15 dropped, it brought a lot of shiny new features. But here’s the secret — the App Router is the real engine powering most of them.
If you don’t understand it, you’re only scratching the surface of what Next.js can do.

Think of it like upgrading from a regular car to a Tesla. Sure, it looks sleek on the outside, but the magic is in the new engine and smart features inside.

2. What is the App Router?

The App Router is a new way to structure and render your application using the /app directory.
It’s built for speed, better organization, and flexibility.
With it, you get:

Layouts that stay in place while you switch pages
Server Components that reduce JavaScript bundle size
Streaming so pages start loading before all data arrives
Simpler data fetching without boilerplate

In short: it’s designed for modern, scalable apps.

3. Pages Router vs App Router: What Changed?

Why it’s better:

No more copying the same layout into multiple pages
Faster loads because less JavaScript is sent to the browser
Easier to keep related files together

4. Why the App Router is a Game-Changer in Next.js 15

Server Components → Send only what’s needed to the browser
Nested Layouts → Keep sidebars, navbars, and headers while switching pages
Server Actions → Handle form submissions and database updates without extra API endpoints
Streaming & Suspense → Show parts of the UI as soon as they’re ready
Simplified Data Fetching → Fetch right inside your component without special functions

5. Core Concepts You Must Understand

Special Files in App Router:

page.tsx → Defines what shows up at a route
layout.tsx → Wraps your pages with shared UI like a navbar
loading.tsx → Shows while the page is fetching data
error.tsx → Handles errors for that route

Client vs Server Components:

Server Components (default) → Run only on the server, don’t ship JS to the browser
Client Components ("use client") → Run in the browser for interactive features

6. Practical Example: A Simple Dashboard

app/
 ├─ dashboard/
 │   ├─ layout.tsx   // Sidebar + header
 │   ├─ page.tsx     // Main dashboard content
 │   ├─ loading.tsx  // Loading spinner
 │   └─ error.tsx    // Error message

With this setup:

The layout stays while switching between sections
Data fetching happens in page.tsx on the server
Loading states are automatic with loading.tsx

7. Common Mistakes and How to Avoid Them

❌ Mistake 1: Overusing Client Components

// ❌ Wrong - No need to make this a Client Component
"use client"
export default function Dashboard() {
  return <h1>Welcome</h1>
}

✅ Correct: Use Server Components unless you need interactivity

export default function Dashboard() {
  return <h1>Welcome</h1>
}

❌ Mistake 2: Fetching in Client Components when you can use Server Components

// ❌ Wrong
"use client"
import { useEffect, useState } from "react";
export default function Users() {
  const [users, setUsers] = useState([]);
  useEffect(() => {
    fetch("/api/users").then(res => res.json()).then(setUsers);
  }, []);
  return <pre>{JSON.stringify(users, null, 2)}</pre>;
}

✅ Correct: Fetch on the server

// ✅ Right
export default async function Users() {
  const users = await fetch("https://api.example.com/users").then(res => res.json());
  return <pre>{JSON.stringify(users, null, 2)}</pre>;
}

❌ Mistake 3: No error boundaries
If one component crashes, the whole page breaks.
✅ Add error.tsx for each route folder.

❌ Mistake 4: Misusing and not using the"use client"
When to use: If your component needs state, event listeners, or browser APIs (e.g., useState, useEffect, window).
When not to: If it’s purely presentational or only fetches data, keep it a Server Component to reduce bundle size.

8. Final Thoughts

The App Router isn’t just an upgrade — it’s a complete rethink of how we build with Next.js.
If you want faster, cleaner, and easier-to-maintain applications, it’s worth learning inside out.

JavaScript’s Most Misunderstood Feature: The Event Loop Isn’t What You Think

Jonathan Idioseph — Thu, 14 Aug 2025 09:58:38 +0000

Demystifying async behavior so you can predict it, without memorizing diagrams.

1. Why this matters (in plain English)

The Problem That Made Me Google at 2 AM

I was building a dashboard in Next.js.
Everything worked… except my loading spinner.

It just froze.
No error, no crash, it just stopped spinning.

Turns out, I had no clue I’ve met the event loop, just… indirectly. This guide strips the jargon and gives you a mental model you’ll actually use.

2. Think of JavaScript as a Restaurant

Kitchen = Call Stack (where cooking happens)
Waiter = Event Loop (decides what order to serve next)
Two waiting lines:
- Fast line = Promises (.then(), async/await) → “urgent orders”
- Slow line = Timers (setTimeout, clicks, network) → “big meal orders”

3. The Secret Rule Nobody Told Me

Before serving any big orders, the waiter must finish all "urgent orders" first.

That’s why a Promise often runs before a setTimeout, even if the timeout is set to 0.

Example 1: Why `setTimeout(0)` still feels “late”

console.log("Start");

setTimeout(() => console.log("Timeout"), 0);

Promise.resolve().then(() => console.log("Promise"));

console.log("End");

Output:

Start  
End  
Promise  
Timeout

Why?

JavaScript finishes the current work (Start, End)
Runs Promises (urgent orders) → "Promise"
Then runs setTimeout (big orders) → "Timeout"

Example 2: The silent performance bug with `async/await`

Bad:

await task1();
await task2(); // Waits for task1 before even starting task2

Better:

await Promise.all([task1(), task2()]); // Both start together

If tasks don’t depend on each other, run them in parallel. Saves time.

4. How This Saved My Spinner

My “frozen” spinner was because I ran a heavy loop that never let the Event Loop breathe.

for (let i = 0; i < 1e9; i++) {} // freezes everything

Fix: Break work into chunks so the UI gets a chance to update.

function doWorkInChunks() {
  let i = 0;
  function chunk() {
    for (let j = 0; j < 100000; j++) i++;
    if (i < 1e9) setTimeout(chunk); // let UI breathe
  }
  chunk();
}

5. Why You Should Care

Understanding the Event Loop means:

Faster apps
Less “freezing” UIs
Predictable async behavior

Even if you’re not “deep into backend stuff,” this is frontend survival skill.

6. Myths vs Reality (quick de-mystification)

Myth: setTimeout(fn, 0) runs immediately. Reality: It waits until all microtasks finish.
Myth: async/await is always faster than Promises. Reality: It’s about ordering. Sequential await can be slower than Promise.all.
Myth: The event loop is “browser stuff only.” Reality: Node.js has the loop too (with its own task sources); the microtask > macrotask rule still applies.

7. When to care (and when not to)

Care when: spinners freeze, progress bars stutter, “0ms” timers feel late, await feels slow.
Don’t overthink it when: the page is simple and nothing is heavy—ship it.

8. Debug checklist you can copy

Is something “late”? → Check for a Promise running first.
Is something “slow”? → Run independent tasks in parallel with Promise.all.
Is UI freezing? → Break big loops with setTimeout/requestIdleCallback.
Still weird? → Log order: console.log("A"), Promise .then("B"), setTimeout("C", 0).

9. Too Long; Didn't Read (stick this in your notes)

1). Sync finishes → 2) All microtasks run → 3) One macrotask runs → repeat.
Use Promise.all for parallel work; slice heavy loops so the UI can breathe.

Your turn: Ever had a bug that only happened because of “JavaScript timing magic”? Drop it in the comments, I might try to explain it in plain English.

The Power of Deep-Level Multi-Tenancy: and How I Nailed It in My Latest Project

Jonathan Idioseph — Wed, 13 Aug 2025 05:17:51 +0000

Multi-tenancy is one of those architectural concepts you hear tossed around a lot in SaaS circles, but when you really get it right, it feels like a superpower.

In my latest project, I built deep-level multi-tenancy into a Next.js application, and the results were nothing short of game-changing:

One codebase serving multiple schools
Data isolation for security and privacy
Scalability without the chaos of separate deployments

Here’s how I did it, and how you can too.

Why Multi-Tenancy Matters

For a SaaS product, multi-tenancy means that a single application instance serves multiple clients (“tenants”), with each tenant’s data, settings, and user sessions kept separate.

The benefits:

Lower hosting and maintenance costs
Faster feature rollouts (update once, all tenants benefit)
Easier scaling compared to managing multiple deployments

In my case, each school using the platform has its own subdomain, isolated authentication, onboarding process, and dashboard.

Why Next.js Was a Perfect Fit

Next.js gives you the exact tools needed for deep multi-tenancy:

Dynamic routing → Perfect for tenant-specific paths
Middleware → Great for intercepting requests and directing them to the right tenant context before rendering
API Routes → Handle tenant-specific API calls with ease
SSR/SSG flexibility → Customize pages per tenant

My Deep-Level Multi-Tenancy Setup

Here’s a quick peek at my project structure:

This folder structure allows me to scope every route, page, and feature to a specific subdomain (tenant).

The Middleware Magic

The heart of this setup is my Next.js middleware, which:

Extracts the tenant subdomain from the request
Handles local dev and production environments (even Vercel preview URLs)
Manages authentication & onboarding flows per tenant
Rewrites URLs so each request is served from the correct tenant route

Here’s the key part of my middleware logic:

function extractSubdomain(request: NextRequest): string | null {
  const url = request.url;
  const host = request.headers.get("host") || "";
  const hostname = host.split(":")[0];

  // Localhost handling
  if (url.includes("localhost")) {
    const match = url.match(/http:\/\/([^.]+)\.localhost/);
    return match?.[1] || hostname.split(".")[0];
  }

  // Production handling
  const rootDomainFormatted = rootDomain.split(":")[0];
  const isSubdomain =
    hostname !== rootDomainFormatted &&
    hostname !== `www.${rootDomainFormatted}` &&
    hostname.endsWith(`.${rootDomainFormatted}`);

  return isSubdomain ? hostname.replace(`.${rootDomainFormatted}`, "") : null;
}

And the rewrite step that ties it all together:

if (subdomain) {
  const redirectUrl = new URL(`/tenat/${subdomain}${pathname}`, request.url);
  return NextResponse.rewrite(redirectUrl);
}

This means:

school1.example.com/dashboard → internally becomes /tenat/school1/dashboard
school2.example.com/login → becomes /tenat/school2/login

All while keeping the public-facing URL clean.

Guiding You to Set This Up Yourself

If you want to replicate this deep-level multi-tenancy approach:

Plan your folder structure under /app/[subdomain] or /app/tenant/[subdomain] so that tenant-specific routes are cleanly separated.
Write middleware that:

Extracts the subdomain
Handles special cases (localhost, staging domains, etc.)
Decides what to do based on user session and onboarding state
1. Use NextResponse.rewrite to send the request to the correct tenant-specific route without changing the public URL.
2. Integrate authentication per tenant, your session should store the tenant identifier (schema_name in my case) so you can easily redirect users post-login.
3. Test across environments, production, staging, and local dev, to make sure subdomain routing behaves consistently.

Why This Was Worth It

The result?

Isolated environments for each school without deploying multiple apps
Centralized updates: push new features once, all tenants get them
Secure, predictable routing thanks to middleware control

Multi-tenancy isn’t just about being clever, it’s about scaling right. And when done well, it turns complexity into something manageable, even elegant.

Have you tried multi-tenancy before? What was the toughest part, routing, auth, or database isolation?

#Nextjs #SaaS #Multitenancy #WebDevelopment #DevExperience

Why I Keep Choosing Next.js — and What It’s Taught Me

Jonathan Idioseph — Mon, 11 Aug 2025 10:37:23 +0000

You don’t need to know every JavaScript framework to ship great products.

But for most of my projects, I keep coming back to Next.js.

It’s not hype. It’s a mix of flexibility, developer experience, and built-in performance wins that make it a solid choice for both small and large projects.

Here’s my story and what I’ve learned along the way.

How I First Met Next.js, Like most frontend devs, I started with plain React. I loved the component model, but I quickly ran into the same problems:

SEO challenges with SPAs

Too much setup for routing and performance optimization

Having to choose between server-side rendering and static generation, with no simple middle ground

Next.js came in like a toolkit that already had answers for most of these problems.

Why I Keep Choosing It

1. SSR + SSG Flexibility
Next.js lets me choose rendering strategies per page. I can make one route statically generated for speed, and another server-rendered for up-to-date data, all in the same project.

2. Performance Built In
Image optimization, smart routing, and lazy loading happen almost automatically. Less time on micro-optimizations, more time on core features.

3. Developer Experience
File-based routing, built-in API routes, TypeScript support, I spend less time wiring things together and more time building.

4. Ecosystem Fit
It works seamlessly with Tailwind CSS, Framer Motion, and my usual backend stack (Node.js, MongoDB, Firebase).

5. Multitenancy Support
One of my recent projects required multi-tenant architecture, different clients having their own custom subdomains, data isolation, and branding, all within a single codebase.
Next.js made it straightforward to handle dynamic routing and domain mapping, which saved weeks of manual work.

Lessons Learned Along the Way
No tool is perfect; I’ve had to manage longer build times on large projects.

The temptation to over-engineer is real, sometimes a plain React app is enough.

For me, Next.js isn’t just a tool; it’s a balance between performance, flexibility, and developer happiness.

Have you tried Next.js? What’s the biggest lesson it taught you, or the biggest pain point you’ve had with it?

DEV Community: Jonathan Idioseph

Why Websites Feel Slow, And How I Fix It as a Frontend Developer

1. Introduction

2. Why Website Speed Matters

3. The Usual Suspects Behind Slow Websites

4. How I Fix It (Practical Approaches)

5. How the Next.js App Router Supercharges This

6. Real-World Wins

7. Why This Matters for Businesses

8. Final Takeaway

Everything You Need to Know About JavaScript’s this Keyword

1. Why I Care About this

2. What is this?

3. this in Normal Functions

4. this in Arrow Functions

5. Common Situations Where this Trips You Up

❌ Lost this in Callbacks

❌ Forgetting bind

6. The Golden Rule

7. Quick Reference (Copy This!)

🍝 Spaghetti Code: Why Your App Breaks When You Touch One Line

🍝 What is Spaghetti Code?

🚨 Why It’s a Problem

⚡ Real Examples

Example 1: Nested Conditionals

Example 2: Inline Database Queries Everywhere

Example 3: React Components That Do Too Much

How to Avoid Spaghetti Code

Mastering the App Router in Next.js 15: The Powerhouse Behind Its Full Feature Set

1. Introduction

2. What is the App Router?

3. Pages Router vs App Router: What Changed?

4. Why the App Router is a Game-Changer in Next.js 15

5. Core Concepts You Must Understand

6. Practical Example: A Simple Dashboard

7. Common Mistakes and How to Avoid Them

8. Final Thoughts

JavaScript’s Most Misunderstood Feature: The Event Loop Isn’t What You Think

1. Why this matters (in plain English)

The Problem That Made Me Google at 2 AM

2. Think of JavaScript as a Restaurant

3. The Secret Rule Nobody Told Me

Example 1: Why setTimeout(0) still feels “late”

Example 2: The silent performance bug with async/await

4. How This Saved My Spinner

5. Why You Should Care

6. Myths vs Reality (quick de-mystification)

7. When to care (and when not to)

8. Debug checklist you can copy

9. Too Long; Didn't Read (stick this in your notes)

The Power of Deep-Level Multi-Tenancy: and How I Nailed It in My Latest Project

Why Multi-Tenancy Matters

Why Next.js Was a Perfect Fit

My Deep-Level Multi-Tenancy Setup

The Middleware Magic

Guiding You to Set This Up Yourself

Why This Was Worth It

Why I Keep Choosing Next.js — and What It’s Taught Me

1. Why I Care About `this`

2. What is `this`?

3. `this` in Normal Functions

4. `this` in Arrow Functions

5. Common Situations Where `this` Trips You Up

❌ Lost `this` in Callbacks

❌ Forgetting `bind`

Example 1: Why `setTimeout(0)` still feels “late”

Example 2: The silent performance bug with `async/await`