| [[JavaScript| 관련 문서 | |||
| {{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px)" {{{#!folding [ 펼치기 · 접기 ] {{{#!wiki style="margin: -5px -1px -11px" | <colbgcolor=#f7df1e,#f7df1e><colcolor=#000,#000> 관련 문서 | 표준(TC39 · 브라우저 전쟁) · Vanilla JS · AJAX · JSFuck · 상태관리 라이브러리 · JSON | |
| 문법 | 표준 내장 객체, this · undefined | ||
| 구현체 | <bgcolor=#f7df1e,#f7df1e> 엔진 | V8 · SpiderMonkey · JavaScriptCore · 헤르메스 · Boa | |
| <bgcolor=#f7df1e,#f7df1e> 런타임 | Node.js · Deno · Bun · workerd | ||
| 패키지 관리자 | npm · Bun | ||
| 파생 언어 | TypeScript · CoffeeScript · 액션스크립트 · AssemblyScript · elm · ReasonML · ReScript | ||
| 관련 인물 | 브랜든 아이크 | ||
| 기타 | JavaScript npm 마비 사태 | }}}}}}}}} | |
1. 개요
구성 요소가 많고 표준 스펙이 통일되기까지 과정의 험난했던 JavaScript의 특성상 다양한 구현체가 존재한다.후술할 내용에서 ECMAScript란 대체로 ECMA-262 표준을 의미한다. ECMA-402 표준을 구현하지 않는 구현체도 많고, TC39 제안상태인 스펙들은 정식 표준으로 간주하지 않아 메이저 브라우저 엔진을 제외하면 pre-implement되는 경우가 드물다.
2. 코어 ECMAScript 구현체
브라우저에서 출발한 역사적 맥락상 흔히 엔진이라고 불린다. 다양한 버전의 ECMAScript를 스펙에 맞게 파싱하고, 실행하는, 또는 스펙과 동일한 실행 semantic을 보존하는 기계어/바이트코드를 유도하는 영역을 가리킨다. 스펙 자체는 언어의 내부 구현 방식에 일절 관여하지 않기에, 대부분의 엔진은 내부 아키텍처 구조가 상이하다. 대부분의 browser-grade 엔진의 경우 자체적인 bytecode set을 정의하고 JIT 컴파일을 사용해 구현된다.- V8 - The Chromium Projects 산하의 자바스크립트 엔진. 대부분의 Chrome 계열 브라우저 및 여러 서버사이드 런타임에서 사용된다.
- SpiderMonkey - Gecko 엔진에 사용되는 JavaScript 구현체. 때문에 주로 Firefox 파생 브라우저에서 사용되며, MongoDB 등에서도 내장되는 엔진이다.
- KJS - KDE 프로젝트에서 Konqueror에 내장되기 위해 개발된 JavaScript 엔진. 애플이 이를 기반으로 WebKit을 개발하며 현재는 JavaScriptCore의 전신이 되었다.
- JavaScriptCore - WebKit에 내장된 엔진.
- Chakra - 구 Internet Explorer 및 Microsoft Edge/레거시에서 사용되던 JavaScript 엔진.
- 헤르메스
- goja - Go 구현체. Grafana k6 등에서 내장하고 있다.
- Rhino - 모질라 재단의 공식 프로젝트. Java로 구현되어 있다.
- QucikJS - QEMU의 개발자가 만들었다.
- QucikJS-ng - 위 QucikJS의 포크. txiki 등의 런타임에서 쓰인다.
- njs - NGINX에서 JavaScript 모듈의 실행을 위해 개발된 엔진. 모듈 설정에서 njs 엔진 대신 위의 QucikJS 백엔드를 사용하도록 설정할 수도 있다.
- V4 - Qt 프레임워크 v5.2 버전부터 QML 실행을 위해 새로 개발된 ECMAScript 엔진.
- Espruino - 임베디드 디바이스용 ECMAScript 구현체.
- Nashorn - Oracle이 개발하고 현재는 OpenJDK 재단에서 관리하는 Java 구현체.
- NectarJS - ECMAScript 네이티브 컴파일러 구현체. ECMAScript 3 표준의 80% 가량을 구현했으나, 사실상 개발이 중단되었다.
- PrimJS - TUI 브라우저인 lynx에 내장하기 위해 개발된 JavaScript 엔진.
- Duktape
- Boa - Rust로 작성된 ECMAScript 구현체.
- Kiesel - Zig로 작성된 ECMAScript 구현체.
3. 런타임
JavaScript를 실행하는 데 필요한 여러 IO 구현 및 시스템 콜 바인딩, 언어 내부에 보여지는 내장 객체 구현을 포함한 완성형 구현체. 주로 위 항목의 언어 구현체와 대비에 런타임이라고 불린다.과거 serverside-js라는 개념이 부족했던 시절엔 '브라우저 API와 분리된 내장 시스템 인터페이스'라는 개념이 희박해 CommonJS라는 독자적인 확장 표준이 생겨나기도 했으나, 현재는 대부분 표준 Web API 인터페이스 수준에서 구현할 수 있도록 표준화가 이루어진 상태이다. Deno가 이와 같은 구현의 대표적인 사례. 다만 파일 시스템 등은 브라우저 API단에서 커버할 수 없기 때문에 최소한의 런타임 의존성은 생겨나게 되며, 이로 인해서 각 런타임간 호환성 역시 내려간다. 가령 내장 Deno 객체로 작성된 코드를 바로 Node.js에서 실행시킬 순 없다. 때문에 최근 등장하는 대부분의 런타임은 Bun과 같이 사실상 Node.js 인터페이스와의 호환 레이어를 기본적으로 내장하는 편.
이를 해결하기 위해 현재는 TC55 위원회에서 mincomm API 스펙을 정의하려고 시도하는 중이다.
런타임에 시스템 인터페이스 외에도 다양한 부가 API를 넣는 것이 현대 웹 개발환경 추세가 되고 있다. 일례로 Bun은 테스트, SSR 렌더 엔진까지 내장한다. 이전에는 보통 독자적인 모듈 시스템이나 패키지 관리 시스템을 구현했지만 현재는 대부분 npm 호환으로 굳어진 상태. JSR 등 최신 외부 레지스트리의 경우 PM단에서 first-class로 구현되나, 런타임 간 패키징 시스템 호환성 문제는 여전하다. 때문에 npm 패키지를 다이렉트로 쓸 수 있냐 없느냐가 중요 평가 요소로 갈리는 편.
- 웹 브라우저
- Node.js - V8 엔진을 사용한다.
- Deno - Rust로 구현되고 V8 엔진을 사용하는 런타임. Node.js와 같은 개발자인 라이언 달이 개발했다.
- Bun - JavaScriptCore 엔진을 사용한다.
- Cloudflare workerd - V8을 사용한다.#
- AWS LLRT - AWS 람다 백엔드로 사용되는 JavaScript 엔진. QuickJS 엔진을 기반으로 Rust로 제작되었다.
- just - V8 엔진을 사용한다.
- Tixiki.js - QuickJS-ng 엔진을 사용한다.
- WinterJS - Wasmer 및 SpiderMonkey 기반의 런타임.
- elsa - QuickJS를 사용하는 Go 구현체.