Hacker News 의견

요약하면 다음과 같습니다:

• OpenEtG 프로젝트에서는 Rust로 작성된 WASM 바이너리 크기를 400KB 미만으로 유지하기 위해 다음과 같은 노력을 기울임
  • float 대신 고정 소수점 연산 사용
  • HashMap 대신 Vec 사용
  • 문자열 사용 최소화
  • 작은 할당자(talc) 사용
  • 의존성 최소화 (rand, fxhash만 사용)
  • 제네릭 다양성 피하기
  • 크기를 고려한 알고리즘 설계
• Tree-shaking은 잘못된 명명법이며, Virgil 컴파일러에서는 이를 Reachability Analysis라고 부름. 컴파일 과정에서 main 진입점에서 탐색하여 도달 가능한 코드만 최종 바이너리에 포함시킴.
• WasmGC 덕분에 Java와 Kotlin은 2-3KB 정도의 작은 WASM 바이너리를 생성할 수 있음. 하지만 API 선택에 주의해야 함.
• WASM을 이용한 DOM 조작은 여전히 JS에 의존적임.
• Tree Shaking 용어가 생겨난 이유는 Dead Code Elimination이 오래전부터 존재했기 때문임.
• WASM의 코드 크기 문제는 언어 런타임과 표준 라이브러리를 모두 번들링해야 하기 때문에 발생함.
• 이를 해결하기 위해 공유 라이브러리와 동적 링킹을 고려해볼 수 있음.
  • Pyodide는 동적 링킹을 지원하는 대표적인 예시
  • 브라우저가 인기 있는 언어 런타임을 미리 로드한다면, 웹 페이지에서 해당 런타임을 공유할 수 있음
• Zig 언어는 작은 WASM 바이너리 생성에 적합함. 하지만 100KB 미만이라면 크기는 중요한 요소가 아님.
• 내장 GC는 모든 앱에 중요한 것은 아니며, GC 없는 웹앱을 만드는 것이 좋음.
• WASM을 사용하는 앱의 성공 요인은 여전히 성능 향상임.
• ClojureScript, TypeScript, ReasonML 등 컴파일-투-JS 언어를 통해 오래전부터 JS 외의 언어로 DOM 프로그래밍을 해왔음.
• asm.js와 emscripten을 통해 WASM 이전에도 C 기반 언어를 웹에서 컴파일해 사용했음.
• Google Maps와 Google Earth는 WASM을 사용하는 대표적인 앱임.