Hacker News 의견들

• 나는 Wasm이 만들어질 때의 목표를 대부분 달성했다고 생각함
  개인적으로 수십 개의 프로젝트에서 Wasm을 핵심 구성요소로 사용했음
  JS 엔진이 매우 빠르지만, Wasm은 여전히 CPU 제어 수준이 높고 성능이 탁월함
  다만 JS+HTML+CSS를 완전히 대체할 것이라는 기대에는 미치지 못했음. DOM 바인딩 부재가 큰 이유라고 봄
  Yew 같은 Wasm 프레임워크도 써봤지만 JS 위에 덧붙인 어색한 레이어처럼 느껴졌음
  Blazor는 아직 안 써봤지만, 나는 여전히 JS로 작성하는 게 더 편함
  그래도 Wasm은 조용히 많은 곳에서 돌아가고 있으며, 그게 진정한 성공의 증거라고 생각함

  • 글이 Wasm을 앱 프레임워크처럼 평가한 것 같지만, 사실 Wasm은 CPU 최적화와 네이티브 코드 재사용을 위한 기술임
    예를 들어 브라우저에서 오디오 속도 조절 기능은 C++ 라이브러리를 Wasm으로 돌려야만 가능한 수준의 성능을 냄
  • 문제는 “근본적인 다른 이유”가 아니라, 확실히 DOM 접근 성능 부족 때문임
    제대로 된 DOM 바인딩만 생기면 JS는 10년 안에 프론트엔드에서 밀려날 것임
  • Blazor WASM은 현재 가능한 Wasm 활용 중 가장 완성도 높은 접근 중 하나임
    C#은 백엔드와 프론트엔드 코드 공유가 쉽고, Razor 템플릿도 IDE 지원이 좋음
    하지만 .NET CLR과 BCL을 통째로 실어야 해서 번들 크기가 큼
    DOM 접근이 어려워 Blazor는 JS 쪽에 작은 Virtual DOM 렌더러를 두는 구조임
    성능은 괜찮지만, 직접 작성한 JS보다는 여전히 느림
    F# 기반의 Bolero도 흥미롭지만 팀 설득은 어려움
  • 나는 처음부터 Wasm으로 전체 웹앱을 만드는 건 비현실적이라 생각했음
    DOM과 상호작용하려면 그에 맞는 고수준 언어가 필요함
    JS는 그 역할을 잘하고 있고, HTML/CSS/JS 조합은 이미 UI 개발의 공용어가 되었음
    브라우저 렌더링을 버리고 캔버스 기반으로 가는 시도도 있지만, 여전히 틈새 영역임
  • JS를 완전히 대체하지 못한 게 오히려 다행이라 생각함
    단순한 웹사이트조차 수 MB짜리 런타임을 내려받아야 하는 세상은 끔찍함
    실제 느림의 원인은 JS가 아니라 DOM임. 결국 DOM과 상호작용해야 하니까

• 나는 몇 년간 WebAssembly로 일했고, 곧 Wasm 기반 프레임워크를 공개할 예정임
  생태계가 빠르게 발전하다가 갑자기 느려지면서 WASI와 Component Model 도입이 혼란을 초래했음
  엔진마다 지원 수준이 달라 문서와 코드, 이슈를 전전해야 하는 상황이 많음
  가장 큰 문제는 JS/TS 지원임. 현재는 해킹에 가까운 통합 방식이라 안정적이지 않음
  Web Containers가 개선을 가져왔지만, 이미 많은 개발자가 Bun으로 이동했음

  • JS/TS 지원이 구체적으로 무엇을 의미하는지 궁금하다는 질문이 있었음

• Wasm의 잠재력은 엄청남
  이론적으로는 모든 플랫폼의 공통 컴파일 타깃이 될 수 있음
  하지만 현실은 Figma의 일부 기능을 빠르게 만드는 수준이라 다소 실망스러움
  위원회 중심의 개발 구조라 속도가 느린 것도 한계임

  • 잠재력만 이야기할 때가 아니라 결과를 보여줘야 함
    Native Client 시절엔 네이티브 속도의 앱이 가능했는데, 지금 Wasm은 그보다 느림
    JS 바인딩 구조를 Wasm에도 적용할 수 있었을 텐데 아쉬움
    게다가 Wasm이 JS보다 빠르지도 않음
  • “이론상 가능”만으로는 사람들이 Wasm을 채택하지 않음
    HTML/CSS/JS는 이미 유용성이 입증된 반면, Wasm은 여전히 낯선 기술 스택임
  • 컨테이너를 WASI로 대체해야 한다고 생각함
    Docker 중심의 생태계가 발목을 잡고 있음
  • The Birth and Death of JavaScript 영상을 추천함

• JS 생태계의 많은 빌드 도구가 Rust로 작성되어 있고, 일부는 Wasm으로 브라우저에서 실행됨
  React나 npm 생태계도 내부적으로 Wasm을 사용함
  Wasm이 사라지면 JS 프론트엔드 세계가 크게 흔들릴 것임
  다만 네이티브 Wasm UI 프레임워크는 아직 미비함
  DOM과 CSS에 의존해야 하고, JS를 통해 브라우저 API에 접근해야 해서 비효율적임
  Rust나 Kotlin으로 DOM을 제어할 수는 있지만, Rust는 프론트엔드엔 너무 저수준임
  모바일 크로스컴파일이 점점 늘고 있고, JetBrains Compose Multiplatform이 그 예임

  • React가 Wasm 컴포넌트를 많이 쓴다는 건 잘못된 주장이라는 반박이 있었음

• Wasm의 발전을 가로막는 건 툴링임
  디버깅은 여전히 printf 수준이고, Chrome의 DWARF 플러그인도 오래전부터 업데이트가 없음
  언어별로 .wasm 파일을 만들고 import/export를 설정하는 과정이 복잡함
  GC 지원도 완전하지 않아 .NET 같은 생태계는 자체 GC를 실어야 함
  WIT는 또 다른 COM/CORBA/gRPC 시도처럼 보임

  • 10년이 지나도 툴링은 여전히 미완성임
    Emscripten은 복잡하고 불안정하며, wasi-sdk는 기능이 부족함
    LLVM과 엔진 모두 최적화가 미흡하고, Rust의 Wasm 툴링도 사실상 중단됨
    JS에서 Wasm 모듈을 표준 방식으로 import하는 방법조차 없음
    멀티스레드 지원도 COOP/COEP 헤더 설정이 필요해 GitHub Pages에서는 불가능함
    툴링이 “기술 데모” 수준을 벗어났다면 훨씬 더 많이 쓰였을 것임
  • “WASM Components Model”이 이런 문제를 해결할 수 있지 않냐는 의견도 있었음

• 우리 회사 Leaning Technologies는 Wasm을 적극적으로 사용함
  WebVM으로 브라우저에서 x86 바이너리를 실행하고,
  BrowserCraft로 Java 앱(Minecraft 포함)을 돌리며,
  BrowserPod로 Node.js 컨테이너를 브라우저에서 구동함
  매우 강력하지만 파워 유저용 도구임. 일반 프론트엔드 로직을 Wasm으로 컴파일하는 건 비효율적임

  • Firefox에서 BrowserCraft가 안 돌아가지만 Brave에서는 잘 됐다는 피드백이 있었음
    CheerpJ의 발전 속도가 인상적이며, 10년만 일찍 나왔어도 웹 플랫폼이 달라졌을 것 같다는 의견임
  • “왜 프론트엔드 로직을 Wasm으로 컴파일하면 안 되냐”는 반론도 있었음
    JS를 싫어하는 입장에서는 JS 없는 웹사이트를 만드는 게 Wasm의 진짜 매력임

• 나는 Rust 기반 Wasm 프레임워크 Dioxus에서 일함
  프론트엔드 Wasm은 번들 분할, 핫리로드, 디버깅 심볼, 에셋 통합 등 기본 툴 부족이 문제였음
  2025년에 이를 많이 개선했고, Vite 같은 도구와의 통합도 좋아짐
  AI 도구 덕분에 Rust 개발 속도도 빨라졌고, 앞으로 Wasm 프레임워크가 더 주목받을 거라 기대함

• Wasm의 바이너리 크기가 너무 크다는 지적이 있었음
  DSL 환경에서는 다운로드에 수 초~수 분이 걸릴 수 있음
  JS는 더 작고 다운로드 중에도 실행 가능하다는 주장임

  • 사실 Wasm은 JS보다 작을 때가 많음
    Rust로 빌드하면 10~100KB 수준으로 줄일 수 있음
    JS는 다운로드 중 실행되지 않으며, Wasm은 스트리밍 컴파일로 더 빠르게 시작할 수 있음
  • Godot 같은 게임은 런타임 외에도 대용량 에셋을 내려받아야 해서 사용자 경험이 나쁨
    브라우저가 이미 제공하는 기능을 중복 구현하는 셈임
  • Wasm의 비효율은 포맷이 아니라 언어 런타임의 부피 때문임
    예를 들어 FSHistory는 24KB로 x86 에뮬레이션을 구현함
  • Wasm 포맷은 본래 크기 최적화를 고려해 설계되었음
    다만 네이티브 생태계는 코드 크기 최적화에 익숙하지 않음
  • GC 언어를 WasmGC로 컴파일하면 JS보다 커질 이유가 거의 없음

• 기사에서 “Wasm으로 만든 대형 웹사이트가 없다”는 말은 내 경험과 다름
  Wasm 프로젝트의 목표가 웹앱 전체를 대체하는 게 아니었음
  사람들이 잘못된 기대를 품고 “왜 그게 안 됐냐”고 묻는 것 같음

• 나는 실제로 Wasm을 여러 실무 사례에 적용했음

  • 코덱 지원: 브라우저에서 지원하지 않는 비디오·오디오 코덱을 Wasm으로 구현
  • 코드 공유: C로 작성된 비즈니스 로직을 프론트엔드와 백엔드에서 동일하게 사용
  • 난독화: JS의 핵심 로직을 Rust+Wasm으로 옮겨 성능과 보안을 동시에 확보함
  • JS를 숨기려면 아예 브라우저로 보내지 않는 게 낫다는 의견도 있었음
    백엔드에서 필요한 부분만 잘라내는 식으로 처리 가능함
  • 오픈소스 코덱이 있는지 묻는 댓글도 있었음. 브라우저 기반 VLC 같은 프로젝트 아이디어로 연결됨