Hacker News 의견

• Amazon이 Lambda로 서버리스 컴퓨팅 시대를 시작했음. Google App Engine은 Lambda보다 6년 앞서 출시되었음.

• WASM과 Java Applets, ActiveX, Silverlight, Macromedia Flash 같은 이전 기술의 차이를 이해하기 어려움. 웹 브라우저에서 신뢰할 수 없는 서드파티 컴파일 코드를 실행하는 것에 대한 교훈을 배웠다고 생각했음.

• JIT 컴파일은 보안상의 이유로 동적 WASM 코드 생성이 허용되지 않아 불가능함. 이는 코드 핫 리로딩 같은 작업을 깔끔하게 수행하는 데 필수적인 기능임.

• 보안 주장은 신뢰할 수 없다고 생각함. 런타임에서 JS를 핫 리로드하거나 코드 생성을 할 수 있으며, WASM 런타임을 동적으로 리로드하여 메모리를 유지할 수 있지만 사용자 경험은 불편할 것임.

• 기술적으로 불가능한 이유를 찾지 못했음. 보안 조치라면 쉽게 우회할 수 있을 것임.

• WASM 바이트코드는 .NET IL, Java 바이트코드 등 JIT 컴파일을 위해 설계된 것들과 개념적으로 유사함.

• WASM 프로젝트는 명확한 방향성과 성공 의지가 부족하다고 생각함. 기본적인 기능들이 여전히 부족함.

  • 핫 리로드, 비해킹 스레딩, DOM과의 네이티브 인터페이스, 저오버헤드 그래픽/컴퓨팅 API 지원, 저수준 오디오 접근 등이 포함됨.

• WASM은 특정 언어의 VM을 일반 목적의 VM으로 대체함. 이는 컴파일러나 인터프리터로 거의 모든 것을 실행할 수 있음.

  • 일반적으로 자바스크립트 엔진의 일부로 구현되어 샌드박싱과 API 접근을 상속받음. 표준화는 진행 중임.

• WASM은 자바스크립트 대체, Docker 대체, Java 대체, CGI 대체 등으로 스타일링됨. 이는 모든 것임.

• WASM이 PHP 애플리케이션처럼 쉽게 호스팅 및 배포될 수 있어야 한다고 생각함. 아직 그렇게 되지 않았을 것임.

• 소프트웨어의 오래된 법칙을 상기시킴. 충분히 크고 오래된 애플리케이션은 결국 실행 중인 전체 소프트웨어 스택을 재구현하게 됨.

• 서버 측 WASM의 큰 약속은 정기적인 업데이트가 필요 없는 영원한 플랫폼을 제공하는 것임.

  • AWS Lambda 앱을 Node.js나 Python 버전이 더 이상 지원되지 않을 때마다 업데이트하고 재배포하는 것은 큰 문제임.

• 로컬 우선이 미래라고 생각함. 앱이 주로 사용자의 브라우저 내에서 실행되고 서버의 도움은 거의 필요하지 않음.

  • Figma, Linear, Superhuman 같은 앱이 이 모델을 성공적으로 사용하고 있음.

• WASM은 사용자의 브라우저에서 성공할 수 있음. Microsoft는 C#/Blazor에 이를 사용하고 있음.

• JVM과 그 생태계를 재발명하고 있는 것 같음.

• WASM이 클라우드에서 람다 함수 실행 코드를 대체하는 방향으로 나아갈 것이라고 생각함.

  • WASM은 호스트 플랫폼에서 실행되는 것으로 전통적으로 인식되지만, 반드시 그럴 필요는 없음.

  • WASM의 샌드박스 특성 덕분에 운영 체제 외부나 ring0에서 실행할 수 있음.