JS? ES6? ES?
- 넷스케이프 커뮤니케이션즈에서 JavaScript를 선보였다.
- 1995년, 넷스케이프 커뮤니케이션즈는 정적인 HTML을 동적으로 표현하기 위해 JavaScript를 도입하게 되었다. (처음에는 Mocha, 그 다음에 LiveScript, 그 다음에 JavaScript가 되었다)
- 마이크로소프트에서 JScript를 선보였다.
- 그러나, JavaScript가 탄생한 뒤 얼마 지나지 않아, MS에서 자바스크립트의 파생 버전인 JScript를 출시하였다. 이로써 JavaScript가 위기를 맞기 시작했다.
- 더해서 1996년 8월, MS는 JScript를 IE 3.0에 탑재하였다. 그런데 문제는 JScript와 JavaScript가 표준화되지 못하고 적당히 호환되었다는 것이다. 왜냐하면 자사 브라우저의 시장 점유율을 점유하기 위해 자사 브라우저에서만 동작하는 기능을 추가했기 때문이었다.
- 크로스 브라우징 이슈가 발생하기 시작했다.
- 이로인해, 브라우저에 따라 웹 페이지가 정상 동작하지 않는 크로스 브라우징 이슈가 발생하기 시작했다. 이에 모든 브라우저에서 동작하는 웹 페이지를 개발하는 것은 무척 어려워졌다.
- 표준화된 JavaScript에 대한 필요성이 제기되기 시작했다.
- 이에 JavaScript의 파편화를 방지하고, 모든 브라우저에서 동일하게 동작하는 표준화된 JavaScript에 대한 필요성이 제기되기 시작했다.
- ECMA 인터내셔널이 JavaScript 표준화를 하게 되었다.
- 이를 위해 1996년 11월, 넷스케이프 커뮤니케이션즈는 컴퓨터 시스템의 표준을 관리하는 비영리 표준화 기구인 ECMA 인터내셔널에 JavaScript의 표준화를 요청하였다.
- ECMAScript
- 이에 1997년 ECMA-262라 불리는 표준화된 자바스크립트 초판(ECMAScript 1)의 명세(specification)가 완성되었고 상표권 문제로 자바스크립트는 ECMAScript로 명명되었다.
- 왜 ES6라고 부르는걸까?
- 2015년 ECMAScript 6(ECMAScript 2015)가 공개되었고 범용 프로그래밍 언어로서 갖추어야 할 let/const 키워드, 화살표 함수, 클래스, 모듈 등과 같은 기능들을 대거 도입하는 큰 변화가 있었다. 이에 2018년 기준 ES9 까지 나왔지만, 퉁쳐서 ES6라고 부른다.
JavaScript의 성장과 역사
- 한정적인 JavaScript의 역할
- 서버로부터 완전한 HTML을 전송 받아 웹 페이지 전체를 렌더링하는 방식으로 동작했다.
- 대부분 로직은 주로 웹 서버에서 실행되었고 브라우저는 서버로부터 전달받은 HTML과 CSS를 단순히 렌더링하는 수준이었다.
- Ajax
- 1999년, 자바스크립트를 이용해서 비동기적(Asynchronous)으로 서버와 브라우저가 데이터를 교환할 수 있는 통신 기능인 Ajax(Asynchronous JavaScript and XML) 가 XMLHttpRequest이라는 이름으로 등장했다.
- 서버로부터 필요한 데이터만을 전송 받아 변경이 필요한 부분만을 한정적으로 렌더링 할 수 있게 되었다.
- Google Maps
- 2006년, 구글이 발표한 Google Maps는 웹 애플리케이션 개발 프로그래밍 언어로서 자 바스크립트의 가능성을 확인하는 계기를 마련했다.
- 웹 브라우저에서 자바스크립트와 Ajax를 기반으로 동작하는 Google Maps 데스크톱 애플리케이션과 비교해 손색이 없을 정도의 퍼포먼스와 부드러운 화면 전환 효과를 보여 준 것이다.
- jQuery
- 2006년, jQuery의 등장으로 다소 번거롭고 논란이 있던 DOM(Document Object Model)을 보다 쉽게 제어할 수 있게 되었고 크로스 브라우징 이슈도 어느 정도 해결되었다.
- 이로 인해 당시 다소 까다로운 자바스크립트보다 배우기 쉽고 직관적인 jQuery를 더 선호하는 개발자가 양산되기도 했다.
- V8
- Google Maps를 통해 가능성이 확인된 자바스크립트로 웹 애플리케이션을 구축하려는 시도가 늘어가면서 보다 빠르게 동작하는 자바스크립트 엔진이 요구되었다.
- 2008년 등장한 구글의 V8 자바스크립트 엔진은 이러한 요구에 부합하는 빠른 성능을 보여 주었다.
- V8 자바스크립트 엔진으로 촉발된 자바스크립트의 발전으로 말마암아 과거 웹 서버에서 수행되던 역할들이 클라 이언트(브라우저)로 이동하였고, 이로써 웹 애플리케이션에서 프런트엔드 영역이 주목받는 계기가 되었다.
- C++로 작성되었으며 크롬에서도 사용 중이다.
- Node.js
- 2009년, 브라우저에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서 동작시킬 수 있는 자바스크립트 실행 환경인 Node.js의 등장으로 자바스크립트는 웹 브라우저를 벗어나 서버 사이드 애플리케이션 개발에서도 사 용되는 범용 프로그래밍 언어가 되었다.
- 웹 브라우저에서만 동작하는 반쪽짜리 프로그래밍 언어 취급을 받던 자바스크립트는 이제 Front-End 영역은 물론 백엔드 영역까지 아우르는 웹 프로그래밍 언어의 표준으로 자리잡고 있다.
지금의 JavaScript
V8 엔진과 Node.js 위에서 작동한다. Java가 모든 OS에서 똑같은 결과를 내기 위해 VM 환경 안에서 Runtime이 구동되듯이, 브라우저가 아닌 환경에서도 빠르게 작동하기 위해 V8 엔진과 Node.js 위에서 작동한다.
JavaScript 엔진은 V8 엔진 외에도 Rhino, SpiderMonkey 등이 있다. 그 중에서도 대중적으로 알려지고 많이 쓰이고 있는 것이 V8이다.
JavaScript는 Compile 언어일까, Interpreter 언어일까?
이 부분에 대해서 공부하면서 V8엔진과 다른 엔진들, JIT 컴파일러에 대해 알 수 있었다. 어떤 책에서는 컴파일 언어라 하고, 인터넷의 어떤 자료는 콕 찝어서 말할 수 없다고 한다. 이에 좀 더 찾아보았고 흥미로운 점을 알게되었다.
자바스크립트 엔진은 인터프리팅 하기 전에 그 코드를 먼저 컴파일한다
컴파일도 하고, 인터프리팅도 한다는걸까? 여러 자료를 보고 든 생각은 어떨 때는 맞고 어떨 때는 아니다 라는 것이었다. 그리고 어떨 때의 기준은 엔진 이라고 생각했다. JavaScript에는 다양한 엔진이 있다. 우리가 알고있는 가장 대표적인 V8 엔진 뿐만 아니라 Mozila 에서 java로 만든 Rhino 엔진, 최초의 JavaScript 엔진인 Monkey 엔진 등이 있다.
- V8 엔진은 인터프리터 없이 두 개의 컴파일러로 구성이 되어있다. (어떤 자료에서는 JIT 컴파일러로 되어있다고 하고, 어떤 자료는 아니라고해서 조금 혼란스럽다.)
- Rhino 엔진은 기본적으로 인터프리터, 부분적으로 자바 바이트코드로 컴파일 한다.
- Monkey 엔진은 컴파일러(JIT(Just in Time) )를 사용하고 있다. (다만 JIT도 순수한 컴파일러로 보기에는 어렵다)
예전에는 스크립트 언어에 대해 '이 언어는 인터프리터 언어고, 저 언어는 컴파일 언어다' 이야기할수 있었지만 사실 JIT 컴파일러와 VM의 등장이후 어느정도 경계가 흐려졌다고 한다. 따라서 하나로 콕 찝어서 말할 수는 없는 언어이며, 나는 개인적으로 엔진에 따라달라진다고 생각한다.
JIT
Just-In-Time(이하 JIT)의 약자이다. JIT 컴파일러는 인터프리터 언어와 컴파일러 언어의 장점을 취하고 단점을 버리기 위해 등장하였다.
- 컴파일 언어의 장/단점
- 장점: 최적화를 하기때문에, 반복문이 있다고 하여 속도가 느려지지 않는다.
- 단점: compile time에 최적화를 해야하기 때문에, 초기 구동 시간이 인터프리터 언어에 비해 오래걸린다.
- 인터프리터 언어의 장/단점
- 장점: compile을 하지 않고 runtime에 바로 해석하기 때문에 속도가 빠르다.
- 단점: 반복문과 같은 동일한 코드가 있어도 매번 번역해야 하기 때문에, 컴파일 언어에 비해 오래걸린다.
컴파일 언어의 장점과 인터프리터 언어의 장점을 고루 사용하게끔 도와주는 모니터
- 이처럼 컴파일 언어와 인터프리터 언어의 장/단점은 완전 상극이다. 이런 장/단점을 잘 조화시킨 방법은 모니터 이다.
- 모니터는 코드가 실행되는 것을 관찰하면서 해당 코드가 얼마나 많이 실행되고, 어떤 타입이 사용되는지를 기록한다. 먼저, 모니터는 인터프리터를 통해서 모든 것을 실행한다. 만약 같은 줄의 코드가 적은 횟수로만 실행되면, 그 코드는 따뜻하다(warm) 라고 칭한다. 만약 많이 실행된다면 뜨겁다(hot) 라고 칭한다.
- 어떤 함수가 따뜻해지기(warm) 시작하면 JIT는 그 함수를 컴파일 하기 위해 전송한다. 그 이후에 JIT는 컴파일된 정보를 저장한다.
- 만약 코드가 정말로 뜨겁다면(hot) – 코드가 아주 많은 횟수로 실행된다면 – 최적화를 더 하기 위해 추가적인 시간을 들일만한 가치가 있을 것이다. 모니터는 그 부분을 최적화 컴파일러에게 전송한다. 이 컴파일러는 또 다른 더욱 빠른 버전의 함수를 생성하며, 이 함수 역시 저장된다.
참고 자료
- JavaScript의 성장과 역사
- 지금의 JavaScript
'자바스크립트 JavaScript' 카테고리의 다른 글
| Closure (0) | 2023.01.18 |
|---|---|
| Scope (0) | 2023.01.18 |
| 실행 컨텍스트 (Execution Context) (2) | 2023.01.17 |
| JITC, Adaptive-JITC (0) | 2023.01.17 |
| 변수의 타입과 Scope, Hoisting, 함수 (0) | 2023.01.16 |