My AI Coding Tool: Claude Code

The AI tool I use is Claude Code.

I’ve tried Cursor, ChatGPT, and Gemini, but ultimately settled on Claude Code. I’m currently on the Max plan ($100/month).

At this point, a paid plan feels pretty much essential if you’re going to have AI handle your development work. I was originally on the Plus plan, but I kept running out of usage, so I upgraded to Max. $100 has been more than enough for me.

Documenting with CLAUDE.md and the .ai Folder

This is something I use not just for personal projects, but for team projects as well.

On our team, everyone’s AI-generated code style was different, so we needed a way to unify it. My solution was to specify in CLAUDE.md that the AI should read the markdown files in the .ai folder before writing any code.

Here’s what we keep in the .ai folder and share across the team:

• CODING_STANDARDS.md (coding conventions)
• ARCHITECTURE.md (project structure)
• SEO.md (SEO guidelines)

We also established a rule: if the documentation and code are out of sync, update the documentation first, then reflect the changes in the code.

This approach gave us three benefits:

1. Code consistency — Same style regardless of who’s working on it
2. Better reusability — Shared components and utility functions are actually used
3. Maintained project understanding — Even when AI writes the code, developers don’t lose track of the overall flow

Fast Development + Learning in One Go: The /wrap Command

This is something I picked up from a post on LinkedIn.

I created a custom command called /wrap that summarizes the tasks I had Claude work on that day and generates technical quizzes based on them.

As a junior developer, it’s been great for keeping up with learning while shipping at the same time.

Deploying to Vercel

I use the Vercel platform for fast deployment.

Vercel deployment is well-documented elsewhere, so I’ll skip the details here.

Using PWA to Test Like a Native App

On iPhone Safari, you can go to Share → Add to Home Screen for your deployed service, and an app icon will appear on your home screen.

This lets you test the experience as if it were a native app before actually publishing to the App Store.

Tracking Service Usage

Checking user responses after launch is crucial. No matter how fast you build something, you can’t improve it if you don’t know whether people are actually using it or where they’re dropping off.

1. Google Analytics (GA4)

A tool for tracking “what users are doing in my service.”

Key metrics I look at:

• Real-time users — How many people are on the site right now
• Traffic acquisition — Where they came from (Google search, direct, social media, etc.)
• Popular pages — Which pages get the most views
• Average session duration — How long users stay
• Bounce rate — The percentage of users who leave after viewing only one page

Setup is straightforward — get your Measurement ID (G-XXXXXX) from GA4 and add the script to your <head>. If you're using Next.js, the @next/third-parties package makes integration even easier.

2. Google Search Console

A tool for managing “how my site appears in Google search results.”

Key metrics I look at:

• Search keywords — What search terms are bringing people in
• Impressions vs. clicks — Whether people see my site in results but don’t click
• Average position — Where my site ranks in search results
• Indexing status — Whether Google has properly crawled my pages

Submitting a sitemap.xml here helps Google understand your site structure faster. With Next.js, you can auto-generate it using the next-sitemap package. Keep in mind that submitting doesn't mean instant indexing — expect to wait at least 1–2 days.

Key Metrics to Focus on Early

For an early-stage service, you don’t need to look at every metric. These three matter most:

• Daily Active Users (DAU) — How many people use it each day
• Return rate — Whether users come back after their first visit
• Core feature usage — Whether people are actually using the main functionality

Wrapping Up

Here’s the overall flow:

Idea → Build with Claude Code → Deploy on Vercel → Test as PWA → Improve with analytics

It used to take weeks to build a single app, but now it feels like we’re in an era where you can ship an MVP in a day and put it in front of real users.

I put this post together while thinking about how to make better use of AI in this new landscape, and how to set up documentation and conventions within a team.

I’m still learning as I go, so this is by no means the definitive answer — but I hope it helps anyone going through similar thought processes.

If you have questions or want to know more, feel free to leave a comment!

Thanks for reading 😊

With the rapid advancement of AI, it seems like the skills expected of developers no longer stay confined to a single domain.

Frontend developers need to understand the backend, backend developers need to know AI — the scope of what a single developer has to cover is constantly expanding.

That said, I believe there’s one area that frontend developers are uniquely positioned to champion.

That area is Web Accessibility.

Web accessibility means ensuring that all users — including those with disabilities — can use websites equally and without barriers.

Many frontend developers tend to overlook this when racing against deadlines, but especially in today’s world where global services have become the norm, I believe it’s an essential value we must prioritize.

In reality, each individual accessibility practice isn’t that difficult.

However, there are so many things to keep track of, and the details are so granular, that it’s easy to miss things in practice.

That’s why I decided to put together this document — to organize everything systematically.

1. Semantic HTML: Building Meaningful Structure

Choosing the Right Tags

Semantic HTML is the foundation of web accessibility. Using the appropriate HTML tags allows screen readers to understand the page structure and helps users navigate to the content they need quickly.

Bad example:

<div class="header">
  <div class="nav">
    <div class="nav-item">Home</div>
    <div class="nav-item">About</div>
  </div>
</div>
<div class="content">
  <div class="title">Title</div>
  <div class="text">Body content...</div>
</div>

Good example:

<header>
  <nav>
    <ul>
      <li><a href="/">Home</a></li>
      <li><a href="/about">About</a></li>
    </ul>
  </nav>
</header>
<main>
  <article>
    <h1>Title</h1>
    <p>Body content...</p>
  </article>
</main>

Heading Hierarchy

Heading tags should be used sequentially. You should never skip from h1 to h3, or go from h2 to h4.

<h1>Main Title</h1>
  <h2>First Section</h2>
    <h3>Subtopic 1</h3>
    <h3>Subtopic 2</h3>
  <h2>Second Section</h2>
    <h3>Subtopic 3</h3>

2. Keyboard Accessibility: Fully Usable Without a Mouse

Focus Management

All interactive elements (buttons, links, input fields) must be accessible via keyboard. Users should be able to navigate with the Tab key and activate elements with Enter or Space.

/* Never do this! */
*:focus {
  outline: none;
}

/* Instead, provide clear focus styles */
button:focus,
a:focus,
input:focus {
  outline: 2px solid #0066cc;
  outline-offset: 2px;
}

/* Or a more polished style */
button:focus-visible {
  box-shadow: 0 0 0 3px rgba(0, 102, 204, 0.5);
}

Logical Tab Order

The HTML structure order is the tab order. Avoid forcing the order by setting tabindex to positive values.

<!-- Good example: Natural order -->
<form>
  <input type="text" placeholder="Name">
  <input type="email" placeholder="Email">
  <button type="submit">Submit</button>
</form>

<!-- Bad example: Forcing order with tabindex -->
<button tabindex="3">Third</button>
<button tabindex="1">First</button>
<button tabindex="2">Second</button>

Preventing Keyboard Traps

When a modal or dropdown is opened, focus must not become trapped inside it. Users should be able to close it with the ESC key, and focus should cycle within the modal.

// Modal focus trap implementation example
const modal = document.querySelector('.modal');
const focusableElements = modal.querySelectorAll(
  'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
);
const firstElement = focusableElements[0];
const lastElement = focusableElements[focusableElements.length - 1];

modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal();
  }
  if (e.key === 'Tab') {
    if (e.shiftKey && document.activeElement === firstElement) {
      e.preventDefault();
      lastElement.focus();
    } else if (!e.shiftKey && document.activeElement === lastElement) {
      e.preventDefault();
      firstElement.focus();
    }
  }
});

3. ARIA: Communicating with Screen Readers

ARIA Usage Principles

ARIA (Accessible Rich Internet Applications) conveys information to assistive technologies that can’t be expressed through HTML alone. But remember the principle: “No ARIA is better than Bad ARIA.”

Ground rules:

• If a native HTML element exists, don’t use ARIA.
• ARIA does not change the visual appearance of an element.
• All interactive ARIA controls must be keyboard-accessible.

Key ARIA Attributes

role: Defines an element's role

<!-- Custom button -->
<div role="button" tabindex="0">Click me</div>

<!-- But this is better -->
<button>Click me</button>

aria-label: Provides a brief description

<button aria-label="Search">
  <svg><!-- Magnifying glass icon --></svg>
</button>

<button aria-label="Close menu">
  <span aria-hidden="true">×</span>
</button>

aria-labelledby / aria-describedby: References other elements

<div role="dialog" aria-labelledby="dialog-title" aria-describedby="dialog-desc">
  <h2 id="dialog-title">Sign Up</h2>
  <p id="dialog-desc">Please fill in the information below</p>
  <!-- Form content -->
</div>

State attributes:

<!-- Toggle button -->
<button aria-pressed="false" onclick="this.setAttribute('aria-pressed', 'true')">
  Enable Notifications
</button>

<!-- Accordion -->
<button aria-expanded="false" aria-controls="content-1">
  FAQ 1
</button>
<div id="content-1" hidden>Answer content...</div>
<!-- Tab panel -->
<div role="tablist">
  <button role="tab" aria-selected="true" aria-controls="panel-1">Tab 1</button>
  <button role="tab" aria-selected="false" aria-controls="panel-2">Tab 2</button>
</div>
<div role="tabpanel" id="panel-1">Panel 1 content</div>
<div role="tabpanel" id="panel-2" hidden>Panel 2 content</div>

aria-live: Announces dynamic content changes

<!-- Notification message -->
<div aria-live="polite" aria-atomic="true" class="notification">
  <!-- Messages are dynamically added here -->
</div>

<!-- Live chat -->
<div aria-live="assertive" role="log">
  <!-- New messages are read immediately -->
</div>

4. Alternative Text: Giving Meaning to All Content

Image Alt Text

<!-- Meaningful image -->
<img src="chart.png" alt="2024 revenue trend chart: increased from $10,000 in Q1 to $50,000 in Q4">

<!-- Decorative image -->
<img src="decoration.png" alt="">
<!-- Image inside a link -->
<a href="/profile">
  <img src="avatar.jpg" alt="View John's profile">
</a>
<!-- Complex images: provide longdesc or detailed description -->
<figure>
  <img src="complex-diagram.png" alt="System architecture diagram">
  <figcaption>
    <details>
      <summary>View detailed description</summary>
      <p>The frontend is built with React...</p>
    </details>
  </figcaption>
</figure>

Icons and SVGs

<!-- Font Awesome icon -->
<button>
  <i class="fas fa-trash" aria-hidden="true"></i>
  <span class="sr-only">Delete</span>
</button>

<!-- SVG icon -->
<button aria-label="Go to home">
  <svg aria-hidden="true" focusable="false">
    <use xlink:href="#icon-home"></use>
  </svg>
</button>
<!-- Meaningful SVG -->
<svg role="img" aria-labelledby="chart-title chart-desc">
  <title id="chart-title">Monthly Visitors</title>
  <desc id="chart-desc">Increased from 1,000 in January to 5,000 in December</desc>
  <!-- SVG content -->
</svg>

Visually Hidden but Exposed to Screen Readers

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

5. Color and Contrast: Making Everything Readable

WCAG Contrast Standards

• Level AA (minimum): Normal text 4.5:1, large text (18pt+ or bold 14pt+) 3:1
• Level AAA (enhanced): Normal text 7:1, large text 4.5:1

/* Good example: Sufficient contrast */
.text-good {
  color: #333333; /* Near-black gray */
  background-color: #ffffff; /* White */
  /* Contrast ratio: 12.63:1 */
}

/* Bad example: Insufficient contrast */
.text-bad {
  color: #cccccc; /* Light gray */
  background-color: #ffffff; /* White */
  /* Contrast ratio: 1.61:1 - Hard to read */
}

Don’t Convey Information Through Color Alone

<!-- Bad example: Status indicated only by color -->
<span style="color: red;">Error</span>
<span style="color: green;">Success</span>

<!-- Good example: Icons and text used together -->
<span class="status-error">
  <svg aria-hidden="true"><!-- X icon --></svg>
  Error
</span>
<span class="status-success">
  <svg aria-hidden="true"><!-- Checkmark icon --></svg>
  Success
</span>

Link Differentiation

/* Distinguish links in body text with underlines */
p a {
  text-decoration: underline;
  color: #0066cc;
}

/* Don't rely on color alone */
p a {
  color: #0066cc;
  text-decoration: underline;
}

p a:hover {
  text-decoration: none;
  background-color: #e6f2ff;
}

6. Form Accessibility: The Heart of User Input

Connecting Labels

Associate related label and input elements using the for and id attributes.

<!-- Properly connected label -->
<label for="username">Username</label>
<input type="text" id="username" name="username">

<!-- Or wrap with label -->
<label>
  Email
  <input type="email" name="email">
</label>

<!-- Don't use only placeholder -->
<!-- Bad example -->
<input type="text" placeholder="Enter your name">

<!-- Good example -->
<label for="name">Name</label>
<input type="text" id="name" placeholder="e.g. John Doe">

Indicating Required Fields

These days, many libraries handle this well, but required is still an attribute you should add for accessibility.

<label for="email">
  Email <span aria-label="required">*</span>
</label>
<input
  type="email"
  id="email"
  required
  aria-required="true"
>

<!-- Or more explicitly -->
<label for="email">
  Email <span class="required">(required)</span>
</label>
<input type="email" id="email" required>

Error Message Handling

<label for="password">Password</label>
<input
  type="password"
  id="password"
  aria-invalid="true"
  aria-describedby="password-error"
>
<span id="password-error" class="error" role="alert">
  Password must be at least 8 characters
</span>

// Real-time validation
const passwordInput = document.getElementById('password');
const errorMessage = document.getElementById('password-error');

passwordInput.addEventListener('blur', () => {
  if (passwordInput.value.length < 8) {
    passwordInput.setAttribute('aria-invalid', 'true');
    errorMessage.textContent = 'Password must be at least 8 characters';
  } else {
    passwordInput.setAttribute('aria-invalid', 'false');
    errorMessage.textContent = '';
  }
});

Grouping with Fieldset

<fieldset>
  <legend>Shipping Information</legend>

  <label for="address">Address</label>
  <input type="text" id="address">

  <label for="postal">Postal Code</label>
  <input type="text" id="postal">
</fieldset>

<fieldset>
  <legend>Notification Settings</legend>

  <label>
    <input type="checkbox" name="notification" value="email">
    Email notifications
  </label>

  <label>
    <input type="checkbox" name="notification" value="sms">
    SMS notifications
  </label>
</fieldset>

7. Responsive Design and Zoom

Handling Text Enlargement

/* Use relative units */
html {
  font-size: 16px; /* Base size */
}

body {
  font-size: 1rem; /* 16px */
}

h1 {
  font-size: 2rem; /* 32px */
}

.small-text {
  font-size: 0.875rem; /* 14px */
}

/* Avoid fixed px values */
.bad-example {
  font-size: 14px; /* Size stays fixed even when user zooms */
  width: 300px;
  height: 200px;
}

/* Flexible layout */
.good-example {
  font-size: 0.875rem; /* Responds to zoom */
  max-width: 90%;
  padding: 1em;
}

Touch Target Size

Ensure adequate touch areas on mobile devices.

/* Minimum 44x44px touch target */
button,
a {
  min-height: 44px;
  min-width: 44px;
  padding: 0.5em 1em;
}

/* Even small icon buttons need sufficient touch area */
.icon-button {
  width: 20px; /* Icon size */
  height: 20px;
  padding: 12px; /* Total: 44x44px */
}

Viewport Settings

<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=5.0">

Setting maximum-scale to 1.0 prevents zooming and should be avoided.

8. Multimedia Accessibility

Video and Captions

<video controls>
  <source src="video.mp4" type="video/mp4">
  <track
    kind="subtitles"
    src="subtitles-ko.vtt"
    srclang="ko"
    label="Korean"
    default
  >
  <track
    kind="subtitles"
    src="subtitles-en.vtt"
    srclang="en"
    label="English"
  >
  <track
    kind="descriptions"
    src="descriptions.vtt"
    srclang="ko"
    label="Audio Descriptions"
  >
</video>

Limiting Autoplay

<!-- Provide controls when autoplaying -->
<video autoplay muted loop controls>
  <source src="background.mp4">
</video>

<!-- Or provide a pause button -->
<button id="pause-animation">Pause Animation</button>

Reduced Motion

/* For users sensitive to motion */
@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
  }
}

/* Original animation */
.fade-in {
  animation: fadeIn 0.5s ease-in;
}

/* In reduced motion mode, show immediately */
@media (prefers-reduced-motion: reduce) {
  .fade-in {
    animation: none;
    opacity: 1;
  }
}

9. Practical Component Examples

Accessible Modal

<button id="open-modal">Open Modal</button>

<div
  id="modal"
  class="modal"
  role="dialog"
  aria-modal="true"
  aria-labelledby="modal-title"
  hidden
>
  <div class="modal-content">
    <h2 id="modal-title">Notification</h2>
    <p>This is the modal content.</p>
    <button id="close-modal">Close</button>
  </div>
</div>

const openBtn = document.getElementById('open-modal');
const closeBtn = document.getElementById('close-modal');
const modal = document.getElementById('modal');
let previousFocus;

openBtn.addEventListener('click', () => {
  previousFocus = document.activeElement;
  modal.hidden = false;
  closeBtn.focus();
  document.body.style.overflow = 'hidden';
});

closeBtn.addEventListener('click', () => {
  modal.hidden = true;
  document.body.style.overflow = '';
  previousFocus.focus();
});

// Close with ESC key
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeBtn.click();
  }
});

Accessible Dropdown

<div class="dropdown">
  <button
    id="menu-button"
    aria-expanded="false"
    aria-haspopup="true"
    aria-controls="menu-list"
  >
    Menu
  </button>

  <ul
    id="menu-list"
    role="menu"
    hidden
  >
    <li role="none">
      <a href="/profile" role="menuitem">Profile</a>
    </li>
    <li role="none">
      <a href="/settings" role="menuitem">Settings</a>
    </li>
    <li role="none">
      <a href="/logout" role="menuitem">Logout</a>
    </li>
  </ul>
</div>

const menuButton = document.getElementById('menu-button');
const menuList = document.getElementById('menu-list');
const menuItems = menuList.querySelectorAll('[role="menuitem"]');

menuButton.addEventListener('click', () => {
  const isExpanded = menuButton.getAttribute('aria-expanded') === 'true';
  menuButton.setAttribute('aria-expanded', !isExpanded);
  menuList.hidden = isExpanded;

  if (!isExpanded) {
    menuItems[0].focus();
  }
});

// Arrow key navigation
menuList.addEventListener('keydown', (e) => {
  const currentIndex = Array.from(menuItems).indexOf(document.activeElement);
  
  if (e.key === 'ArrowDown') {
    e.preventDefault();
    const nextIndex = (currentIndex + 1) % menuItems.length;
    menuItems[nextIndex].focus();
  } else if (e.key === 'ArrowUp') {
    e.preventDefault();
    const prevIndex = (currentIndex - 1 + menuItems.length) % menuItems.length;
    menuItems[prevIndex].focus();
  } else if (e.key === 'Escape') {
    menuButton.click();
    menuButton.focus();
  }
});

10. Testing Methods

Screen Reader Testing

• Windows: NVDA (free) or JAWS
• Mac: VoiceOver (built-in)
• Mobile: iOS VoiceOver, Android TalkBack

Color Blindness Simulation

• Chrome DevTools → Rendering → Emulate vision deficiencies

Closing Thoughts

Web accessibility isn’t for a special group of users — it’s for everyone.

It might feel like extra work at first, but once you get used to it, writing accessible code becomes second nature.

I hope these efforts, however small, contribute to a web that everyone can use without barriers — and that more developers continue to make accessibility a priority.

References

• WCAG 2.1 Guidelines
• MDN Web Accessibility
• A11y Project Checklist
• WebAIM
• Korean Web Accessibility Certification

회사에서 어드민 페이지 개발을 혼자 맡게 되면서

스택을 홀로 정할 수 있는 기회가 주어졌다.

(이참에 하고싶었던 거 다 써봐야지)

그래서 전부터 써보고 싶었던 요즘 핫한 shadcn/ui를 우선으로 생각했다.

그렇게 최종적으로 결정된 스택들은 React + TS, Vite, Tailwind css, Shadcn/ui, React Query !

But.. 현실은 버전 충돌의 연속

설치하면서 오류를 몇번이나 마주했는지 모르겠다.

그 중 하나의 예시는 tailwind를 설치하면서 발생했다.

tailwind 버전을 3.x대로 낮춰서 다시 설치하였는데, 다른데서 계속해서 버전문제가 발생했다. 그래서 그냥 지피티한테 각 스택들이 호환되는 버전을 알려달라고 했다. ㅋㅋ

이것들로 다시 초기세팅 진행

우선 노드 버전 체크부터

node -v

// v20.14.0

(1) Vite React + TypeScript 프로젝트 생성

npm create vite@5 . # 현재 디렉토리에 Vite 프로젝트 생성

그럼 프레임워크와 언어를 선택하라고 뜨는데 React와 TypeScript를 선택해준다.

React는 v18.3.1, TypeScript는 v5.6.2 가 설치되었다.

(2) Tailwind CSS 설정

# 1) Tailwind CSS 3.x 버전 지정해서 설치
npm install -D tailwindcss@^3.3.0 postcss autoprefixer

# 2) Tailwind config 파일 생성
npx tailwindcss init -p

• ^3.3.0으로 설치해두면 3.x 범위의 마이너/패치 업데이트가 허용되므로, 3.4.x, 3.5.x 등이 나오면 자동으로 업데이트된다.

tailwind.config.js에서 content 부분을 Vite 구조에 맞게 설정:

module.exports = {
  content: [
    "./index.html",
    "./src/**/*.{ts,tsx}",
    // shadcn/ui 컴포넌트를 직접 src/components/ui 아래에 두는 경우
    "./src/components/ui/**/*.{ts,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
};

그리고 src/main.tsx 혹은 src/index.css 등에 Tailwind 지시문 추가:

@tailwind base;
@tailwind components;
@tailwind utilities;

현재 Vite의 버전에서는 TypeScript 구성이 세 개의 파일로 분리되어 있으며, 그 중 두 파일을 수정해야 한다.
tsconfig.json과 tsconfig.app.json 파일의 compilerOptions 섹션에 baseUrl과 paths 속성을 추가:

(a) tsconfig.json

{
  "files": [],
  "references": [
    {
      "path": "./tsconfig.app.json"
    },
    {
      "path": "./tsconfig.node.json"
    }
  ],
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

(b) tsconfig.app.json

{
  "compilerOptions": {
    // ...
    "baseUrl": ".",
    "paths": {
      "@/*": [
        "./src/*"
      ]
    }
    // ...
  }
}

마지막으로, 다음 코드를 vite.config.ts 파일에 추가해서 앱에서 경로를 문제없이 해석할 수 있게 한다.

npm install -D @types/node

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

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      "@": path.resolve(__dirname, "./src"),
    },
  },
})

(3) shadcn/ui 가져오기

참고로 shadcn/ui를 Vite에서 쓸 경우, 공식 CLI(npx @shadcn/ui init)가 Next.js 전용 설정을 만들어버리므로, 일부 설정은 수동으로 가져와야 한다. 헷갈리면 공식문서 ㄱㄱ

npx shadcn init

그러면 추가로 선택할 것들이 뜨는데, 나는 아래처럼 선택해주었다.

이러면 shadcn까지 설치 끝!

npm run dev로 정상 작동되는지 확인하기

(4) 이제 진짜 shadcn 컴포넌트 사용

나는 사이드바 부터 사용해보기로 하였다.

npx shadcn add sidebar

이렇게 했을 때 프로젝트의 src > components > ui 에 sidebar.tsx가 생긴다.

그리고 나는 아래 문서를 참고해서 임시 사이드바 컴포넌트(AppSidebar.tsx)를 생성해주었다.

https://ui.shadcn.com/docs/components/sidebar#your-first-sidebar

App.tsx에서 사이드바 불러오기

import { SidebarProvider, SidebarTrigger } from "@/components/ui/sidebar";
import AppSidebar from "@/components/AppSidebar";

function App() {
  return (
    <div>
      <SidebarProvider>
        <AppSidebar />
        <main>
          <SidebarTrigger />
        </main>
      </SidebarProvider>
    </div>
  );
}

export default App;

그렇게 만들어진 사이드바! 짜잔

좀 더 shadcn스럽게(?) 다크테마 적용

index.html :

<html lang="en" class="dark">

혹은, React 컴포넌트 레벨에서:

<div className="dark">

완성!!!

이제 본격적으로 커스텀해서 사용해봐야겠다 ㅎㅎ

참고자료

• [shadcn 설치] https://ui.shadcn.com/docs/installation/vite
• [shadcn sidebar 컴포넌트] https://ui.shadcn.com/docs/components/sidebar

Of course, import order isn’t the most critical part of a project — but it was hard to see at a glance which modules were being used, so I thought it was worth improving.

So I set up ESLint rules to sort import order automatically, and also cleaned up relative paths by converting them to absolute paths using @/* based on the src directory.

1. Setting Up Absolute Paths

If You’re Using Create React App (CRA)

Create a jsconfig.json file at the project root and add the following:

// jsconfig.json

{
  "compilerOptions": {
    "baseUrl": "src",
    "paths": {
      "@/*": ["./*"]
    }
  }
}

📌 Before (relative paths):

import MyComponent from "../../component/MyComponent";
import useCustomHook from "../../hook/useCustomHook";
import apiClient from "../../api/client";

📌 After (absolute paths with @):

import MyComponent from "@/component/MyComponent";
import useCustomHook from "@/hook/useCustomHook";
import apiClient from "@/api/client";

• @/ is automatically resolved to src/, keeping the code clean!
• Much better for maintainability and readability

2. Sorting Imports with ESLint

Step 1: Install eslint-plugin-import

First, install the eslint-plugin-import package in your project.

npm install --save-dev eslint-plugin-import
# or with yarn
yarn add -D eslint-plugin-import

✔️ Use the --save-dev flag to add it as a dev dependency.

Step 2: Add the import/order Rule to Your .eslintrc

Update your .eslintrc file to automatically enforce import sorting.

Add the following to your .eslintrc:

"import/order": [
  "warn",
  {
    "groups": [
      "builtin",
      "external",
      "internal",
      ["sibling", "parent", "index"]
    ],
    "pathGroups": [
      {
        "pattern": "react",
        "group": "builtin",
        "position": "before"
      },
      {
        "pattern": "react-dom",
        "group": "builtin",
        "position": "before"
      },
      {
        "pattern": "react-dom/*",
        "group": "builtin",
        "position": "before"
      },
      {
        "pattern": "recoil",
        "group": "external",
        "position": "before"
      }
    ],
    "pathGroupsExcludedImportTypes": ["builtin"],
    "alphabetize": { "order": "asc", "caseInsensitive": true }
  }
]

If you’re using eslint.config.js instead:

Add "import/order" to rules the same way, and also add import: importPlugin to plugins:

// eslint.config.js
import importPlugin from "eslint-plugin-import";
    
plugins: {
  "react-hooks": reactHooks,
  "react-refresh": reactRefresh,
  import: importPlugin,
},

Step 3: Understanding the import/order Groups

• builtin → Node.js built-in modules (react, react-dom, fs, path, http, etc.)
• external → npm libraries like axios, lodash, moment
• internal → Internal project modules (e.g., @/component/)
• parent → Relative path modules starting with ../
• sibling → Modules in the same folder starting with ./
• index → Files like index.js

✔️ Auto alphabetical sorting is enabled with: "alphabetize": { "order": "asc", "caseInsensitive": true }

Step 4: Result After Applying the Rules

❌ Before (React modules mixed in the middle):

import html2canvas from "html2canvas";
import jsPDF from "jspdf";
import { useCallback, useRef } from "react";
import { createRoot } from "react-dom/client";
import { RecoilRoot } from "recoil";

✅ After (React modules sorted to the top):

import { useCallback, useRef } from "react";
import { createRoot } from "react-dom/client";
import { RecoilRoot } from "recoil";
import html2canvas from "html2canvas";
import jsPDF from "jspdf";

Typically, people add newlines between groups, but I personally prefer no newlines — so I didn’t add "newlines-between": "always".

Step 5: Enable Auto-Fix on Save in VS Code

To automatically sort imports when you save (⌘ + S), add the following to your VS Code settings.

📌 VS Code settings (settings.json):

{
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  }
}

Setting "source.fixAll.eslint": true ensures all ESLint rules are auto-fixed on save.

References

eslint-plugin-import/docs/rules/order.md at main · import-js/eslint-plugin-import

Click the green New button on the right.

2. Clone the Empty Repo Locally

git clone <your-repo-url>
cd <cloned-repo-folder>

3. Create a Project with Vite

npm create vite@latest . # Create a Vite project in the current directory

git init
git add .
git commit -m "init"

npm install
npm run dev

3–1. Push to the Remote Repo

git branch -M main
git remote add origin <your-repo-url> # Can be skipped in most cases
git push -u origin main

At this point, your repository should look something like this:

4. ESLint Configuration

module.exports = {
  root: true,
  env: { browser: true, es2020: true }, // Browser and ES2020 environment

  extends: [
    'eslint:recommended', // ESLint default recommended rules
    'plugin:@typescript-eslint/recommended', // TypeScript recommended rules
    'plugin:react-hooks/recommended', // React Hooks rules
  ],

  ignorePatterns: ['dist', '.eslintrc.cjs'], // Files/directories to ignore

  parser: '@typescript-eslint/parser', // Use TypeScript parser

  plugins: ['react-refresh'], // React Refresh plugin

  rules: {
    'react-refresh/only-export-components': [
      'warn',
      { allowConstantExport: true },
    ], // Components should only export components

    indent: ['error', 2], // 2-space indentation

    'no-unused-vars': 'off', // Disable base unused vars rule

    '@typescript-eslint/no-unused-vars': [
      'error',
      { vars: 'all', args: 'after-used', ignoreRestSiblings: false },
    ], // Detect unused variables in TypeScript

    '@typescript-eslint/explicit-function-return-type': 'warn',
    // Warn when function return types are not explicitly declared

    'no-empty': 'warn', // Warn on empty block statements

    semi: ['error', 'always'], // Enforce semicolons
  },
};

.eslintrc

{
  "extends": ["react-app", "plugin:prettier/recommended"],
  "rules": {
    "no-var": "warn", // Disallow var
    "no-multiple-empty-lines": "warn", // Disallow multiple blank lines
    "no-console": ["warn", { "allow": ["warn", "error"] }], // Disallow console.log()
    "eqeqeq": "warn", // Require strict equality operators
    "dot-notation": "warn", // Use dot notation when possible
    "no-unused-vars": "warn", // Disallow unused variables
    "react/destructuring-assignment": "warn", // Enforce destructuring for state/props
    "react/jsx-pascal-case": "warn", // Component names must be PascalCase
    "react/no-direct-mutation-state": "warn", // Disallow direct state mutation
    "react/jsx-no-useless-fragment": "warn", // Disallow unnecessary fragments
    "react/no-unused-state": "warn", // Disallow unused state
    "react/jsx-key": "warn", // Require key on iterated elements
    "react/self-closing-comp": "warn", // Use self-closing tags when possible
    "react/jsx-curly-brace-presence": "warn", // Disallow unnecessary curly braces in JSX
    "prettier/prettier": ["error", { "endOfLine": "auto" }]
  },
  "settings": {
    "import/resolver": {
      "node": {
        "moduleDirectory": ["node_modules", "src"]
      }
    }
  }
}

5. Prettier Configuration

npm install -D prettier

// .prettierrc
{
   "trailingComma": "none",
   "endOfLine": "auto",
   "tabWidth": 2,
   "semi": true,
   "singleQuote": true
}

// .prettierignore
node_modules/
build/
dist/
*.min.js

6. .vscode/settings.json

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true
}

7. Create an .nvmrc File

Set the Node version for the project.

// .nvmrc

20.14.0

8. Install a Styling Library

npm install styled-components

9. Router

npm install react-router-dom

10. Write the README.md

# <Project Name>

## 🎧 About Project
Project description

## ✨ Installation
```bash
git clone <repo-url>
nvm use
npm install
npm run dev
```

저에게는 개발을 시작하고 꾸준히 진행하고 있는 사이드 프로젝트가 하나 있는데요,

이번에 major 버전을 업그레이드 하면서 돌이켜보니 1년이 넘는 시간이 훌쩍 지났더라구요!?

이참에 사이드 프로젝트 관련하여 회고록을 남겨보면 좋겠다는 생각에 이렇게 회고록을 작성하게 되었습니다 :)

🎧 시작하게 된 계기

시작하게 된 계기는 작년 여름 당시 취준생이던 친구가 “테오의 스프린트 14기”를 신청하고

“당장 내일 아이디어 발표인데 나 뭘 할지 못 정했어” 라고 말을 했고

그 말을 들은 저는 핸드폰을 꺼내어 메모장에 있던 저의 아이디어를.. 방출했습니다.

한 6가지 정도 말했던걸로 기억하는데

그 중 친구는 “퍼스널컬러 자가진단”이 괜찮다며 사용하겠다고 했습니다.

그러고 발표를 얼마나 잘한건지 다음날 친구는 50명 정도의 아이디어 중에서 Top10으로 선정 되어 본인이 팀장이 되었다고 전해줬습니다. 😂

그렇게 친구는 일주일간 진행된 스프린트를 무사히 마쳤고,

“몇몇 팀원들과 이 프로젝트를 더 보완해나가고 싶은데, 너도 같이 할래?” 라고 제안해주어 그렇게 이 팀에 합류하게 되었습니다.

합류해서 맡았던 첫 작업은 봄, 여름, 가을, 겨울 이렇게 4가지였던 퍼스널컬러 타입을 12유형으로 확장하는 작업이었습니다.

12타입에 쓰일 색상, 타입별 설명, 연예인 이미지 등등 꽤나 많은 정보가 필요했고 “결과 타입 도출 로직”을 구현하는데에도 많은 고민이 들어갔습니다.

온라인 자가진단이지만 그래도 결과가 정확하게 나오면 좋겠고.. 그렇다고 또 너무 복잡한 과정을 거치면 안되고.. 결과적으로는 9번의 단계에서 모든 유형의 컬러가 3번씩 등장하고, 필요시 보너스단계를 진행하는 것으로 결론 내렸습니다.

그렇게 만들어진 결과 페이지..!

🏃🏻‍♀️ 사이드 프로젝트에서 진행한 것

사실 일년내내 계속 이 프로젝트만 진행했던 건 아니고, 중간에 다른 프로젝트도 시도하고 방학?도 가졌지만

어찌됐든 유지보수를 진행하며 이 사이트는 초기 모습과는 꽤나 많이 달라졌습니다.

그동안 진행되었던 작업들로는

• JavaScript → TypeScript 마이그레이션
• Next.js 도입
• SEO 개선
• 다국어 서비스
• 퍼스널컬러 타인 대리 테스트 기능
• 랜딩 페이지에 3D 이미지 추가
• 컬러칩 선택 인터랙션
• CI/CD
• 코딩 컨벤션

(사실 더 많지만 여기까지만..)

매주 일요일 아침10시 일어나는 것도 힘든데 주간회의를 하며 회의록도 열심히 남기고

마일스톤 설정하여 자체 스프린트 진행

: 작업할 내용 리스트업 후, 가치와 비용 기준으로 우선순위 정해서 진행하는 방식

서로 코드리뷰 해주는 팀원들..

각자 작업한 내용도 문서화 해보고

열심히 꾸민 팀 노션 페이지

그렇게 다가온 마지막 배포!

🩰 사이드 프로젝트를 하며 느낀점 (반모주의)

어느날 문득 들었던 생각이

어떻게 보면 나의 메모장에 들어있던 작은 아이디어 하나였는데,

그게 세상 밖으로 나오고

친구들의 도움으로 완성도가 높아져가고

그러다 결국 누군가에게 사용되는 모습을 보니 기분이 되게 묘했다.

이제 더이상 이 아이디어를 설명할 때 긴 말 필요없이 사이트를 보여주면 되고, 그렇게 생각하니 그동안 함께 달려와준 팀원들에게 너무 고마웠다.

잘하는데 열심히까지 하는 친구들 덕분에 옆에서 많이 배우고
재밌는 경험, 기억에 남을 추억이 만들어졌다.

퇴근하고 따로 시간을 내어 사이드 프로젝트를 한다는게 쉽지 않지만

혼자였다면 절대 해내지 못했을 것들이 함께였기에 가능했고

처음에는 별 기대 없이 시작한 프로젝트에서 많은 것을 얻은 프로젝트가 되어

누군가가 사이드 프로젝트 하는 것을 망설이고 있다면 하는 것을 적극 권장합니다 ㅎㅎ

마무리는 첫 오프라인 만남때 방탈출 사진으로 ㅎㅎ..

긴 글 읽어주셔서 감사합니다!!

샤라웃 to 설탕, 준, 코코 ✨

지금 바로 내 퍼스널컬러 확인하러 가기 => https://omct.web.app/ko

The first was about needing to use the .cjs extension for the ESLint config file.

The second was a library failing to find a .config.js file due to an incorrect file extension.

Both of these errors are related to JavaScript’s module system.

JavaScript has two module systems: CommonJS (CJS) and ECMAScript Modules (ESM).

In this post, I’ll cover the differences between the two, and why JavaScript ended up with two separate ways of loading modules in the first place.

The JavaScript Standard

To understand the difference, it helps to first note that JavaScript is used on both the backend and the frontend.

From its introduction in 1995 through 2009, JavaScript was originally used only on the frontend.

Then in 2009, Node.js came along — an environment that made it possible to write backend code in JavaScript. However, the base JavaScript standard didn’t have APIs for things like file system access or networking. To address this, CommonJS was introduced as a new standard for backend development.

The Emergence of CommonJS

Along with the APIs mentioned above, CommonJS also introduced a module management system — and that’s where the require syntax first appeared.

This is exactly why you get an error when you try to use require in a JavaScript environment that doesn't have CommonJS applied.

So the backend now had a proper module system with CommonJS, but the frontend still had no module management system of its own.

(There were workarounds like global variables and <script> tags, but these came with namespace collision issues and performance problems.)

Some developers got around this by using bundlers like webpack to emulate a CommonJS environment and use require in the browser.

So two problems remained:

1. The frontend still lacked a proper module management system
2. The JavaScript standards for backend and frontend were out of sync

The Emergence of ECMAScript Modules

Then in 2015, ES6 arrived and finally introduced a new syntax for managing modules on the frontend: import.

import has two key advantages over require: it's better suited for static analysis and code optimization.

First, unlike require, which can be placed anywhere in the code, import must be placed at the top of the file. This addresses the readability issues caused by module loading logic scattered throughout the code.

Second, import explicitly declares dependency modules, making it easy to see which parts of a module are dependencies — and it's also favorable for tree shaking.

“Tree shaking” is an optimization technique that removes unused code at build time to reduce bundle size.

Today, ES6 is supported not only on the frontend but also in Node.js LTS versions, so import can be used in both backend and frontend environments.

If you’re on an older version of Node.js that only supports CommonJS, you’ll need to use require. Similarly, if your frontend targets legacy browsers that don't support ES6, you'll need to use a bundler or manage modules through global variables.

The type Field in package.json

.cjs files are always interpreted as CJS, and .mjs files are always interpreted as ESM.

So what determines how a .js file is interpreted?

It’s determined by the type field in package.json.

• The default value is "commonjs", in which case .js files are interpreted as CJS.
• If set to "module", .js files are interpreted as ESM.

CJS vs. ESM Syntax

CommonJS (CJS)

// add.js
module.exports.add = (x, y) => x + y;

// main.js
const { add } = require('./add');

add(1, 2);

ECMAScript Modules (ESM)

// add.js
export function add(x, y) {
 return x + y
}

// main.js
import { add } from './add.js';

add(1, 2);

CJS uses require / module.exports.

ESM uses import / export statements.

References

• https://www.youtube.com/watch?v=KlpPYjCo0Do
• https://toss.tech/article/commonjs-esm-exports-field

The Weaknesses of JavaScript

JavaScript is a “dynamically typed language.”

In a dynamically typed language, developers don’t specify the types of variables when writing code. But this makes it very likely that unexpected bugs will surface.

The weaknesses of JavaScript:

☑️ Variable types are determined at runtime.

• Because JavaScript resolves variable types at runtime, mistakes are easy to make and hard to track down.
• Errors caused by these mistakes only reveal themselves when the program actually runs.

☑️ Weak type checking.

• JavaScript only provides keywords like let and const to distinguish between variables and constants.
• For example, let a = 1; a = "hello"; is perfectly valid (changing from number to string), which can lead to unexpected behavior.
• It doesn’t throw an error, but the type change can easily cause unintended side effects.

Enter TypeScript!

TypeScript is an open-source programming language developed by Microsoft. It includes all of JavaScript’s features while providing additional capabilities — namely type definitions and type checking.

TypeScript requires you to specify variable types when writing code, enabling static analysis to catch errors that would otherwise only appear at runtime.

Without this, errors would only surface after deployment to production, meaning users would be affected before you could fix anything.

Of course, TypeScript only catches type-related errors — you still have to find other bugs on your own. But catching type-related errors alone covers a significant portion of all errors.

Here’s how it differs from JavaScript:

☑️ Runtime type resolution → Compile-time type checking

The problem with JavaScript code:

What changed after introducing TypeScript:

• Errors caught in VS Code

• Errors caught at compile time

☑️ Weak type checking → Error messages the moment you type in VS Code

This early error detection through type checking is arguably the biggest benefit.

Now that we’ve covered the basic differences, let’s take a closer look at the terms “compile” and “static typing” mentioned above.

Compiled Languages vs. Interpreted Languages

TypeScript is a compiled language; JavaScript is an interpreted language.

With a compiled language, once you finish writing your code, it goes through a process called compilation that transforms it into a different form. The output could be machine code, bytecode for a virtual machine (like Java’s .class files), or even JavaScript — as in the unique case of TypeScript. The key characteristic of compiled languages is that this compilation step happens before execution.

An interpreted language, on the other hand, doesn’t go through a separate build step. The code you write is sent directly to an interpreter, which translates it into machine code on the fly as it runs.

Strictly speaking, languages like JavaScript do go through a compilation phase at the execution stage. But the important distinction is this: during the development phase (before the code runs), compiled languages include a compilation step, while interpreted languages do not.

Data Types: Static vs. Dynamic Typing

Generally, compiled languages use static typing, while interpreted languages use dynamic typing.

Dynamic typing is convenient for writing simple code, but as a project grows, the risk of runtime errors increases — like passing a string into a function that expects a number.

Since type consistency isn’t enforced at the time of writing, problems only explode at runtime.

This is why you need to be extra careful about type-related errors when using dynamically typed languages.

TypeScript was created to address exactly this. You write code safely with static types, then compile (transpile) it to JavaScript that runs in the browser or Node.js — preventing type-related errors along the way.

With a statically typed language, you must declare data types upfront when defining variables. The variable’s type can’t be changed, only values matching the declared type can be assigned, and type checking happens at compile time — failing to pass means an error.

In JavaScript, a variable’s type is determined not by declaration but by assignment (type inference). And through reassignment, a variable’s type can change dynamically at any time.

Fundamentally, “variables” don’t have types — “values” do. It’s more accurate to say that a variable’s type is dynamically determined (inferred) by the value assigned to it.

let a = 1;   // The type of 1 (number) becomes the type of variable a
a = '1';     // The type of '1' (string) changes the type of variable a

Is TypeScript Really Necessary?

Now that we’ve looked at the differences, is TypeScript truly essential?

First, let’s understand how browsers read TypeScript.

Browsers like Chrome, Whale, and Safari don’t understand TypeScript — they only have a JavaScript engine built in, not a TypeScript engine.

So if they can only understand JavaScript, how can we use TypeScript?

The answer is transpilation.

Compilation refers to converting a higher-level (more abstracted) language into a lower-level language. Transpilation, on the other hand, converts between languages at a similar or equal level of abstraction.

Since JavaScript isn’t a lower-level language like machine code, the TS → JS process is called transpilation.

In short: browsers can’t understand TypeScript, so it gets converted to JavaScript before running in the browser.

This means TypeScript code goes through a transpilation step, which adds to build time.

So Why Use TypeScript Despite the Extra Complexity?

If it adds complexity and increases build time, why bother with TypeScript?

Frontend code doesn’t run on a server — it runs on each user’s device.

That device could be a latest Android phone, an iPhone, or a Windows PC. In extreme cases, it might even be a device like a Galaxy S2 that no longer receives updates.

Modern JavaScript syntax might not work on these older devices. To support them, we use polyfills — which convert code into older JavaScript syntax that legacy engines can handle.

In other words, frontend code almost always goes through a polyfill conversion step before deployment. (This process also includes optimizations like minification to reduce code size.)

So converting TypeScript to JavaScript fits naturally into this existing workflow — it doesn’t add significant overhead.

The reasoning boils down to this: “Since we’re already going to transform the code for browser compatibility and optimization anyway, let’s use TypeScript for safety and convenience during development and just include it in the transformation.”

Switching from JavaScript to TypeScript can feel tedious at first, because you lose the “flexibility” that JavaScript provided. But in return, TypeScript gives you stability. The scope of errors caused by type issues is larger than you might expect, and discovering them in production is costly — both in terms of engineering time and user experience. By using TypeScript, you can improve the stability and user experience of your web applications, and that’s its greatest advantage.

References

• Understanding TypeScript in 5 Minutes (Transpile, Compile, Polyfill)
• Data Types and Static/Dynamic Typing (+ Relationship with Compiled/Interpreted Languages)
• What Is Compilation, and Is JavaScript an Interpreted Language?
• How V8 Executes JavaScript Code

Browser Internal Structure

A browser’s internal structure consists of the following components:

• User Interface
• Browser Engine
• Rendering Engine
• Networking
• JavaScript Engine
• UI Backend
• Data Storage

Among these, the rendering engine parses web page resources like HTML, CSS, and JavaScript, and displays them on screen.

The engine primarily parses HTML to build the DOM tree, parses CSS to create the CSSOM, combines them to form the render tree, and ultimately draws the page on screen.

Let’s look at this in more detail.

The Browser Rendering Process

The browser rendering process broadly follows these stages: DOM Tree Creation → CSSOM Creation → Layout (Reflow) → Paint (Repaint) → Compositing.

1. Receiving the HTML document: The browser receives the HTML document from the server. The HTML document is transmitted as plain text.
2. Parsing the HTML document: The browser parses the received HTML document. Parsing is the process of converting HTML text into a tree structure the browser can understand. This produces the DOM (Document Object Model) tree. The DOM tree represents each HTML element as a node, with elements connected through parent-child relationships.
3. CSS parsing and style calculation: The browser also downloads and parses CSS files linked within the HTML document. It then applies CSS style rules to construct the Render Tree. Unlike the DOM tree, the render tree only includes elements that will actually be displayed on screen. For example, elements hidden with display: none are not included in the render tree.
4. JavaScript parsing and execution: When a <script> tag is encountered during HTML parsing, the browser downloads and executes the JavaScript. Since JavaScript can manipulate the DOM, DOM parsing may be blocked. To prevent this, you can add defer or async attributes to the <script> tag to enable asynchronous execution.
5. Layout calculation: After both the DOM and CSSOM (CSS Object Model) have been parsed, the browser calculates the size and position of each element. This is called the layout stage, where the on-screen placement of elements is determined.
6. Painting: Once the layout of all elements is determined, the browser draws them onto the screen. Elements are rendered according to their style properties — text, colors, shadows, and so on.
7. Compositing: The browser splits certain areas of the page into separate layers and composites them. This optimizes performance for operations like scrolling and animations.

Improving Browser Performance

The size and complexity of the DOM and CSSOM directly impact the browser’s rendering performance. If the DOM is too large or CSS rules are overly complex, rendering takes longer, which can delay page load times and negatively affect the user experience.

Reflow occurs when there are changes that affect an element’s layout. It’s relatively expensive because the browser has to recalculate the position and size of all child and surrounding elements.

Repaint, on the other hand, occurs when only an element’s visual properties (color, background, border) change. Since it doesn’t affect layout, it’s relatively less expensive than reflow.

To improve browser performance, it’s best to minimize reflow and repaint. Ways to do this include minimizing DOM changes, using a virtual DOM, reducing complex CSS selectors, minimizing style changes, and leveraging GPU acceleration by using CSS animations instead of JavaScript.

Benefits of GPU Acceleration

By default, the browser uses the CPU to process and render DOM elements. However, certain CSS properties like transform and opacity can leverage GPU acceleration — the GPU handles graphics and video rendering tasks instead of the CPU, resulting in better performance.

The benefits include:

Parallel processing: GPUs have many cores, allowing them to handle many tasks simultaneously at high speed. This parallel processing makes graphics and animation work much more efficient.

Reduced CPU load: With GPU acceleration handling the graphics rendering, the CPU can focus on more important tasks like application logic and data management.

Improved graphics performance: GPU acceleration enables smoother and faster processing of complex graphics in web pages and applications, delivering a better user experience. It’s particularly effective for smooth animations, high-resolution video playback, and 3D graphics.

An execution context is the environment in which JavaScript code runs.

There are two types of execution context in JavaScript: the Global Execution Context and the Function Execution Context.

1. Global Execution Context

When the JavaScript engine first runs your code, it creates a Global Execution Context. During this creation, it generates the global object — the Window object (or Global in Node.js) — and sets this to point to it.

Even with no code at all, the JavaScript engine creates a Global Execution Context the moment it runs the file.

2. Function Execution Context

The JavaScript engine creates a new Execution Context every time a function is called. Each function has its own Execution Context at the point of invocation.

👉🏻 The JavaScript engine creates the Global Execution Context exactly once when it first runs the code, and creates a Function Execution Context each time a function is called.

Call Stack

The call stack is a data structure that stores the Execution Contexts created as code runs. When the engine first executes a script, it creates the Global Execution Context and pushes it onto the call stack. After that, each time the engine encounters a function call, it creates a Function Execution Context and pushes it onto the stack.

The JavaScript engine executes whichever function is at the top of the call stack. When that function finishes, it’s removed (popped) from the stack, and control moves to the next function at the top.

Given the following code:

function first() {
    console.log('first');
    second();
}

function second() {
    console.log('second');
}

first();

Execution Contexts are pushed and popped from the call stack in the following order:

Step-by-step breakdown:

1. The engine starts executing the JavaScript file, creates the Global Execution Context, and pushes it onto the call stack.
2. The engine encounters the first() function call, creates an Execution Context for first, and pushes it onto the call stack.
3. Inside first, the engine encounters console.log, creates an Execution Context for it, and pushes it onto the call stack.
4. console.log('first') finishes and is removed from the call stack.
5. The engine encounters the second() call, creates an Execution Context for second, and pushes it onto the call stack.
6. Inside second, the engine encounters console.log, creates an Execution Context for it, and pushes it onto the call stack.
7. console.log('second') finishes and is removed from the call stack.
8. second finishes and is removed from the call stack.
9. first finishes and is removed from the call stack.
10. After all code has finished executing, the JavaScript engine removes the Global Execution Context from the call stack.

So far, we’ve covered what execution contexts are and when they’re created and added to the call stack.

Now let’s look at what’s inside an execution context and how the JavaScript engine creates one.

Execution Context Creation Process

Execution Context creation is divided into two phases:

• Creation Phase
• Execution Phase

JavaScript stores information like variables somewhere within the execution context — that place is called the Environment Record. The environment record is an object that maps identifiers to their bound values. How variables are stored in the environment record follows the rules of hoisting. (During the creation phase, new identifiers are recorded in the environment record, and this is when hoisting occurs.)

(See: hoisting reference 🔗)

This scanning and preparation step before actual execution is called the creation phase — declaration statements are executed first and recorded in the Environment Record.

Then the remaining code (everything other than declarations) is executed sequentially — this is the execution phase. During this phase, the engine references or updates the recorded information as needed.

Viewing Execution Context in DevTools

Let’s verify this execution context using browser DevTools.

Open DevTools, select the Sources tab, set a breakpoint on a specific line, and refresh the page — you’ll be able to inspect the Scope.

Note that the (anonymous) entry in the Call Stack on the left is the Global Execution Context created first, while fn1 and fn2 are Function Execution Contexts.

l0 and l2 are logged correctly in the console — but how did JavaScript retrieve these values?

First, JavaScript looks within the Local scope of the currently executing function fn2. Since l0 isn't in the local scope, it checks the Script scope below it. l0 exists there, so it returns "l0". (The Script scope is a globally accessible scope.)

For l2, since it exists in the Local scope, JavaScript returns "l2" and stops looking further.

That’s why l0 and l2 are logged correctly.

The way the Local scope, Script scope, and Global scope are linked together is called scope chaining.

Now, if we uncomment the previously commented-out console.log and run it again, a reference error occurs.

Why does this error happen?

l2 is defined inside fn2. Even though fn1 calls fn2, it can't access variables defined inside fn2 — hence the error.

In other words, even if fn2 is called from within fn1, l2 lives inside fn2's local scope — where it was declared.

If the accessible scope changed based on where a function is called, that would be called dynamic scope.

But JavaScript doesn’t use dynamic scope — it uses static scope (also known as lexical scope).

Back in the ES3 era, execution contexts weren’t central to identifier resolution (determining the value of variables and functions in code) the way they are now. At that time, scope varied depending on where a function was called. This meant that every time a function was invoked, the engine had to dynamically create a matching scope and wire up the scope chain.

Starting with ES5 (2009~), the mechanism for identifier resolution changed — it became managed as a single bundle called the execution context.

Scope is now determined “statically” based on where code is declared, regardless of where it’s called. Because everything is bundled into a single context concept, the JavaScript engine can resolve identifiers much faster and more efficiently.

In this sense, we’ve seen how the execution context serves as a mechanism for more efficient identifier resolution.

References

• Call Stack and Execution Context
• YouTube — JavaScript Closure
• YouTube — Execution Context