잘못된 Pretext 데모를 보고 있습니다

getBoundingClientRect, offsetHeight, clientWidth 같은 API는 브라우저가 즉시 최신 레이아웃을 계산 하도록 강요합니다. 가상 리스트에서 500번 호출하면 500번의 동기 reflow가 프레임을 먹습니다(layout thrashing). Pretext는 DOM에 묻지 않고 캔버스 측정값으로 답해 이 멈춤을 0으로 만듭니다.

// 전형적 layout thrashing
items.forEach(el => {
  const h = el.getBoundingClientRect().height; // read
  el.style.top = `${offset}px`;                // write → 다음 read에서 또 reflow
  offset += h;
});

rAF 로 감싸면 read/write 순서는 재배열되지만 reflow 자체는 사라지지 않습니다. Pretext 방식은 DOM read를 아예 제거합니다.

텍스트를 캔버스로 그리면 다음이 모두 멈춥니다.

Pretext는 높이만 수학적으로 예측 하고 실제 텍스트는 DOM에 그대로 두므로 접근성 트리가 온전합니다. CodeMirror·Monaco·ProseMirror 같은 주요 에디터가 캔버스로 가지 않은 이유가 바로 이것입니다.

prepare() 와 layout() 을 분리하는 것이 Pretext의 핵심 설계입니다.

리사이즈·스크롤처럼 자주 발생하는 이벤트는 전부 빠른 경로로 처리되므로 전체 비용이 amortize 됩니다.

const prepared = pretext.prepare(items); // 한 번
window.addEventListener('resize', () => {
  const boxes = pretext.layout(prepared, container.width); // 매 프레임 OK
});

측정이 목표가 되면, 그것은 더 이상 좋은 측정이 아니다. — Goodhart's Law

GitHub 스타와 소셜 임프레션은 '유용함' 의 대리 지표 일 뿐입니다. 이를 목표로 삼으면 시각적으로 인상적인 용 데모가 라이브러리의 정체성을 결정해 버리고, 진짜 가치인 '측정 엔진' 은 '잘 돌아가는 웹페이지처럼 보이기 때문에' 눈에 띄지 않습니다. 평가자에게 측정 가능한 숫자(reflow 횟수, 프레임 예산) 를 기준으로 제시해야 허상의 데모에 휘둘리지 않습니다.

[감점 답변] '고정 높이를 가정한다' 에서 멈추면 감점. [좋은 답변] canvas.measureText 기반 사전 측정 + 단어 경계(Intl.Segmenter)·양방향 텍스트·웹폰트 로드 타이밍 같은 엣지 케이스까지 언급하고, DOM 텍스트를 유지해 접근성을 보존하는 경로(Pretext 방식)를 '500개 ~0.09ms' 같은 구체 수치 와 함께 설명. 트레이드오프로 폰트·letter-spacing·커닝 차이로 측정 오차가 있어 텍스트 CSS를 폭넓게 허용하기 어렵다는 점을 덧붙이면 만점.

[감점 답변] '느려서 안 된다' 같은 사실 오인은 감점. [좋은 답변] 스크린 리더가 캔버스를 건너뛰고, 네이티브 선택·Cmd+F 검색·번역 확장·복사가 사라지며 canvas 가 단일 탭 스톱이 되는 접근성 손실 을 구체적으로 나열. CodeMirror·Monaco·ProseMirror 같은 주요 에디터가 DOM에 남은 이유, 그리고 '측정은 canvas, 렌더는 DOM' 이라는 Pretext 식 절충안을 제시.

[감점 답변] '성능이 느리면 재계산' 수준은 감점. [좋은 답변] 다음 패턴을 구체적으로:

• 루프 안에서 read(getBoundingClientRect/offsetHeight) → write(style/classList) → read 가 섞이는 경우
• ResizeObserver 콜백 내 동기 DOM write
• 스크롤 핸들러에서 측정/수정이 혼재

해결로 rAF 기반 read/write 분리, FastDOM 같은 배치 라이브러리, Pretext 식 사전 측정(아예 DOM read 제거) 을 단계적으로 제시.