4P by GN⁺ | ★ favorite | 댓글 1개
  • Watlings는 여러 작은 프로그램을 고치면서 WebAssembly Text Format을 배우는 연습 프로젝트임
  • 각 과제는 exercises 디렉터리 안의 지시를 따라 완료하고, npm start 001_hello로 답안을 테스트하는 방식임
  • 풀이 확인은 npm run show 001_hello, 풀이를 과제에 직접 적용하는 작업은 npm run solve 001_hello 명령 사용
  • 컴파일과 테스트에 Node 23+wasm-tools를 사용하며, 스크립트 내부에서 wasm-tools parse를 호출함
  • 015번 이후 과제는 exception handling, GC types 같은 더 새로운 WebAssembly 기능을 사용하며, Node.js 23 이상에서만 제공되는 --experimental-wasm-exnref 플래그 필요
  • 브라우저에서 실행할 수 있는 웹 버전을 제공하며, 편집기로는 VSCodewat-lsp 확장 사용 권장
  • 학습 방식은 파일별 주석으로 작업과 배경을 제시하고, 가능한 한 설명을 줄이며, 서로 다른 문맥에서 문법에 반복적으로 노출되도록 하는 직접 작성 중심 접근임
  • 프로젝트 구조의 참고 사례로 rustlingsZiglings를 명시함

댓글과 토론

Hacker News 의견들
  • 여기저기서 자주 보는데, 브라우저의 WASM에 빠진 건 DOM 접근만이 아니라 fetchXMLHttpRequest를 포함한 거의 모든 웹 API임
    브라우저가 지원하지만 WASM이 지원하지 않는 웹 API 목록은 여기 있고, DOM은 그중 하나일 뿐임: https://developer.mozilla.org/en-US/docs/Web/API
    그래도 GC가 확정되고 브라우저에서 지원되면 이런 인터페이스를 쓸 수 있을 가능성은 있음. GC가 지원되면 WebAssembly 코드가 JavaScript, DOM, 일반 WebIDL 정의 객체를 참조하고 접근할 수 있다고 되어 있음
    마지막 문단 참고: https://webassembly.org/docs/web/

  • Exercism 모델과 매우 비슷해 보임. Exercism에도 작은 연습문제로 채운 무료 WASM 과정이 있음: https://exercism.org/tracks/wasm
    저자가 그 과정에 기여하거나 함께 작업하는 걸 고려했는지 궁금함. 그러면 더 넓은 독자에게 닿고 Exercism의 기존 도구도 활용할 수 있을 듯함

    • Exercism을 정말 좋아하지만, 거기의 연습문제 모델은 훨씬 더 자유형이라 훨씬 큰 덩어리로, 상대적으로 덜 가르치는 편임
      특정 맥락에서는 좋은 모델이지만, 이 저장소의 형식은 코드 예제와 함께 문법과 기능을 배우는 rustlingsziglings에 더 가까움
      Exercism의 Wasm 모듈이 꼭 “고장 난” 건 아니라서, 내 기여가 환영받을지는 잘 모르겠음
    • Exercism에서 마음에 안 드는 점은 인기 언어를 제외하면 연습문제가 대체로 체계적이지 않다는 것임
      다시 말해 난이도순으로 정렬된 LeetCode식 문제 묶음에 가까움
      제대로 된 과정이라면 언어 기능별로 연습문제를 배열해야 함. Exercism은 이를 위한 훌륭한 인터페이스를 이미 만들었지만 대부분의 언어에서 활용하지 않음: https://exercism.org/tracks/csharp/concepts
  • 새 언어나 프레임워크를 배울 때 좋아하는 방식 중 하나가 koans인데, 이게 그걸 떠올리게 함: https://github.com/ahmdrefat/awesome-koans/blob/master/koans...
    기본 기능에서 고급 기능까지 부드럽게 올라가고, 테스트가 실패하는 걸 보고 이유를 이해한 뒤 고치는 TDD식 흐름이 학습에 잘 맞음. “아하!” 하는 순간의 도파민도 줌

    • 혼자 언어를 배우기에 좋은 방식처럼 들림. 아쉽게도 Rust가 빠져 있는데, 링크를 추천해줄 수 있는지 궁금함
  • WASM의 GC 같은 기능을 실험하려면 WABT 대신 Binaryen의 wasm-opt를 쓰는 게 좋음. wasm-opt가 훨씬 더 많은 WASM 확장을 지원함

  • 꽤 멋짐
    WASM을 직접 깊게 다뤄보진 않았지만 이 가이드는 한번 해볼 생각이고, 이미 몇 년이 지난 지금 웹 개발에 큰 이득을 줬다고 봄
    일부가 기대했던 “JavaScript 킬러”는 아니지만, 애초에 그런 목적도 아니었음. 대신 기존 생태계와 꽤 잘 통합되어 기존 사용 사례를 최적화하고, 무거운 계산이 필요할 때는 새 사용 사례도 가능하게 함
    모든 웹 개발자에게 순이득임. 더 빠른 라이브러리, 인상적인 개발 도구, 더 이식성 좋은 Node 바이너리가 생김

    • WASM을 멀리서 지켜봤는데, JS 킬러가 아닌 이유는 DOM이나 대부분의 DOM API에 직접 접근할 수 없기 때문으로 이해하고 있음
      혹시 내가 놓친 다른 이유가 있는지 궁금함
  • WebAssembly 채택이 계속 진전되는 게 반가움. 여기서는 Microsoft가 자주 작게 다뤄지지만, WASM에 관심 있다면 Blazor WebAssembly를 꼭 실험해보길 권함
    C#과 대부분의 .NET 라이브러리, NuGet 패키지까지 브라우저에서 컴파일된 WASM으로 사용할 수 있게 해주는 매우 강력한 프레임워크임

    • “대부분의 NuGet 패키지”라고 할 때 제한이 뭔지 궁금함
      디스크의 파일을 읽을 수 있어야 하는 패키지라면 바로 실패하는지, 아니면 파일 읽기 인터페이스가 동작을 서버 측 렌더링 같은 방식으로 넘기는지 궁금함
    • 읽어본 바로는 Go를 WASM으로 컴파일할 때와 같은 문제가 있어 보임. 페이로드가 크고, 압축 후에도 보통 여러 MB임
  • 멋진 프로젝트임
    어느 정도 관련된 저장소를 여기서 관리하고 있음: https://github.com/eliben/wasm-wat-samples/

    • 정말 유용해 보임. 처음 wat을 배울 때 이걸 알았으면 좋았을 텐데, 훌륭한 참고 자료가 될 듯함
  • WASM을 시도해봤는데, 로컬로 연결하려던 SQLite 데이터베이스 연결을 노출하는 데 문제가 생겼음
    비슷한 걸 해본 사람이 있거나 좋은 자료를 알려줄 수 있는지 궁금함

  • WebAssembly가 손으로 어느 정도 작성할 수 있는 진짜 언어처럼 보인다는 점이 정말 흥미로움
    타깃으로 삼을 때 진입 장벽을 꽤 낮춰줄 것 같음

  • WebAssembly가 여러 생태계의 공통 언어가 되어가면서, 작동 방식을 탄탄히 이해하는 데 시간을 투자할 가치가 커짐