DOM 템플릿 API를 도입할 적기임

• 웹 플랫폼에는 현재 개발자들이 꼭 필요로 하는 선언적 템플릿 API가 부족함
• 대부분의 현대 웹 프레임워크에서는 템플레이팅이 핵심 기술이지만, 표준 DOM API에는 안전하고 효율적인 템플릿 생성·업데이트 방법이 없음
• 이로 인해 사용자와 개발자, 프레임워크, 심지어 플랫폼 차원에서 모두 불편과 성능 저하 문제 발생함
• 템플릿 API를 도입할 시점으로, 최근 프레임워크 경험과 자바스크립트 기능이 충분히 축적되어 구현 및 표준화가 더 실용적임
• 템플릿 식별성, 시그널 기반 반응성 등 다양한 모델을 종합해, 차세대 템플릿 API의 방향성이 제시됨

제안 요약

• 이 글은 웹 플랫폼에 선언적 템플릿 API를 추가할 것을 제안하는 배경과 필요성에 대해 설명함
• DOM API는 강력하지만, 표준 DOM에서는 데이터를 바탕으로 안전하고 효율적으로 여러 노드를 생성·업데이트할 템플릿 API가 부재함
• React, Vue, Angular 등 주요 프레임워크는 모두 선언적 템플레이팅이 핵심이며, 개발 생산성과 보안, 성능, 정적 분석, 서버 사이드 렌더링 등 여러 이점 제공함
• 템플릿 API 부재로 인해 사용자, 개발자, 프레임워크, 그리고 플랫폼 모두가 불필요한 복잡성, 보안 위협, 성능 저하, 진입 장벽 등을 겪음
• 지금이 API를 도입할 적기임을 주장하며, 기존 프레임워크 경험과 현대 자바스크립트 기능을 활용하여 점진적 표준화를 제안함

템플릿의 필요성 및 현재 문제

• DOM API는 웹 플랫폼의 동적 기능을 이끄는 기반임
• 하지만 표준 DOM에는 데이터로부터 DOM 트리를 안전하게 정의하고 효율적으로 업데이트하는 선언적 템플릿 방법이 없음
• 현대 웹 프레임워크(React, Vue, Angular, Svelte 등)는 모두 선언적 템플레이팅을 제공함
• 선언적 템플레이팅이 인기 있는 이유는 다음과 같음
  • 명령형 API 대비 더 나은 사용성과 가독성 제공
  • XSS 보안 강화. 템플릿 내부 데이터 자동 이스케이프
  • 효율적이고 빠른 렌더링 성능
  • 정적 분석, 타입체크, 인텔리센스 등 개발 생산성 증대
  • 서버 사이드 렌더링 지원

현재 상황의 문제점

• 사용자: 라이브러리 다운로드 및 렌더링 지연으로 초기 로딩이 느려짐. 클라이언트 코드 크기 증가로 UX 악화
• 개발자: 템플릿 사용을 위해 별도 라이브러리(npm, CDN 등) 필요. 진입 장벽, 비표준 적재
• 프레임워크: 템플릿 엔진 직접 구현 필요. 성능, 기능, 코드크기 간 무거운 트레이드오프 존재
• 플랫폼: 네이티브 앱과의 경쟁에서 불리. Flutter, SwiftUI 등은 내장 템플릿 시스템 제공

지금이 적기인 이유

• 과거 템플릿 관련 시도(E4X, E4H, html 템플릿 리터럴 등)는 실패했으나, 당시에는 DOM 업데이트에 약점이 있었음
• 최근 프레임워크와 커뮤니티에서 템플릿 API의 베스트 프랙티스가 충분히 축적됨
• 자바스크립트 기반 API 제안 가능. 현재 표준 JS에선 태그드 템플릿 리터럴이 이미 존재
• 바닐라 JS 개발자와 웹 컴포넌트 커뮤니티에서도 편리한 DOM 조작 수요가 지속해서 증가함
• DOM Parts 등 저수준 원시 제안도 병행 중이나, 고수준 선언적 API가 더 큰 효용과 발전 방향 제시 가능

좋은 템플릿 문법의 사례 분석

• 주류 템플릿 시스템(React-JSX, Vue, Svelte, Angular 등)은 말단적으로 매우 유사한 마크업+바인딩 문법 기반임
• JS API 기반 템플릿의 경우, 템플릿 표현식이 DOM 설명을 반환하고, 별도 렌더 함수가 이를 실제 DOM에 반영하는 구조가 일반적임
• E4X 등 구시대 시도는 DOM 자체를 리턴하여 업데이트 모델이 떨어졌음

자바스크립트 기반 템플릿 API 가능성

• 태그드 템플릿 리터럴을 통해, 새로운 JS 기능 도입 없이 템플릿 API 설계 가능
• 이미 JSX-to-Lit 등 여러 실증 사례 보유

JSX 통합 논의

• JSX 표준화는 복잡한 의미 정의 및 런타임 시멘틱스가 필요함. JSX 자체는 문법일 뿐임
• 현행 비표준 JSX는 순수 문법 변환이므로, 향후 표준 템플릿 API가 도입되면 JSX->템플릿 리터럴 변환 컴파일러로 연계 가능
• 추후 진짜 JSX 표준화 시, 템플릿 API에 맞춘 데이터 타입 수용 구조로 전환 용이

HTML 기반 템플릿 API와의 관계

• 많은 개발자와 커뮤니티에서 HTML 템플릿 시스템을 요청함
• 그러나 HTML 기반 시스템은 바인딩, 표현식 언어, 제어문 등 새로운 문법·표현식 설계가 요구되어 훨씬 큰 작업임
• 최근 프레임워크(Lit 등)가 HTML 템플릿에서 JS API로 옮겨온 배경 역시 동일
• 따라서 JS 기반 템플릿 API가 우선적으로 도입되고, 추후 HTML API로 단계적 확장 가능성이 큼

반응성(reactivity) 구현 경험의 성숙

• VDOM diffing(React), 템플릿 식별성(Lit), 신호(fine-grained signals, Solid/Svelte/Vue 등) 등 다양한 반응성 모델이 검증됨
• VDOM 기반은 느린 반면, 템플릿 식별성+ 시그널 모델의 조합은 빠르고 효율, 설명력도 높음
• 시그널 기반은 모든 데이터가 신호로 래핑될 필요 있으나, 일반적인 데이터와 혼용도 가능함

발전 경로와 기대효과

• 제안된 선언적 JS 템플릿 API는 바닐라 JS·웹 컴포넌트·새 프레임워크 모두에 직접적 이점 제공
• 기존 프레임워크에도 컴파일 타겟·런타임 백엔드 또는 직접 지원 API로 활용 가능
• "재렌더링" 방식과 시그널 기반의 반응성 모두 지원
• 차후 HTML 기반 선언형 템플릿, 선언형 커스텀 엘리먼트로의 확장 기반 마련
  • API 범위 좁고 명확, 기존 API(예: DOM Parts)와의 연동도 용이
• 다만 표면상의 API와 문법은 단순하지만, 하부 DOM Parts 및 스케줄러 등 구현 면적은 넓으며, 표준화·테스트 등 협업이 필요함

마무리

• 저자는 GitHub 이슈에서 본 제안을 논의 중이며, 플랫폼 엔지니어 등 커뮤니티의 참여를 요청함