또다른 막다른 길
1990년대 중반부터 후반에 걸쳐 소프트웨어 컴포넌트라는 개념에 상당한 관심이 몰렸다. 여러 소프트웨어 컴포넌트 모델들이 제안되고 구현되었 다. 그런 컴포넌트 모델에는 객체 관리 그룹(OMG)의 CORBA, Microsoft의 COM, Sun Microsystems의 JavaBeans 등이 있었다. 일반적으로 소프트웨어 컴포넌트 모델은 객체 기반 소프트웨어 모듈을 기술하고, 발견하고, 사용하는 방법을 제공하는 모듈화 체계였다. 1997년 7월 TC39 회의 [1997g]에서 오라클의 Jim Tressa는 컴포넌트 스크립팅 언어의 대한 OMG의 RFP에 대한 발표를 했다. 그 회의에서 IBM, Netscape, 오라클 등이 ECMAScript 기반의 제안에 관심이 있다고 보고되었다. 하지만 OMG에서 최종적으로 만들어진 명세는 ECMAScript를 기반으로 하지 않았다.
ECMAScript 컴포넌트는 브라우저 및 기타 Javascript 호스트에서 사용하기 위한 Javascript 특유의 컴포넌트 모델을 전파하기 위한 시도였다. 이는 Javascript 컴포넌트를 기술하는 XML 스키마와 어휘들, 그리고 구현 규칙들의 집합을 명시했다. 이런 노력을 NetObjects, Inc.1와 Netscape가 후원했다. NetObjects의 Richard Wagner [1998]는 1998년 6월에 Ecma 총회에서 초기 발표를 했다. 그 회의에서 기술 명세 초안 [Wagner and Shapley 1998]이 TC39에 제출되었다. 그 문서는 3번 더 개정되었고 그 이후 Ecma 총회에 제출되었다. 이는 Ecma 표준으로 승인되었고 ECMA-290 [Wagner 1999]이라는 이름으로 출판되었다. 이 표준이 구현된 기록은 없다. TC39의 권고에 따라, Ecma 총회는 2009년에 ECMA-290 표준에서 을 철회하기로 투표했다 [Ecma International 2009b].
ECMAScript 3판의 컴팩트 프로파일(compact profile)프로젝트라는 게 있었다. 그 프로젝트에서는 ES3의 덜 동적인 부분들에 대한 언어인 profileg을 정의했다. 자원이 제한된 환경에서의 Javascript 구현체도 ECMAScript 명세를 따를 수 있도록 하기 위해서였다. profile의 창조는 휴대폰 애플리케이션2 [Lewis 1999b]에서 사용하는 Javascript 방언을 정의하려는 Ecma 외부에서의 시도 WMLScript에 의해서 촉발되었다[Raggett 2000]. 컴팩트 프로파일은 ES3의 모든 기능을 포함했지만, 구현체가 with 문을 지원하지 않는 것을 허용했다. 그 이외에도 구현체는 eval과 Function 생성자를 지원하지 않을 수 있었다. 컴팩트 프로파일은 또 구현체가 내장 라이브러리 객체들을 불변(immutable)으로 만드는 것을 허용했고, 이는 프리컴파일이나 ROM 기반의 구현 가능성을 열어 주었다. Ecma 총회는 컴팩트 프로파일 표준을 ECMA-327 [Vartiainen 2001]로 승인했다. ECMA-290과 달리, ECMA-327은 실제로 일부 환경에서 구현되었다. 하지만 ECMA-262의 새로운 판이 출시됨에 따라 ECMA-327을 업데이트하는 데 대한 관심이 부족해졌다. 당시 ECMA-262의 최신판은 매우 자원이 제한된 환경에서 구현되었다. 자원이 제한된 환경에서의 구현체가 특정한 기능을 제외해야 한다면 단순히 그렇게 하면 된다. 실제로 자원이 제한된 환경의 대부분의 애플리케이션에서 구현체 간의 완벽한 Javascript 상호 운용성은 필수적인 것으로 입증되지 않았다. Ecma 총회는 2015년에 ECMA-327을 표준으로 철회하기로 투표했다 [Ecma International 2015b].
2002년, TC39-TG1은 'XML용 ECMAScript' 명세를 개발하는 것에 대부분의 관심을 집중했다. E4X는 ES3에 XML 문서 처리를 지원하는 문법 확장을 추가한 별도의 Ecma 표준이었다. ECMA-357 [Ecma International 2004; Schneider et al. 2005]의 판들은 2004년과 2005년에 발행되었다. E4X는 파이어폭스에서 유일하게 구현되었 다. 그리고 브라우저 게임 이론에 따라서 E4X는 거의 사용되지 않았다. ECMA-357은 ECMAScript 2015와 호환되지 않았기 때문에 ECMA-357은 2015년 Ecma 표준에서 철회되었다[Ecma International 2015b].