본문으로 건너뛰기

ES4, 첫번째 도전

첫번째 TC39 회의에서는 Borland International [1996]이 언어에 클래스 정의를 추가하는 제안을 발표했다. 그때부터 더 큰 프로그램의 복잡성을 관리하는 기능을 Javascript에 추가하는 것에 대한 수요는 있었다. Netscape의 Javascript 1.2는 import와 export선언을 통해 통합되는 암호화된 스크립트를 지원했다 [Netscape 1997a]. Microsoft의 JScript 3에는 조건부 컴파일 기능이 포함되어 있었다 [Clinick 1997]. 1998년 2월 버전의 ECMAScript의 예정 작업 목록 [TC39 1998c]에는 V2의 가능성 있는 항목으로 "패키지 개념"이 있었다. 이런 대규모 프로그래밍을 위한 기능은 ES3 기능 목록에서 상대적으로 빠르게 제외되었지만 이에 대한 작업은 TC39 내에서 계속 병행해서 이루어지고 있었다.

첫 번째 주요 제안은 휴렛팩커드가 후원하는 W3C 펠로우인 Dave Raggett이 제출했다. W3C에서 Raggett은 HTML, CSS, Javascript의 통합을 개선하기 위한 'Spice'라는 이름의 제안을 개발하고 있었다. 제안의 초기 버전 [Raggett 1998c]은 1998년 2월 TC39에 제출되었다. Raggett의 초기 제안은 HTML과 CSS 통합과 관련된 기능 외에도 Borland의 클래스 선언 제안과 비슷한, 프로토타입 객체를 선언하기 위한 구조를 포함하고 있었다. 이는 프로토타입 객체와 이벤트 핸들러를 선언적으로 연결할 수 있도록 해주었다. 제안에는 "라이브러리"를 정의하고 라이브러리에서 정의들을 가져오기 위한 구조도 포함되어 있었다. 다음과 같이 말이다.

import document, block, Inline from "http://www.w3.org/Style/std.lib";

prototype Link extends Inline
{
  href = "http://www.w3.org/";
  when onmousedown
  {
    document.load(this.href);
  }
}

1998년 2월의 Spice 제안

1998년 3월 회의 노트 [TC39 1998d]에 따르면 회의에서 Dave Raggett의 초기 Spice 제출물이 논의되었다. 그리고 "초기 피드백은 부정적이다"라고 언급되었다. Raggett은 HP Labs의 두 언어 디자이너인 Chris Dollin, Steve Leach와 함께 그의 제안을 계속 발전시켰다. 1998년 9월 Reggett은 확장된 Spice 제안을 기술하는 새로운 문서 묶음[Raggett et al. 1998]을 제출했다. 그 제안은 사실상 ECMAScript를 대체하는 새로운 언어였고 ECMAScript와 호환되지 않았다. 그 제안은 심지어 중괄호로 단락을 구분하는 C 스타일 문법도 종결 키워드 기반의 문장 문법으로 대체했다.

Dave Raggett[1998a]은 1998년 11월 TC39 작업 그룹 회의에서 수정된 Spice 제안을 발표했다. 이 회의는 그 달 초 Spice 설계자들과 Netscape와 Microsoft의 TC39 대표들 간의 비공개 회의에 이어 열렸다. 작업 그룹 회의에서 TC39 멤버들은 기존 구문 문법을 대체하거나 스타일 시트에 대한 선언적인 지원을 즉시 통합하려고 시도하는 데에 관심이 없었다. 그러나 Spice 제안에 있는 클래스, 숫자 단위1, 타입, 모듈과 같은 개념으로 ECMAScript를 확장하는 데 관심이 있었다. Raggett에게 물었을 때, 그는 비슷한 기능이 ECMAScript에 추가되면 HP가 Spice 개발을 계속할 가능성이 낮다고 말했다2.

// C 스타일의 선언 대안
var float x, int[] y, z; // z의 타입은 무엇인가?
var float x, int[] y, int[] z; // 이런 식의 선언인가?
var float x, int[] y, any z; // 아니면 이런 선언?
// Pascal 스타일 선언 대안
var x: float, y: int[], z; // z의 타입은 any이다.

그림 24. 타입 선언에 대한 초기 ES41 논의. C와 Pascal에서 영향을 받은 문법적 대안들이 고려되었다.

TC39의 새로은 Spice 작업 그룹은 1999년 1월 전체 그룹에 제안을 발표하기 위해 개발할 것을 인가받았다. 위원회의 의견은 이랬다. 새로운 핵심 기능을 지원하는 새로운 기능들은 이미 예약된 Java 키워드를 사용해서 정의되어야 하고 클래스 시맨틱은 Java와 비슷해야 한다는 것이었다. 숫자 단위는 클래스 최상위에 정의되어야 했고 연산자 오버로딩 추가를 필요로 했다.

Spice 작업 그룹의 첫 원격 회의는 1998년 12월의 첫번째 주에 열렸다. 12월 10일, Dave Raggett[1998b]은 그 회의를 기반으로 한 새로운 문서를 배포했다. 이 문서는 패키지와 숫자 단위에 관해서 언급했지만 그보다는 클래스 및 인터페이스 정의를 포함하여 타입 선언에 대해서 더 광범위하게 탐구하였다. 이 문서의 초점은 시맨틱보다는 문법에 맞춰져 있었다. 해당 문서는 이름 기반의 타입 시스템(nominal type systemg)을 가정하였다. 그리고 그 타입 시스템이 이름이 붙은 내장 원시 타입, 동종 배열 타입, 서브클래스가 이름 기반의 서브타입으로 정의되는 클래스 타입, 인터페이스 타입, 접근이 동적으로 타입 검사되어야 한다는 것을 나타내는 any 타입을 가지고 있다고 가정했다. 문법적으로는 변수 바인딩과 타입을 연관짓는 데 대한 대안을 탐구하였다. 문서는 변수 선언에는 여전히 var키워드를 사용할 거라고 가정하고 선언된 이름 앞의 접두사로 타입 표현을 사용하는 C 스타일, 그리고 선언된 이름 뒤에 콜론과 타입 표현을 사용하는 Pascal 스타일을 모두 탐구했다. 이러한 대안들의 예시는 그림 24에 있다.

해당 문서의 클래스와 인터페이스 정의 구문은 대략적으로 자바를 따랐다. 그리고 public, private, protected와 기본(패키지) 접근 제한자 수정 방식 전체를 포함했다. 근본적인 메타 객체 구조는 다루어지지 않았지만 기존 Javascript의 프로토타입 기반 상속 모델과는 다른 메타 객체 모델을 가지고 있다는 것은 함축되어 있었다. 문서는 선언된 정적 타입 정보를 사용하는 조기 바운드 멤버 접근과 정적 타입 정보가 없을 시점에 이루어지는 늦은 바운드 멤버 접근을 구별하는 문제를 제기했다. 동적인 속성 추가3가 탐구되었고, 문서는 클래스가 이를 금지하는 것이 바람직할 수도 있다고 제안했다.

주로 클래스, 타입 표기g, 스코핑과 관련된 설계 논의들은 Chris Dollin, Waldemar Horwat, Herman Venter를 주요 참가자로 하여 1999년 1월과 2월[Raggett 1999b,c]에 계속되었다. 대부분의 토론은 클래스로 정의된 객체의 본질과 클래스 멤버 접근의 시맨틱에 관한 것이었다. Dollin과 Venter는 클래스 인스턴스의 구조가 클래스 선언에 의해 정적으로 결정되고 클래스 멤버 접근 제한도 참조 지점의 타입 정보에 기반하여 정적으로 결정되는, Java와 비슷한 시맨틱을 일반적으로 선호하였다. Horwat는 타입 표기가 존재하더라도 멤버 접근 시에 동적인 조회(실패할 수도 있는)를 사용하는 더 동적인 모델을 읿반적으로 선호했다. 선택적인 타입 표기, expando propertiesg, 기존 Javascript 프로그래머들의 기대, 프로토타입 기반으로 클래스를 흉내내어 만들어진 기준의 코드들과의 호환성 등은 모두 더 동적인 시맨틱을 요구하는 것처럼 보였다. 또한 Horwat는 동적인 시맨틱이 스크립팅의 본질과 더 일치한다고 주장했다. 여기서 말하는 스크립팅의 본질은 여러 출처를 가진 코드를 동적으로 조립하고 라이브러리를 참조하는 스크립트의 버전과 상관없이 라이브러리를 사용하는 것을 포함한다. Horwat[1999b]는 멤버 조회의 대안을 설명하는 문서에서 정적 접근과 동적 접근의 차이를 요약했다.

  • 모듈성 향상: 클래스, 타입, 모듈, 라이브러리, 패키지 등
  • 국제화(I18N) 항목:
    • 국제화 라이브러리 [별도의 ECMA 기술 보고서가 될 가능성이 있음]
    • 달력
  • 십진수 연산(향상된 또는 대안적인 숫자 객체)
  • 타입을 포함한 catch 가드
  • 원자성(스레드-안전) 연산의 논의/정의(비규범적일 수 있음)
  • 기타 개선점들[모듈성 외의 다른 것들]:
    • 선언 한정자 확장 메커니즘
    • 확장 가능한 구문(예: RGB 값에 대한 # 사용)
    • 단위에 관한 문법과 연산 라이브러리
    • "Here documents" (긴 문자열 상수)

그림 25. 1999년 11월의 TC39 "추후 작업 목록"[TC39 1999d]에 있던 잠정적인 ES41 기능

2월 회의에서 Waldemar Horwat [1999a]는 "Javascript 2.0"에 대한 그의 명세를 밝혔다. 그리고 원래는 Netscape4를 위해서 작성된 실험적인 설계이며 TC39에서 최근에 논의된 많은 내용과 일치한다고 이야기했다5. 이 명세는 이름 기반의 타입 시스템과 기계 수준의 많은 숫자 타입, Java와 비슷한 클래스 멤버 접근 제한자 규칙, 명시적인 import가 있는 패키지를 포함하고 있었다. 또한 그 명세는 여러 새로운 기능들도 포함하고 있었다. 클래스 확장 선언, 패키지 멤버의 선언 수준 버전 관리, nullable과 non-nullable 타입, 일급 타입 값 등이다. 이전 Javascript 버전의 선언 호이스팅 시맨틱 대신 Javascript 2.0은 프로그램 실행 중에 선언을 만나기 전까지 해당 선언이 처리되지 않는 "스트리밍 실행 모델" [Raggett 1999d]을 제안했다. 예를 들어 if문을 사용하여 조건에 따라 변수를 선언하거나 다른 타입 표기를 가진 선언들 사이에서 하나를 선택할 수 있었다. 일급 타입 값과 선언의 스트리밍 실행의 조합은 일부 경우에 전체적인 정적 타입 검사를 불가능하게 했다.

Javascript 2.0은 원래의 Javascript와 완전히 호환되도록 하려는 시도가 아니었다. 그때 당시에도 아직 완성되지 않았던 ECMAScript 3과도 마찬가지로 호환을 시도하지 않았다. TC39에 Javascript 2.0을 소개하면서 Waldemar Horwat는 "최소한 ECMAScript 1.0과 2.0 [ES4]에서 작동하는 코드를 작성할 수 있어야 합니다. 완전한 후방 호환성은 오히려 골치아플 것입니다." [Raggett 1999c] 예를 들어 선택적인 타입 표기의 문법적인 복잡성은 줄바꿈 시에 자동 세미콜론 삽입을 지원하지 못하게 했다. 후방 호환성에 대한 Howart의 해결책은 구현체가 여러 컴파일러를 제공하는 것이었다. 그는 언어 버전에 따라 컴파일러를 전환하는 것이 엄격한 전방 호환성을 가진 단일 언어보다 바람직하다고 생각했다.

1999년의 남은 기간 동안 TC39의 주요 관심사는 ES3을 완성하는 데에 집중되었다. 3월에 TC39는 ES3 이후에 생길 가능성이 있는 "예정 작업 목록[TC39 1999c]"을 발행했다. Spice 작업 그룹은 모듈화 하위 그룹으로 변했고 가끔씩 ES41에 관한 회의[Raggett 1999a,d; TC39 1999a]를 열었다. 11월에 TC39가 주요 관심사를 "Edition 4"로 전환하고 ES3 이후의 예정 작업 목록을 업데이트하면서 속도가 빨라졌다(그림 25). 1999년 11월의 TC39 의장 보고서 [Lewis 1999a]는 ES41의 목표를 다음과 같이 기술한다.

ECMAScript 2.0[ES41]은 [위원회에서] 2000년도에 표준화되기를 바라고 있는 야심차고 크게 향상된 ECMAScript 언어 정의입니다(비록 이것이 지나치게 야심찬 목표일 수도 있겠지만). ECMAScript 2.0의 주요 목표는 '대규모 프로그래밍'을 지원하는 것입니다. 즉, 여러 다른 사람들이 같이 작성하고 사용자의 컴퓨터에서 아마도 처음 조립되는 그런 프로그램의 구축을 지원하는 것입니다.

2000년 1월 회의 [Raggett 2000]에서 Microsoft는 2000년 12월에 제4판을 출판하도록 하고 그 기한을 맞추기 위해서 기능을 축소하기를 제안했다. Microsoft의 주요 관심사는 정적 타입 어노테이션의 추가와 자동 세미콜론 삽입의 지원을 포함한 후방 호환성 유지였다. Ventor는 그가 타입 어노테이션을 지원하기 위해 충분하다고 생각한 ES3 명세의 변경사항들을 다른 사람들에게 알렸다. 그러나 아직 많은 불확실성이 남아 있었다. 타입 시스템의 본질, 클래스와 패키지와 네임스페이스의 시맨틱, 하나의 언어에 정적 언어와 동적 언어의 개념을 통합하는 방법 등에 대한 것이었다.

2000년 6월 22일, Microsoft [2000b]는 .NET 프레임워크를 발표했다. 이건 Sun Microsystems의 Java 플랫폼에 대한 Microsoft의 경쟁적 대응이었다. Microsoft의 .Net은 다중 언어 애플리케이션 개발 플랫폼이었다. .Net의 주요 언어인 C# 외에도 Visual Basic, JavaScript, 그리고 다른 언어들의 방언을 지원했다. 닷넷 발표에 이어 7월에는 Microsoft의 전문 개발자 컨퍼런스[Microsoft 2000a]에서 첫 .NET 프리뷰 빌드6가 릴리즈되었다. 이 프리뷰에는 JScript.NET의 초기 버전 [Clinick 2000]이 포함되어 있었다. 브라우저에서의 Javascript와 달리 JScript.NET은 .NET 공용 언어 런타임(CLR)을 대상으로 하는 사건 컴파일 언어(precompiled language)였고 .NET 타입 시스템을 내부적으로 사용했다. 인터넷 익스플로러는 JScript.NET(또는 .NET 일반)을 지원하지 않았다. 대신 JScript.NET은 초기에 다양한 .NET 프레임워크 컴포넌트를 사용하여 데스크탑, 서버, 커맨드라인 어플리케이션을 구축하는 데에 사용될 수 있었다. JScript.NET은 ES3 명세와의 호환성을 주장했지만 이걸 이용해서 브라우저용으로 작성된 Javascript 코드를 실행할 것으로 걸로 예상되지 않았기 때문에 엄격한 후방 호환성은 그다지 중요한 문제가 아니었다. ES3 기능 외에도 JScript.NET은 선택적인 정적 타입 어노테이션, 멤버 접근 제한자 속성을 포함하는 클래스와 인터페이스 선언, 명시적인 import가 있는 패키지를 추가했다. Microsoft의 Andrew Clinick [2000]은 새로운 기능들이 다른 Ecma TC39 회원들과 함께 설계되었다고 했다. 그리고 TC39에서 계속 진행 중인 논의를 기반으로 설계의 세부 사항이 변경될 수 있다고 경고했다.

2000년 6월의 .Net 발표 전까지 Microsoft의 Herman Venter는 Waldemar Horwat 등 다른 TC39 멤버들과 .NET이나 JScript.NET에 대해 논의할 수 없었다. 8월에 Horwat과 Venter는 사적으로 만나서 ES4 표준의 완성을 가능하게 할 조정을 찾기 위해 노력했다. Horwat의[2000] 회의록은 문제점 또는 합의되지 못한 부분 43가지에 대한 논의를 기록했다. 그 회의록에서는 논의를 다음과 같이 요약했다.

General: Herman [Venter]는 서버용 JScript의 구현을 준비하고 있다. 그리고 그는 언어를 고정시키고 Microsoft의 .NET 런타임과 쉽게 호환될 수 있게 하고자 한다. Waldemar [Horwat]는 언어의 브라우저 적용 가능성과 동적성(dynamism)을 유지하는 것에 대해서 우려하고 있다. Horwat는 그 2가지가 언어의 차별화 요소라고 보기 때문이다. 그는 JScript가 Java나 C#에 가깝게 변화하는 것에 대해 우려하고 있다. 해당 언어들의 영역에 다른 언어의 필요성이 별로 없으며 JScript의 그런 변화의 결과가 어쨌든 정적 프로그래밍에 있어서는 C#에 비해 열등할 것으로 보았기 때문이다. Herman은 또한 새로운 서버 프로젝트는 JScript 대신 C#을 사용할 것을 권장한다. 그는 새로운 JScript를 이미 JScript 프로그래밍에 익숙한 개발자들을 위한 언어로 보고 있다.

Horwat[2003a]는 Javascript 2.0 문서에서 별도의 'ECMAScript 4 Netscape 제안' 문서를 분리해냈다. 이 문서는 이후 진행 중인 ES41 개발을 위한 작업 초안으로 사용되었다. Javascript 2.0 문서는 TC39가 포함하기로 동의하지 않은 추가 기능을 포함하여 병렬로 유지되었다.

Microsoft는 .NET과 그 언어들이 표준을 기반으로 한 기술로 여겨지길 원했다. Ecma는 상표가 있는 기술을 표준 트랙으로 쉽게 옮길 수 있는 기관으로서의 명성이 있었고 Microsoft는 TC39가 진행된 방식에 만족했다. 그래서 Microsoft는 Ecma에 TC39의 범위를 확장하고 .NET을 그 안에서 표준화할 것을 제안했다. TC39는 '프로그래밍 환경'을 위한 Ecma 기술 위원회로 재인가되었다. 진행 중이었던 ECMAScript 활동은 TC39 내에서 작업 그룹으로 강등되어 TC39-TG1로 알려지게 되었다. CLR 및 C#에 대한 표준을 개발하기 위한 추가적인 TC39 작업 그룹이 형성되었다.

ECMAScript 명세의 제4판을 만들기 위한 작업은 이후 3년간 계속되었다. 하지만 회고해 보면 JScript.NET의 발표가 노력이 끝나기 시작한 시점이었다. 2000년 6월까지 Netscape는 시장 점유율이 14% 미만으로 떨어지면서 [Reuters 2000] "브라우저 전쟁" [Borland 2003]에서 패배했다. 그리고 아메리카 온라인에 인수된 후에 Netscape는 직원을 잃고, 축소된 자원으로 운영하며, 새로운 브라우저 버전을 출시하는 데 어려움을 겪고 있었다.

인터넷 익스플로러를 가진 Microsoft는 승리하여 결국 90% 이상의 시장 점유율을 달성했다. Microsoft는 자신이 독점적으로 통제할 수 없는 웹 프로그래밍 플랫폼을 향상시키는 데 지속적인 관심이 거의 없었다. 내부적으로는 ECMAScript와 같은 개방된 브라우저 기술을 발전시키는 것에서 윈도우 프레젠테이션 프레임워크7 [Microsoft 2016] 과 같은 Microsoft의 독점 기술들을 개발하는 데로 자원을 전환했다. Microsoft는 이런 자신의 독점 기술들이 개방적인 웹 기술들을 구식으로 만들고 대체하기를 바랐다. Microsoft는 .NET용 프로그래밍 언어 분야에서는 C#과 VisualBasic.NET에 중점을 두었다. 이러한 맥락에서 JScript.NET은 Javascript 프로그래머들이 .NET 플랫폼으로 이동할 수 있게 하는 정도의 의의만 가지고 있었다.

TG1은 계속해서 모여 특정 이슈를 논의하고 초안 명세를 업데이트했다. Microsoft와 Netscape 간에는 타입 시스템의 본질에 관한 상당하고 지속적인 의견 불일치가 있었다. Waldemar Horwat는 MIT 경량 언어 워크숍에서 Javascript 2.0의 설계에 관한 논문 [Horwat 2001]을 발표했다. 그 논문에서 그는 Javascript 2.0이 "강력한 동적 타이핑"을 가진 것으로 특징지었다. 그리고 그는 Javascript 2.0에서 모든 변수들은 변수에 저장될 수 있는 값의 종류를 제한하는 연관된 타입을 가지고 있지만 타입 제약 조건에 대한 검사는 런타임에 이루어져야 한다고 설명했다. Javascript 2.0의 일급 타입 값과 암시적 다운캐스트8는 프로그램의 타입 검사를 정적으로 수행하는 걸 일반적으로 불가능하게 만든다.

TG1 회의의 빈도와 참석률은 점차 감소했다. Chris Dollin은 2001년 6월에 마지막으로 참석했다. Herman Venter가 참석한 마지막 TC39-TG1 회의는 2002년 6월이었다. 2003년 7월 15일, 아메리카 온라인은 Netscape를 해체하고 Waldemar Horwat를 포함한 대부분의 직원들을 해고한다고 발표했다. 그 주에 열린 TG1 회의에서 Horwat는 ES4 편집자 자리에서 물러났다. TG1의 남은 멤버들은 ECMAScript에 대한 XML 지원 개발에 집중하고, XML 프로젝트가 완료되고 새로운 편집자가 생길 때까지 ES4 작업을 중단하기로 결정했다.

Footnotes​

  1. 숫자 단위(numeric units)는 숫자값에 미터, 킬로그램과 같은 측정 단위를 다는 것을 의미한다. 웹 페이지의 경우, 픽셀과 포인트와 같은 단위가 특히 관심의 대상이었다. ↩

  2. Chris Dollin과 Steve Leach는 Javascript에 기반하지 않은 Spice 언어를 계속 개발했다[Dollin 2002]. 그리고 Leach는 이후 이를 Ginger 프로그래밍 언어로 발전시켰다[Leach et al. 2018]. ↩

  3. Microsoft는 이를 "expando properties"라고 불렀다. ↩

  4. 모질라의 소스코드 레포지토리는 에피메테우스(Epimetheus [Horwat et al. 2003])의 코드 [Horwat et al. 2005]를 가지고 있다. 에피메테우스는 Netscape의 실험적인 Javascript 2.0 구현이었다. ↩

  5. 2018년의 개인적인 대화에서는 Venter는 Raggett의 제안이 Horwat의 설계에 별로 영향을 미치지 않았다고 믿고 있었다. ↩

  6. .NET 플랫폼은 2022년 2월 13일에 나왔다. ↩

  7. 이후 Windows Presentation Foundation으로 리브랜딩되었다. ↩

  8. downcast는 특정 타입으로 선언된 변수의 값이 더 특화된 서브타입 값을 요구하는 맥락에서 사용 가능한지를 검사한다. ↩