이 모든 일은 반십 년 전에 이미 가능했을 것 같음
WebIDL을 WebAssembly에서 지원하려던 초기 목표를 버리고, 또 다른 IDL을 만들겠다고 하면서 DOM 접근 부재를 문제로 보지 않았던 게 아쉬움
물론 시장 현실을 이해하지만, 잃어버린 시간이 아깝다는 생각을 지울 수 없음
관련 참고 링크: commit 기록, stringref 회고, ACM 기사
예전에 interface-types 제안서 작업에 참여했었음
이후 목표가 두 가지 추가되었는데, 하나는 비웹 API 지원, 다른 하나는 언어 간 상호운용성이었음
WebIDL은 JS와 Web API의 합집합이라 표현력은 높지만, 이런 목표와 충돌하는 개념이 많았음
그래서 component interface는 표현력은 줄었지만 훨씬 이식성 높은 교집합 접근법을 택했음
개인적으로 DOM 접근은 중요하다고 생각하지만, Wasm CG가 우선순위 높은 일들로 바빴음
이번 글을 쓴 이유는 아직도 이 문제를 기억하고 있고, 계속 작업할 계획이 있다는 걸 알리고 싶었음
stringref가 다시 돌아오길 정말 바람
WASM의 진입 장벽은 실제로 큼
툴체인과 빌드 과정이 너무 복잡해서, 사용할 때마다 인지적 부담을 느끼고 있음
성능은 glue 없이 훨씬 좋지만, 그만큼 위험 요소도 큼
component 모델이 새로운 복잡성을 도입하지 않길 바라지만, 여러 언어 예시를 보면 이미 꽤 혼란스러움
특히 Go 예시를 보면 생성된 파일이 너무 많고, 개발자 입장에서는 툴링 단순화가 절실함
지금은 복잡성을 없애는 게 아니라 단지 이동시키는 것처럼 보임
아직 툴링이 초기 단계임을 인정함
wasm component 사양이 계속 바뀌면서 churn이 많았음
목표는 웹 개발자가 직접 WIT를 작성하지 않고, Web API를 라이브러리처럼 쓸 수 있게 하는 것임
하지만 아직은 갈 길이 멀음
WebAssembly component 발전은 멋지지만, 웹 API를 작은 표준 단위로 분리할 기회를 놓치고 있다고 느낌
예를 들어 텍스트 공유, 미디어 공유, 애플리케이션 공유 등으로 나누면 보안도 좋아지고, 소규모 팀이 브라우저 대안을 만들 수도 있음
하지만 거대한 웹 API와 CSS의 규모가 브라우저 독점을 지탱하는 요소라 이런 시도는 어려울 듯함
WebAssembly registry를 표준화해 컴포넌트를 쉽게 조합할 수 있게 하면 좋겠음
결국 웹은 분산 운영체제 정의를 만드는 과정임
최신 WebAssembly를 배우고 싶다면 Component Model Book을 추천함
개념부터 코드 예시까지 잘 정리되어 있음
JS 생태계에서는 StarlingMonkey, ComponentizeJS, jco 세 프로젝트가 핵심임
현재 가장 성숙한 툴체인은 Rust지만, LLVM 기반 언어(C/C++, Go, Python 등) 지원도 점점 좋아지고 있음
WebAssembly의 목표는 로컬 툴체인에 자연스럽게 녹아드는 컴파일 타깃이 되는 것임
“first-class”라는 표현이 중요한 이유는 대부분의 개발자가 성능보다 마찰(friction) 때문에 플랫폼을 포기하기 때문임
여전히 언어별 glue 코드나 두 런타임 모델을 이해해야 한다면, WebAssembly는 여전히 “극단적 상황에서만 쓰는 도구”로 남을 것임
진짜 변화를 만들려면, 일반적인 빌드 경로를 단순화해야 함
웹은 동적 기능 감지 없이는 작동하지 않음
Component Model에서 이 부분이 어떻게 처리되는지 불분명함
DOM은 브라우저마다 다르고, 페이지 로드마다 기능이 달라짐
JS 브리지 계층에서는 polyfill을 쉽게 적용할 수 있지만, WIT 인터페이스에서는 런타임 메서드 감지나 polyfill이 어려움
성능 외에도 생태계의 유연성이 중요함
이 글은 “WebAssembly 벽”의 답답함을 잘 표현함
JS glue 코드를 직접 관리하거나 자동 생성 도구에 의존하는 건 큰 후퇴처럼 느껴짐
Dodrio 실험에서 glue를 생략해 45% 오버헤드 감소를 얻은 건 인상적임
다만 WebAssembly Component Model이 Web API와 직접 상호작용할 때 메모리 관리가 어떻게 되는지 궁금함
Wasm GC 제안이 DOM 참조를 유지하는 데 쓰이는지, 아니면 여전히 JS GC에 의존하는지 알고 싶음
Wasm이 진정한 1급 시민으로 자리 잡는 걸 기대함
최근 v8과 Bun의 sendMessage 개선이 이 문제를 완화할 수 있을지 궁금함
하지만 현재 IPC는 여전히 비효율적이며, 메모리 페이지 단위 전송 같은 방식이 필요하다고 생각함
위 댓글들이 LLM이 작성한 것처럼 보인다며, HN 규칙 위반 가능성을 지적함 (가이드라인)
웹은 흥미로운 실험의 연속이었음
아무나 복잡한 프로그램을 내 컴퓨터에서 실행하게 한다는 건 보안상 미친 아이디어였지만, 실제로 그렇게 해왔음
JS 덕분에 20년간 수많은 브라우저 보안 버그를 겪었지만, 이제는 설계 원칙과 완화책이 자리 잡고 있음
그런데 이제 와서 또 다른 위험한 실행 패러다임으로 교체하려는 게 아이러니하면서도 아름다움
사실 이런 역할은 운영체제(OS) 가 해야 하는 일임
모바일 OS는 데스크톱보다 훨씬 잘 해내고 있음
JS 자체가 아니라 브라우저 API가 보안 문제의 주범이었음
“교체”되는 건 없고, 단지 확장되는 것뿐임
WASM이 JS보다 위험한 이유가 궁금함
WebUSB처럼 샌드박스를 깨는 기능이 문제이지, wasm 자체는 그렇지 않다고 생각함
요즘 새 표준들은 단순함보다 복잡한 JS 보일러플레이트를 우선시함
엔지니어 중심으로 설계되어 있고, 저자(author) 친화적인 기본 워크플로우가 없음
그래도 이런 문제를 신경 쓰는 사람들이 남아 있어서 다행임
개인적으로는 여전히 좋은 아이디어가 아니라고 생각함 (이전 논의)
DOM API를 1:1로 매핑하기 위해 2배 빠른 문자열 처리만을 위해 과도한 엔지니어링을 하는 느낌임
WebGL2, WebGPU, WebAudio 같은 API에서는 JS shim의 비용이 이미 미미함
진짜 문제는 GPU 버퍼 복사 같은 부분인데, component model이 거기엔 도움이 안 됨
WebGL2나 WebGPU에서 수만 번의 draw call을 테스트한 벤치마크를 보고 싶음
일부 케이스에서는 큰 향상이 없겠지만, DOM 성능은 여전히 많은 앱의 병목임
성능 외에도 개발자 경험(DX) 개선이 중요함
지금은 시작하기 너무 어렵고, 모든 사람이 전문가가 되어야만 이점을 얻을 수 있음
단순히 2배 빠른 문자열 처리뿐 아니라, glue 코드가 필요 없다는 점이 가장 큰 이점임
WebAssembly가 모바일 OS의 폐쇄성에 대한 대안이 될 수 있음
네이티브 앱 수준의 효율로 경쟁할 수 있다면, 웹의 미래를 위한 비전 있는 변화임
DOM 접근만 빨라져도 충분히 큰 의미가 있음
component model은 불필요한 자기 일거리 만들기처럼 보임 코딩 에이전트 시대에는 그들이 말하는 DX 개선이 더 이상 중요하지 않음
Hacker News 의견들
WebIDL을 WebAssembly에서 지원하려던 초기 목표를 버리고, 또 다른 IDL을 만들겠다고 하면서 DOM 접근 부재를 문제로 보지 않았던 게 아쉬움
물론 시장 현실을 이해하지만, 잃어버린 시간이 아깝다는 생각을 지울 수 없음
관련 참고 링크: commit 기록, stringref 회고, ACM 기사
이후 목표가 두 가지 추가되었는데, 하나는 비웹 API 지원, 다른 하나는 언어 간 상호운용성이었음
WebIDL은 JS와 Web API의 합집합이라 표현력은 높지만, 이런 목표와 충돌하는 개념이 많았음
그래서 component interface는 표현력은 줄었지만 훨씬 이식성 높은 교집합 접근법을 택했음
개인적으로 DOM 접근은 중요하다고 생각하지만, Wasm CG가 우선순위 높은 일들로 바빴음
이번 글을 쓴 이유는 아직도 이 문제를 기억하고 있고, 계속 작업할 계획이 있다는 걸 알리고 싶었음
툴체인과 빌드 과정이 너무 복잡해서, 사용할 때마다 인지적 부담을 느끼고 있음
성능은 glue 없이 훨씬 좋지만, 그만큼 위험 요소도 큼
component 모델이 새로운 복잡성을 도입하지 않길 바라지만, 여러 언어 예시를 보면 이미 꽤 혼란스러움
특히 Go 예시를 보면 생성된 파일이 너무 많고, 개발자 입장에서는 툴링 단순화가 절실함
지금은 복잡성을 없애는 게 아니라 단지 이동시키는 것처럼 보임
wasm component 사양이 계속 바뀌면서 churn이 많았음
목표는 웹 개발자가 직접 WIT를 작성하지 않고, Web API를 라이브러리처럼 쓸 수 있게 하는 것임
하지만 아직은 갈 길이 멀음
예를 들어 텍스트 공유, 미디어 공유, 애플리케이션 공유 등으로 나누면 보안도 좋아지고, 소규모 팀이 브라우저 대안을 만들 수도 있음
하지만 거대한 웹 API와 CSS의 규모가 브라우저 독점을 지탱하는 요소라 이런 시도는 어려울 듯함
WebAssembly registry를 표준화해 컴포넌트를 쉽게 조합할 수 있게 하면 좋겠음
결국 웹은 분산 운영체제 정의를 만드는 과정임
개념부터 코드 예시까지 잘 정리되어 있음
JS 생태계에서는 StarlingMonkey, ComponentizeJS, jco 세 프로젝트가 핵심임
현재 가장 성숙한 툴체인은 Rust지만, LLVM 기반 언어(C/C++, Go, Python 등) 지원도 점점 좋아지고 있음
WebAssembly의 목표는 로컬 툴체인에 자연스럽게 녹아드는 컴파일 타깃이 되는 것임
여전히 언어별 glue 코드나 두 런타임 모델을 이해해야 한다면, WebAssembly는 여전히 “극단적 상황에서만 쓰는 도구”로 남을 것임
진짜 변화를 만들려면, 일반적인 빌드 경로를 단순화해야 함
Component Model에서 이 부분이 어떻게 처리되는지 불분명함
DOM은 브라우저마다 다르고, 페이지 로드마다 기능이 달라짐
JS 브리지 계층에서는 polyfill을 쉽게 적용할 수 있지만, WIT 인터페이스에서는 런타임 메서드 감지나 polyfill이 어려움
성능 외에도 생태계의 유연성이 중요함
JS glue 코드를 직접 관리하거나 자동 생성 도구에 의존하는 건 큰 후퇴처럼 느껴짐
Dodrio 실험에서 glue를 생략해 45% 오버헤드 감소를 얻은 건 인상적임
다만 WebAssembly Component Model이 Web API와 직접 상호작용할 때 메모리 관리가 어떻게 되는지 궁금함
Wasm GC 제안이 DOM 참조를 유지하는 데 쓰이는지, 아니면 여전히 JS GC에 의존하는지 알고 싶음
Wasm이 진정한 1급 시민으로 자리 잡는 걸 기대함
하지만 현재 IPC는 여전히 비효율적이며, 메모리 페이지 단위 전송 같은 방식이 필요하다고 생각함
아무나 복잡한 프로그램을 내 컴퓨터에서 실행하게 한다는 건 보안상 미친 아이디어였지만, 실제로 그렇게 해왔음
JS 덕분에 20년간 수많은 브라우저 보안 버그를 겪었지만, 이제는 설계 원칙과 완화책이 자리 잡고 있음
그런데 이제 와서 또 다른 위험한 실행 패러다임으로 교체하려는 게 아이러니하면서도 아름다움
모바일 OS는 데스크톱보다 훨씬 잘 해내고 있음
엔지니어 중심으로 설계되어 있고, 저자(author) 친화적인 기본 워크플로우가 없음
그래도 이런 문제를 신경 쓰는 사람들이 남아 있어서 다행임
DOM API를 1:1로 매핑하기 위해 2배 빠른 문자열 처리만을 위해 과도한 엔지니어링을 하는 느낌임
WebGL2, WebGPU, WebAudio 같은 API에서는 JS shim의 비용이 이미 미미함
진짜 문제는 GPU 버퍼 복사 같은 부분인데, component model이 거기엔 도움이 안 됨
WebGL2나 WebGPU에서 수만 번의 draw call을 테스트한 벤치마크를 보고 싶음
성능 외에도 개발자 경험(DX) 개선이 중요함
지금은 시작하기 너무 어렵고, 모든 사람이 전문가가 되어야만 이점을 얻을 수 있음
네이티브 앱 수준의 효율로 경쟁할 수 있다면, 웹의 미래를 위한 비전 있는 변화임
코딩 에이전트 시대에는 그들이 말하는 DX 개선이 더 이상 중요하지 않음