02장. 자바스크립트

✅ 자바스크립트의 탄생 

1995년, 웹페이지의 보조적인 기능을 수행하기 위해 브렌던 아이크가 개발했다.
1996년 3월, '모카' 넷스케이프 내비게이터에 탑재
→ 96년 9월 '라이브스크립트' 변경
→ 96년 12월 '자바스크립트' 최종 명명

 

✅ 자바스크립트의 표준화 

자바스크립트의 파생 버전인 "JScript"와 자바스크립트가 표준화되지 못하고 적당히 호환되어 크로스 브라우징 이슈가 발생했다.
자바스크립트의 파편화를 방지하고 모든 브라우저에서 정상 동작하는 표준화된 자바스크립트의 필요성이 되두되었고, 1996년 11월 넷스케이프 커뮤니케이션즈는 컴퓨터 시스템의 표준을 관리하는 ECMA 인터내셔널에 자바스크립트의 표준화를 요청했다.

1997년 7월, ECMA-262라 불리는 표준화된 자바스크립트 초판(ECMAScript 1) 사양 완성
→ 1999년 ECMAScript 3(ES3) 공개
→ 2009년 ECMAScript 5(ES5) 출시, HTML5와 함께 출현한 표준 사양
→ 2015년 ECMAScript 6(ES6) 공개, let/const 키워드, 화살표 함수, 클래스, 모듈 등 범용 프로그래밍 언어로서 갖춰야할 기능을 대거 도입하는 큰 변화.
ES6 이후의 버전업은 비교적 작은 기능을 추가하는 수준으로 매년 공개할 것으로 예고되었다.

 

✅ 자바스크립트 성장의 역사 

1) Ajax(Asynchronous JavaScript and XML)

1999년, 자바스크립트를 이용해 서버와 브라우저 비동기 방식으로 데이터를 교환할 수 있는 통신기능인 Ajax가 XMLHttpRequest라는 이름으로 등장했다.

이전의 웹페이지는 html로 시작하여 html로 끝나는 완전한 html 코드를 서버로부터 전송받아 웹페이지 전체를 렌더링하는 방식으로 동작했다. 이러한 방식은 변경할 필요가 없는 부분도 서버로부터 다시 전송받아야 하기 때문에 불필요한 데이터 통신이 발생하고, 성능 면에서도 불리하다. 이로 인해 화면이 전환되면 깜빡이는 현상이 발생했고, 웹페이지의 한계로 받아들여졌다.

Ajax의 등장 이후, 변경할 필요가 없는 부분은 다시 렌더링하지 않고, 서버로부터 필요한 데이터만 전송받아 변경이 필요한 부분만 한정적으로 렌더링하는 방식이 가능해졌다. 웹 브라우저에서도 데스크톱 앱과 유사하게 빠른 성능과 부드러운 화면 전환이 가능해진 것이다.

 

2) jQuery

2006년, jQuery의 등장으로 DOM(Document Object Model)을 더 쉽게 제어할 수 있게 되었고 크로스 브라우징 이슈도 어느정도 해결되었다.

 

3) V8 자바스크립트 엔진

자바스크립트가 웹 애플리케이션 프로그래밍 언어로서의 가능성이 확인된 이후, 자바스크립트로 웹 어플리케이션을 구축하려는 시도가 늘며 빠르게 동작하는 자바스크립트 엔진의 필요성이 대두되었다.

2008년, 구글의 V8 자바스크립트 엔진은 이러한 요구에 부합하는 빠른 성능을 보여주었고, 이 덕분에 자바스크립트는 데스크톱 애플리케이션과 유사한 사용자 경험을 제공할 수 있는 웹 애플리케이션 프로그래밍 언어로 정착하게 되었다. 

 

4) Node.js

2009년, 라이언 딜이 발표한 구글 V8 자바스크립트 엔진으로 빌드된 자바스크립트 런타임 환경이다.
Node.js는 브라우저의 자바스크립트 엔진에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서도 동작할 수 있도록 독립시킨 자바스크립트 실행 환경이다. 다양한 플랫폼에 적용할 수 있지만 서버 사이드 애플리케이션 개발에 주로 사용되며, 이에 필요한 모듈, 파일 시스템, HTTP등 빌트인(내장) API를 제공한다.

Node.js는 자바스크립트 엔진을 기반으로 하므로 Node.js 환경에서 동작하는 애플리케이션은 자바스크립트를 사용해 개발한다.
프런트엔드와 백엔드 영역에서 모두 자바스크립트를 사용할 수 있다는 동형성은 별도의 언어를 학습할 시간을 덜 수 있다는 장점이 있다.

비동기 I/O를 지원하며, 단일 스레드 이벤트 루프 기반으로 동작함으로써 요청 처리 성능이 좋다. 따라서 Node.js는 데이터를 실시간으로 처리하기 위해 I/O가 빈번하게 발생하는 SPA(Single Page Application)에 적합하다. 하지만 CPU 사용률이 높은 앱에는 권장하지 않는다.

 

5) SPA 프레임워크

모던 웹 애플리케이션은 데스크톱 애플리케이션과 비교해도 손색없는 성능과 사용자 경험을 제공하는 것이 필수가 되었고, 개발 규모와 복잡도도 상승했다. 이로 인해, 이전의 개발 방식으로는 복잡해진 개발 과정을 수행하기 어려워졌고 이를 보완하기 위해 많은 패턴과 라이브러리가 출현했다. 그 덕에 많은 도움이 되었지만 변경에 유연하면서 확장하기 쉬운 애플리케이션 아키텍처의 구축이 어려웠고, 필연적으로 프레임워크가 등장했다.

이러한 요구에 발맞춰 CBD(Component based development) 방법론을 기반으로 하는 SPA가 대중화 되었다.

 

✅ 자바스크립트와 ECMAScript 

ECMAScript는 자바스크립트의 표준 사양인 ECMA-262를 말하며, 프로그래밍 언어의 값, 타입, 객체와 프로퍼티, 함수, 표준 빌트인 객체 등 핵심 문법을 규정한다. 자바스크립트는 이 모든 걸 아우르는 개념

 

✅ 자바스크립트의 특징 

자바스크립트는 웹 브라우저에서 동작하는 유일한 프로그래밍 언어.

기본 문법은 C, 자바와 유사하고, 셀프(Self)에서는 프로토타입 기반 상속을, 스킴(Scheme)에서는 일급 함수의 개념을 차용

자바스크립트는 별도의 컴파일 작업을 수행하지 않는 인터프리터 언어(Interpreter language).
+ 인터프리터 언어의 특징
1) 코드가 실행되는 단계인 런타임에 문 단위로 한 줄씩 중간 코드인 바이트코드로 변환한 후 실행
2) 실행파일을 생성하지 않음
3) 인터프러트 단계와 실행 단계가 분리되어 있지 않음. 한 줄씩 바이트코드로 변환하고 즉시 실행
4) 코드가 실행될 때마다 인터프리트 과정이 반복 수행
5) 인터프리트 단계와 실행 단계가 분리되지 않고 반복 수행되므로 코드 실행 속도가 비교적 느림

하지만 대부분의 모던 브라우저에서 사용되는 인터프리터는 복잡한 과정을 거치며 일부 소스코드를 컴파일하고 실행한다. 이를 통해 인터프리터 언어의 장점인 동적 기능 지원을 살리며 실행 속도가 느린 단점을 극복한다. 현재는 컴파일러와 인터프리터의 기술적 구분이 점차 모호해져 가는 추세다. 하지만 자바스크립트는 인터프리터의 도움 없이 실행할 수 없기 때문에 컴파일러 언어라고 할 수 없다.

 

이웅모, 『모던 자바스크립트 Deep Dive』 (위키북스, 2020)