Firefox 148부터 SpiderMonkey의 asm.js 최적화는 기본적으로 비활성화되었으며, 향후 릴리스에서 관련 코드를 완전히 제거할 계획입니다.
도끼의 때, 칼의 때, 방패는 부서지고,
바람의 때, 늑대의 때, 세상이 무너지기 전에.
Firefox 148부터 SpiderMonkey의 asm.js 최적화는 기본적으로 비활성화되었으며, 향후 릴리스에서 관련 코드를 완전히 제거할 계획입니다.
asm.js를 사용하는 사이트를 유지보수하고 있더라도 아무것도 깨지지 않습니다. asm.js는 그저 일반 JavaScript의 부분집합이므로, 코드는 다른 스크립트와 마찬가지로 우리의 일반 JIT를 통해 계속 실행됩니다. 다만 WebAssembly로 다시 컴파일하면 더 빠른 실행 속도와 더 작은 바이너리를 얻을 수 있습니다.
asm.js는 NaCl 및 PNaCl이 던진 질문, 즉 웹이 어떻게 네이티브 수준의 속도로 코드를 실행할 수 있는가에 대한 Mozilla의 답이었습니다.
아이디어는 영리했습니다. 엔진이 실행 중에 인식하고 네이티브 코드로 컴파일할 수 있는, 엄격하고 정적으로 타입이 지정된 JavaScript의 부분집합을 고르는 것이었습니다. 그러면 NaCl/PNaCl과 비슷한 성능을 얻으면서도 코드가 웹 콘텐츠 안에 머물고 웹 API를 사용할 수 있었습니다(별도의 샌드박스, IPC, 또는 대체 API가 필요 없음).
asm.js는 2013년에 Firefox 22에서 출시되었고 성공을 거두었습니다. 이를 통해 Unity와 Unreal 같은 프로젝트가 처음으로 표준 웹 기술만 사용해 C/C++ 코드베이스를 웹에 배포할 수 있었습니다. Epic Citadel 데모는 단 4일 만에 웹으로 포팅되었습니다. 이것은 기념비적인 성취였고, 원래 asm.js 팀에게는 소중한 추억입니다.
Video 3 asm.js는 표준 웹 기술만으로도 웹에서 거의 네이티브 속도로 코드를 실행할 수 있음을 증명했습니다. 이것은 몇 년 뒤 Firefox 52에서 출시된 WebAssembly의 길을 열었습니다. asm.js가 없었다면 우리는 아마 WebAssembly를 갖지 못했을 것입니다.
그렇다면 왜 끄는 걸까요? WebAssembly는 성공했고, asm.js 사용은 대부분 그쪽으로 옮겨갔습니다. WebAssembly와 함께 asm.js 경로를 계속 유지하는 것은 유지보수 시간을 소모하고 VM에 추가적인 공격 표면을 제공합니다.
asm.js 콘텐츠를 배포하고 있다면, WebAssembly로 다시 컴파일하는 것을 고려해 주세요! 우리의 WebAssembly 파이프라인은 asm.js 파이프라인이 한때 그랬던 것보다 훨씬 더 발전해 있습니다. 더 빠른 실행 속도와 더 작은 바이너리를 보게 될 것입니다.
asm.js 컴파일러의 이름은 OdinMonkey입니다. 오래전에 예언되었듯, OdinMonkey는 예정된 파멸을 맞아야 합니다. 버그 Ragnarök은 “OdinMonkey의 황혼”을 추적합니다.
하지만 모든 것이 끝난 것은 아닙니다. OdinMonkey에게서 태어난 것이 바로 우리의 WebAssembly 최적화 컴파일러 BaldrMonkey이기 때문입니다. OdinMonkey는 늑대 Fenrir에게 통째로 삼켜질지 모르지만, BaldrMonkey는 우리의 WebAssembly 베이스라인 컴파일러인 RabaldrMonkey(“소동”)와 함께 다시 태어난 세계를 다스릴 것입니다.
이 Odin의 날(수요일)에 우리는 OdinMonkey의 13년간의 봉사에 감사드립니다. Skål!
그러면 씨 뿌리지 않은 들판에도 무르익은 열매가 맺히고,
모든 해악은 나아지며, Baldr가 돌아오고;
Baldr와 Hoth는 Hropt의 전투의 전당에 거하리라. – Völuspá, Poetic Edda
