├── .gitignore ├── README.md ├── babel.config.js ├── docs ├── appendix │ ├── a-dramatis-persona.mdx │ ├── b-dramatis-corporationes.mdx │ ├── c-glossary.mdx │ ├── d-abbreviations-and-acronyms.mdx │ ├── e-timelines.mdx │ ├── f-december4-2005-javascript-announcement.mdx │ ├── g-issues-list-from-first-tc39-meeting.mdx │ ├── h-initial-proposed-ecmascript-version-2-new-feature-list.mdx │ ├── i-a-partial-e3-draft-status-report.mdx │ ├── j-january11-1999-consensus-on-modularity-futures.mdx │ ├── k-es4-reference-implementation-announcement.mdx │ ├── l-es42-approved-proposals-september-2007.mdx │ ├── m-ecmascript-harmony-announcement.mdx │ ├── n-harmony-strawman-proposals-may-2011.mdx │ ├── o-harmony-proposals-wiki-page-following-may2011-triage.mdx │ ├── p-tc39-post-es6-process-definition.mdx │ ├── q-the-evolution-of-ecmascript-pseudocode.mdx │ └── references.mdx └── paper │ ├── Part 1. The Origins of JavaScript │ ├── 2-prehistory.mdx │ ├── 3-javascript-10-and-11.mdx │ ├── 4-microsoft-jscript.mdx │ ├── 5-from-mocha-to-spidermonkey.mdx │ ├── 6-interlude-critics.mdx │ ├── README.mdx │ └── pictures │ │ ├── figure4.png │ │ ├── figure8.png │ │ └── mocha-console.png │ ├── Part 2. Creating a Standard │ ├── 10-naming-the-standard.mdx │ ├── 11-iso-fast-track.mdx │ ├── 12-defining-ecmascript-3.mdx │ ├── 13-interlude-javascript-doesnt-need-java.mdx │ ├── 7-finding-a-venue.mdx │ ├── 8-the-first-tc39-meeting.mdx │ ├── 9-crafting-the-specification.mdx │ └── README.mdx │ ├── Part 3. Failed Reformations │ ├── 14-dissatisfaction-with-success.mdx │ ├── 15-es4-take-1.mdx │ ├── 16-other-dead-ends.mdx │ ├── 17-flash-and-actionscript.mdx │ ├── 18-es4-take-2.mdx │ ├── 19-interlude-taking-javascript-seriously.mdx │ └── README.mdx │ ├── Part 4. Modernizing JavaScript │ ├── 20-developing-es31-es5.mdx │ ├── 21-from-harmony-to-ecmascript-2015.mdx │ ├── 22-conclusion.mdx │ ├── README.mdx │ ├── acknowledgments.mdx │ └── pictures │ │ └── figure34.png │ ├── abstract.mdx │ └── introduction.mdx ├── docusaurus.config.ts ├── package-lock.json ├── package.json ├── sidebars.ts ├── src ├── asset │ └── article.ts ├── components │ └── ArticleList │ │ └── index.tsx ├── css │ └── custom.css └── pages │ ├── index.module.css │ ├── index.tsx │ └── reference.md ├── static ├── .nojekyll └── img │ ├── docusaurus-social-card.jpg │ ├── docusaurus.png │ ├── favicon.ico │ ├── logo.svg │ ├── undraw_docusaurus_mountain.svg │ ├── undraw_docusaurus_react.svg │ └── undraw_docusaurus_tree.svg └── tsconfig.json /.gitignore: -------------------------------------------------------------------------------- 1 | # Dependencies 2 | /node_modules 3 | 4 | # Production 5 | /build 6 | 7 | # Generated files 8 | .docusaurus 9 | .cache-loader 10 | 11 | # Misc 12 | .DS_Store 13 | .env.local 14 | .env.development.local 15 | .env.test.local 16 | .env.production.local 17 | 18 | npm-debug.log* 19 | yarn-debug.log* 20 | yarn-error.log* 21 | original/* 22 | .DS_Store -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # JavaScript: The First 20 Years Translation 2 | 3 | Allen Wirfs-Brock, Brendan Eich가 저술하여 2020년 공개한 [JavaScript: the first 20 years](https://dl.acm.org/doi/pdf/10.1145/3386327)을 번역하는 작업입니다. 4 | 5 | JS는 왜 이렇게 되었는지에 대한 간략한 발표를 준비하다가 JS의 역사를 다룬 한글 자료가 많아지면 좋겠다는 취지에서 시작되었으며 Docusaurus로 배포되고 있습니다. 6 | 7 | 추후 설명이 추가될 예정입니다. 8 | 9 | 원본은 [ACM Digital Library](https://dl.acm.org/doi/10.1145/3386327)에서 확인할 수 있습니다. 10 | 11 | # 혹시나 읽을 분들에게 12 | 13 | 저는 전문 번역가가 아니며 개인적인 취미로 번역하는 작업입니다. 때문에 오타나 비문 등이 있을 수 있습니다. 또한 단순한 직역보다는 의미에 따라 의역하는 쪽을 선택하였습니다. 14 | 15 | 다만 기술 문서의 특성을 감안하여 문체나 뉘앙스까지 완벽히 옮길 수는 없더라도 내용의 정확성은 보장하고자 노력하였습니다. 그 과정에서 참고하게 된 문서들은 [참고 문서](https://js-history.vercel.app/reference)에서 확인할 수 있습니다. 16 | 17 | # 번역자 18 | 19 | [김성현](https://witch.work/), soakdma37@gmail.com 20 | 21 | # 기여 22 | 23 | [이창희](https://github.com/blurfx) 24 | 25 | # 번역 진행 상황 26 | 27 | 2023-12-21 번역 시작 28 | 29 | 2023-12-25 Introduction 번역 완료 30 | 31 | 2024-01-04 Part 1 번역 초안 완료 32 | 33 | 2024-01-20 Part 2 번역 초안 완료 34 | 35 | 2024-02-15 Part 3 번역 초안 완료 36 | 37 | 2024-04-02 Part 4 번역 초안 완료, docusaurus 환경 세팅 -------------------------------------------------------------------------------- /babel.config.js: -------------------------------------------------------------------------------- 1 | module.exports = { 2 | presets: [require.resolve('@docusaurus/core/lib/babel/preset')], 3 | }; 4 | -------------------------------------------------------------------------------- /docs/appendix/a-dramatis-persona.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 1 3 | slug: /appendix/a 4 | --- 5 | 6 | # A. 등장인물들 7 | 8 | | 이름 | 소속 | 역할/기여 | 9 | | :-------------------- | :---------------------------------- | :------------------------------------------------------------------------------------------------------- | 10 | | Marc Andreessen | NCSA
Netscape | Mosaic 웹 브라우저 개발자
Netscape 공동 창립자, Mocha를 위해 싸움 | 11 | | Jeremy Ashkenas | New York Times | CoffeeScript 언어 개발 | 12 | | Ihab Awad | Google | CommonJS 모듈 시스템 설계에 기여 | 13 | | Jan van den Beld | Ecma | 1992-2007 사무총장 | 14 | | Tim Berners-Lee | CERN, W3G | 월드 와이드 웹 발명자 | 15 | | Eric Bina | NCSA
Netscape | Mosaic 웹 브라우저 개발자
Netscape 공동 창립자 | 16 | | Leo Balter | Bocoup | ES6의 완료 이후 Test262 개발 주도 | 17 | | Norris Boyd | Netscape | 초기 SpiderMonkey 개발자 | 18 | | Robert Cailliau | CERN | HTML 스크립팅 옹호자, Javascript 비판자 | 19 | | Carl Cargill | Netscape | 표준 기여자, 1997년의 TC39 부의장 | 20 | | Jim Clark | Netscape | Silicon Graphics, Netscape 창립자 | 21 | | Andrew Clinick | Microsoft | 1998-1999 TC39 부의장, 조건부 컴파일 제안 | 22 | | Donna Converse | Netscape | ES1 사양의 첫번째 드래프트에 기여 | 23 | | Mike Cowlishaw | IBM | ES2, ES3 프로젝트 에디터, 10진수 연산 지지자 | 24 | | Douglas Crockford | Yahoo!, PayPal | JavaScript 전도사, ES42 반대자, JSON "발견" | 25 | | Kevin Dangoor | Khan Academy | ServerJS/CommonJS 프로젝트 시작 | 26 | | Ryan Dahl | Joyent | Node.js 최초 개발자 | 27 | | Chris Dollin | HP | Spice 언어 설계자 | 28 | | Patrick Dussud | Microsoft | Digital sanitation 엔지니어, JScript 가비지 컬렉터 개발 | 29 | | Jeff Dyer | Nombas/self
Macromedia/Adobe | ES4 지지자, ES3&ES41 기여자
ActionScript3 컴파일러, ES42 에디터 개발 | 30 | | Brendan Eich | Netscape
Mozilla | 최초 JavaScript 설계자 및 구현자
Mozilla CTO, ES4에 대한 노력 재시작, Harmony 기여자 | 31 | | Cormac Flanagan | Univ Cal Santa Cruz | 하이브리드 타입 시스템 전문가, ES42 설계 팀 | 32 | | David Fugate | Microsoft | Test262의 초기 ES5 단계 개발 주도 | 33 | | Richard P. Gabriel | Sun | Lisp 사용자, 시인; ECMA-262 언어 개요 섹션 작성 | 34 | | Andreas Gal | Mozilla | SpiderMonkey에 TraceMonkey 최적화 추가 | 35 | | Michael Gardner | Borland | ES1 작업 초안의 공동 편집자 | 36 | | Jonathan Gay | Macromedia | Flash를 만듦 | 37 | | Bill Gibbons | Netscape | ES3 작업 초안 편집자 | 38 | | Richard Gillam | IBM | I18N 작업 그룹 의장 (1998-2000) | 39 | | Gary Grossman | Macromedia/Adobe | ActionScript 설계자 | 40 | | Peter Hallam | Google | Traceur transpiler 개발자 | 41 | | Lars Thomas Hansen | Opera, Adobe | ES42 편집자 | 42 | | Dave Herman | Northeastern Univ
Mozilla | 박사과정, 프로그래밍 언어 의미론 학자, ES42 설계 팀, 모듈을 포함한 많은 ES6 프로포절의 챔피언 | 43 | | Graydon Hoare | Mozilla | ES42 설계 팀 | 44 | | Luke Hoban | Microsoft | 2011년부터 Microsoft의 TC39 대표단 주도 | 45 | | Waldemar Horwat | Netscape
Google | JS2/ES41 설계자 및 편집자
ES5&ES6 기여자 | 46 | | Chris Houck | Netscape | JavaScript 팀의 두번째 멤버; SpiderMonkey 작명 | 47 | | Mr. Huffadone | Callscan | 첫번째 TC39 회의 불참 | 48 | | Oliver Hunt | Apple | ES5&ES6 기여자 | 49 | | Scott Isaacs | Microsoft | DHTML 개발자, MS Live 프레임워크 설계자 | 50 | | Bill Joy | Sun | 해커, Sun의 공동 창립자; Netscape와의 JavaScript 작업의 경영 스폰서 | 51 | | Yahuda Katz | jQuery Fdn/Tilde | 모듈 챔피언, ES6 클래스 설계에 영향을 줌 | 52 | | Shon Katzenberger | Microsoft | ES1을 위한 많은 의사코드 알고리즘 개발 | 53 | | Kris Kowal | | CommonJS 모듈 시스템 설계자 | 54 | | Peter Kukol | Microsoft | JScript 파서 작성 | 55 | | Pratap Lakshman | Microsoft | ES42 반대자, ES5 에디터, ES5conform test suite 고안 | 56 | | Russell Leggett | es-discuss | 클래스에 대한 "안전 문법" 제안 | 57 | | Norbert Lindenberg | Mozilla | ECMA-402 1판 편집자 | 58 | | Julia Liuson | Microsoft | 비주얼 베이직 총지배인(GM); Wirfs-Brock의 상사 | 59 | | Steve Leach | HP | Spice 언어 설계자 | 60 | | Clayton Lewis | Netscape | Netscape JavaScript 팀의 첫번째 매니저 | 61 | | David McAllister | Adobe | 표준의 큰 기여자, Ecma CC 회원 2008-2011 | 62 | | Tom McFarland | HP | 국제화(i18n) 전문가 | 63 | | Sam McKelvie | Microsoft | 초기 JScript 인터프리터 개발자 | 64 | | Sebastian McKenzie | Emmerich Manual HS | 고등학생; Babel 트랜스파일러 개발 | 65 | | C. Rand McKinny | Netscape | 1번째 JavaScript 사양에 배정되었던 테크니컬 라이터 | 66 | | Mark S. Miller | Google | OCAP 전문가; ES5&ES6 기여자; Proxy 공동 챔피언 | 67 | | Neil Mix | es-discuss | ES5의 새로운 프로퍼티 속성 이름 제안 | 68 | | Anup Murarka | Spyglass | 1번째 TC39 회의에서 망설이며 보조 편집자 임명 | 69 | | John Neumann | Ecma | 표준의 큰 기여자; TC39 의장 2008-2015 | 70 | | Anh Nguyen | Netscape | 1번째 TC39 회의에서 Netscape 대표 | 71 | | Brent Noorda | Nombas | 임베디드 시스템을 위한 ECMAScript 방언 개발 | 72 | | Bob Nystrom | Google | Traceur 트랜스파일러 개발자 | 73 | | Jason Orndorff | Mozilla | ES6 모듈 로더의 프로토타입 제작 | 74 | | Adam Peller | IBM | ES5 기여자 | 75 | | Dave Raggett | HP/W3C | Spice 발명자 | 76 | | Thomas Reardon | Microsoft | 인터넷 익스플로러 개발 책임자 | 77 | | Sam Ruby | IBM | ES5&ES6 기여자; 10진수 연산 프로토타입 제작 | 78 | | Alex Russell | Dojo Foundation
Google | ES5 기여자, Google Chrome 웹 표준 주도; ES6 기여자 | 79 | | William Schulze | Macromedia | TC39-TG1 의장 2004-2005 | 80 | | István Sebestyén | Ecma | 사무총장 2007-2019 | 81 | | Dan Smith | Macromedia/Adobe | Flash 런타임 엔지니어링 디렉터 | 82 | | Edwin Smith | Macromedia/Adobe | ActionScript 2&3를 위한 AVM2 가상 머신 개발 | 83 | | Walter Smith | Microsoft | Apple NewtonScript 베테랑; JScript 사양의 all-nighter | 84 | | Randy Solton | Borland | 1번째 ES1 작업 초안의 공동 편집자 | 85 | | Maciej Stachkowiak | Apple | Safari/WebKit 개발자 | 86 | | Guy L. Steele Jr. | Sun | 원조 Scheme 애호가; ES1 프로젝트 편집자 | 87 | | David Stryker | Netscape | Core Technologies 부사장 | 88 | | Brian Terlson | Microsoft | ES6를 위한 Test262 개발 주도; 2015년 7월부터의 ECMA-262 편집자 | 89 | | Lee Thornason | Macromedia | JVM에서 동작하는 Flash 프로토타입 개발 | 90 | | Sam Tobin-Hochstadt | Northeastern Univ | ES6 모듈 공동 챔피언 | 91 | | Jim Tressa | Oracle | TC39에 컴포넌트 모델 소개 | 92 | | Isabelle Valet-Harper | Microsoft | 표준의 큰 기여자; Ecma 조정 위원회 회원 | 93 | | Tom Van Cutsen | Vrije Universiteit | ES6 기여자; Proxy 공동 챔피언 | 94 | | Herman Venter | Microsoft | ES3&ES41 기여자; JScript.net 개발자 | 95 | | Richard Wagner | NetObjects | TC39 내에서 JavaScript 컴포넌트 프로젝트 시작 | 96 | | Rafael Weinstein | Google | 4단계로 이루어진 TC39 개발 프로세스 제안 | 97 | | Rick Waldron | jQuery Fdn/Bocoup | TC39 노트 테이킹 체계화; ECMA-402 2판 편집자 | 98 | | Robert Welland | Microsoft | 최초의 JScript 개발자; JScript 사양의 all-nighter | 99 | | Chris Wilson | Microsoft | IE 플랫폼 아키텍트 | 100 | | Scott Wiltamuth | Microsoft | TC39 부의장; ES1 기술 작업 그룹 조사 위원 | 101 | | Allen Wirfs-Brock | Microsoft
Mozilla | ES42 반대자; ES5/5.1 편집자, ES6 편집자 | 102 | | Rok Yu | Microsoft | JScript 프로그램 매니저, 2004년 TC39-TG1 의장 | 103 | | Alon Zakai | Mozilla | Emscripten 개발 | 104 | | Boris Zbarsky | Mozilla | DOM 바인딩과 브라우저 표준 엔지니어 | 105 | | Kris Zyp | Dojo Foundation | ES5 기여자 | 106 | -------------------------------------------------------------------------------- /docs/appendix/b-dramatis-corporationes.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 2 3 | slug: /appendix/b 4 | --- 5 | 6 | # B. 등장 기업들 7 | 8 | | 이름 | 역할 | 9 | | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------ | 10 | | Adobe | 그래픽 툴 소프트웨어 업체. 2005년 Macromedia 인수 | 11 | | America Online (AOL) | 1998년 Netscape Communications Corp 인수 | 12 | | Apple | 컴퓨터, 모바일 기기 제조업체. Safari 브라우저 개발 | 13 | | Borland International | 소프트웨어 개발 도구와 컴파일러를 개발하는 주요 회사 | 14 | | CERN | 월드 와이드 웹이 처음 개발된 물리 연구 센터 | 15 | | Dojo Foundation | 오픈 소스 Dojo Toolkit를 홍보하는 비영리 단체 | 16 | | Ecma International | 스위스 기반의 컴퓨팅 관련 표준 기구 | 17 | | General Magic | 모바일 기기를 위한 혁신적이지만 상업적으로는 실패한 소프트웨어 플랫폼을 개발한 회사 | 18 | | Google | 인터넷 검색과 광고의 거물. Chrome 브라우저 개발 | 19 | | Hewlett-Packard (HP) | PC, 워크스테이션, 서버, 프린터를 생산하는 거대 기업 | 20 | | IEFT | 인터넷 엔지니어링 작업 그룹(Internet Engineering Task Force), 인터넷 표준을 만듦 | 21 | | IBM | 거대한 소프트웨어 서비스와 레거시 메인프레임 회사 | 22 | | ISO/IEC | 국제 표준 기구 | 23 | | Joyent | Node.js 개발 초기의 기업 호스트 | 24 | | Macromedia | Flash를 개발한 회사. 2006년 Adobe에 의해 인수됨 | 25 | | Microsoft Corporation | 개인용 컴퓨터 시스템과 응용 소프트웨어 업계의 지배적인 회사 | 26 | | MicroUnity | 1990년대 초반 비디오 미디어 프로세서를 개발했던, 투자를 많이 받은 회사 | 27 | | Mozilla Foundation | Firefox 브라우저를 개발하는 오픈 소스 개발재단. Netscape에서 파생됨 | 28 | | NCSA | UIUC의 국립 응용 슈퍼컴퓨팅 센터 | 29 | | Nombas | 스크립팅 언어를 개발한 회사. 내장형 자바스크립트 지원 | 30 | | Netscape Communications Corp | Netscape 브라우저를 개발한 회사. 1998년 AOL에 인수됨 | 31 | | Object Management Group(OMG) | 분산 객체 시스템을 위한 표준을 개발하기 위해 설립된 협력단체 | 32 | | Opera Software | Opera 브라우저 패밀리를 개발하는 회사 | 33 | | PayPal | 전자 결제 시스템을 개발한 회사. 2002-2014년 동안 eBay의 자회사였음 | 34 | | Silicon Graphics Inc. (SGI) | 고성능 그래픽 워크스테이션을 생산하는 회사 | 35 | | Spyglass | 모자이크 브라우저를 상업화하도록 NCSA에게 라이센스를 받은 일리노이의 소프트웨어 회사 | 36 | | Sun Microsystems Inc. | 컴퓨터 제조업체. Java를 개발함. 2009년 Oracle에 인수됨 | 37 | | SunSoft | Sun의 부서 | 38 | | TC39 | Javascript 표준화를 담당하는 Ecma International 기술 위원회 | 39 | | UIUC | 일리노이 어바나-샴페인 대학교(University of Illinois at Urbana-Champaign.) | 40 | | Yahoo! | 웹의 초기에 널리 사용되었던 웹 포털과 검색 엔진을 개발한 회사 | 41 | | WHATWG | 웹 하이퍼텍스트 응용 기술 작업 그룹(Web Hypertext Application Technology Working Group), 그리고 HTML 관련 표준을 개발하는 비공식 그룹 | 42 | | W3C | 월드 와이드 웹 컨소시엄(World Wide Web Consortium), Tim Berners-Lee가 이끄는 웹 표준을 만드는 기구 | 43 | -------------------------------------------------------------------------------- /docs/appendix/c-glossary.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 3 3 | slug: /appendix/c 4 | --- 5 | 6 | # C. 용어사전 7 | 8 | 9 | **ActionScript** 명사. ECMAScript의 방언으로 Adobe Flash 플랫폼에서 사용되는 10 | 프로그래밍 언어. 11 | 12 | 13 | 14 | **attribute** 명사. 1. ECMAScript 명세에서 객체 프로퍼티의 설정 가능한 특성. 2. HTML에서, 여는 태그 내의 동작 수정자. ``태그의 `href`와 같은 것이다. 15 | 16 | 17 | 18 | **AWK** 명사. Unix용으로 처음 만들어진 도메인 특화 텍스트 처리 언어 [Aho et 19 | al. 1988](/docs/appendix/references#aho-1988). 20 | 21 | 22 | 23 | **binding** 명사. 이름을 변수 또는 상수 값에 매핑하는 연결. 24 | 25 | 26 | 27 | **breaking-change** 명사. 기존 프로그램이 거부되거나 제대로 작동하지 않게 28 | 만드는 프로그래밍 언어나 플랫폼의 변경사항 29 | 30 | 31 | 32 | **browser wars** 명사. 브라우저 공급 업체들이 시장 지배를 위해 치열하게 33 | 경쟁했던 기간. 34 | 35 | 36 | 37 | **Chrome** 명사. Google에 의해 개발되고 배포된 웹 브라우저. 38 | 39 | 40 | **Chromium** 명사. Chrome 브라우저의 오픈 소스 코어. 41 | 42 | 43 | **class** 명사. 프로그래밍 언어 개념으로, 객체 그룹이 공유하는 공통 44 | 인터페이스와 구현을 정의하는 메커니즘. 45 | 46 | 47 | 48 | **classical inheritance** 명사. 객체가 클래스 정의 체인으로부터 상태와 동작을 49 | 획득하게 되는 상속 메커니즘. 50 | 51 | 52 | 53 | **CoffeeScript** 명사. JavaScript로 컴파일되는 프로그래밍 언어로 Jeremy 54 | Ashkenas에 의해 만들어졌다. 55 | 56 | 57 | 58 | **CommonJS** 명사. 브라우저 이외의 환경에서도 JavaScript 기술을 사용할 수 59 | 있도록 하기 위해 Kevin Dangoor에 의해 시작된 프로젝트. 60 | 61 | 62 | 63 | **compiler** 명사. 프로그램을 (일반적으로) 프로세서에서 직접 실행될 수 있는 64 | 기계 언어로 변환하는 엔진. 65 | 66 | 67 | 68 | **constructor** 명사. constructor function 항목 참조. 69 | 70 | 71 | 72 | **constructor function** 명사. 객체를 할당하고 초기화하는 JavaScript 함수로, 73 | `new` 연산자를 사용하여 호출될 수 있음. 74 | 75 | 76 | 77 | **cyclic garbage collection** 동사. 다른 곳에서는 도달할 수 없는 고립된 순환 78 | 구조에 할당된 공간을 회수할 수 있는 메모리 관리 과정. 79 | 80 | 81 | 82 | **Dart** 명사. 원래는 웹 브라우저에서 JavaScript를 대체할 목적으로 Google에 83 | 의해 개발된 클래스 기반 객체 지향 프로그래밍 언어. 84 | 85 | 86 | 87 | **declarative** 형용사. 원하는 결과의 특성을 기술하는 것에 기반한 프로그래밍 88 | 접근 방식. 89 | 90 | 91 | 92 | **delegation** 명사. 객체가 클래스 정의가 아닌 다른 객체로부터 상태와 동작의 93 | 일부 또는 전부를 획득하는 메커니즘. 94 | 95 | 96 | 97 | **discriminated union** 명사. 내부에 여러 대체 가능한 구조들이 들어 있는 98 | 데이터 레코드이며 실제 구조는 명시적인 태그 값을 통해서 정해진다. 99 | 100 | 101 | 102 | **destructuring** 명사. 배열이나 객체의 프로퍼티를 배열이나 객체 리터럴과 103 | 유사한 문법을 사용하여 참조하는 것. 104 | 105 | 106 | 107 | **desugar** 동사. 프로그래밍 언어의 문장이나 연산을 더 기본적인 문장과 108 | 연산으로 분해하는 것. 109 | 110 | 111 | **DevDiv** 명사. Microsoft의 개발자 도구 부서. 112 | 113 | 114 | **dynamic language** 명사. 실행 이전 시점에 프로그램의 분석을 거의 또는 전혀 115 | 요구하지 않는 프로그래밍 언어. 언어에서 지정한 대부분의 오류 검사는 실행 중에 116 | 발생하며, 일반적으로 동적 언어로 짜인 프로그램은 런타임에 구성되거나 수정될 수 117 | 있음; cf. _static language_. 118 | 119 | 120 | 121 | **dynamically typed** 형용사. 데이터 타입의 안전성 제약이 주로 프로그램 실행 122 | 시점에 검사되는 프로그래밍 언어. 123 | 124 | 125 | 126 | **es-discuss** 명사. ECMAScript의 발전을 논의하기 위한 공개 이메일 포럼. 127 | 128 | 129 | **ECMA-262** 명사. ECMAScript 언어 명세. 130 | 131 | **ECMA-402** 명사. ECMAScript 초기화 API 명세. 132 | 133 | **engine** 명사. 프로그램을 실행하는 메커니즘. 134 | 135 | 136 | **es4-discuss** 명사. `es-discuss` 이메일 포럼의 원래 이름. 137 | 138 | 139 | 140 | **ES.next** 명사. TC39 내에서 ECMA-262의 다음 버전을 가리키는 데에 때때로 141 | 사용된 용어. 142 | 143 | 144 | 145 | **exotic object** 명사. 모든 객체가 지원해야 하는 필수 내부 메서드 중 하나 146 | 이상이 없거나 기본 동작과 다른 방식으로 동작하는 JavaScript 객체; cf. ordinary 147 | object. 148 | 149 | 150 | 151 | **expando property** 명사. 객체 생성 후 객체에 동적으로 추가된 속성. 152 | 153 | 154 | 155 | **factory function** 명사. 새 객체를 생성해 반환하는 함수. 156 | 157 | 158 | 159 | **Firefox** 명사. Mozilla에 의해 개발되고 배포된 웹 브라우저. 160 | 161 | 162 | 163 | **first-class** 형용사. 데이터 값으로 사용될 수 있는 프로그래밍 언어 런타임 164 | 엔티티; 예를 들어, 변수에 할당되거나 함수 인자로 사용되거나, 함수에서 165 | 반환되거나, 자료구조에 저장될 수 있음. 166 | 167 | 168 | 169 | **Flash** 명사. 리치 인터넷 애플리케이션 및 기타 용도를 지원하는 Adobe의 170 | 멀티미디어 소프트웨어 플랫폼. 171 | 172 | 173 | 174 | **free variable** 명사. 참조할 수 있지만 로컬 스코프에서 정의되지 않은 175 | 바인딩의 변수 176 | 177 | 178 | 179 | **function** 명사. 하위 프로그램(subroutine); 프로그램의 매개변수화된 부분. 180 | 181 | 182 | 183 | **hackathon** 명사. 프로그래머들이 몇 일 동안 모여 프로젝트 협업을 하는 184 | 이벤트. 185 | 186 | 187 | 188 | **Harmony** 명사. ES42를 포기한 후 ECMA-262 개발을 위한 TC39의 189 | 코드명. 190 | 191 | 192 | 193 | **host object** 명사. Javascript 엔진에 의해 제공되는 객체 또는 객체 클래스로 194 | 호스트 애플리케이션 또는 플랫폼의 기능에 대한 접근을 제공함. 195 | 196 | 197 | 198 | **imperative** 형용사. 원하는 결과를 얻기 위해 수행될 일련의 단계들을 기술하는 199 | 계산 접근 방식. 200 | 201 | 202 | 203 | **inherit** 동사. 객체 지향 언어에서, 간접적으로 특성을 획득함. 204 | 205 | 206 | 207 | **inheritance** 명사. 객체 지향 언어에서, 객체가 일부 또는 전부의 데이터와 208 | 행동을 상속하는 메커니즘. 209 | 210 | 211 | 212 | **inherited property** 명사. 프로토타입으로부터 상속된 JavaScript 객체의 속성. 213 | 214 | 215 | 216 | **internal method** 명사. 객체의 시맨틱을 정의하는 메커니즘으로 사용자가 접근 217 | 가능한 부분이 아니다. 218 | 219 | 220 | 221 | **internal property** 명사. 객체 시맨틱의 일부를 정의하는데 필요한 상태를 222 | 저장하기 위해 내부 메서드가 사용하는 객체의 부분. 223 | 224 | 225 | 226 | **interpreter** 명사. 프로그램의 표현을 훑어 나가면서 통해 각 연산을 만나는 227 | 대로 수행함으로써 프로그램을 실행하는 엔진. 228 | 229 | 230 | 231 | **internationalization** 명사. 프로그램이 다양한 인간 언어, 문자, 작성 규칙을 232 | 처리할 수 있도록 하는 과정. 233 | 234 | 235 | 236 | **Internet Explorer** 명사. Microsoft에 의해 개발되고 배포된 웹 브라우저. 237 | 238 | 239 | 240 | **Java** 명사. Sun Microsystems에 의해 개발된 클래스 기반 객체 지향 프로그래밍 241 | 언어. 242 | 243 | 244 | 245 | **JavaScript engine** 명사. JavaScript 언어의 구현체. 246 | 247 | 248 | 249 | **JScript** 명사. Microsoft에 의해 구현된 JavaScript의 방언. 250 | 251 | 252 | 253 | **lambda expression** 명사. 식별자에 바인딩되지 않은 함수 정의. 받는 인자와 254 | 그걸 이용한 실행 또는 평가의 단계들을 정의하는 표현식이다. 람다 대수와 255 | Lisp에서 유래함. 256 | 257 | 258 | 259 | **leaky abstraction** 명사. 숨겨지거나 비공개여야 할 추상화의 세부 정보를 260 | 의도치 않게 드러내는 추상화. 261 | 262 | 263 | 264 | **mashup** 명사. 독립적으로 관리되는 서버에서 각각 도착하는 JavaScript 코드와 265 | 콘텐츠를 동적으로 결합한 웹 페이지. 266 | 267 | 268 | 269 | **membrane** 명사. 객체-능력(object-capability) 시스템에서 객체를 변조 방지한 270 | 상태로 보안 컨텍스트 간에 공유하기 위해 사용되는 메커니즘. 271 | 272 | 273 | 274 | **metaobject protocol** 명사. 객체 지향 언어에서, 언어에서의 기본적인 동작을 275 | 정의하고 접근하기 위한 잘 지정된 인터페이스. 276 | 277 | 278 | **method** 명사. 객체의 구성 요소인 함수. 279 | 280 | 281 | **Netscape Navigator** 명사. Netscape Communications에 의해 개발되고 배포된 웹 282 | 브라우저. 283 | 284 | 285 | 286 | **Mocha** 명사. JavaScript가 되었던 언어의 코드명; 또한, Netscape의 원래 287 | JavaScript 엔진의 이름. 288 | 289 | 290 | 291 | **Mosaic** 명사. NCSA에서 Marc Andreessen과 Eric Bina에 의해 개발된 웹 292 | 브라우저. 293 | 294 | 295 | 296 | **Node.js** 명사. 2009년 Ryan Dahl에 의해 처음 개발된 JavaScript 기반 서버 297 | 플랫폼. 298 | 299 | 300 | 301 | **nominal type system** 명사. 각 타입 정의가 고유한 데이터 타입을 도입하는 302 | 타입 시스템; 일부 객체 지향 언어에서는 클래스 정의가 명목 타입 정의로 취급됨. 303 | 304 | 305 | 306 | **non-normative** 형용사. 어떤 요구 사항도 정의하지 않는 표준 문서의 부분. 307 | 308 | 309 | **no-op** 명사. 아무 것도 하지 않는 연산. 310 | 311 | 312 | **normative** 형용사. 요구 사항을 정의하는 표준 문서의 부분. 313 | 314 | 315 | 316 | **object** 명사. 데이터와 동작을 일급 복합 엔티티로 그룹화하는 연산 장치; 317 | 객체를 정의하고 조작하는 메커니즘은 프로그래밍 언어마다 다름. 318 | 319 | 320 | 321 | **Opera** 명사. Opera Software에 의해 개발되고 배포된 웹 브라우저. 322 | 323 | 324 | 325 | **own property** 명사. 상속된 것이 아니라 객체에 직접 속해 있는 JavaScript 326 | 객체의 속성. 327 | 328 | 329 | 330 | **ordinary object** 명사. 모든 객체가 지원해야 하는 필수 내부 메서드에 대한 331 | 기본 동작을 가진 JavaScript 객체; cf. exotic object. 332 | 333 | 334 | 335 | **profile** 명사. 특정 장치, 플랫폼 또는 애플리케이션의 요구 사항에 맞춰 336 | 조정된 기능의 집합. 337 | 338 | 339 | 340 | **polyfill** 명사. 브라우저에서 제공해야 하지만 버전 차이 등의 이유로 지원하지 341 | 않는 API를 제공하는 라이브러리. 342 | 343 | 344 | 345 | **proper tail call** 명사. 호출한 함수로 제어를 전혀 반환하지 않는 꼬리 호출. 346 | 347 | 348 | **property** 명사. JavaScript 객체의 구성 요소. 349 | 350 | 351 | **property key** 명사. 객체의 특정 프로퍼티를 식별하는 데 사용되는 문자열 또는 352 | 심볼. 353 | 354 | 355 | 356 | **prototype** 명사. 다른 객체에 상속된 상태와 동작을 제공하는 객체. 357 | 358 | 359 | 360 | **prototypal inheritance** 명사. 객체가 프로토타입 체인에서 상태와 동작 일부 361 | 또는 전부를 획득하는 상속 메커니즘. 362 | 363 | 364 | **Safari** 명사. Apple에 의해 개발된 웹 브라우저. 365 | 366 | 367 | **sandbox** 명사. 호스트 환경과 다른 프로그램이 직접 데이터에 접근하거나 368 | 간섭하는 것을 방지하기 위해 프로그램이나 프로그램의 일부를 분리하는 메커니즘. 369 | 370 | 371 | 372 | **Secure ECMAScript** 명사. 보안 취약점이 될 수 있는 기능을 제거한 ECMAScript 373 | 방언. 374 | 375 | 376 | 377 | **self-hosting** 명사. 프로그래밍 언어 엔진 코드의 일부를 해당 엔진에서 378 | 구현하는 언어로 작성하는 것. 379 | 380 | 381 | 382 | **shadow** 동사. 상속된 특성을 재정의하지 않고 덮어쓰기. 383 | 384 | 385 | 386 | **Silverlight** 명사. 다채로운 인터넷 애플리케이션을 위한 Microsoft 플랫폼. 387 | 388 | 389 | 390 | **scope** 명사. 변수(또는 선언된 바인딩)가 참조될 수 있는 프로그램의 영역. 391 | 392 | 393 | 394 | **scope contour** 명사. 중첩된 스코프 그룹 내에서 단일 스코프의 표현. 395 | 396 | 397 | 398 | **scripting language** 명사. 컴퓨팅 시스템, 애플리케이션 또는 다른 언어로 399 | 정의된 연산 추상화 작업을 조율하는 데 쓰이는 프로그래밍 언어로 일반적으로 400 | 간단한 편이다. 401 | 402 | 403 | 404 | **SpiderMonkey** 명사. 1996년 이후 개발된 모든 Netscape 및 Mozilla 405 | 브라우저에서 사용되는 JavaScript 엔진. 406 | 407 | 408 | 409 | **static language** 명사. 실행 이전 시점에 프로그램의 일부 또는 상당 부분을 410 | 분석해야 하는 프로그래밍 언어. 언어에서 규정한 대부분의 오류 검사는 실행 411 | 이전에 발생하고 일반적으로 런타임에는 프로그램이 수정될 수 없다. cf. _dynamic 412 | language_. 413 | 414 | 415 | 416 | **statically typed** 형용사. 데이터 타입의 안전성 제약에 대한 집행이 주로 417 | 프로그램 실행 이전에 수행되는 프로그래밍 언어. 418 | 419 | 420 | 421 | **tail call** 명사. 메서드 내에서 메서드나 함수 호출을 하는 것이 메서드의 최종 422 | 동작이 되는 것. 이러한 호출의 구현은 메서드로의 제어 반환을 포함할 수도 있으나 423 | 필수적인 것은 아님. cf. proper tail call. 424 | 425 | 426 | 427 | **transpiler** 명사. 하나의 언어로 작성된 프로그램을 다른 언어로 컴파일하는 428 | 언어 프로세서. 429 | 430 | 431 | 432 | **type** 명사. 표현과 사용 가능한 연산 등의 공통 특성을 공유하는 값의 범주. 433 | 434 | 435 | 436 | **type annotation** 명사. 변수나 다른 바인딩에 타입을 연결하는 데 사용되는 437 | 문법적인 형태. 438 | 439 | 440 | 441 | **URL** 명사. 월드 와이드 웹 페이지의 주소. Uniform Resource Locator의 약자. 442 | 443 | 444 | 445 | **value** 명사. 프로그램이 조작하는 정보의 단위; 타입이 지정된 프로그래밍 446 | 언어에서는 값이 다양한 타입으로 분류됨. 447 | 448 | 449 | **V8** 명사. Chrome 브라우저에서 사용되는 JavaScript 엔진. 450 | 451 | 452 | **WebKit** 명사. Apple Safari 및 일부 다른 브라우저에서 사용되는 오픈 소스 453 | 브라우저 코어. 454 | 455 | 456 | 457 | **Web 2.0** 명사. 사용자 정의 콘텐츠에 초점을 맞춘 웹 애플리케이션 스타일; 458 | 대부분 사용자와 활발하게 상호작용하며 AJAX 기술을 사용하여 구축됨. 459 | 460 | 461 | 462 | **Web Reality** 명사. 현재 존재하는 월드 와이드 웹의 기술적인 면과 특성. 또한 463 | 현존하는 웹 페이지와 애플리케이션에 의해 사용될 때의 기술적인 부분과 특성. 웹 464 | 인프라 구조의 확장은 일반적으로 이러한 기존의 기술적 측면 및 특성을 그대로 465 | 유지할 수 있게 해야 함. 466 | 467 | -------------------------------------------------------------------------------- /docs/appendix/d-abbreviations-and-acronyms.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 4 3 | slug: /appendix/d 4 | --- 5 | 6 | # D. 약어와 두문자어 7 | 8 | **AJAX** Asynchronous JavaScript and XML 9 | 10 | **API** Application Program Interface 11 | 12 | **CC** Co-Ordinating Committee-Ecma International’s management committee 13 | 14 | **CLR** Common Language Runtime component of Microsoft .NET 15 | 16 | **CSP** Content Security Policy 17 | 18 | **CSS** Cascading Style Sheets 19 | 20 | **DHTML** Dynamic HTML 21 | 22 | **DOM** Document Object Model 23 | 24 | **GA** General Assembly-Semi-annual meeting of all Ecma members 25 | 26 | **GCC** GNU C Compiler 27 | 28 | **GWT** Google Web Toolkit 29 | 30 | **HTML** Hypertext Markup Language 31 | 32 | **IE** Microsoft’s Internet Explorer browser 33 | 34 | **IIFE** Immediately Invoked Function Expression 35 | 36 | **I18N** Internationalization (18 letters between "I" and "n") 37 | 38 | **JIT** Just In Time compiler 39 | 40 | **JVM** Java Virtual Machine 41 | 42 | **MOP** Metaobject Protocol 43 | 44 | **NCSA** National Center for Supercomputing Applications 45 | 46 | **OCAP** Object Capability 47 | 48 | **OMG** Object Management Group 49 | 50 | **POSIX** Portable Operating System Interface modeled on UNIX 51 | 52 | **RFP** Request For Proposal 53 | 54 | **SES** Secure ECMAScript 55 | 56 | **TC** A Technical Committee of Ecma International 57 | 58 | **TDZ** Temporal Dead Zone 59 | 60 | **TG** A Task Group within an Ecma International TC 61 | 62 | **VM** Virtual Machine 63 | 64 | **WG** A Working Group-an ad hoc group within an Ecma TC or TG 65 | -------------------------------------------------------------------------------- /docs/appendix/f-december4-2005-javascript-announcement.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 6 3 | slug: /appendix/f 4 | --- 5 | 6 | # F. 2005년 12월 4일 Javascript 발표문 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/g-issues-list-from-first-tc39-meeting.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 7 3 | slug: /appendix/g 4 | --- 5 | 6 | # G. 첫 TC39 회의의 이슈 목록 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/h-initial-proposed-ecmascript-version-2-new-feature-list.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 8 3 | slug: /appendix/h 4 | --- 5 | 6 | # H. 처음 제안된 ECMAScript 2의 새로운 기능 목록 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/i-a-partial-e3-draft-status-report.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 9 3 | slug: /appendix/i 4 | --- 5 | 6 | # I. E3 초안 상태 보고서 일부 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/j-january11-1999-consensus-on-modularity-futures.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 10 3 | slug: /appendix/j 4 | --- 5 | 6 | # J. 1999년 1월 11일 모듈 기능의 미래에 대한 합의 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/k-es4-reference-implementation-announcement.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 11 3 | slug: /appendix/k 4 | --- 5 | 6 | # K. ES4 참조 구현 발표 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/l-es42-approved-proposals-september-2007.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 12 3 | slug: /appendix/l 4 | --- 5 | 6 | # L. ES4.2의 승인된 제안 (2007년 9월) 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/m-ecmascript-harmony-announcement.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 13 3 | slug: /appendix/m 4 | --- 5 | 6 | # M. ECMAScript Harmony 발표문 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/n-harmony-strawman-proposals-may-2011.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 14 3 | slug: /appendix/n 4 | --- 5 | 6 | # N. 2011년 5월의 Harmony 초안 제안서 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/o-harmony-proposals-wiki-page-following-may2011-triage.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 15 3 | slug: /appendix/o 4 | --- 5 | 6 | # O. 2011년 5월의 분류에 따른 Harmony 제안서 위키 페이지 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/p-tc39-post-es6-process-definition.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 16 3 | slug: /appendix/p 4 | --- 5 | 6 | # P. TC39의 ES6 이후 프로세스 정의 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/appendix/q-the-evolution-of-ecmascript-pseudocode.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | sidebar_position: 17 3 | slug: /appendix/q 4 | --- 5 | 6 | # Q. ECMAScript 의사 코드의 발전 7 | 8 | [이 부록은 원문인 JavaScript: The First 20 Years를 참고한다.](https://dl.acm.org/doi/pdf/10.1145/3386327) 9 | -------------------------------------------------------------------------------- /docs/paper/Part 1. The Origins of JavaScript/2-prehistory.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 2. Javascript 이전 시대 3 | sidebar_position: 1 4 | slug: /part-1/prehistory 5 | --- 6 | 7 | # Javascript 이전 시대 8 | 9 | 월드 와이드 웹의 개념과 기반 기술들은 1989-1991년에 CERN의 Tim Berners-Lee[[2003]](/docs/appendix/references)에 의해 개발되었다. Berners-Lee의 웹 기술은 몇 년 동안 고에너지 관련 물리학 커뮤니티에서 알려졌다. 하지만 그 커뮤니티 외부에서는 큰 주목을 받지 못했다. 이 상황은 1992-1993년에 당시 학부생이었던 Marc Andreessen과 일리노이 대학교 어바나-샴페인 국립 슈퍼컴퓨팅 응용 프로그램 센터(NCSA)에서 일하던 Eric Bina가 _Mosaic_g를 개발하면서 변화하기 시작했다. 10 | 11 | NCSA Mosaic는 GUI를 갖춘 설치하기 쉽고 사용하기 쉬운 웹 클라이언트였다. 이것은 사실상 '웹 브라우저'라는 소프트웨어 분류를 정의했다. 또한 월드 와이드 웹의 개념을 물리학 커뮤니티의 외부에서도 유명하게 만들었다. Mosaic는 널리 배포되었다. 1994년 초, NCSA Mosaic의 라이센스를 얻거나 Mosaic에서 영감을 얻은 브라우저를 처음부터 만드는 데에 상업적 관심이 쏠렸다. 브라우저 열풍에 편승하기 위해서였다. Silicon Graphics Inc.의 창립자 Jim Clark는 벤처캐피탈 투자를 얻은 후 Marc Andreessen과 Eric Bina를 고용했다. 그리고 1994년 4월 그들은 나중에 Netscape Communications Corporation으로 불리게 될 회사를 공동 창립한다. Netscape는 NCSA Mosaic를 대체하는 브라우저를 만들고 그 브라우저를 세계에서 가장 인기있게 만드는 걸 목표로 삼았다. Netscape는 Mosaic와 비슷한 다음 세대의 브라우저를 맨 처음부터 개발했고 이를 1994년 10월 널리 배포하기 시작했다. 1995년 초까지 _Netscape Navigator_g는 초기 목표를 달성하고 Mosaic를 빠르게 대체하고 있었다. 12 | 13 | Tim Berners-Lee의 웹 기술은 선언적인(_declarative_g) HTML 마크업 언어를 사용하여 웹 페이지로 문서를 표시하는 데에 중점을 두었다. 반면 산업에서는 스크립트 언어(_scripting language_g)[[Ousterhout 1997]](/docs/appendix/references)를 사용하여 사용자가 애플리케이션의 동작을 직접 만들 수 있도록 하는 데에 상당한 관심이 있었다. Microsoft Office의 Visual Basic, AppleScript[[Cook 2007]](/docs/appendix/references)과 같은 언어들은 주요 애플리케이션의 핵심을 구성하는 복잡한 자료구조와 알고리즘들을 구현하기 위해 만들어진 게 아니었다. 이런 언어들은 사용자들이 애플리케이션의 이미 존재하는 구성 요소들을 사용자가 원하는 새로운 방식으로 결합할 수 있도록 했다. Netscape는 월드 와이드 웹을 더 많은 사람들에게 보급했고 그에 따라 스크립팅이 어떤 방식으로 웹 페이지에 통합되어야 할지는 중요한 질문이 되었다. 14 | 15 | ## 2.1. Brendan Eich가 Netscape에 합류 16 | 17 | Brendan Eich[^4]는 1985년 일리노이 어바나-샴페인 대학교에서 석사 학위를 마치고 즉시 Silicon Graphics Inc.(SGI)에서 일을 시작했다. 그는 주로 Unix 커널과 네트워크 계층에 관련된 일을 했다. 1992년에 그는 SGI를 떠나서 많은 투자를 받은 스타트업 MicroUnity에 합류했다. MicroUnity는 비디오 미디어 프로세서를 만드는 회사였다. 두 회사에서 Eich는 커널과 네트워크 프로그래밍 작업을 지원하는 작은 특수목적 언어를 구현했다. MicroUnity에서는 _GCC 컴파일러_g에 대한 작업도 조금 했다. 18 | 19 | 1995년 초 Brandon Eich는 "Netscape에 와서 브라우저에서 돌아가는 Scheme을 구현해라"[^5]라는 말을 미끼로 Netscape에 고용되었다. 그는 1995년 4월 3일에 Netscape에 합류했다. 그러나 그는 Scheme을 구현하게 되는 대신 웹 제품과 프로그래밍 언어 시장의 복잡한 상황을 마주하게 된다. Netscape는 1994년 말, Microsoft의 저가 인수 제안을 거절했다. 그 후 Netscape 경영진은 Microsoft의 "Embrace, Extend, Extinguish" 전략[[Wikipedia 2019]](/docs/appendix/references)에 의해 직접적으로 공격받을 것으로 예상했다. 당시 Microsoft는 Bill Gates의 직접적인 경영하에 있었는데, 그들은 웹이 크로스-OS 플랫폼으로 부상할 것을 깨달았다. 또한 그에 따라 Microsoft에서 곧 출시하려고 한 사설 환경의 정보 유틸리티인 Blackbird 프로젝트[[Anderson 2007]](/docs/appendix/references)가 무의미해질 것을 빠르게 깨달았다. Bill Gates의 "Internet Tidal Wave"[[Gates 1995]](/docs/appendix/references) 메모는 Microsoft의 방향을 Blackbird 프로젝트에서 _Internet Explorer_g와 서버 제품군 쪽으로 완전히 전환시켰다. 그 시점에 Netscape는 해당 시장을 점유하기 위해 서두르고 있었다. 20 | 21 | 웹 페이지에 쓰일 스크립트 언어 후보로는 Scheme과 같은 연구용 언어와 Perl, Python, Tcl과 같은 실용적인 Unix 기반 언어, 그리고 Microsoft의 Visual Basic 같이 독점권이 있는 언어들이 있었다. Brendan Eich는 브라우저에 Scheme을 구현할 것으로 예상했다. 하지만 1995년 초 Sun Microsystems는 아직 출시되지 않은[^6] Java 언어에 대한 기습적인 홍보 캠페인[[Byous 1998]](/docs/appendix/references)을 시작했다. Sun과 Netscape는 빠르게 협력하여 Java를 Netscape 2에 통합하는 계약을 체결했다. Eich는 Netscape 회의에서 Marc Andreessen이 "Netscape에 Java가 더해지면 Windows를 죽인다"라는 구호를 외쳤던 걸 회상했다. 1995년 5월 23일 Sun이 Java를 공개한 날, Netscape는 Java의 라이센스를 받아서 브라우저에 사용하려고 한다는 발표를 했다 [[Netscape 1995a]](/docs/appendix/references). 22 | 23 | Netscape 내부에서는 브라우저에 사용할 스크립트 언어를 고르기 위한 급박한 계획 수립이 있었다. 여기서 Scheme, Perl, Python, Tcl, Visual Basic은 후보에서 제외되었다. 이는 시장 출시까지의 시간과 사업적 이해관계로 인해서였다. Netscape와 Sun의 고위 관리자들, 특히 Marc Andreessen과 Sun의 Bill Joy는 Java를 보완하는 "작은 언어"[^7]를 설계하고 구현하는 것만이 가능하다고 생각했다. 24 | 25 | Sun과 Netscape의 주류에 해당하는 사람들은 간단한 스크립트 언어의 필요성에 대해 의문을 제기했다. Java는 스크립팅에 쓰기에는 적합하지 않은가? Java 하나만 있는 것보다 왜 2개의 언어가 있는 게 나은지 설명 가능한가? 그리고 Netscape가 새로운 언어를 만들 만큼의 충분한 전문성을 갖추고 있는가? 26 | 27 | 첫 번째 의문은 쉽게 반박되었다. 1995년 봄 당시 Java는 초보자에게 적합한 언어가 아니었다. 메인 프로그램의 코드 본문은 패키지의 _class_g 선언 내부의 `main`이라는 정적 _메서드_g내에 있어야 했다. 모든 매개변수, 리턴값 그리고 변수에는 정적 _타입_g을 선언해 주어야 했다. Visual C++을 보완하는 Visual BASIC, 그리고 네이티브 코드 기반의 컴포넌트를 보완하는 여러 Unix 언어의 경험을 기반으로 고려할 때, 이미 만들어진 컴포넌트들을 조립하는 역할을 할 스크립터들에게 있어 Java는 명백히 복잡했다. 28 | 29 | 두번째 의문은 Microsoft의 제품을 인용하는 것으로 극복할 수 있었다. Microsoft는 전문 Windows 애플리케이션 프로그래머들에게 Visual C++을 판매했다. 그리고 아마추어와 파트타임 프로그래머, 디자이너, 회계사 등에게는 Visual Basic을 판매했다. Visual C++로 만들어진 컴포넌트들을 덜 숙련된 사람들도 조립하고 커스텀할 수 있도록 해주는 스크립트 언어로서였다. "애플리케이션을 위한 Visual Basic"이라고 불린 Visual Basic 버전은 Microsoft Office 제품에 통합되어 오피스 제품들의 사용자 확장과 스크립팅을 지원했다. 30 | 31 | 처음의 두 가지 의문을 극복한 후 Marc Andreessen은 브라우저에 들어갈 스크립트 언어의 코드네임으로 "Mocha"를 제안했다. Eich에 의하면 이때 언어의 이름을 적절한 시점에 "Javascript"로 바꾸게 될 거라는 바람이 있었다고 한다. 아무튼 이 Java의 동반자격의 언어는 "Java처럼 보여야" 했고 그럼에도 사용하기 쉬워야 했으며 Java같은 클래스 기반이 아닌 "객체 기반"이어야 했다. 32 | 33 | 아직 스크립트 언어 개발에 반대하는 사람들이 제기한 마지막 하나의 의문점이 남아 있었다. Netscape가 효율적인 스크립트 언어를 만들고 1995년 9월의 Netscape 2 베타에 맞춰서 스크립트 언어를 준비할 수 있을 만큼 충분한 전문성을 갖추고 있는가? Mocha를 만드는 것으로 이걸 증명하는 것이 Brendan Eich의 과제였다. 34 | 35 | ## 2.2. Mocha의 이야기 36 | 37 | Java의 발표가 코앞이었다. 그래서 Brendan Eich는 이 스크립트 언어 개발에 있어서 시간이 가장 중요하다고 보았다. 그리고 불확실한 가능성보다는 확실하게 할 수 있는 부분을 택해야 한다고 보았다. 그런 생각을 바탕으로 그는 1995년 5월에 열흘 동안 최초의 _Mocha_g 구현체 프로토타입을 만들었다.[^8] 이 작업은 기한 안에 실행 가능성을 보여주기 위해 서둘러 진행되었다. 데모는 꼭 필요한 최소한의 언어 구현만으로 구성되었으며 Netscape 2 pre-alpha 버전 브라우저에 최소한으로 통합되었다. 38 | 39 | Eich가 만든 프로토타입은 Silicon Graphics Indy Unix 워크스테이션에서 개발되었다 [[Netfreak 2019]](/docs/appendix/references). 그 프로토타입은 수작업으로 만들어진 렉서와 재귀 하강 파서를 사용했다. 파서는 parse tree 대신 바이트코드로 변환된 명령어들을 출력했다. 바이트코드 _인터프리터_g는 간단하고 느렸다.[^9] 40 | 41 | 바이트코드는 Netscape의 LiveWire 서버[^10] 쪽의 요구사항이었다. 그쪽의 개발자들은 Mocha 프로토타입이 만들어지기도 전부터 Mocha를 내장할 걸로 생각하고 있었다. 그 팀에 있는 Borland 전 경영진과 엔지니어링 스태프들은 동적인 스크립트 언어의 강력한 지지자였지만, 더 빠른 서버 애플리케이션 로딩을 위해서 소스 파싱보다는 바이트코드를 원했다. 42 | 43 | Marc Andreessen은 Mocha가 사용하기 쉬워야 한다고 강조했다. 누구든지 HTML 문서 내에서 코드 몇 줄 정도는 바로 쓸 수 있을 정도로 말이다. Sun과 Netscape의 고위 경영진들은 Mocha가 "Java처럼 보여야 한다"고 되풀이해 요구했으며 BASIC과 비슷한 부분을 명시적으로 배제했다. 하지만 Java처럼 보이는 외관을 가지는 것은 Java와 비슷하게 동작하리라는 기대를 만들었다. 이는 _객체_g 모델의 설계와 `boolean`, `int`, `double`, `string`과 같은 "원시 타입"의 의미에 영향을 미쳤다. 44 | 45 | Java처럼 보여야 한다는 것을 제외하면 Brendan Eich는 언어 설계에 관한 세부 사항 대부분을 자유롭게 선택할 수 있었다. Netscape에 합류한 후 Eich는 HyperTalk [[Apple Computer 1988]](/docs/appendix/references), Logo [[Papert 1980]](/docs/appendix/references), Self [[Ungar and Smith 1987]](/docs/appendix/references)와 같은 사용하기 쉽고 교육적인 언어들을 탐구했다. Mocha가 객체 기반이 되어야 한다는 것에는 모두가 동의했다. 하지만 클래스는 없어야 했다. 왜냐 하면 클래스를 지원하는 것은 너무 오래 걸릴 뿐더러 클래스를 지원한다면 이미 클래스 모델을 갖추고 있던 Java와 경쟁해야 하는 위험이 생겼기 때문이다. Eich는 _위임_g과 단일 프로토타입 링크를 사용하는 동적인 객체 모델을 사용하기로 결정했다. 이는 Self 언어에서 영감을 받은 것이었다. 그는 이런 선택이 구현 시간을 절약해줄 것으로 생각했다. 하지만 결국 Mocha 프로토타입에서는 시간이 없어서 이 객체 모델을 넣을 수 없었다. 46 | 47 | 객체는 _생성자 함수_g에 `new` 연산자를 적용하여 생성할 수 있었다. 기본 객체 생성자 함수인 `Object`는 다른 내장 객체들과 함께 환경에 내장되어 있었다. 각 객체는 0개 혹은 그 이상의 속성들로 구성된다. 각 _속성_g은 이름(또는 _property key_g라고도 한다)과 값으로 구성된다. 이때 값은 _함수_g, 객체 또는 다른 내장 데이터 타입일 수 있다. 속성은 아직 사용되지 않은 속성 키에 값을 할당함으로써 생성됩니다. 속성에 대한 접근 제한이나 할당 제한은 없다(역주: private나 setter 같은 개념). 생성자 함수는 객체가 생성될 때 갖는 초기 속성 집합을 제공할 수 있다. 객체 생성 후에도 추가 속성을 객체에 추가할 수 있다. 매우 동적인 이러한 접근 방식은 특히 LiveWire 팀에게 좋은 반응을 얻었다. 48 | 49 | Scheme을 사용할 수는 없게 되었지만 Brendan Eich는 여전히 Lisp 스타일의 _일급_g 함수 개념에 매력을 느꼈다. 클래스가 없어서 메소드를 포함할 수는 없었지만 일급 함수는 Scheme의 영향을 받은 용법들을 구현할 수 있도록 해주었다. 최상위 레벨 프로시저, 함수를 인수로 넘기기, 객체의 메소드, 이벤트 핸들러 등이 그렇다. 시간이 부족해서 함수 표현식(_람다 표현식_g이라고도 불린다)의 구현은 연기되었지만 문법상에는 예약어로 지정되어 있었다. 이벤트 핸들러와 객체 메소드는 Java(그리고 C++)에서 가져온 `this` 키워드를 사용하여 통합되었다. 이 `this` 키워드는 메소드로 호출된 함수의 컨텍스트 객체를 나타낸다. 50 | 51 | 프로토타입은 프로그램 코드를 포함하는 문자열을 파싱하고 실행할 수 있는 `eval` 함수를 지원했다. 이는 Marc Andreessen과 초기 Netscape 엔지니어들과의 비공식적인 토론에서 동기를 얻은 것이었다[^11]. 여기에 담긴 직관은 런타임에 문자열을 프로그램으로 변환하는 이런 종류의 동적인 프로그래밍이 웹 브라우저와 서버의 몇몇 애플리케이션에서 중요해질 거라는 생각이었다[^12]. 하지만 `eval` 지원하기로 한 이 결정은 즉각적인 결과를 가져왔다. 몇몇 사용 사례에서는 Java와 비슷한 `toString` 메서드를 통해서 문자열 형식으로 함수의 소스 코드를 전달해야 했다. 52 | 53 | Eich는 10일간의 스프린트[^13]동안 바이트코드 디컴파일러를 구현하기로 결정했다. 필요한 몇몇 아키텍처를 위해서 소스 코드의 주요 저장소를 건드리거나 보조 저장소로부터 이를 복구하는 건 너무 비용이 많이 드는 연산으로 보였기 때문이다. 이는 Windows 3.1 개인용 컴퓨터에서 특히 그랬다. 이 컴퓨터는 Intel 8086 16비트 세그먼트 메모리 모델에 의해 제한되어 있었고 무제한 또는 큰 인메모리 구조를 위해 오버레이와 수동으로 관리되는 멀티-세그먼트 메모리가 필요했기 때문이다. 54 | 55 | ![그림 2. Mocha 콘솔](./pictures/mocha-console.png) 56 | 57 | > 그림 2. Mocha 콘솔. Brandon Eich가 만든 Mocha의 초기 데모에는 SGI Unix 워크스테이션에서 실행된 Netscape 2 pre-alpha 버전에서 구동되는 "Mocha 콘솔" 기능이 있었다. 이 Mocha 콘솔은 이름만 바뀐 채로 Netscape 2 정식 릴리즈에 포함되었다. 사진은 Windows 95에서 실행되는 Netscape 2.02의 화면 캡처다. Mocha 콘솔은 를 브라우저 주소창에 `mocha:`를 입력하는 것으로 활성화되었다. 정식 버전의 Netscape 2에서는 주소창에 `javascript:`를 입력하는 것로 바뀌었지만 `mocha:`도 여전히 작동했다. 콘솔을 활성화하면 브라우저에서 두 칸으로 이루어진 페이지가 열렸다. 아래 칸의 텍스트 박스에 입력된 Mocha 표현식은 위 칸의 컨텍스트에서 평가되고 실행되었다. 이 예시는 표현식의 값을 보여주는 팝업을 표시하기 위해 내장 `alert` 함수가 호출되는 것을 보여준다. 원래의 데모 버전에서는 "Javascript Alert" 대신 "Mocha Alert"가 표시되었을 것이다. 58 | 59 | 열흘의 프로토타이핑 기간 이후 Mocha 프로토타입은 Netscape의 전체 엔지니어링 스태프가 모인 회의에서 공개되었다(그림 2). 이는 성공적이었고 이 성공은 1995년 9월에 첫 베타 릴리즈가 예정되어 있던 Netscape 2가 더 완전하고 통합된 버전으로 나올 수 있을 거라는 과도한 낙관주의로 이어졌다. 그해 여름 Brendan Eich는 Mocha와 브라우저를 더 완벽하게 통합하는 것에 주로 초점을 맞췄다. 그러기 위해서는 Mocha 프로그램이 웹 페이지와 상호 작용할 수 있도록 API를 설계하고 구현해야 했다. 동시에 언어의 프로토타입 수준 구현을 상용 가능한 소프트웨어로 변환하고 Mocha를 초기에 사용한 내부 사용자들의 버그 리포트, 변경 제안, 기능 요청에도 응답해야 했다. 60 | 61 | 열흘간 진행된 Mocha 개발에 대한 더 많은 내용은 Brandon Eich가 그때 당시에 대해 이야기한 글에서 찾아볼 수 있다 [[Eich 2008c, 2011d; JavaScript Jabber 2014; Walker 2018]](/docs/appendix/references). Mocha의 프로덕션 버전 소스코드는 인터넷 아카이브에서 볼 수 있다 [[Netscape 1997b]](/docs/appendix/references). Jamie Zawinski[[1999]](/docs/appendix/references)의 "the netscape dorm"은 그 시절의 Netscape에서 소프트웨어 개발자로 일한 경험에 대한 동시대의 기록이다. 62 | 63 | [^4]: Eich의 초기 커리어에 대해서는 Coders At Work[[Seibel 2009, chapter 4]](/docs/appendix/references)라는 책에서 더 자세히 다루고 있다. 64 | [^5]: Scheme 언어에 대한 언급[[Sussman and Steele Jr 1975]](/docs/appendix/references) 65 | [^6]: Java의 스텔스 알파 릴리즈는 1995년 3월/4월이었다. 66 | [^7]: Jon Bentley [[1986]](/docs/appendix/references)는 작고 배우기 쉬운 언어를 묘사하기 위한 용어 "little language"를 다음과 같은 의미로 소개했다. "특정한 문제 도메인에 특화되어 있으며 전통적인 언어들에서 발견되는 많은 특징들을 포함하지 않는 언어" 67 | [^8]: 정확한 날짜에 대한 알려진 기록은 없다. Brandon Eich는 이것이 5월 6일에서 15일까지였다고 기억하고 있었다. 68 | [^9]: 데이터 _값_g을 나타내기 위해서 메모리를 많이 차지하는 _discriminated union_g을 사용했으며 메모리 관리에는 레퍼런스 카운팅 기법을 사용했다. 69 | [^10]: Brandon Eich는 Netscape에서의 첫 달 동안 공식적으로는 서버 그룹에서 일했다. 70 | [^11]: General Magic에서 일했던 John Giannandrea를 포함한다. General Magic은 2개의 프로그래밍 언어를 만들었으며 이 언어들은 클라이언트와 서버 두 분야 모두에서 쓰일 수 있었다. 71 | [^12]: 문자열을 동적으로 프로그램으로 변환함으로써, 예를 들어 form의 부분적인 평가를 하거나 클라이언트에서 제공된 코드를 서버에서 실행하는 걸 지원하도록 할 수 있었다. 이는 Telescript [[General Magic 1995]](/docs/appendix/references) 에이전트와 비슷했다. 72 | [^13]: 1995년의 개발자들은 "스프린트"라는 단어를 쓰지 않았다. 하지만 이 단어는 당시 Eich가 한 활동을 잘 묘사한다. 73 | -------------------------------------------------------------------------------- /docs/paper/Part 1. The Origins of JavaScript/4-microsoft-jscript.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 4. Microsoft JScript 3 | sidebar_position: 3 4 | slug: /part-1/microsoft-jscript 5 | --- 6 | 7 | # Microsoft JScript[^22] 8 | 9 | Microsoft는 Visual Basic을 "Visual Basic Script를 사용해서 월드 와이드 웹 기반 애플리케이션을 만드는 표준" [Wingfield 1995]으로 만들 계획임을 발표했다. Netscape와 Sun이 Javascript를 공식적으로 발표한 것과 같은 주였다. Microsoft는 1996년 5월 29일 Internet Explorer 3.0 베타 릴리즈에서 Javascript를 지원한다고 공식적으로 발표했다[Microsoft 1996]. 그 발표 내용은 다음과 같았다. 10 | 11 | > **ActiveX Script** Visual Basic® 스크립트와 Javascript에 대한 네이티브 지원을 통해 Microsoft Internet Explorer 3.0은 가장 포괄적이고 언어와 독립적인 스크립트 기능을 제공합니다. REXX, CGI, PERL과 같은 추가적인 스크립팅 언어를 지원하도록 Microsoft Internet Explorer를 확장할 수 있습니다. 웹 페이지 디자이너들은 HTML 코드에 스크립팅 언어를 삽입하여 ActiveX 컨트롤, Java Applet, 기타 소프트웨어 구성 요소들을 연결하고 사용자와 상호 작용하는 페이지를 만들 수 있습니다. 12 | 13 | 훗날 JScript라고 불리게 될 작업은 1995년 10월 Robert Welland가 Microsoft의 Internet Explorer(IE) 팀에 합류하면서 시작되었다. Welland는 이전에 Apple에서 Newton 휴대용 컴퓨터와 NewtonScript 언어 [Smith 1995]에 대한 작업을 하였다. NewtonScript는 Self 언어에 의해 영향을 받은 프로토타입 기반의 객체 지향 언어였다. Welland는 NewtonScript의 주요 설계자인 Walter Smith와 프로젝트에 컨설턴트로 참여했던 David Ungar와 긴밀하게 협업했었다. 그래서 Welland는 프로토타입 기반 언어에 대한 Ungar의 아이디어와 Self에 매우 익숙했다. Apple을 떠난 후 Welland는 브라우저에 어떻게 스크립팅 기능을 넣을지 고민해 왔다. 이는 Welland가 Internet Explorer에 스크립팅을 넣는 일을 하게 되는 계기가 되었다. 14 | 15 | Microsoft에 도착한 Welland는 IE에 Visual Basic을 넣어야 한다는 지시를 받았다. 하지만 그가 Microsoft의 개발자 도구 부서(_DevDiv_g)의 Visual Basic 팀에 문의했을 때 그 작업이 2년이 걸릴 것이라는 답변을 받았다. Welland와 Sam McKelvie는 IE2에서 Visual Basic for Applications[^23]을 실행시키는 작업을 빠르게 진행했지만, 브라우저의 객체 모델과 그걸 통합하기는 너무 복잡했다. Welland는 Netscape 2 공개 베타에서 LiveScript/Javascript를 보고는 Javascript를 위한 간단한 바이트코드 인터프리터를 실험하기 시작했고 McKelvie가 그것을 개선했다. Welland는 DevDiv의 Peter Kukol이 바이트코드를 생성할 수 있는 Javascript 파서[^24]를 작성한 것을 발견했다. Welland와 McKelvie는 그들이 만든 인터프리터와 Kukol의 파서, 그리고 Patrick Dussud가 작성한 가비지 컬렉터를 연결하여 JScript의 기초적인 구조를 만들었다. 16 | 17 | Microsoft의 DevDiv는 Microsoft의 모든 프로그래밍 언어와 개발자 도구의 개발을 담당하고 있었다. 그래서 Windows 부서의 IE 팀에서 일하는 Robert Welland와 Sam McKelvie가 새로운 언어 구현의 개발에 관여하는 것은 정치적으로 민감한 문제였다. 또한 IE가 Javascript를 지원해야 하는지에 대한 내부적인 논쟁도 있었다. DevDiv는 스크립팅을 위한 Visual Basic과 애플리케이션을 위한 Java에 집중하고자 했다. 그러나 IE 팀의 목표는 IE3이 Netscape 3와 호환되도록 하는 것이었다. 이를 위해서는 Javascript 지원이 필요했다. Microsoft는 Javascript를 지원해야 한다는 사실이 만족스럽지 않았지만 목표를 위해서는 해야 했다. 스크립팅에 Javascript와 Visual Basic을 지원하는 작업은 IE와 Microsoft 전부가 협력해서 진행하고 스크립팅 언어는 DevDiv가 담당하는 것으로 결정되었다. IE/Windows 팀은 브라우저와 기타 제품에 스크립팅 기능을 통합하는 걸 담당했다. 18 | 19 | 1996년 1월, Sam McKelvie는 DevDiv로 팀 이동을 했고 Robert Welland는 IE 팀에 남아 있었다. 또한 1월에는 Microsoft Word 팀에서 DevDiv로 옮겨온 Shon Katzenberger가 스크립팅에 관한 작업을 시작하였다. Katzenberger는 인터프리터를 담당하게 되었다. 그리고 Visual Basic 팀의 도움을 받아 해당 인터프리터에서 실행되는 Visual Basic의 스크립팅 언어 방언을 만들었다. 이는 이후 Visual Basic Script 또는 VBS로 알려지게 되었다. 20 | 21 | Welland와 McKelvie는 JScript와 VBS 모두를 지원하는 스크립팅 시스템을 임베딩 가능한 컴포넌트로 구성했다. 이는 Active Scripting이라는 이름으로 알려지게 된다. 이 컴포넌트는 1996년 IE3와 Microsoft의 웹 서버 제품인 IIS의 일부로 출시되었다. IIS는 Active Server Pages에 서버사이드 스크립팅 기술을 제공했다. Active Scripting은 이후 Microsoft Windows의 표준 구성 요소가 되었고 2019년까지 여전히 사용 가능했다. 레거시 애플리케이션 지원을 위해서였다. 22 | 23 | IE 팀은 Netscape와의 경쟁에 매우 집중하였다. 그들은 Active Scripting의 기능이었던 스크립트 디버거가 Javascript 웹 개발자들을 끌어들일 것으로 기대했다. Netscape에는 Javascript 디버거가 없었기 때문이다. 하지만 그들은 또한 IE가 받아들여지려면 Netscape 브라우저의 웹사이트와 상호 호환되어야만 한다는 것을 이해하고 있었다. Shon Katzenberger 등의 사람들은 Javascript를 사용하는 수천 개의 웹사이트에서 IE3의 개발 버전을 실행하고 Netscape 2, Netscape 3의 결과와 비교하였다. 차이점을 발견할 때마다 Katzenberger는 무엇이 어떻게 다르게 동작하는지를 이해하기 위해 Netscape Javascript 동작을 리버스 엔지니어링했다. 그들은 Netscape Javascript의 몇몇 동작들에 크게 놀랐다. 당시 Netscape의 구현에서는 HTML 프레임들이 공통 객체 주소 공간을 공유하고 객체들을 자유롭게 공유할 수 있었는데, 그들은 여기에 특히 놀랐다. IE는 각각의 프레임을 고립된 환경으로 구현했으며 객체들이 그들 간에 전달될 수 있도록 하려면 상당히 많은 재설계가 필요했다. 24 | 25 | JScript의 개발 과정 동안, 적절한 언어 명세의 부재는 늘 문제였다. Welland가 회상한 바에 따르면, Thomas Reardon은 언제나 Javascript 언어 명세가 없는 것을 불평하며 Netscape를 비난했다고 한다. Thomas Reardon은 IE3 개발 전반을 주도했던 사람이다. 26 | 27 | [^22]: 이 섹션의 대부분 자료는 2018년 3월 22일에 Allen Wirfs-Brock이 Robert Welland, Shon Katzenberger, Peter Kukol과 진행한 인터뷰 기록을 바탕으로 작성되었다 [Welland et al. 2018]. 28 | [^23]: Visual Basic for Applications는 Visual Basic 6의 변종으로 Microsoft 오피스 어플리케이션에 포함되었다. 29 | [^24]: 2018년 인터뷰 당시 Kukol은 자기가 최근에 Microsoft의 Javascript 팀에 방문했는데 그가 작성했던 파서 원본이 확장들과 함께 Microsoft의 그 시점 Javascript 구현과 여전히 사용되고 있는 것을 보았다고 이야기했다. 30 | -------------------------------------------------------------------------------- /docs/paper/Part 1. The Origins of JavaScript/5-from-mocha-to-spidermonkey.mdx: -------------------------------------------------------------------------------- 1 | --- 2 | title: 5. Mocha에서 SpiderMonkey까지 3 | sidebar_position: 4 4 | slug: /part-1/from-mocha-to-spidermonkey 5 | --- 6 | 7 | # Mocha에서 SpiderMonkey까지 8 | 9 | 1995년 전체와 1996년의 대부분 기간 동안, Brendan Eich는 Netscape에서 _Javascript 엔진_g[^25]을 담당하는 유일한 풀타임 개발자였다. 1996년 8월 Netscape 3.0의 프로덕션 릴리즈에 포함된 Javascript 1.1은 여전히 주로 1995년 5월의 열흘간 만들어진 프로토타입에서 나온 코드로 구성되어 있었다. 이 릴리즈 이후 Eich는 _엔진_g의 기술 부채[^26]를 청산하고 Javascript를 "더 깔끔한 언어"로 만드는 작업을 시작할 때라고 느꼈다. Netscape 경영진은 그가 언어 명세 작업을 하기를 원했다. 그들은 Javascript에 명세가 없다는 Microsoft의 비판에 민감했고 곧 시작될 표준화 작업 활동의 시작이 명세를 요구할 것으로 예상했다. Eich는 이에 저항했다. 그는 Mocha를 재구현하는 것부터 시작하고자 했다. 명세를 작성하려면 Mocha 구현을 신중하게 검토해야 했다. 그는 검토하면서 Mocha를 다시 작성하는 것이 가장 효율적일 것이라고 생각했다. 이는 또한 원본의 설계 실수를 명세에 넣어버리기 전에 고칠 수 있게 해줄 것이었다. 10 | 11 | 이 논쟁에 좌절한 Eich는 사무실을 떠나 2주 동안 집에서 일하면서 Javascript 엔진의 핵심부를 재설계하고 재구현했다. 그 결과는 더 빠르고, 더 신뢰할 수 있으며, 더 유연한 실행 엔진이었다. 그는 원래 Javascript의 값들을 discriminated uniong으로 표현했는데 이를 폐기하고 대신 원시값이 직접적으로 포함된 tagged pointer를 사용했다. 그리고 원래 엔진에는 포함되지 않았던 중첩 함수, 함수 표현식, switch문 등의 기능을 구현했다. 레퍼런스 카운팅 형식의 메모리 관리자는 마크 앤 스윕 가비지 컬렉터로 대체되었다. 12 | 13 | Eich가 사무실로 돌아왔을 때, 새로운 엔진은 Mocha를 대체했다. Netscape의 원래 개발자 중 한 명인 Chris Houck가 Eich와 함께 Javascript 팀의 두 번째 풀타임 멤버로 합류했다. Houck는 새 엔진을 "“SpiderMonkeyg"로 명명했다. 이는 영화 *Beavis and Butt-Head Do America*에 나오는 외설적인 대사에서 따온 거였다[Judge et al. 1996]. Clayton Lewis가 팀에 매니저로 합류했고 Norris Boyd를 고용했다. 테크니컬 라이터 Rand McKinny가 Eich의 명세 작성을 돕기 위해 배정되었다. 14 | 15 | Brendan Eich는 Netscape 4.0 릴리즈에 들어갈 Javascript 1.2를 계속 개선했다.그 첫번째 베타 릴리즈는 1996년 12월이었다. 정규 표현식은 1997년 4월 베타에 추가되었다. 다양한 플랫폼을 지원하는 Netscape 4의 프로덕션 릴리즈는 6월에 시작되어 1997년 하반기에 걸쳐 이루어졌다. 16 | 17 | - `do` 문 18 | - 문장 레이블과 레이블로의 `break`와 `continue` 19 | - `switch` 문 20 | - 중첩 함수 선언(렉시컬 스코핑) 21 | - 함수 표현식(람다 표현식) 22 | - `==` 연산자의 자동 형변환 규칙 삭제 23 | - 실제로 객체 프로퍼티를 삭제하는 프로퍼티 삭제 연산자 24 | - 객체 리터럴 25 | - 배열 리터럴 26 | - 정규 표현식 리터럴 27 | - 정규 표현식 매칭을 위한 메서드를 가진 `RegExp` 객체 28 | - 모든 객체가 가지고 있는 `__proto__` 의사 프로퍼티 29 | - 새로운 배열 메서드 `push`, `pop`, `shift`, `unshift`, `splice`, `concat`, `slice` 30 | - 새로운 문자열 메서드 `charCodeAt` 31 | - `RegExp`를 이용하는 `fromCharCode`(ISO latin-1), `match`, `replace`, `search`, `substr`, `split` 32 | - 함수의 `arity` 프로퍼티 33 | - 함수와 그 `arguments`가 서로 다른 객체가 되는 것 34 | - 함수의 형식 매개변수와 지역 스코프 선언은 함수의 `arguments` 객체를 통해 접근 가능 35 | - `arguments` 객체에 `callee` 속성 추가 36 | - `watch`/`unwatch` 함수 37 | - `import`/`export` 문과 signed script 38 | 39 | > 그림 10. Javascript 1.2의 새 기능들 40 | 41 | SpiderMonkey에 의해 구현된 Javascript 1.2 언어와 내장 라이브러리는 Javascript 1.0/1.1에 비해 상당한 개선을 이루었다. 그림 10은 Javascript 1.2의 주요한 새 기능들을 나열한 것이다[Netscape 1997c]. Javascript 1.2의 라이브러리 추가 사항 대부분은 다른 인기 있는 언어들의 기능에서 영향을 받은 것이다. 배열의 `concat`, `slice` 메소드는 Python의 시퀀스 연산에서 영감을 받았다. 배열의 `push`, `pop`, `shift`, `unshift`, `splice`는 비슷한 이름을 가진 Perl의 배열 함수를 직접적으로 따왔다. 문자열의 `concat`, `slice`, `search` 메소드는 Python에서 영향을 받았고, 문자열 `match`, `replace`, `substr`은 Perl에서 왔다. Java는 `charCodeAt`에 영향을 주었다. 정규 표현식과 문자열 매칭의 문법과 의미는 Perl에서 차용되었다. 42 | 43 | 문장 수준의 추가 사항들은 C 계열 언어에 익숙한 프로그래머들이 기대했지만 이전에는 빠져 있던 문장들을 제공했다. `do` 문은 C의 `do` 문의 문법과 유사한 의미를 직접 복제해왔다. Javascript 1.0에는 해당 기능이 빠져 있었다. 레이블 문과 `break`, `continue`에 레이블을 붙이는 것은 Java의 같은 기능을 모델로 삼았다. 해당 기능은 중첩된 반복문과 `switch`문에서 여러 중첩 레벨을 탈출하는 것을 가능하게 하고 비반복적인 코드 블럭에서 조기 탈출도 가능하게 한다. Javascript 1.2의 `switch`문은 C와 Java처럼 `case` 선택자 표현식의 컴파일 타임 평가를 포함하고 있었다[Eich et al. 1998, jsemit.c lines 757-776]. 44 | 45 | Javascript 1.0/1.1에서는 함수가 스크립트의 최상위 스코프에서만 전역 선언을 통해 정의될 수 있었다. Javascript 1.2는 다른 함수 내부에서 지역 선언을 사용해서 내부 함수를 정의할 수 있게 허용했다. 이런 내부 함수는 무제한으로 중첩될 수 있다. 내부 함수에는 렉시컬 스코프가 지정되며 내부 함수의 지역 선언은 외부 스코프에서 동일한 이름으로 선언된 것을 덮어쓴다. Javascript 1.0/1.1에서는 최상위 레벨의 `var`와 `function` 선언이 스크립트의 최상단으로 "끌어올려졌다(hoisted)". 그리고 함수의 지역적인 `var` 선언도 함수 본문의 시작 부분으로 끌어올려졌다. 그래서 변수와 함수가 선언되기 전에 참조하는 것이 가능했다. Javascript 1.2에서는 중첩된 `function` 선언도 해당 함수를 포함하는 외부 함수 본문의 시작 부분으로 끌어올려지게 되었다. 같은 이름을 가지는 `function` 선언이 2개 이상 있을 경우 이를 감싸는 함수 스코프의 소스코드 상에서 맨 마지막에 나오는 것이 이름에 바인딩된다. 46 | 47 | Javascript 1.2는 함수 정의가 표현식 형태로 나타나는 것을 허용함으로써 람다 표현식을 제공했다. 이들은 "함수 표현식"이라고 불렸다. 그리고 함수 이름이 선택 사항인 것을 제외하고는 함수 선언과 문법적으로 동일하다. 만약 이름이 있으면 함수 표현식은 바인딩 목적으로 스코프 최상단으로 끌어올려진 `function` 함수 선언으로 취급된다. 함수 이름이 없는 함수 표현식은 익명 함수를 정의한다. 어느 경우에든, 함수 표현식의 런타임 평가는 새로운 클로저를 생성한다. `arguments` 객체에 `callee` 속성을 추가함으로써 이러한 클로저들이 자기 자신을 재귀적으로 참조할 수 있게 되었다. 48 | 49 | 배열 리터럴과 객체 리터럴[^28]은 Python 언어의 유사한 기능에서 영감을 받았다. 배열 리터럴은 배열 객체의 요소를 생성하고 초기화하기 위한 간결한 문법을 제공한다. Javascript 프로그래머는 배열 리터럴을 사용하면 이렇게 작성할 수 있다. 50 | 51 | ```js 52 | var p2 = [1, 2, 4, 8, 16, 32, 64]; 53 | ``` 54 | 55 | > Javascript 1.2에서 56 | 57 | 원래 Javascript 1.1에서는 이렇게 해야 했다. 58 | 59 | ```js 60 | var p2 = new Array(); 61 | p2[0] = 1; 62 | p2[1] = 2; 63 | p2[2] = 4; 64 | // etc. 65 | ``` 66 | 67 | > Javascript 1.1에서 68 | 69 | 비슷하게 객체 리터럴은 객체를 생성하고 속성을 만들기 위한 간결한 문법을 제공했다. 객체 리터럴은 이렇게 작성할 수 있다. 70 | 71 | ```js 72 | var origin = { x: 0, y: 0 }; 73 | ``` 74 | 75 | > Javascript 1.2에서 76 | 77 | 원래 Javascript 1.0에서는 이렇게 해야 했다. 78 | 79 | ```js 80 | var origin = new Object(); 81 | origin.x = 0; 82 | origin.y = 0; 83 | ``` 84 | 85 | > Javascript 1.0에서 86 | 87 | 객체 리터럴과 함수 표현식의 조합은 클래스 없이도 메서드를 가지는 객체를 생성하는 것을 쉽게 만들었다. 예시로 다음과 같은 코드를 들 수 있다. 88 | 89 | ```js 90 | function Point(x, y) { 91 | return { 92 | x: x, 93 | y: y, 94 | distance: function (another) { 95 | return Math.sqrt( 96 | Math.pow(this.x - another.x, 2) + Math.pow(this.y - another.y, 2) 97 | ); 98 | }, 99 | }; 100 | } 101 | 102 | var origin = new Point(0, 0); 103 | alert(origin.distance(new Point(5, 5))); 104 | ``` 105 | 106 | > Javascript 1.2에서 107 | 108 | 객체 리터럴과 함수 표현식을 결합하면 프로토타입 객체를 더 편리하게 정의할 수도 있다. 또한 Javascript 프로그램이 객체의 프로토타입 객체 참조를 동적으로 접근하고 수정할 수 있도록 해주는 `__proto__` 의사 속성(pseudo-property)를 추가했다. 이 속성을 사용하면 각 객체가 상속된 속성에 접근하기 위해서 사용하는 내부 참조를 동적으로 접근하고 수정할 수 있다[^29]. `__proto__`를 사용하면 프로그램은 임의의 깊이의 상속 계층을 동적으로 구성하고 객체가 상속된 속성을 가져오는 출처도 동적으로 변경할 수 있다. 109 | 110 | Javascript 1.2의 일부 변경 사항은 결국 좋지 못한 결정이었던 게 드러났다. `import`와 `export` 문은 Netscape 4에서 제공된, Java와 호환 가능한 스크립트 서명 메커니즘(script signing mechanism)[Netscape 1997a]과 같이 사용하기 위해 만들어졌다. 서명된 스크립트에서 정의된 전역 변수들은 `export` 문을 사용해 명시적으로 내보낸 함수들을 제외하고 다른 스크립트에서는 접근할 수 없었다. (번역자: 지금의 private와 비슷한 기능으로 보인다) 이 기능은 Netscape 계열이 아닌 브라우저에서는 전혀 도입되지 않았다. 111 | 112 | Javascript 1.0/1.1의 `==`연산자의 자동 형변환 규칙은 사용자들의 요구사항이었음에도 불구하고, 일부 사용자들은 그 동작이 놀랍고 혼란스럽다는 것을 깨닫고 있었다. 브랜든 아이크는 Javascript 1.2에서 `==`연산자의 자동 형변환 규칙 대부분을 제거함으로써 `==` 연산자를 고치기로 결정했다 [Netscape 1997d; Rein 1997]. 두 피연산자가 동일한 원시 타입(숫자, 문자열, 불리언, 객체)이 아니라면 `==`는 `false`를 반환하도록 했다. 113 | 114 | Javascript 1.2에서는 여러 변경사항들이 있었는데, 이렇게 Javascript 1.0, 1.1로부터의 변화들은 `