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 이슈에서 본 제안을 논의 중이며, 플랫폼 엔지니어 등 커뮤니티의 참여를 요청함

[GN⁺]

Hacker News 의견

• "좋은 템플릿 문법을 우리가 안다"는 말에 웃음이 나오는 이유는, 실제로는 그 기준조차 제대로 합의된 적이 없다는 생각임. 템플릿은 기호적(symbolic)인 관점보다 시각적(visual)인 경험이 더 중요하다고 생각함. 예전 Dreamweaver와 같은 도구가 그토록 성공했던 것도 이 때문임. 많은 디자이너들이 Photoshop 같은 툴로 배움을 시작하는 것도 같은 맥락임. 지금 이 시도가 XSLT를 다시 만들려는 시도 같아서 아쉬움이 있음. 잘 만들어지지 않은 구조물을 잘 만들어진 결과로 합치는 게 템플릿팅의 본질 문제임. 더 나아가, 'label'과 'for'처럼 연결은 돼 있지만 같은 트리에 속하지 않은 엔티티를 표현하는 문제가 있음. 내가 마법을 부릴 수 있다면, 굳이 표준 문서 레이아웃에 기이하게 모든 걸 맞추려 하지 않기를 바람. 절대 위치(absolute positioning)를 잘만 써도 많은 UI 문제를 효율적으로 해결할 수 있는데, 왜 이렇게 반복적으로 수학적 연산까지 모두 기계에 강제로 맡기려 하는지 의문임

  • XSLT를 다시 만들려고 한다는 것에 공감함. XML 자체는 좋아하지 않았지만 XSLT는 정말 강력한 존재였음. 브라우저에서도 아직 널리 지원되는 기능임. XML이 설정(Configuration)이나 IPC 등에서는 단점이 두드러졌지만, 뛰어난 마크업 언어에 XSLT의 변환력이 더해지는 부분에서는 오히려 제대로 활용되지 못했다는 점이 아쉬움. XSLT가 대중화되지 못한 건 진짜 선언적이고 함수형인 DSL이라서임. 많은 사람이 DSL에 대해 긍정적으로 얘기하지만, 실제로는 인기 있는 언어의 절차적 의미만 얇게 감싼 수준인 경우가 많음. 잘 설계된 DSL로 복잡한 일을 간단히 처리할 수 있는데, 공부하려는 노력이 부족하다고 생각함

  • 제대로 된 템플릿 문법이라는 게 시각성이 핵심이라고 말하는데, 이런 결론에 이르게 된 이유를 알고 싶음. 내 생각에는 HTML+CSS 자체, 즉 생성 방식에 대한 불만처럼 들림. 절대 위치 언급한 이유도 궁금함. 절대 위치는 분명 쓸 자리에서는 유용하지만, 전체 레이아웃을 위해 쓸 때는 오히려 관리가 어렵고 화면 크기나 콘텐츠 양에 따라 쉽게 망가짐. 신문 레이아웃도 실제로는 문자와 타이포그래피의 미묘한 요소가 많아서 절대 위치만으로 해결이 불가함. CSS를 깊이 다룰 때 절대 위치로 시작된 레이아웃을 나중에 flex나 flow로 재구성하는 게 오히려 빠르고 쉽게 문제를 해결한 경험이 많음. calc()와 viewport 단위를 잘 쓰면 의미를 찾을 수 있지만, 실제로는 완전히 고정된 콘텐츠나 뷰포트가 아니라면 절대 위치는 적합하지 않음

  • 사람들이 절대 위치를 잘 활용하면 쉽고 빠르게 구현할 수 있는 걸 너무 복잡하게 돌아가서 결국은 같은 효과를 내려고 한다는 이야기를 봤는데, 웹에서는 모든 디바이스의 크기, 방향, 성능에 따라 문서가 좋아 보여야 하는 요구 사항이 있음. 일반 앱(윈도우 앱 등)은 이런 고민이 없고, 모바일 앱도 표준화된 화면 크기만 고려하면 됨. 오직 웹만이 이 모든 걸 다뤄야 하는 특성이 있음

  • "좋은 템플릿 문법"에 비꼬듯 반응하는 건 진보를 주장하는 사람에게 크게 예의 있는 태도는 아니라는 생각임. 그리고 지금은 좋은 템플릿 문법이 있다고 생각함, 바로 jsx가 대표적임. 나는 React의 팬이 아니지만, jsx가 웹 개발에 혁신을 일으켰고, 대부분의 js 템플릿 시스템이 "표현식으로서의 템플릿", "중첩을 통한 조합", 자바스크립트로 제어 흐름을 다루는 구조로 거의 수렴했다고 생각함

  • React와 Svelte는 표면상으로만 닮아 있을 뿐, 실제 동작 방식은 꽤 다름. React는 (거의) 평범한 자바스크립트 함수가 JSX 형태의 지연(lazy) 마크업을 반환하는 것이 핵심임. 루프나 조건부 렌더링에 대한 템플릿 자체 구문이 없고, 전부 일반 자바스크립트로 처리하는 점이 주요 차이점임

• API와 ABI(애플리케이션 이진 인터페이스)는 절대 최종적이지 않다는 점을 반복적으로 배움. 앱의 요구는 고정되지 않고, 시간에 따라 계속 바뀌므로 영원히 쓸 수 있는 완벽한 API는 존재하지 않음. 이번 제안이 좋은 예시임. 문제를 우선 사용자 라이브러리(React 등)가 해결하다가, 결국 표준으로 내려올 때가 됨. Polyfill도 마찬가지 패턴임. 이런 제안이 성공해도, 결국 구형 기술이 되고, 사람들은 이를 우회하려 새로운 방법을 만듦. DOM API, ECMA, 구형 브라우저 등도 같은 운명임. 기술적인 엔트로피, 확장성, 그리고 하위 호환성 자체를 표준 사용 사례로 생각할 수 있을지 고민하게 됨

  • 웹 표준의 새로운 기능 추가는 결국 유지 관리에 엄청난 코드 부담이 생기고, 표준을 따르는 브라우저를 만들 때도 구현해야 할 코드가 계속 늘어남. Servo 같은 프로젝트가 조금이라도 따라잡으려 할 때 늘 확장만 따라가야 하는 상황이 반복됨. 웹 플랫폼이 네이티브 환경의 모든 기능을 가질 수 있길 바람(프라이버시와 샌드박스 제약 내에서). 개발자의 경험이 우수해지는 것도 원함. 하지만 이런 꿈을 실현하려면 복잡성 증가라는 대가를 고민해야 함. 이번에 논의 중인 네이티브 템플릿팅이 정말 개발자 경험을 확실히 올려줄지 의문임

  • 하위 호환성을 유지하고 인터페이스를 바꾸지 않는다면 버전 관리가 그 역할을 하는 것 아닌지 질문함

  • 오래되면 우회하거나 패치하는 상황이 반복된다는 주장이지만, 그 과정에서 기반 기능이 한 단계 올라가는 긍정적 효과도 있음. 점진적 업데이트는 유저 요구가 계속 새로운 빈틈과 사용 사례를 발견하더라도 충분히 가치 있음

  • "API와 ABI는 영원히 안정적이지 않다"는 주장에 동의하지 않음. 예를 들어 getElementById는 25년 넘게 안정적으로 유지되고 있음. 불변의 API가 불가능하다는 건 개인적 체념에 가깝고, 세상에는 수많은 예외가 있음. 수요는 끝이 없으니, 새 API를 추가하면 됨. 작동 중인 API를 깨뜨릴 필요 없음

  • 웹에서는 한 번 공개된 API라면 그 형식을 그대로 평생 의존하는 사용자가 있게 됨. 그래서 20년 전 결정의 여진이 아직도 이어지는 경우가 있음. 예를 들면 "smooshgate"와 같은 사례에서 확인할 수 있음

• 리액티브 프로그래밍 유행을 언급하며, 사용자 레벨(system)이 이 영역을 충분히 시도했고, 이제는 다양한 접근법의 장점만 모아 진짜 표준 시스템을 만들 수 있다고 주장함. 하지만 Ryan Carniato/Solid JS 같은 곳에서는 여전히 신호(signals)를 활용한 새로운 가능성을 탐색하고 있어서 아직 탐험이 끝난 건 아니라 생각함. 더 발전할 여지가 충분함

• 웹에 네이티브 템플릿, 리액티비티, 데이터 바인딩이 정말 필요함. 전세계 수십억 사용자가 React 등 무거운 프레임워크를 다운받고, 파싱하며, 실행하는 데 쓰는 CPU와 대역폭 낭비가 상상 초월임

  • LLM과 암호화 연산의 엄청난 자원 낭비와 비교하면, 이런 낭비는 별거 아니라고 느끼게 됨

  • TC39에서 signals 관련 proposal이 나오고 있는데, 이 덕분에 한 걸음 더 나아가고 있음

  • 실제로 개발에 필요한 건 양방향 데이터 바인딩과 jsx 클론 정도면 충분함

  • React는 템플릿 시스템이 아님

• 웹 표준에 고수준 템플릿 시스템을 도입하는 논의를 지켜보며, 오히려 먼저 제공해야 할 것은 브라우저 내장 저수준 API라고 생각함. 모두가 표준 템플릿 시스템에 동의하는 건 거의 불가능에 가까움. 반면 브라우저가 DOM에 diff를 적용하는 저수준 API를 제공해주면 됨. 예를 들면 다음과 같은 메소드가 네이티브로 있으면 좋겠음: element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' }). 이렇게 diff를 적용하면 현재 element의 포커스, input 값, 오디오/비디오 상태 등을 보존하면서 비파괴적으로 갱신 가능함. Idiomorph 같은 js 라이브러리가 있으나, 네이티브 솔루션은 훨씬 빠를 가능성이 높음

  • 기사에 DOM parts proposal이 링크되어 있음. 이 제안은 저수준 API로 쓸모가 큼. VDOM 기반 프레임워크에는 잘 안 맞을 수 있지만, 그 외 프레임워크에서는 구현을 단순하게 하고, 최적화 여지도 넓어짐. signals proposal까지 적용된다면, 프레임워크 없이도 활용성이 높음

• 이번 글의 저자는 관련 분야에서 최고 수준의 경험자라고 소개됨. Lit, Polymer, 구글의 web components, 여러 핵심 DOM 스펙에 크게 기여한 인물임

  • 그러나 그 사람이 밀어붙인 수많은 스펙이 오히려 문제를 더 많이 만든다는 비판이 있음. 완전히 다듬어지지 않은 얕은 해결책을 위해 20개 이상의 웹 스펙이 필요하게 만들었고, 이미 유저랜드에서 가능하던 일을 너무 복잡한 방식으로 표준화했다는 시각임. 게다가 15년 전부터 Safari는 선언형 방식의 필요성을 주장했지만 무시당했다고 언급함

• JSX 방식 대신, Kotlin이 receiver와 builder를 활용해 DSL을 일반화한 것 같은 문법 접근을 원함. 이런 방식은 단순 HTML 템플릿을 넘어 다양한 컴포넌트 계층, 설정(config), 다양한 상황에서 아주 유용해질 수 있음. 템플릿팅과 데이터 바인딩의 실제 의미는 결국 이런 문법적 기능을 활용하는 표준 함수 세트에 불과하며, 이는 Jetpack Compose와 유사함

  • 꼭 필요한 기능은 몇 개뿐임: 반복(loop), 속성 조건부, 노드 조건부 등. 사실 이런 구조만 있으면 언어를 넘나드는 활용도 가능함

• 선언적(Declarative) 템플릿팅이 jQuery보다 나은지 항상 확신이 생기진 않음. React를 거의 10년간 쓰고 있지만, 내 SPA가 복잡해질수록 DOM의 명령형(imperative) 제어가 그리워짐. DOM의 추상화가 새어나오고(leaky abstraction), 결국 단순한 "마지막 기록이 이김(last-write-wins)" 같은 패턴이 오히려 더 명확함. 선언형 템플릿이 이런 문제를 해결한다지만, 컴포넌트 간에 mutable한 상태를 공유하기 시작하면 한계가 너무 빨리 드러남

  • 이 느낌은 React 쪽 개발자가 DOM API 직접 호출을 죄악시해서 생기는 부분도 있음. ref를 적극적으로 쓰거나 id로 컴포넌트를 직접 찾고 조작하는 것도 괜찮음. 실제로 빠르고 리렌더가 적은 form 라이브러리 등은 이렇게 동작함

  • 나는 React를 좋아하진 않지만, 선언형 DOM에서 벗어나 innerHTML, ref 등을 쓰는 데 장벽이 없다고 생각함. 명령형 제어로 가능하지만, 실용적으로 선언형에서 못할 일은 많지 않음. attachShadow()나 showModal()도, 10줄 정도만 추가하면 선언형으로 쉽게 래핑 가능함

• Records와 Tuples proposal이 진전됐다면, JSX가 해당 구조를 활용해 새로운 의미론을 가질 수 있었을 텐데, 실제로는 그 proposal이 멈춘 수준이 아니라 완전히 철회됨(issue 참고). 대신 composites proposal로 대체됨

• 이런 고수준 기능 표준화 논의는 중단해야 한다고 생각함. 대신 하위 레벨 특성을 확장해, 상위 라이브러리 구현에 더 가치가 있는 방향으로 집중하는 게 좋음. 표준 제안이 라이브러리보다 분명한 장점이 없으면 의미가 없음. 라이브러리로 최소 5~10년 이상 널리 검증된 경우에만 표준화 논의를 시작해야 한다고 생각함