JavaScript

{{{#!wiki style="margin-right:10px;margin-left:30px"

이 문서는 비로그인 사용자의 편집이 제한되어 있습니다. 자세한 사유는 여기를 참고하시기 바라며, 편집을 원하는 비로그인 사용자는 편집 요청 기능을 이용해 주시기 바랍니다. 단, 편집 제한이 적용된 문서는 편집 요청 또한 제한될 수 있습니다.

}}}

{{{#!html <div style="margin-left:50px;"><b style="font-size:14px">

이 문서는 <a href="/w/나무위키 컴퓨터 프로젝트">나무위키 컴퓨터 프로젝트</a>에서 다루는 문서입니다. </b><br /> 해당 프로젝트 문서를 방문하여 도움이 필요한 문서에 기여하여

주세요!</div>}}}

TIOBE에서 선정한 프로그래밍 언어 월간 점유율 순위 (2016년 6월 기준)

자세한 내용은 이곳에서 확인 할수 있으며, 점유율을 정하는 기준은 다음과 같다.
7월 2일 기준으로 아직 갱신되지 않았다. 갱신되었다면 틀:프로그래밍 언어 월간 점유율 순위를 통해 갱신 바람.

1. Java

2. C

3. C++

4. Python

5. C#

점유율 20.794%
작년 대비 2.97% 증가

점유율 12.376%
작년 대비 4.41% 감소

점유율 6.698%
작년 대비 1.56% 감소

점유율 3.900%
작년 대비 0.1% 감소

점유율 3.786%
작년 대비 1.27% 감소

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

1. 개요
2. 역사
3. 개발 툴
4. 특징
5. DOM 과 JavaScript
6. CommonJS
7. JavaScript와 관련 있는 것
8. 웹과 자바스크립트
9. 기타
10. 참고할 만한 곳

1. 개요

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

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

2. 역사

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

JS는 본래 넷스케이프 서버에서 애플리케이션을 제작하기 위한 고수준 추상화 언어로 설계되어 LiveScript라는 이름으로 네비게이터에 포함되었다. 그러나 JS는 당시 기준에서 무리한 추상화[3]를 시도했기 때문에 성능 문제가 많았다. 게다가 마케팅 좀 해보자고 붙인 이름인 JS가 Java의 열화판이라는 느낌이라서 당시 개발자들 사이에서 이름으로 무시당했다.[4] 여기에 더해서 그나마 클라이언트용 JS 엔진에 있던 시스템 자원 접근용 API[5]들이 보안사고의 원인이 되면서 삭제되는 과정에서, 별다른 보완 방법을 제시하지 못하는 등 한계가 여실했다.

하지만 JavaScript의 막강한 기능은 웹 브라우저의 각 벤더 사에서 필수적으로 구현할만큼 성장해갔다. MS에서는 이를 채택함과 동시에 자사만의 문법을 끼워 넣어 JScript를 탄생시켰다. 넷스케이프가 여러 문제에도 불구하고 점유율을 막대하게 차지해가던 어느 95년 중반, MS가 Windows 95 Plus에서 IE 1.0를 선보였다. 이것이 바로 제 1차 브라우저 전쟁이라 불리는 사건의 시작이다.[6]

제 1차 브라우저 전쟁에서 MS는 OS 점유율을 늘려감에 따라 사용자들을 IE를 사용하도록 지속적으로 유도하였고, 이에 버티지 못한 넷스케이프는 기어코 망하고 만다.

MS에서 1999년에 본래 아웃룩에서 쓰였던 IXMLHTTPRequest라는 이름으로 XMLHTTP wrapper로서 xml request 기능을 제공하기 시작했다. 넷스케이프의 후예를 자처하는 모질라 재단에서도 이것을 2002년에 구현시켰다. 이후 주목 받지 못하고 있다가 구글에 의해 String 기반의 Data 전송 방식을 AJAX라는 이름으로 조합해 선보이면서 AJAX 인터넷 신세계가 열리고 말 그대로 대박이 났다.

이렇듯 JS는 각 벤더 사마다 다른 것이 문제인 것을 글을 읽으면 쉽게 알 수 있을 것이다. 하지만 이를 단일화한 움직임은 이미 97년 ECMA TC39라는 문서를 통해 시작이 되었지만, 각 벤더(특히 MS)의 비협조적인 태도로 인해 글러 먹게 생겼었다. 그러다가 두 번째 브라우저 전쟁이 발발한 후 구글한테 처참하게 발린 MS가 깽깽 거리고 나서야 ECMAScript(이하 ES) 5가 제정되고 표준 문제가 '다소' 해결되었다.[7]

참고로 저 ES는 어도비 플래시액션스크립트 3.0 문법으로도 사용되고 있다.

한편 그렇게 표준화를 거친 JS는 AJAX, jQuery 등의 등장으로 거침없는 발전을 보였고, 기어이 Node.js의 등장으로 Server side 언어로서 탈바꿈하게 된다. JIT 컴파일 방식을 도입한 구글의 V8이라는 JavaScript 엔진을 개발하였고, ES6 구현율이 당시 80% ~ 현재 96%에 달하면서 CommonJS, AMD 진영 등의 등장도 나타났다. 과거의 JS와 비교해 보면 격세지감마저 들 정도로 그야말로 장족의 발전이다.

2016년 즈음 이후 국내에서도 점점 ES6가 많이 쓰이고 있는 추세다. ES6를 구현하지 않은 브라우저들을 위해 트랜스파일러라는 일종의 컴파일을 거쳐 제공되고 있으며, 카카오스토리[8]나 네이버 밴드[9] 등이 그 대표적인 예이다. 현재는 대부분의 주요 브라우저들이 ES6 구현 100%를 달성한 상태. 다만 해외나 국내나 ES5로 짜여진 코드가 워낙 많고 다수의 JavaScript 입문서 역시 ES5 기준으로 짜여진 경우가 대부분이라 당분간 ES6가 ES5의 자리를 완전히 대체하기는 어려울 것으로 예상된다.

ES5 기준의 JS는 디자이너들에게도 교육이 되고 있는 만큼 진입 장벽이 타 언어에 비해 낮은 편으로 인식되고 있다. 해외는 front-end 전담 개발자가 있을 만큼 전문화되어있는 반면, 국내에서는 수준이 현격히 낮은 만큼 일반인도 쉽게 접근하고 배울 수 있다. Google 등을 비롯한 여러 벤더 사에서는 이 언어를 활용한 다양한 플랫폼 환경을 지원하고 있으며, Chrome Extension이나 App들이 그 좋은 예이다. 순수 JS로 이루어져 있어 실력이 된다면 자신만의 것들을 구현해 배포할 수도 있기 때문.

3. 개발 툴

날코딩 항목에서 서술되어 있듯, 웹 개발자들은 다양한 마크업 언어프로그래밍 언어를 사용하기 때문에 통합 개발 환경보다는 텍스트 에디터를 사용하는 경우가 많다. 크롬이나 파이어폭스에서는 개발자 도구를 지원하여 브라우저에서 개발을 돕기도 한다.# 텍스트 에디터로는 그냥 메모장을 사용하는 사람들도 있지만 EditPlus, UltraEdit, Notepad++가 주로 사용되었다. 최근 GitHub의 Atom, MS의 Visual Studio Code, 어도비의 Brackets 등의 오픈소스 에디터도 출시되고 있다.[10] 자세한 내용은 텍스트 에디터 참고. 통합 개발 환경이 필요하다면 JetBrains 사의 WebStorm이 권장되는데 이는 유료이다. 이클립스의 JavaScript Development Tools는 무료.

4. 특징

JavaScript는 멀티-패러다임 언어로 명령형, 함수형, 객체지향형 언어다. 기본적으로는 함수형 프로그래밍 패러다임을 따른다. 자연스럽게 이는 클로저로 시작해 끝을 보는 것이 가능하다.[11]

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

짧은 동작들의 경우 절차적 프로그래밍을 해 잘 돌아가는 것처럼 보이지만 긴 코드를 짜보면 의외로 골치 아프다.[12] 예를 들어 웹 브라우저나 Node.js 서버에서도 JavaScript의 비동기 프로그램 작성시에는 스레드를 분기하여 작업을 분산 처리하거나, 코루틴으로 작업을 대기 시키는 대신 컨티뉴에이션(+타이머)만 이용해 비동기 프로그램을 구현한다. 즉 싱글스레드 위에 시분할만 존재하고 무조건 1 프로세스 1 스레드로 작동한다. 스레드 분기와 코루틴 같은 추상화 된 비동기 처리 자원에 익숙한 프로그래머들이라면 이러한 방식으로 인하여 꽤 고생할 수 있다.[13] 특히 람다식이 여러 번 중첩되는 고차 함수는 그야말로 아스트랄의 극치. 정작 Java는 람다식을 8버전에서야 지원한다... 게다가 호이스팅이라는, 특정 조건 하에서 순서를 무시하고 멋대로 변수 및 함수를 할당하는 개같은 특성이 있다.

대표적인 라이브러리로는 jQuery가 있다. 잘 익혀두면 직접 짜는 것보다 꽤 간단하게 기능을 불러 쓸 수 있다.

자바스크립트는 구글의 V8 JS Engine 버프를 받아 하루가 다르게 발전하고 있으며 이러한 모양새는 다음 글에서도 잘 나타난다. 2016년에 자바스크립트를 배우는 기분. 개발자들 사이에서 이런 발전상이 화제가 되기도 했다.

관련 책으로는 Douglas Crockford의 JavaScript 오브젝트 생성 패턴, JavaScript: The Good Parts(자바스크립트 핵심 가이드) 등이 있다. 매우 얇은 게 함정

자바스크립트의 이러한 특이성을 풍자한 JSFuck(...)이란 프로그래밍 스타일도 존재한다.

5. DOM[14]과 JavaScript

오늘날 JavaScript가 가장 널리 쓰이는 분야는 클라이언트용 인터페이스이다. 이 때 주로 JavaScript는 웹 브라우저에서 제공되는 DOM API로 사용하게 된다.

JavaScript에서 html의 문서에 접근하는 API를 뜻하는 용어로 DOM이 등장하였다. 초창기 ECMA 5의 등장과 본격화 이전 Browser War의 사건에서 알 수 있다시피 MS는 자사만의 구현을 고집하였고, 이는 DOM의 구현이 각 벤더 사마다 다르다는 것을 의미했다. 위에서 말한 IE 8 이하의 브라우저들이 addEventListener가 아닌 attachEvent 등 MS 자사의 문법을 개발했다고 했는데, 이 method들은 모두 document object 아래에 있다. 다행히 이 문제점은 browser war 2 이후 구글이 MS를 꺾음으로서 JS 표준화로 점차 사라지고 있다.

그 중에서도 DOM의 경우 ECMAScript 쪽에 의한 제정보다는 Apple을 비롯한 google 등이 WHATWG working group을 구성하고 html5 표준을 정한 것에 의해 표준화 되었다.

6. CommonJS

Java 같은 이름이기는 해도 프로그래밍 언어로서 상당히 우수한 설계를 자랑한다. 우수한 텍스트 표기법(JSON)[15]을 가졌으며, 구조적으로 비동기 프로그래밍에 유리하다.

그 때까지 JavaScript 엔진들은 모두 실시간 인터프리팅을 하고 있었는데, 모질라에서 SpiderMonkey 엔진에 JIT 컴파일 방식을 도입했다. 이는 JavaScript 엔진으로는 최초로 도입한 것이고, 이 때 알려진 것으로는 순수 JavaScript 성능만 기존 버전의 20~40배에 달했다.[16] 그리고 구글 역시 V8이라는 JavaScript 엔진을 개발하면서 JIT 컴파일 방식을 도입하였고, ES6를 상당수 구현함으로서 JS의 본격적인 발전의 신호탄을 날렸다.

지금은 JavaScript 3D게임 엔진도 개발되고 있다.[17] 이러한 발전 속에서 JavaScript 서버 사이트 스크립팅의 표준화 움직임이 일어났으며 ,그 기관의 출범이 바로 CommonJS다. 표준이기도 한 이 기관에서 'JS는 언제 어디서나 쓸 수 있어야 한다' 는 내부 의견과 부딪혀 그로부터 AMD어?가 탄생하게 된다. 당연하게도 CommonJS는 전적으로 ES6 를 기반으로 하므로 V8 엔진을 탑재했다.

CommonJS의 현재 사양은 모듈 1.0 이다. 이 표준을 이용한 가장 주요한 플랫폼은 Node.js이다. Node.js로 이뤄진 서버는 꽤 인기를 끌고 있는데, 웹의 프론트엔드와 백엔드를 동일 언어로 프로그래밍 함으로서 얻는 이득이 상당하고, 순수한 서버로서의 성능이 꽤 좋은 편이기 때문이다.

ES6로 넘어오면서 다양한 모듈들이 탄생하였고 cluster 등을 이용하면 멀티 프로세스[18]로 동작하는 서버도 만들 수 있다.

7. JavaScript와 관련 있는 것

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

8. 웹과 자바스크립트

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

반면, 같은 웹 환경에서 사용되는 나머지 두 핵심 언어(마크업 언어)인 HTMLCSS는 자바스크립트로 대체가 가능하다. 그 중 HTML은 웹 브라우저가 .js 파일을 직접 읽어 실행하지 못하기 때문에 최소한의 코드(script 태그 한 줄)는 필요하지만, CSS는 완전히 자바스크립트로 대체해서 기술하는 것도 가능하다. 단지 성능과 편의성에서 손해를 보기 때문에 그렇게 하지 않을 뿐이다. 페이스북에서 개발한 React 라이브러리는 HTML과 CSS를 자바스크립트로 제어한다. jsx 템플릿 문법이 HTML을 닮아있긴 하지만 jsx transformer(babel 컴파일러 등)를 통과한 뒤에는 모두 자바스크립트 함수로 변환돼있는 것을 볼 수 있다. 네이티브 환경에서의 기계어와 같은 지위를 현재의 자바스크립트가 누리고 있는 셈이다.

2016년 까지는 자바스크립트의 성능을 끌어올리려는 시도(asm.js 등)는 있어도 자바스크립트를 대체하려는 시도는 이루어지지 않고 있다. 그나마 구글의 DART 언어가 대체를 시도하고는 있지만 2016년 현재까지는 Dart 언어도 트랜스컴파일러에 의해 자바스크립트로 번역되는 굴욕을 당하는 중이다. 자바스크립트를 거치지 않고 직접 Dart코드를 실행할 수 있는 브라우저는 구글 크롬 브라우저가 유일하다. 그나마도 구글 측도 싸움이 안 되는 걸 아는지 Dart 언어를 기반으로 한 다른 프로젝트를 진행하지는 않고 있다.

2016년 11월 기준 구글·MS·모질라·애플에서 웹어셈블리(Webassembly)에 대한 시도가 이루어지고 있다. 웹 엔진을 위한 일종의 어셈블리 언어(정확히는 바이트코드)를 개발하려는 프로젝트로, 개발자가 C, C++ 언어로 작성된 프로그램을 어떤 브라우저에서든 돌아가도록 컴파일 할수 있게 되는 것이 목표다. 현재로서는 C/C++ 프로그램을 컴파일 해서 돌리는 것이 목표지만, 나중에는 다른 언어들도 목표를 하고 있다. 2017년 3월 사용자에게 선보일 예정이라고 한다. 다만 자바스크립트를 완전히 대체하는 것은 아니고, 상호 보완의 관계로 연구되고 있다.

9. 기타

  • 해외에서는 JavaScript를 결과물로 내보내는 컴파일러가 많이 등장하고 있다. 이와 함께 고성능을 요구하는 프로그램을 작동시키기 위해 가비지 컬렉터와 산술 연산을 지금보다 효율적으로 수행하기 위한 서브셋 개발이 진행중이다. LLJS(Low-Level JavaScript)와 asm.js가 대표적이다. 이러한 서브셋과 컴파일러는 C++ 같은 언어로 작성된 프로그램을 JavaScript로 컴파일 해서 돌릴 수 있게 한다. 또한 JSIL은 CIL과 .net 가상기계를 다시 JavaScript로 컴파일하는 프로젝트다. 이러한 방식을 사용한 예로, archive.org에서 제공하는 Classic PC Games Archive가 있다. DOSBox, MESSLLVM/Clang으로 컴파일하여 웹 브라우저에서 구동하게 한 것. Core i5 정도의 컴퓨터라면 플레이 하는 데 거의 지장이 없는 수준을 보여주어 흠좀무하다.
  • 웹 애플리케이션의 개발 트렌드를 따라가다 보면 흥미로운 사실을 발견할 수 있는데, 웹 클라이언트 사이드 언어인 JavaScript를 사용하는 방식이 절차형에서 객체지향으로, 다시 함수형으로 이동하고 있다는 사실을 발견할 수 있다. 현재는 함수형에서 더 발전해 반응형(Reactive)으로 가고 있지만 반응형 설계는 이제 겨우 AngularJS에 적용된 정도이고 널리 사용되진 않는다. 참고로 JavaScript는 멀티패러다임 언어로, 절차형, 함수형, 논리형을 포함한 그 어떤 방식으로도 코딩이 가능하다. 단, 이걸 JavaScript 킹왕짱 만능 끝판왕 종결자로 생각해서는 안 된다. 나쁘게 말하면 잡탕이기 때문. 적마도사
  • 얼마 전까지만 해도 언어가 아닌 매크로로 취급됐는데 이제는 독립적인 언어로 인정되고 있는 이유는, 더 이상 브라우저의 확장이나 플러그인만을 위한 것이 아닌, 서버형인 NodeJS(구글 V8 엔진)나 컴파일형인 JavaScript .Net 같은 것들의 개발에 기인한 것이다. 아마도 머지않아 더글라스 크락포드(Douglas Crockford)의 주장과 요구대로 독립적인 언어로 선언이 될 수도 있을 것이다.
  • 류샤오보 사망 이후 중국에서는 뜬금없이 금지어가 되었다(...). 추모 분위기 확산 방지를 위해 RIP를 금지어로 지정했더니 이 철자가 들어가는 자바스크립트(JavaScript)가 얼떨결에 피해를 본 것.

10. 참고할 만한 곳


  1. [1] 이 때문에 동적인 홈페이지가 필요없다면 JavaScript는 안 써도 된다. 그러나 2016년 현재 웬만한 홈페이지에는 동적인 요소가 들어가므로 거의 필수적으로 쓰이는 것이 현실.
  2. [2] 당시에 Java가 유행을 타기 시작하니까 Sun microsystems(지금은 오라클로 인수됨)에게 트레이드 마크 라이센스를 빌려 왔다.라이센스
  3. [3] 1990년대 중반에 발표된 언어가 요즘 새롭게 나오는 언어들 보다도 더 한 추상화를 자랑한다.
  4. [4] 그때는 Java를 할 줄 알면 JS를 몰라도 깔 수 있었다. 이름으로...
  5. [5] 과거에는 브라우저의 JS 엔진이 파일 시스템 같은 자원에 접근할 수 있었다.
  6. [6] 링크를 보면 알겠지만 초창기 넷스케이프 사의 점유율은 80%로 압도적이었지만 일방적으로 IE에게 밀리는 것이 보인다. 참조.
  7. [7] 아직도 IE 8 이하의 버전에서는 JScript만의 문법이 남아있어 오늘날까지도 Cross-browsing 문제가 빈번하게 일어난다. 대표적으로 addEventListener를 attachEvent 같은 식으로 구현 하는 것이 그러하다.
  8. [8] CommonJS 진영에서 facebook이 선보인 ReactJs.
  9. [9] AMD 진영의 RequireJS.
  10. [10] 재미있는 점은 이 세 에디터는 내부적으로 JavaScript를 쓴다! 정확히는 Node.js의 라이브러리인 ElectronJS로 만든 것이다.
  11. [11] 특히 arrow syntax의 등장으로 이 기능은 더더욱이 강해졌다.
  12. [12] 물론 절차적 프로그래밍에 익숙한 사람 기준에서다.
  13. [13] 반대로 JavaScript 커뮤니티에서는 싱글스레드와 컨티뉴에이션의 단순하고 투명한 작동 모델이 오히려 프로그램을 더 좋게 만든다는 의견도 있다.
  14. [14] Document Object Model
  15. [15] JavaScript Object Notation, 즉 JavaScript 객체 표기법으로 오늘날 AJAX의 XML 대신 쓰이고 있다. 그래서 AJAJ라고 불려야 된다는 사람들이 있을 정도.
  16. [16] Paul, Ryan (2008-08-22). "Firefox to get massive JavaScript performance boost". Ars Technica. Retrieved 2013-03-21.
  17. [17] 이런 3D 게임 같은 분야에서는 빠른 JavaScript와 WebGL 등으로도 부족해서 이젠 모질라에서 asm.js 같은 서브셋까지 만들어서, 산술 연산이 거의 네이티브 코드에 가깝게 실행될 수 있도록 극한의 최적화를 하고 있다.
  18. [18] fork.

최종 확인 버전:

cc by-nc-sa 2.0 kr

Contents from Namu Wiki

Contact - 미러 (Namu)는 나무 위키의 표가 깨지는게 안타까워 만들어진 사이트입니다. (static)