웹 어셈블리 바이너리가 JavaScript/TypeScript 번들보다 작습니까?
WASM은 언어에 대한 컴파일 대상을 제공하여 브라우저 내에서 실행 가능한 언어를 컴파일할 수 있게 한다.
물론 현재 WASM에서 직접 DOM에 액세스하거나 JavaScript를 사용하지 않고 바이너리를 초기화하는 등의 특정 기능이 부족합니다.
그것을 무시하고, 브라우저 호환 컴파일 대상의 목표는 오늘날 자바스크립트에 의해 충족된다. 그러나 출력 자바스크립트는 높은 수준의 언어이기 때문에 종종 난해하며 종종 소스 코드 자체보다 큰 출력을 초래한다.
DOM 액세스가 내부에 존재한다고 가정하면 다음과 같다:
- 언어 런타임을 제외하고, WASM으로 컴파일된 자바스크립트나 TypeScript는 웹팩을 사용하여 생성된 동등한 자바스크립트 번들보다 작은 이진 크기를 가질 것인가?
- 런타임이 공유되고 별도로 전달됩니까? Java, SilverLight, Flash, Shockwave 참조
여러분이 상상할 수 있듯이, 이것은 확실하게 대답할 수 있는 질문은 아니지만, 나는 여러분에게 현재의 상황과 상황이 어떻게 진행되고 있는지에 대해 더 잘 이해시킬 수 있습니다.
웹 어셈블리 모듈로 컴파일된 앱에는 다음과 같은 구성 요소가 있습니다:
- 앱 로직 자체
- (선택사항) 런타임
- (선택사항) 호스트 API 통합
각 항목을 차례로 살펴봅니다:
(1)과 관련하여, Web Assembly 모듈은 크기 효율적인 이진 형식입니다. 이러한 이유로 최소화된 자바스크립트로 표현되는 동등한 논리보다 더 콤팩트하다(즉, 더 작다).
Re:2, WebAssembly는 메모리 관리 및 가비지 수집기와 같은 일반적인 런타임 기능이 없습니다. 이러한 이유로 런타임은 종종 애플리케이션 로직과 함께 제공됩니다. 어떤 경우에는 (Rust) 이 런타임이 상당히 가벼우며, 다른 경우에는 (Blazor) 매우 무겁습니다. 새로운 Web Assembly 기능(쓰레기 수집, 모듈 캐싱)과 더 나은 컴파일 기술(사전 컴파일)로 인해 이러한 런타임의 가중치가 시간이 지남에 따라 크게 감소할 것입니다.
Re:3, 당신이 인정한 바와 같이, Web Assembly는 DOM 액세스가 부족합니다. 사실은 어떠한 형태의 I/O도 부족합니다. 이때 '표준' WebAssembly 도구는 WebAssembly 모듈과 일부 JavaScript 'glue' 코드에 가중치를 추가하는 '바인딩'을 생성합니다. 이는 시간이 지남에 따라 감소할 것으로 예상됩니다.
그래서 질문에 답하기 위해, 네, 저는 wasm 모듈이 미래에 그들의 동등한 것들보다 더 콤팩트할 것이라고 생각합니다. 또한 런타임이 별도로 제공되어 캐시되겠지만, 더 중요한 것은 이로 인해 크기가 크게 줄어들 것이라는 점입니다.
'개발하자' 카테고리의 다른 글
| Terraform S3 백엔드를 구성하는 동안 오류가 발생했습니다 (0) | 2023.02.10 |
|---|---|
| Svelte - 스크롤에 네비게이션 숨기기 및 표시 (0) | 2023.02.10 |
| 빌드하는 동안 플러터 공급자 setState() 또는 MarkNeedsBuild() 호출됨 (0) | 2023.02.09 |
| C# 코드에서 python.net을 사용하여 명명된 매개 변수로 파이썬 함수를 호출 (0) | 2023.02.08 |
| 데이터 가져오기의 python 스크립트 변수에 대한 Power BI Pass 매개 변수 값 (0) | 2023.02.08 |