Hacker News 의견

• 작은 팀으로서 빠르게 배포해야 한다는 의견이 있음

  • 하지만 한 달 가까이 프로토타입을 만들고, Go-app UI 컴포넌트를 직접 작성해야 했으며, Go WASM이 JSON을 파싱하는 데 느리다는 문제로 인해 아키텍처가 크게 변경되었다고 함
  • 이는 이력서 중심의 프로그래밍처럼 들린다는 의견이 있음

• 강력한 Go 엔지니어 팀과 TypeScript/React로는 확장하기 어려운 복잡한 UI가 있었음

  • 데모를 통해 웹 프론트엔드에 대한 경험이 부족한 팀이라는 인상을 받았음
  • 회원가입 페이지가 화면에 맞지 않고, 대시보드 내 클릭 시 전체 화면에 스피너가 나타나며 페이지가 다시 로드됨
  • 아이콘이 로딩 중일 때 alt-text가 표시됨
  • React가 확장되지 않았다는 점이 다행이라는 의견이 있음

• "캔버스로 렌더링"하는 프레임워크일까 걱정했지만, 그렇지 않음

  • WASM과 DOM의 상호 운용성이 충분히 빨라졌다는 점이 긍정적임
  • 그러나 32MB 바이너리는 큰 단점임

• 그들은 <a href="https://go-app.dev/" rel="nofollow">https://go-app.dev/</a>를 사용하여 프론트엔드를 만들기로 결정했음

  • Go-app은 Golang과 WebAssembly를 사용하여 PWA를 구축하는 패키지임

• Go는 이런 종류의 작업에 적합하지 않다는 의견이 있음

  • Rust를 사용하여 더 나은 결과를 얻었다고 함
  • Rust로 만든 wasm 바이너리는 평균 240kb이며, 전송 시 잘 압축됨

• 몇 달 후에 더 무거운 스택에서 더 성능이 좋지만 다소 특이한 스택으로의 전환이 긍정적인 결과를 가져오는지에 대한 후속 보고가 흥미로울 것임

  • 이런 프로젝트에 프론트엔드 개발자를 고용하는 것이 React 개발자를 찾는 것보다 쉽지 않을 것임

• go-app의 창시자가 이 게시물을 발견하고 놀랐으며, 제품의 성공을 기원함

• Go WASM이 JSON을 파싱하는 데 느려서 아키텍처 변경과 WebSockets를 통한 점진적 데이터 로딩을 위한 "스마트 백엔드"를 만들게 되었음

  • gob 데이터의 보안 문제에 대한 우려가 있음

• WASM은 특정한 틈새 용도에 적합하지만 일반적인 웹 앱을 만드는 데는 부적절하다는 의견이 있음

  • go-app으로 만든 앱이 3.6MB의 WASM 코드를 로드함
  • Blazor도 마찬가지로 간단한 앱이라도 초기 로드에 최소 1MB 이상이 필요함

• 모든 구성 요소(프론트엔드/백엔드/앱)를 동일한 언어로 사용하는 것이 큰 가치가 있다고 생각함

  • 반대로 "Typescript everywhere" 접근 방식을 사용하고 있으며, 프론트엔드에 React, 백엔드에 NodeJS, 앱에 Capacitor를 사용함