JavaScript


<syntaxhighlight lang="javascript" line="1">
document.write("Hello, world!");//HTML 문서에 출력된다.
alert("Hello, world!");//알림창으로 출력된다.
console.log("Hello, world!");//보통 F12(macOS의 경우에는 ⌘+⌥+I)를 누르면 보이는 콘솔 창에 출력된다.
</syntaxhighlight>

1 개요

프로그래밍 언어로, 정확히 말하자면 클라이언트 사이드 스크립트 언어(Client-side Script Language)에 해당된다. 특수한 목적이 아닌 이상 모든 웹 브라우저에 인터프리터가 내장되어 있다. 오늘날 HTML, CSS와 함께 웹을 구성하는 요소의 하나다. HTML이 웹 페이지의 기본 구조를 담당하고, CSS가 디자인을 담당한다면 JavaScript는 클라이언트 단에서 웹 페이지가 동작하는 것을 담당한다.[1].

썬 마이크로시스템즈에서 개발한 Java와는 별 관계가 없는 언어이다. 이름이 비슷하다고 같은 언어가 아니다. 사람들이 흔히 헷갈리는 부분 중 하나. 실질적인 구동 방식도 Java 가상 머신을 이용해서 돌리는 Java와, 브라우저 내에 스크립트 엔진이 존재하는 JavaScript는 완전히 다르다. 더불어 둘의 거의 유일한 유사점인 객체지향 조차 Java는 클래스, JavaScript는 프로토타입을 쓰는 객체지향으로 전혀 다르다. 햄이랑 햄스터가 다르고 인도가 인도네시아랑 다르듯이 원본 얼핏 보기에는 문법이 Java와 비슷한데, 이는 Java와 Javascript 모두 C에서 영향받은 C-Family 언어이기 때문이다. 중괄호로 구분하는 블럭, 세미콜론으로 줄이 끝남을 알리는 것, 변수 쓰는 법, 연산자 사용법 등 기초적인 문법이 C 문법과 크게 다르지 않다. 그렇기 때문에 이걸로 유사성을 규정짓기에는 무리가 많다.

2 역사

첫 탄생은 Brendan Eich라는 사람이 10일만에 설계한 것으로부터 시작한다. 처음에는 Mocha라는 이름이었지만 4달 만에 LiveScript라는 이름으로 개명하고 다시 3달 후에는 JavaScript라는 이름이 되어 오늘날까지 이어지고 있다. Java와 구문이 유사하기도 하고 해서 이름을 JavaScript로 명명했다...는 표면상의 이유고 그 속은 Java의 유명세를 타서 묻어가려고 의도적으로 만든 것이다.[2]

JavaScript의 초기 역사는 말 그대로 넷스케이프의 삽질기다. JavaScript는 본래 넷스케이프 서버에서 애플리케이션을 제작하기 위한 고수준 추상화 언어로 설계되어 LiveScript라는 이름으로 네비게이터에 포함되었다. 그러나 JavaScript는 당시 기준에서 무리한 추상화[3]를 시도했기 때문에 성능 문제가 많았다. 게다가 마케팅 좀 해보자고 붙인 이름인 JavaScript가 Java의 열화판이라는 느낌이라서 당시 개발자들 사이에서 이름으로 무시당했다[4]. 여기에 더해서 그나마 클라이언트용 JavaScript 엔진에 있던 시스템 자원 접근용 API[5]들이 보안사고의 원인이 되면서 삭제되는 과정에서, 별다른 보완 방법을 제시하지 못해 진정한 웹 전용 반쪽 언어로 찌그러지게 되었다. 그 후 네스케이프는 착실하게 망해갔고, 주요 API인 DOM은 마이크로소프트와 네스케이프의 자존심 싸움 속에서 조각나 버렸다[6].

그러던 것이 동적 웹 페이지의 요구와 맞물려 부활의 조짐을 보인다. 마이크로소프트에서 1999년에 처음으로 XMLHttpRequest 기능을 제공하기 시작했고, 모질라에서 이것을 흉내내어 비슷하게 구현하면서 2002년에는 브라우저 JavaScript에서 쓸 수 있도록 API에 노출시켰다. 이후 이것이 인기를 끌어 사실상 표준처럼 되고 AJAX 개발도 가능해지면서, 인터넷 신세계가 열리고 말그대로 대박이 났다.[7] 한편, JavaScript가 워낙에 유용했기 때문에 마이크로소프트는 인터넷 익스플로러 3.0에서부터 JScript라는 JavaScript 비스무리한 구현을 추가하였다. 이 때문에 인터넷 익스플로러에서만 동작하는 JavaScript(정확히는 JScript) 코드가 나타나는 등 중구난방이 될 위기도 겪었다. MS의 IE가 웹표준과 상반되는 행보를 하는 바람에 이후로도 한동안 IE 구버전용 코드와 웹킷 코드를 따로 짜야 했었긴 했지만(...)

파편화 문제는 ECMAScript[8]라는 표준안으로 관리되면서 해결되었다. 따라서 JScript든 JavaScript든 모두 저 표준 규격을 따르기 때문에 별 불편함 없이 프로그래밍할 수 있는 상태. 참고로 저 ECMAScript는 어도비 플래시의 액션스크립트 3.0 문법으로도 사용되고 있다.

Javascript의 성능 문제는 후술하겠지만 JIT 컴파일 방식을 도입한 구글의 V8이라는 JavaScript 엔진을 개발하면서 큰 폭의 성능 향상이 이루어졌다. 빠르고 쾌적하게 홈페이지 상의 구성 요소를 제어하고, 동적 웹 페이지 제작이 일반화되면서 하이브리드 앱, 웹 앱 등이 널리 개발되었다. 이에 따라 다양한 라이브러리, 프레임워크 등도 출시되게 되는 등 발전의 선순환이 이루어지고 있다.

현재는 진입 장벽이 낮고, 웹 개발자들이 많이 존재하기 때문에[9] 이들을 자신의 앱 생태계로 끌어오기 위해 다양한 플랫폼/OS 진영에서는 Javascript로 앱을 개발할 수 있도록 노력하고 있다. 웹 분야의 강자 구글은 당연하거니와, C#, C++로 앱을 개발하는 마이크로소프트 진영조차 Javascript 개발자를 지원하려 노력하고 있다.

3 개발 툴

날코딩 항목에서 서술되어 있듯, 웹 개발자들은 다양한 마크업 언어 및 프로그래밍 언어를 사용하기 때문에 통합 개발 환경보다는 텍스트 에디터를 사용하는 경우가 많다. 크롬이나 Firefox에는 개발자 도구를 지원하여 브라우저에서 개발을 돕기도 한다.#

텍스트 에디터로는 그냥 메모장을 사용하는 사람들도 있지만, 에디트플러스, 울트라에디트가 주로 사용되었었고, Notepad++라는 오픈소스 툴도 있다. 최근 GitHub의 Atom(에디터), MS의 Visual Studio Code, 어도비의 brackets 등의 오픈소스 에디터도 출시되고 있다. 자세한 내용은 텍스트 에디터 참고.

4 특징

JavaScript는 멀티-패러다임 언어로 명령형, 함수형, 객체지향형 언어다. 간혹 클래스가 없어서 객체지향이 아니라고 생각하는 사람들도 있으나[10] 프로토타입 객체지향으로 방식이 달라서 그렇지 객체지향 언어다. 또한 명령형 언어라 덜 그래보이지만 기본 바탕으로 함수형 언어의 패러다임을 따른다. 그래서 Continuation Passing Style 같은 함수형 언어 스타일로 프로그램을 짜면 아주 잘 돌아간다[11]. 그리고 함수형 언어답게 프로그램 시작부터 끝까지 람다 대수로 추상화된 익명함수만 이용해서 코딩할 수도 있다.

JavaScript는 동적 타이핑, 약타입 언어고, 간단한 문법에 코딩 방법이 비교적 유연하기 때문에 초기 진입장벽이 거의 없어서 쉽다고 이야기 되지만, 깊이 들어가보면 매우 변태적인 특이한 언어다.

JavaScript에서는 Function이 거의 전지전능하다.[12] 내부에 아무거나 다 때려 넣을 수 있는데, 일반 객체지향언어의 Class, Constructor, Method 모두 Function으로 구현된다.[13]

명령형 언어라서 짧은 동작들의 경우 절차적 프로그래밍을 해도 잘 돌아가는 것 처럼 보이지만 사실 객체지향 + 함수형 언어라는게 함정이어서 긴 코드를 짜보면 의외로 골치아프다.[14]. 예를 들어 웹브라우저나 node.js 서버에서도 JavaScript의 비동기 프로그램 작성시에는 스레드를 분기하여 작업을 분산 처리하거나 코루틴으로 작업을 대기 시키는 대신 컨티뉴에이션(+타이머)만 이용해 비동기 프로그램을 구현한다. 즉 싱글스레드 위에 시분할만 존재하고 무조건 1 프로세스 1 스레드로 작동한다. 스레드 분기와 코루틴 같은 추상화된 비동기 처리 자원에 익숙한 프로그래머들이라면 이러한 방식으로 인하여 꽤 고생할 수 있다.[15]

자동 형변환과 자료형이 비직관적이다. 간단한 예제를 통해 살펴보자. 이에서 영감을 받은 JSFuck 이란 자바스크립트 프로그래밍 스타일도 존재한다.

<syntaxhighlight lang="javascript" line="1">
$ 0.1 + 0.2 //number에 number를 더하면 number이다.
0.30000000000000004 //예상대로

$ +null
0 //null이 숫자로 변하는 기적의 형변환

$ [] + [] //빈 배열끼리 더하면
"" //빈 문자열이 된다

$ [] + {} //배열 + 오브젝트 = 문자열
"[object Object]" //오브젝트를 toString()한 문자열이 된다.

$ ++[[]][+[]]+[+[]]
"10" //???
</syntaxhighlight>
JavaScript는 웹에서의 광범위한 사용처에 비해서 진지하게 매달리는 개발자가 적은 편이다. 여기에는 여러 가지 이유가 있지만 근본적으로 주 용도가 클라이언트 측에서 작동하는 언어기 때문에 개발하면 무조건 오픈소스가 되어버린다는 점이[16] 문제로 작용하고 있다. 즉 내가 a라는 기능의 JavaScript 프로그램이 필요하다면 그 기능이 돌아가고 있는 사이트에서 소스를 받아다 적당히 고치면 구현할 수 있다는 것. 그래서 JavaScript는 퍼다 쓰는 것이 이득이고, 새로운 것을 만들면 손해라는 인식이 퍼졌던 것이다. 하지만 요즘은 JavaScript가 다시 주목받고 있다. 그 이유는 우선 복잡한 JavaScript를 이용한 대규모 웹 서비스들이 돈을 잘 벌고 있다는 것, 또한 CommonJS와 같은 유용한 API 라이브러리를 이용하여 JavaScript로 훌륭한 프로그램을 개발할 수 있게 되었다는 점 등이 있다.

아예 JavaScript에서 많이 쓰이는 여러가지 기능들을 포함해 넣어놓은 라이브러리도 여러 종 배포되고 있다. Prototype이나 jQuery는 꽤 유명한 JavaScript 라이브러리. 최근에는 구글의 AngularJS 또한 자주 쓰이는 편. 이 라이브러리들을 잘 익혀두면 직접 짜는 것보다 꽤 간단하게 기능을 불러 쓸 수 있다.

자바스크립트 생태계는 전반적으로 라이브러리에 절대적으로 의존하는 경향이 크다. 그 이유로는 1. 언어 자체의 기능이 빈약해서 외부 라이브러리의 의존 없이는 뭔가를 개발하기 힘들다는 점과 2. 동적 언어라는 특성상 언어의 자유도가 높아서 온갖 기상천외한 라이브러리가 많아서 선택의 폭이 넓다는 점이 있다. 그러다보니 자바스크립트 생태계에서는 그야말로 하룻밤이면 강산이 뒤바뀌는 난장판이 펼쳐지고 있다. 이 생태계 안에서 개발하면서 느끼는 피로감을 잘 표현한 글이 개발자들 사이에서 화제가 되기도 했다.

5 DOM[17]과 JavaScript

오늘날 JavaScript 프로그래밍이 가장 널리 쓰이는 분야는 클라이언트용 인터페이스 프로그램이다. 이 때 JavaScript는 웹브라우저에서 제공되는 DOM을 API로 사용하게 된다. 문제는 이 DOM이 심히 후진 물건이라는 것. 이벤트의 경우 브라우저마다 구현이 다르게 되고 있는 경우가 많고, 실질적으로 JavaScript용 API로 쓰이는 경우가 대부분인 주제에 JavaScript의 주요 문법 중 일부와 충돌하는 위엄을 자랑한다. 또 기능 설명을 보고 나면, 상식적으로 HTML 페이지 속 특정 엘레먼트를 찾아서 지정하는 기능이 강력 할 것 같지만, 실재로는 매우 부실하다.

다만 이러한 단점들은 오늘날 상당히 개선되었다. 문제는 워낙 개선폭이 컸던 탓에 IE8과 같은 구형 브라우저와 최근의 브라우저들 사이에 채울 수 없는 성능/기능상의 격차가 벌어졌다는 것. 아래 나온 jQuery도 최신 버전에서는 IE8 이하는 지원을 포기한 상태로 시작하고 있다.

이러한 DOM의 병맛에서 나온 것들이 위의 jQuery 같은 라이브러리다. DOM의 구조와 구현을 조금이라도 상식적으로 바꾸어보려고 발버둥 친 결과물인 것.

페이스북에서 Virtual DOM으로 클라이언트 사이드를 렌더함으로써 병맛 DOM을 해결하려 React를 내놓았다. MVC를 해결하려 Flux를 내놓았다. 고만해 미친놈들아! 그냥 Angular로 대동단결하자

6 CommonJS

비록 JavaScript 가 이용 가능한 자원이 한정적이고 Java 같은 이름이기는 해도 순수하게 프로그래밍 언어로서는 상당히 우수한 설계를 자랑[18]한다. JavaScript의 일급 객체는 함수를 포함[19]하며, 우수한 텍스트 표기법(JSON)[20]을 가졌으며, 람다식을 쓸 수 있고, 구조적으로 비동기 프로그래밍에 유리하다. 하지만 동시에 성능 문제를 해결하기 아주 어려운 설계이기도 했다.

그 때까지 JavaScript 엔진들은 모두 실시간 인터프리팅을 하고 있었는데, 모질라에서 SpiderMonkey 엔진에 JIT 컴파일 방식을 도입했다. 이는 JavaScript 엔진으로는 최초로 도입한 것이고, 이 때 알려진 것으로는 순수 JavaScript 성능만 기존 버전의 20~40배에 달했다. 그리고 구글 역시 V8이라는 JavaScript 엔진을 개발하면서 JIT 컴파일 방식을 도입하여 많은 성능 향상을 이뤄내면서 JavaScript의 성능 문제는 상당히 개선되었다. 이 후 마이크로소프트, 애플, 오페라 라는 업계에서 한가닥 하는 집단들이 경쟁적으로 고성능 JavaScript 엔진을 개발하게 되었다. 지구 수비대급 개발력에 떠밀려 성능문제가 해결된 JavaScript 는 과거에 상상도 못할 정도로 속도가 빨라져서 지금은 JavaScript 3D게임 엔진도 개발되고 있다.[21] 이러한 발전 속에서 과거 이루지 못한 JavaScript 의 범용 프로그래밍 진출을 도모하는 새로운 표준이 CommonJS다. 핵심은 간단해서, JavaScript에 파이썬과 유사한 모듈을 도입하도록 표준을 정하는 것이다. 이 CommonJS를 이용한 모듈식 확장을 하면 JavaScript 프로그램을 쉽게 구조화 할 수 있게 된다.

CommonJS의 현재 사양은 모듈 1.0 이다. 이 표준을 이용한 가장 유명한 플랫폼은 Node.js로 JavaScript를 이용한 서버다. 이 서버는 꽤 인기를 끌고 있는데, 웹의 프론트엔드와 백엔드를 동일 언어로 프로그래밍 함으로서 얻는 이득이 상당하고, 순수한 서버로서의 성능이 꽤 좋은 편이기 때문이다. 심지어 cluster 와 같은 모듈을 이용하면 멀티 프로세스[22]로 동작하는 서버도 만들 수 있다.

7 JavaScript와 관련 있는 것

  • jQuery: DOM Manipulating 라이브러리.
  • AngularJS: 클라이언트 사이드 웹 앱 프레임워크. 2.x 버전부터는 TypeScript를 이용해서 구현하는 강좌가 Google(?!)에서 선보였다.
  • React: 단방향 데이터 흐름과, Virtual DOM 개념을 도입한 UI 컴포넌트 라이브러리. Facebook에서 만들었으며, MVC 패턴에서의 V(View)를 담당한다.
  • 언더스코어: 리스트 해석, 고차 함수 집합 라이브러리. 홈페이지
    • Lo-Dash: 위의 언더스코어 라이브러리의 성능 개선 버전.
  • Node.js: 서버 사이드 JavaScript 엔진.
  • CoffeeScript: JavaScript의 문법을 개선한 신형 언어. 컴파일 결과로 JavaScript 코드를 내보낸다. 기존 JavaScript의 설계 결함을 극복할 목적으로 만들어졌다. 그러나 파이썬처럼 들여쓰기로 코드 블록을 구분하는 문법을 채택해 호불호가 갈리는 편이다.
  • Dart: 구글에서 발표한 JavaScript 문법을 개선한 언어. TypeScript보다 조금 빠른 시기에 발표했다.
  • TypeScript: 마이크로소프트에서 발표한 JavaScript에 정적 타입 개념을 추가한 신형 언어. 커피스크립트와 마찬가지로 컴파일 결과는 JavaScript이다. JavaScript 타입 시스템의 구멍을 메우기 위해 나왔다. 타입스크립트는 코드의 견고함을 강점으로 내세우고 있다. 현재는 AngularJS2에서 이 언어를 채택하면서 대세가 되었다. ECMAScript2015 표준도 구현되어 있으며 순수한 JavaScript와 문법적인 차이가 적다.
  • ECMAScript: 넷스케이프가 인터넷 상의 다양한 스크립트 언어를 하나로 묶기 위해 제시한 표준안. 이 스펙을 구현한 JavaScript 구현체로는 구글의 V8 엔진, 모질라의 SpiderMonkey, Microsoft의 Chakra 등이 있다. 실제로 JavaScript에만 적용되는 표준안이 아니라, IE의 JScript나 Adobe Flash ActionScript의 표준이기도 하다. 현재는 ECMAScript 2016의 표준안까지 나와있으며, 대부분의 JavaScript 런타임에서는 이 표준을 모두 구현한 상태는 아니다. 하지만 IE등의 구형 브라우저를 제외하고는 ES2015 표준까지는 적당히 구현이 되어있는 상태. 또한, 구현이 안된 브라우저를 지원하기 위해서 Babel이라는 컴파일러를 사용해서 ES2015를 사용할 수 있다.

8 웹과 자바스크립트

2016년 현재까지 웹 브라우저에서 사용할 수 있는 거의 유일한 언어이자 대체재가 존재하지 않는 언어이다. 일부 정적인 웹사이트는 자바스크립트를 사용하지 않고 만들 수 있지만 단순 애니메이션(애니메이션 gif, CSS 애니메이션)을 넘어서는 무언가를 하려면 자바스크립트가 반드시 필요해진다. 그런데 기존에 자바스크립트가 하던 일을 대신해줄 수 있는 다른 기술이 플래시 말곤 없다. 그나마 그 플래시의 액션스크립트도 결국은 자바스크립트이다. 그래서 네이티브 환경에서는 수십 종의 다양한 프로그래밍 언어가 사용되지만 웹 환경에서는 자바스크립트 사용이 강제되고 있다. 다른 언어로 기술된 소스 코드를 자바스크립트로 변환해 주는 컴파일러(트랜스컴파일러)가 있긴 하지만 어차피 최종적으로는 자바스크립트로 번역돼서 실행되기 때문에 웹 개발자가 자바스크립트를 피해갈 방법이 없다.

반면, 같은 웹 환경에서 사용되는 나머지 두 핵심 언어(마크업 언어)인 HTML과 CSS는 자바스크립트로 대체가 가능하다. 그 중 HTML은 웹 브라우저가 .js 파일을 직접 읽어 실행하지 못하기 때문에 최소한의 코드(script 태그 한 줄)는 필요하지만 CSS는 완전히 자바스크립트로 대체해서 기술하는 것도 가능하다. 성능과 편의성에서 손해를 보기 때문에 그렇게 하지 않을 뿐이다. 페이스북에서 개발한 React 라이브러리는 HTML과 CSS를 자바스크립트로 제어한다. jsx 템플릿 문법이 HTML을 닮아있긴 하지만 jsx transformer(babel 컴파일러 등)를 통과한 뒤에는 모두 자바스크립트 함수로 변환돼있는 것을 볼 수 있다. 네이티브 환경에서의 기계어와 같은 지위를 현재의 자바스크립트가 누리고 있는 셈이다. 2016년 현재까지 자바스크립트의 성능을 끌어올리려는 시도(asm.js등)는 있어도 자바스크립트를 대체하려는 시도는 이루어지지 않고 있다. 그나마 구글의 DART 언어가 대체를 시도하고는 있지만 2016년 현재까지는 Dart 언어도 트랜스컴파일러에 의해 자바스크립트로 번역되는 굴욕을 당하는 중이다. 자바스크립트를 거치지 않고 직접 Dart코드를 실행할 수 있는 브라우저는 구글 크롬 브라우저가 유일하다. 그나마도 구글 측도 싸움이 안 되는 걸 아는지 Dart언어를 기반으로 한 다른 프로젝트를 진행하지는 않고 있다.

9 기타

해외에서는 JavaScript를 결과물로 내보내는 컴파일러가 많이 등장하고 있다. 이와 함께 고성능을 요구하는 프로그램을 작동시키기 위해 가비지 컬렉터와 산술 연산을 지금보다 효율적으로 수행하기 위한 서브셋 개발이 진행중이다. LLJS(Low-Level JavaScript)와 asm.js가 대표적이다. 이러한 서브셋과 컴파일러는 C++ 같은 언어로 작성된 프로그램을 JavaScript로 컴파일 해서 돌릴 수 있게 한다. 또한 JSIL은 CIL과 .net 가상기계를 다시 JavaScript로 컴파일하는 프로젝트다. 이러한 방식을 사용한 예로, archive.org에서 제공하는 Classic PC Games Archive 가 있다. DOSBox, MESS를 clang -> LLVM -> JavaScript 으로 컴파일하여 웹 브라우저에서 구동하게 한 것. Core i5 정도의 컴퓨터라면 플레이하는 데 거의 지장이 없는 수준을 보여주어 흠좀무하다.

웹 애플리케이션의 개발 트렌드를 따라가다 보면 흥미로운 사실을 발견할 수 있는데, 웹 클라이언트 사이드 언어인 JavaScript를 사용하는 방식이 절차형에서 객체지향으로, 다시 함수형으로 이동하고 있다는 사실을 발견할 수 있다. 현재는 함수형에서 더 발전해 반응형(Reactive)으로 가고 있지만 반응형 설계는 이제 겨우 AngularJS에 적용된 정도이고 널리 사용되진 않는다. 참고로 JavaScript는 멀티패러다임 언어로, 절차형, 함수형, 논리형을 포함한 그 어떤 방식으로도 코딩이 가능하다. 단, 이걸 JavaScript 킹왕짱 만능 끝판왕 종결자로 생각해서는 안 된다. 나쁘게 말하면 잡탕이기 때문.

얼마 전까지만 해도 언어가 아닌 매크로로 취급됐는데, 이제는 독립적인 언어로 인정되고 있는 것은 더 이상 브라우저의 확장이나 플러그인만을 위한 것이 아닌, 서버형인 NodeJS(구글 V8 엔진)나 컴파일형인 Javascript .Net 같은 것들로 기인한 것이다. 아마도 머지않아 더글라스 크로포드(Douglas Crockford)의 주장과 요구대로 독립적인 언어로 선언이 될 수도 있을 것이다.

10 참고할 만한 곳

  1. ↑ 이 때문에 동적인 홈페이지가 필요없다면 JavaScript는 안 써도 된다. 그러나 2016년 현재 웬만한 홈페이지에는 동적인 요소가 들어가므로 거의 필수적으로 쓰이는 것이 현실.
  2. ↑ 당시에 Java가 유행을 타기 시작하니까 Sun microsystems(지금은 오라클로 인수됨)에게 트레이드 마크 라이센스를 빌려 왔다.라이센스
  3. ↑ 1990년대 중반에 발표된 언어가 요즘 새롭게 나오는 언어들 보다도 더 한 추상화를 자랑한다.
  4. ↑ 그때는 Java를 할 줄 알면 JavaScript를 몰라도 깔 수 있었다. 이름으로...
  5. ↑ 과거에는 브라우저의 JavaScript 엔진이 파일 시스템 같은 자원에 접근할 수 있었다.
  6. ↑ 이때 생겨난 것이 지금도 남아있는 크로스 브라우징 문제다. 혹자는 이 상황을 두고 고자 API가 정신분열을 일으킨 것이라 평하기도 한다(...)
  7. ↑ 물론 네스케이프는... 그 후신인 모질라 얘기가 나온 것에서 알 수 있겠지만 이미 망해서 구원받을 수 없는 상태
  8. ↑ 2015년 6월 기준 최신 문서 ECMA-262 edition 6 #
  9. ↑ 수준 낮은 개발자도 많다. 하지만 일단 질보다 양이 절실한 상황이라면 Javascript 개발자 풀이 매력적이다.
  10. ↑ 요즘은 별로 없으나 옛날에는 꽤 많았다.
  11. ↑ 물론 CPS 자체는 함수형 언어가 아닌 다른 언어들에도 적용 가능하다. 하지만 함수형 언어가 아닌 경우 CPS를 쓸 필요는 별로...
  12. ↑ 함수가 일급 객체인 것으로 JavaScript 뿐만 아니라 거의 모든 함수형 언어들의 일반적 특징이다. 근데 함수형 언어 자체가 비주류여서 C나 Java 프로그래머 관점으로 볼 때 충분히 특이하긴 하다.
  13. ↑ Douglas Crockford의 JavaScript 오브젝트 생성 패턴 참고. 심심하면 희대의 명저 JavaScript: The Good Parts(자바스크립트 핵심 가이드)도 읽어보자. 매우 앏은게 함정
  14. ↑ 물론 절차적 프로그래밍에 익숙한 사람 기준에서다.
  15. ↑ 반대로 JavaScript 커뮤니티에서는 싱글스레드와 컨티뉴에이션의 단순하고 투명한 작동 모델이 오히려 프로그램을 더 좋게 만든다는 의견도 있다.
  16. ↑ 브라우저로 소스를 전송해줘야 작동하므로 JavaScript로 만든 프로그램은 이용자가 항상 소스를 볼 수 있다.
  17. ↑ Document Object Model
  18. ↑ 물론 사람이 만든 것이라 설계 결함도 많이 있다.
  19. ↑ 이러면 함수가 인자로 함수를 전달받을 수 있어서 프로그래밍이 대단히 편리해진다.
  20. ↑ JavaScript Object Notation, 즉 JavaScript 객체 표기법으로 지금은 다른 언어들에도 도입되어 있다.
  21. ↑ 이런 3D 게임 같은 분야에서는 빠른 JavaScript 와 WebGL 등으로도 부족해서 이젠 모질라에서 asm.js 같은 서브셋까지 만들어서, 산술 연산이 거의 네이티브 코드에 가깝게 실행될 수 있도록 극한의 최적화를 하고 있다.
  22. ↑ fork