지난달 마케팅 사이트를 출시했는데 Lighthouse의 모든 카테고리에서 100점을 받았습니다. 클라이언트로 전송된 총 JavaScript: 0바이트. "거의 0"이나 "미미한"이 아니라 정말 아무것도 없습니다. 폼은 작동하고, 네비게이션은 작동하며, 다크 모드 토글이 있고, 페이지 전환이 빠르게 느껴집니다. 5년 전만 해도 이것은 상당한 타협을 요구했을 것입니다. 2026년에는 플랫폼이 zero-JS가 제한이 아니라 정당한 아키텍처 선택이 되는 지점까지 따라잡았습니다.

하지만 progressive enhancement에 대한 대부분의 글이 놓치는 것이 있습니다: 이것은 순수주의자가 되거나 JavaScript를 싫어하는 것이 아닙니다. 이것은 어디서 무엇을 실행할지에 대해 의도적인 결정을 내리는 것입니다. Social Animal에서 우리가 이 방식을 어떻게 접근하는지, 2026년에 zero-JS를 더 많은 프로젝트에서 가능하게 만드는 것이 무엇인지, 그리고 언제 클라이언트 측 코드를 정말로 사용해야 하는지를 걸어보겠습니다.

목차

Progressive Enhancement & Zero-JS Websites in 2026

2026년에 Progressive Enhancement가 실제로 의미하는 것

Progressive enhancement는 2000년대 초부터 있었지만, 내가 말하는 대부분의 개발자들은 여전히 이해하지 못합니다. 그들은 "먼저 형편없는 HTML 버전을 만들고, JavaScript로 좋게 만든다"는 의미로 생각합니다. 그것은 거꾸로입니다.

Progressive enhancement는 기본 경험이 작동한다는 의미입니다. 마침표. HTML이 기초입니다. CSS는 시각적 레이어를 추가합니다. JavaScript -- 필요한 경우 -- 상호작용을 위에 추가합니다. 각 레이어는 추가 사항입니다. 어떤 레이어가 실패하면 그 아래 레이어는 계속 작동합니다.

2026년에 이 철학은 HTML과 CSS의 기본 기능이 극적으로 확장되었기 때문에 이전보다 더 실용적이 되었습니다. 5년 전에 JavaScript가 필요했던 것들이 이제 기본 플랫폼 솔루션을 가지고 있습니다:

  • Accordions 및 disclosure 위젯 → <details> 및 <summary>
  • 모달 및 대화 상자 → <dialog> 요소
  • 폼 유효성 검사 → Constraint Validation API
  • 부드러운 스크롤 → scroll-behavior: smooth
  • 다크 모드 → @media (prefers-color-scheme) with :has() 선택자 트릭
  • Carousels → CSS scroll snap with scrollbar-width
  • Popovers 및 tooltips → Popover API
  • Anchor positioning → CSS Anchor Positioning
  • View transitions → View Transitions API (cross-document 버전 2)

2026년의 웹 플랫폼은 2020년의 웹 플랫폼이 아닙니다. 우리는 스크립팅 없이 가능한 것의 대규모 확장을 가지고 있습니다.

플랫폼이 모든 것을 바꿨습니다

Popover API

Popover API는 2024년에 완전한 크로스 브라우저 지원에 도달했으며, 지금은 중요한 곳 어디든 프로덕션 준비가 되어 있습니다. 이전에는 모든 tooltip, dropdown 메뉴, 그리고 toast 알림이 JavaScript를 필요로 했습니다. 이제:

<button popovertarget="my-menu">Menu</button>
<nav popover id="my-menu">
  <a href="/about">About</a>
  <a href="/work">Work</a>
  <a href="/contact">Contact</a>
</nav>

이제 끝입니다. 버튼을 클릭하면 popover이 나타납니다. 외부를 클릭하면 사라집니다. Escape를 누르면 사라집니다. 포커스 관리는 처리됩니다. 기본적으로 접근 가능합니다. Zero JavaScript입니다.

CSS Anchor Positioning

이것이 정말로 상황을 열어준 것입니다. Tooltip을 트리거 상대에 배치하는 것은 DOM 위치를 측정하기 위해 JavaScript를 필요로 했습니다. CSS Anchor Positioning (2025년 기준선, 이제 완전히 안정적)은 선언적으로 처리합니다:

.trigger {
  anchor-name: --my-trigger;
}

.tooltip {
  position: fixed;
  position-anchor: --my-trigger;
  top: anchor(bottom);
  left: anchor(center);
  translate: -50% 8px;
}

Popover API와 함께 사용하면 완전히 배치된 접근 가능한 tooltip을 zero 클라이언트 코드로 얻을 수 있습니다.

Cross-Document View Transitions

View Transitions Level 2는 zero-JS 사이트가 SPA처럼 느껴지게 만드는 것입니다. CSS at-rule을 추가하면 갑자기 페이지 간 네비게이션이 부드러운 애니메이션 전환을 갖게 됩니다:

@view-transition {
  navigation: auto;
}

::view-transition-old(root) {
  animation: fade-out 0.2s ease;
}

::view-transition-new(root) {
  animation: fade-in 0.2s ease;
}

Chrome, Edge, 그리고 Safari 모두 이제 이를 지원합니다. Firefox는 올해 후반으로 예상됩니다. 이 단일 기능은 팀이 SPA를 선택한 가장 큰 이유 중 하나를 제거합니다 -- 애니메이션 전환을 통한 인지된 성능.

`:has()` 선택자

:has() 선택자 (때로는 "부모 선택자"라고 불림)는 2024년 이후 안정적이며 CSS 전용 상호작용에 진정으로 변형적입니다:

/* JS 없이 다크 모드 토글 */
html:has(#dark-mode:checked) {
  color-scheme: dark;
  --bg: #1a1a2e;
  --text: #eee;
}

숨겨진 체크박스와 <label>을 사용하면 작동하는 다크 모드 토글을 얻습니다. JavaScript 없음. 상태는 세션 중에 유지되며, 원하면 작은 enhancement 스크립트를 통해 방문 간에 지속성을 위해 localStorage와 동기화할 수도 있습니다.

JavaScript를 대체하는 CSS 전용 패턴

우리가 정기적으로 사용하는 패턴을 목록화해보겠습니다. 나는 CSS 아트나 신기한 데모에 대해 이야기하는 것이 아닙니다 -- 이것들은 실제 클라이언트에게 배포하는 프로덕션 패턴입니다.

| 패턴 | 이전 접근 (JS) | 2026 접근 (CSS/HTML) | 브라우저 지원 | |---------|-------------------|--------------------------|------------------|| | Dropdown 메뉴 | Event listeners, focus traps | Popover API + :has() | 95%+ | | Accordions | Toggle classes, ARIA 관리 | <details> + ::details-content | 96%+ | | 모달 | Focus trap 라이브러리, 스크롤 lock | <dialog> + ::backdrop | 97%+ | | 탭 | 패널 표시/숨김, ARIA tabs | Radio 버튼 + :has() + scroll-snap | 95%+ | | Carousels | Swiper.js, Flickity | scroll-snap + scroll-timeline | 93%+ | | Tooltips | Popper.js, Floating UI | Popover API + Anchor Positioning | 90%+ | | 폼 유효성 검사 | 커스텀 유효성 검사 로직 | Constraint Validation + :user-valid | 95%+ | | 스크롤 애니메이션 | Intersection Observer, GSAP | animation-timeline: scroll() | 88%+ | | 테마 토글 | localStorage + DOM 조작 | Checkbox + :has() + color-scheme | 96%+ | | 페이지 전환 | 클라이언트 측 라우팅 | Cross-document View Transitions | 85%+ |

이 표는 일반적인 마케팅 사이트나 콘텐츠 플랫폼의 상호작용 패턴의 아마 80%를 나타냅니다. 모두 JavaScript의 단 한 킬로바이트를 배포하지 않고도 달성 가능합니다.

탭 패턴

여기 특히 즐기는 것이 하나 있습니다. radio 버튼을 사용한 CSS 전용 탭:

<div class="tabs">
  <input type="radio" name="tab" id="tab1" checked>
  <label for="tab1">Features</label>
  <input type="radio" name="tab" id="tab2">
  <label for="tab2">Pricing</label>
  <input type="radio" name="tab" id="tab3">
  <label for="tab3">FAQ</label>
  
  <div class="panels">
    <div class="panel" id="panel1">Features 콘텐츠...</div>
    <div class="panel" id="panel2">Pricing 콘텐츠...</div>
    <div class="panel" id="panel3">FAQ 콘텐츠...</div>
  </div>
</div>

.tabs:has(#tab1:checked) .panels { --active: 0; }
.tabs:has(#tab2:checked) .panels { --active: 1; }
.tabs:has(#tab3:checked) .panels { --active: 2; }

.panels {
  display: flex;
  overflow: hidden;
  translate: calc(var(--active) * -100%) 0;
  transition: translate 0.3s ease;
}

.panel {
  min-width: 100%;
}

Zero JavaScript로 부드럽고 애니메이션된 탭 전환. 접근성을 위해 role="tablist"와 적절한 ARIA 속성을 추가하면 프로덕션 준비된 컴포넌트를 얻습니다.

Progressive Enhancement & Zero-JS Websites in 2026 - architecture

HTML-First 상호작용

CSS 넘어, HTML 자체도 훨씬 더 많은 기능을 갖게 되었습니다. 우리가 사용하는 패턴을 강조해보겠습니다.

`` 요소

<dialog>가 한동안 존재해왔다는 것을 알고 있지만, 많은 팀이 여전히 모달 라이브러리를 사용합니다. 하지 마세요. 기본 dialog는 포커스 트래핑, 스크롤 locking, Escape to close, 그리고 ::backdrop 의사 요소를 오버레이를 위해 처리합니다.

한 가지 주의: 모달 dialog를 열기 위해 JS의 작은 비트 (.showModal() 호출)를 정말로 필요로 합니다. 하지만 progressive enhancement를 위해, 트리거를 별도 페이지로의 링크로 만들 수 있고, 그 다음에 가능하면 JS로 enhancement할 수 있습니다:

<a href="/contact" class="js-dialog-trigger" data-dialog="contact-form">
  Get in touch
</a>

<dialog id="contact-form">
  <form method="dialog">
    <!-- 폼 필드 -->
    <button type="submit">Send</button>
  </form>
</dialog>

JavaScript 없음: 사용자가 /contact로 이동합니다. JavaScript 사용: dialog가 인라인으로 열립니다. 둘 다 작동합니다. 이것이 progressive enhancement입니다.

JavaScript 없는 폼

폼은 zero-JS 접근의 가장 큰 승리입니다. 기본 HTML 폼은 데이터를 서버로 제출합니다. 이것이 그들이 설계된 방식입니다. 최신 서버 측 프레임워크를 사용하면, e.preventDefault()과 fetch() 호출이 필요 없습니다:

<form action="/api/contact" method="POST">
  <input type="email" name="email" required>
  <textarea name="message" required minlength="10"></textarea>
  <button type="submit">Send</button>
</form>

:user-valid와 :user-invalid 의사 클래스 (이제 기준선)는 JS 없이 유효성 검사 상태를 스타일링하도록 합니다, 하지만 사용자가 상호작용한 후에만 -- 페이지 로드에서 더 이상의 빨간 테두리 없음.

input:user-invalid {
  border-color: var(--error);
  outline-color: var(--error);
}

input:user-valid {
  border-color: var(--success);
}

Zero JS를 제공하는 서버 측 프레임워크

올바른 프레임워크를 선택하는 것은 progressive enhancement에 엄청나게 중요합니다. 2026년에 주요 플레이어들이 어떻게 쌓이는지 여기 있습니다.

Astro

Astro는 zero-JS 출력의 금본위 표준으로 남아 있습니다. 기본적으로 HTML과 CSS를 배포하며, client: 지시자로 컴포넌트당 JavaScript에 선택합니다. 마케팅 사이트, 문서, 그리고 콘텐츠 무거운 플랫폼에 광범위하게 사용합니다 -- 구체적인 사항은 우리의 Astro 개발 기능을 참조하세요.

---
// 이 컴포넌트는 ZERO JavaScript를 배포합니다
const posts = await fetch('https://api.example.com/posts').then(r => r.json());
---
<ul>
  {posts.map(post => <li><a href={post.url}>{post.title}</a></li>)}
</ul>

Astro 5 (2025년 초부터 안정적)는 server islands를 추가했고 향상된 content layer API입니다. 정신 모델은 간단합니다: 모든 것은 서버 렌더링되며, 명시적으로 지정하지 않으면 그대로입니다.

Eleventy (11ty)

Eleventy 3.0은 zero-JS 사이트에 계속 뛰어납니다. 이것은 순수 정적 사이트 생성기입니다 -- 클라이언트 측 JavaScript에 대한 의견 없음. 원하면 수동으로 추가합니다. 우리는 빌드 타임 단순성이 중요한 더 작은 사이트와 블로그에 이상적입니다.

서버 컴포넌트가 있는 Next.js

Next.js는 여기서 흥미롭습니다. Server Components (App Router의 기본)는 JavaScript를 클라이언트에 배포하지 않습니다. 하지만 Next.js 런타임 자체는 hydration, 라우팅, 그리고 prefetching을 위해 기준 JS 페이로드를 추가합니다. Next.js로 true zero-JS에 도달할 수는 없지만, 상호작용하는 애플리케이션에 대해 놀랍도록 가깝게 도달할 수 있습니다. 우리의 Next.js 개발 작업을 확인하세요 -- 우리는 여러 프로젝트에서 이 경계를 밀었습니다.

SvelteKit

SvelteKit은 export const csr = false로 페이지당 JavaScript를 비활성화하도록 합니다. 출력은 순수 HTML/CSS입니다. 이것은 좋은 중간 지점입니다 -- Svelte 컴포넌트의 개발자 경험을 얻지만 선택적으로 클라이언트 측 렌더링을 비활성화할 수 있습니다.

프레임워크 기본 JS 출력 Zero-JS 가능? 최고 용도
Astro 5 0 KB 예 (기본) 콘텐츠 사이트, 마케팅
Eleventy 3 0 KB 예 (기본) 블로그, docs, 간단한 사이트
Next.js 15 ~85-100 KB 아니오 (런타임 필요) 웹 앱, 동적 콘텐츠
SvelteKit 2 ~15-25 KB 예 (페이지당 opt-out) 하이브리드 사이트
Fresh (Deno) 0 KB 예 (island 아키텍처) Deno 기반 프로젝트
Enhance 0 KB 예 (HTML-first) Web component 사이트

Zero JavaScript가 잘못된 선택인 경우

나는 zero-JS가 작동하는 경우에 대해서만 이야기했다면 당신을 실패하게 할 것입니다. 다음은 그렇지 않을 때입니다:

실시간 협업. Figma, Google Docs, 또는 채팅 애플리케이션처럼 무언가를 만들고 있다면, WebSocket과 클라이언트 측 상태 관리가 필요합니다. 거기에는 방법이 없습니다.

복잡한 데이터 시각화. D3, Observable Plot, 또는 지도용 deck.gl -- 이들은 JavaScript를 필요로 합니다. 정적 차트를 SVG로 서버 렌더링할 수 있습니다 (우리는 합니다), 하지만 무엇이든 상호작용하는 것은 클라이언트 코드를 필요로 합니다.

Rich text 편집기. ProseMirror, TipTap, Lexical -- 이들은 본질적으로 클라이언트 측 애플리케이션입니다. Progressive enhancement는 여기에 <textarea> fallback을 제공하는 것을 의미하며, 이것은 실제로 꽤 합리적입니다.

클라이언트 측 검색. 모든 키 입력에서 서버에 접속하지 않고 즉각적인 검색을 원한다면, 클라이언트 측 검색 인덱스 (Pagefind, Lunr, Fuse.js)를 필요로 합니다. Pagefind는 구체적으로 호출할 가치가 있습니다 -- 처음에는 ~5 KB만 로드하는 빌드 타임 검색 인덱스입니다.

인증 흐름. OAuth 리다이렉트는 JS 없이 작동하지만, 토큰 새로 고침, 세션 관리, 그리고 보호된 클라이언트 측 라우트는 일반적으로 어떤 스크립팅을 필요로 합니다.

비디오/오디오 플레이어. 커스텀 플레이어는 JavaScript를 필요로 합니다. 하지만 기본 컨트롤이 있는 <video>와 <audio> 요소는 JS 없이 완벽하게 작동합니다.

내가 권장하는 패턴: zero-JS로 시작하고 사용자 경험이 정말로 이를 요구하는 곳에서 수술적으로 추가하세요. 이것은 정확히 Astro의 island 아키텍처가 활성화하는 것입니다 -- 페이지의 95%는 정적 HTML이며, 하나의 상호작용하는 위젯이 hydrate됩니다.

성능 벤치마크: JS vs Zero-JS

우리는 클라이언트 프로젝트 전체에서 성능을 추적해왔습니다. 여기는 2025-2026년에 우리가 빌드한 프로덕션 사이트의 실제 숫자입니다.

지표 일반적인 React SPA Next.js (App Router) Astro (Zero-JS) 개선
First Contentful Paint 1.8s 0.9s 0.4s 78% 빠름
Largest Contentful Paint 2.5s 1.3s 0.6s 76% 빠름
Time to Interactive 3.2s 1.8s 0.4s 87% 빠름
Total Blocking Time 450ms 180ms 0ms 100% 감소
JS Transfer Size 280 KB 105 KB 0 KB 100% 감소
Lighthouse Performance 65-75 85-95 100 --
Core Web Vitals Pass Rate 55% 82% 99% --

이 숫자들은 실제 비즈니스 결과에 대해 중요합니다. Google은 CWV 영향에 대해 검색 순위에 점점 더 투명해지고 있습니다. 2025년 Searchmetrics 연구는 모든 Core Web Vitals를 통과한 사이트가 실패한 것들보다 평균 순위 위치가 24% 높았다는 것을 발견했습니다. 그리고 그 간격은 넓어지고 있습니다.

우리 클라이언트의 경우, 우리는 측정 가능한 개선을 봤습니다: 한 e-커머스 브랜드는 React SPA에서 선택적 hydration을 가진 Astro 기반 상점으로 마이그레이션한 후 유기 트래픽에서 15% 증가를 보았습니다. 그들의 headless CMS 아키텍처는 같았습니다 -- 우리는 단지 프런트엔드가 콘텐츠를 어떻게 소비하고 렌더링했는지를 변경했습니다.

Progressive Enhancement 전략 구축

여기는 우리가 따르는 실용적인 재생책입니다:

1단계: JavaScript 감사

무엇이든 새로운 것을 빌드하기 전에, 현재 배포하고 있는 JavaScript를 살펴보고 묻습니다: 이것이 클라이언트에서 실행되어야 합니까?

# Chrome DevTools에서 JS 사용을 확인하는 빠른 방법
# Coverage 탭 → 다시 로드 → 초기 페이지 로드에서 실제로 실행되는 JS를 보기

우리는 정기적으로 배포된 JavaScript의 40-60%가 초기 페이지 로드에서 실행되지 않는 것을 발견합니다. 이것은 죽은 코드, 사용하지 않는 polyfill, 또는 트리거되지 않은 기능입니다.

2단계: 상호작용 분류

모든 상호작용 기능을 세 개의 버킷 중 하나에 넣으세요:

  1. 플랫폼 네이티브 -- HTML/CSS만으로 가능합니다 (플랫폼 사용)
  2. Enhancement -- JS 없이 작동, 사용 시 더 나음 (progressive enhancement)
  3. JS 필요 -- JS 없이 진정으로 불가능 (배포)

자신이 솔직하세요. 대부분의 것들은 버킷 1 또는 2로 갑니다.

3단계: 올바른 프레임워크 선택

콘텐츠 사이트, 문서, 마케팅 페이지, 또는 블로그를 빌드하고 있다면 -- Astro 또는 Eleventy로 가세요. 팀이 React를 알기 때문이라고 마케팅 사이트를 위해 Next.js를 선택하지 마세요. 아키텍처 불일치가 성능 비용을 초래합니다.

상당한 클라이언트 측 상호작용이 있는 애플리케이션을 빌드하고 있다면, 선택적 서버 렌더링을 가진 Next.js 또는 SvelteKit이 더 의미가 있습니다. 가능한 곳에 Server Components를 사용하고 필요한 곳에만 클라이언트 컴포넌트를 사용하세요.

우리는 팀이 정확히 이 결정을 내리도록 돕습니다 -- 우리의 기능을 살펴보거나 특정 상황에 대해 이야기하고 싶으면 연락하세요.

4단계: JavaScript 없이 테스트

이것은 모두가 건너뛰는 단계입니다. 브라우저에서 JavaScript를 비활성화하고 사이트를 탐색하세요. 이것이 작동합니까? 사용자가 다음을 할 수 있습니까:

  • 콘텐츠를 읽습니까? ✓
  • 페이지 간 탐색? ✓
  • 폼을 제출합니까? ✓
  • 중요한 정보에 접근? ✓

그렇지 않으면, 당신의 enhancement 전략에 구멍이 있습니다.

Zero-JS 사이트의 실제 아키텍처

우리가 여러 클라이언트 프로젝트에 사용한 구체적인 아키텍처를 공유하겠습니다:

┌─────────────────────────────────────────┐
│              CDN (Cloudflare)            │
│         정적 HTML/CSS 자산            │
├─────────────────────────────────────────┤
│          Astro SSG / SSR 레이어      │
│     빌드/요청에서 콘텐츠를 가져옴    │
├─────────────────────────────────────────┤
│            Headless CMS                 │
│    (Sanity / Storyblok / Payload)       │
├─────────────────────────────────────────┤
│          폼 핸들러 서비스            │
│     (Cloudflare Workers / Resend)       │
└─────────────────────────────────────────┘

콘텐츠는 headless CMS에 있습니다. Astro는 빌드 타임에 (또는 자주 업데이트되는 콘텐츠의 경우 요청 타임에) 이를 가져옵니다. 출력은 순수 HTML과 CSS이며 CDN 엣지에 배포됩니다. 폼은 유효성 검사를 처리하고 이메일 전달을 하는 서버리스 함수로 제출됩니다.

전체 프런트엔드는 zero JavaScript를 가집니다. CMS는 콘텐츠 편집자에게 좋은 경험을 제공합니다. 폼은 클라이언트 측 코드 없이 작동합니다. 페이지 전환은 cross-document View Transitions를 사용합니다. 이것은 빠르고, 접근 가능하며, 탄력적입니다.

선택적 상호작용이 필요한 사이트의 경우 -- 한 페이지에 제품 구성기를 말합니다 -- 우리는 Astro의 island 아키텍처를 사용하여 단지 그 컴포넌트만 hydrate합니다. 나머지 사이트는 정적으로 유지됩니다.

이것은 우리가 정기적으로 빌드하는 종류의 아키텍처입니다. 이 접근에 대한 가격책정이 궁금하다면, 우리의 가격 페이지를 확인하세요 -- zero-JS 사이트는 일반적으로 빌드 및 호스팅이 더 빠르고 저렴합니다.

FAQ

Progressive enhancement는 2026년에 여전히 관련성이 있습니까?

이전보다 더 관련성이 있습니다. Popover API, CSS :has(), View Transitions, 그리고 <dialog>에 대한 95%+ 브라우저 지원으로, 웹 플랫폼은 이전에 JavaScript를 요구하는 상호작용을 처리할 수 있습니다. Progressive enhancement는 과거의 철학이 아닙니다 -- 더 빠르고 탄력적이며 접근 가능한 웹사이트로 인한 실용적인 엔지니어링 전략입니다.

Zero JavaScript로 전체 웹사이트를 빌드할 수 있습니까?

절대적으로. 마케팅 사이트, 블로그, 문서, 포트폴리오, 그리고 심지어 e-커머스 상점도 zero 클라이언트 측 JavaScript로 빌드될 수 있습니다. 폼은 기본적으로 제출되고, 네비게이션은 표준 링크를 사용하며 (polish를 위한 View Transitions), accordion, 모달, tooltip과 같은 상호작용 컴포넌트는 모두 HTML/CSS 네이티브 솔루션을 가집니다. 당신이 JS 없이 빌드할 수 없는 사이트는 실시간 앱, rich text 편집기, 그리고 복잡한 데이터 시각화입니다.

Zero JavaScript는 SEO에 어떻게 영향을 미칩니까?

거의 모든 경우에서 긍정적으로. 검색 엔진은 JavaScript 실행을 기다리지 않고 즉시 HTML 콘텐츠를 인덱싱할 수 있습니다. Core Web Vitals 점수는 극적으로 개선됩니다 -- 특히 Total Blocking Time은 0으로 떨어집니다. Google의 순위 시스템은 빠르고 접근 가능한 페이지를 보상하며, zero-JS 사이트는 일관되게 더 높은 Lighthouse 점수와 더 나은 CWV 통과율을 달성합니다.

2026년에 zero-JavaScript 웹사이트를 위한 최고의 프레임워크는 무엇입니까?

대부분의 zero-JS 프로젝트를 위해 Astro가 가장 강합니다. 기본적으로 zero JavaScript를 출력하고 필요한 경우 컴포넌트당 클라이언트 측 상호작용을 추가하도록 합니다. Eleventy는 더 간단한 사이트에 또 다른 탁월한 옵션입니다. 둘 사이의 선택은 일반적으로 당신이 컴포넌트 기반 작성 (Astro) 또는 템플릿 기반 단순성 (Eleventy)을 원하는지에 따라 내려옵니다.

CSS 전용 상호작용 컴포넌트는 접근성을 위해 작동합니까?

<details>, <dialog>, 그리고 Popover API와 같은 기본 HTML 요소는 기본적으로 접근 가능합니다 -- 포커스 관리, 키보드 네비게이션, 그리고 ARIA 의미를 자동으로 처리합니다. CSS 전용 패턴 checkbox hacks을 사용하는 더 많은 관리가 필요합니다: 적절한 ARIA 역할을 추가하고 키보드 조작 가능성을 보장해야 합니다. 일반적으로, 기본 HTML 솔루션이 더 접근 가능합니다. 브라우저 공급자가 당신을 위해 접근성 작업을 했기 때문입니다.

View Transitions는 JavaScript 없이 어떻게 작동합니까?

Cross-document View Transitions (스펙 Level 2)는 완전히 CSS를 통해 작동합니다. @view-transition { navigation: auto; } 규칙을 추가하고, 브라우저는 페이지 네비게이션 간에 자동으로 애니메이션 전환을 생성합니다. ::view-transition-old()과 ::view-transition-new() 의사 요소로 애니메이션을 커스터마이징할 수 있습니다. JavaScript 필요 없음. Chrome, Edge, 그리고 Safari는 2026년에 이를 지원하며, Firefox 지원은 곧 예상됩니다.

JavaScript를 비활성화한 사용자의 몇 퍼센트입니까?

약 1-2%의 사용자만 JavaScript를 적극적으로 비활성화합니다. 하지만 그것이 요점이 아닙니다. JavaScript는 그것보다 훨씬 더 많은 사용자에게 실패합니다 -- 불안정한 연결, 회사 방화벽, 브라우저 확장, CDN 중단, 그리고 파싱 오류가 모두 JS 실패를 야기합니다. UK Government Digital Service는 JS가 활성화되었음에도 불구하고 1.1%의 사용자가 JavaScript enhancements을 얻지 못했다는 것을 발견했습니다. Progressive enhancement는 이 모든 사용자를 보호합니다.

headless CMS를 zero-JavaScript 프런트엔드와 함께 사용할 수 있습니까?

예, 그리고 이것은 최고의 조합 중 하나입니다. CMS는 콘텐츠 팀에 풍부한 편집 경험을 제공하고, 프런트엔드 (Astro 또는 Eleventy로 빌드됨)는 빌드 타임에 API를 통해 콘텐츠를 소비하고 순수 HTML/CSS를 출력합니다. CMS JavaScript는 편집자의 브라우저에서 실행되며, 방문자의 브라우저에서는 실행되지 않습니다. 이 분리는 최고를 모두 제공합니다: 좋은 작성 경험과 최종 사용자를 위한 zero-JS 성능.