JavaScript (r20220720판)

문서 조회수 확인중...


프로그래밍 사이트 선정 상위 점유율 프로그래밍 언어 목록
⠀[ IEEE Spectrum 2021 ]⠀
IEEE Spectrum에서 집계한 2021년 기준, 웹 분야 상위 10개 프로그래밍 언어
1
Python
2
Java
3
Javascript
4
C#
5
Go
6
HTML
7
PHP
8
Dart
9
Ruby
10
Rust
IEEE Spectrum에서 집계한 2021년 기준, 모바일 분야 상위 10개 프로그래밍 언어
1
Java
2
C
3
C++
4
C#
5
Swift
6
Dart
7
Kotlin
8
Scala
9
Objective-C
10
Delphi
}}}
{{{#!wiki style="display:inline-block; margin:0 0 -5px; min-width:25%"
⠀[ Stack Overflow 2021 ]⠀
{{{#!wiki style="display:inline-block; margin:0 0 -5px; min-width:25%"
⠀[ TIOBE 2022 ]⠀
TIOBE에서 선정한 2022년 2월 기준 검색어 점유율 상위 20개 프로그래밍 언어
1
Python
2
C
3
Java
4
C++
5
C#
6
Visual Basic .NET
7
JavaScript
8
PHP
9
어셈블리어
10
SQL
11
Classic
Visual Basic

12
R
13
Go
14
Fortran
15
Groovy
16
Swift
17
Ruby
18
Perl
19
MATLAB
20
Delphi /
Object Pascal

[ 21위 ~ 50위 펼치기 · 접기 ]
21
Objective-C
22
Prolog
23
Scratch
24
SAS
25
LISP
26
COBOL
27
Rust
28
Ada
29
Dart
30
Transact-SQL
31
PL/SQL
32
ABAP
33
VBScript
34
LabVIEW
35
Julia
36
Scala
37
TypeScript
38
Kotlin
39
Haskell
40
Lua
41
Apex
42
Visual FoxPro
43
Bash
44
Scheme
45
D
46
PL/I
47
Elixir
48
Logo
49
PostScript
50
Ladder Logic
}}}
{{{#!wiki style="display:inline-block; margin:0 0 -5px; min-width:25%">
⠀[ PYPL 2022 ]⠀
PYPL에서 선정한 2022년 3월 기준 검색어 점유율 상위 20개 프로그래밍 언어
1
Python
2
Java
3
JavaScript
4
C#
5
C/C++
6
PHP
7
R
8
Objective-C
9
TypeScript
10
Swift
11
MATLAB
12
Kotlin
13
Go
14
Rust
15
Ruby
16
VBA
17
Ada
18
Abap
19
Dart
20
Visual Basic
프로그래밍 언어 목록 · 분류 · 문법


TIOBE 선정 올해의 프로그래밍 언어 / JavaScript
[펼치기 / 접기]
2013년
Transact-SQL

2014년
JavaScript

2015년
Java


[각주]


자바스크립트
JavaScript
파일:JavaScript 로고.svg}}}
개발
브랜든 아이크, Ecma International
개발일
1995년 12월 4일
최신 버전
ECMAScript 2021(2021년 6월)
링크
파일:홈페이지 아이콘.svg

1. 개요
2. 역사
3. 개발 도구
4. 특징
5. DOM
6. CommonJS
7. 관련 개념
7.1. 표준안
7.2. 주요 라이브러리
7.3. 기타 라이브러리
7.4. 파생 언어
8. 웹과 JavaScript
9. 엔진
10. 문법 예
11. 기타
12. 외부 링크



1. 개요[편집]


document.write("Hello, world!"); // HTML 문서에 출력된다.
alert("Hello, world!"); // 알림창으로 출력된다.
console.log("Hello, world!"); // 보통 F12(또는 Ctrl+Shift+I / macOS의 경우에는 ⌘+⌥+I)를 누르면 보이는 콘솔 창에 출력된다.
Ecma International의 프로토타입 기반의 프로그래밍 언어로, 스크립트 언어에 해당된다. 특수한 목적이 아닌 이상 모든 웹 브라우저에 인터프리터가 내장되어 있다. 오늘날 HTML, CSS와 함께 웹을 구성하는 요소 중 하나다. HTML이 웹 페이지의 기본 구조를 담당하고, CSS가 디자인을 담당한다면 JavaScript는 클라이언트 단에서 웹 페이지가 동작하는 것을 담당한다.[1] 웹 페이지를 자동차에 비유하자면, HTML은 자동차의 뼈대, CSS는 자동차의 외관, JavaScript는 자동차의 동력이라고 볼 수 있다.

썬 마이크로시스템즈(현재 오라클)에서 개발한 Java와는 별 관계가 없는 언어이다. 이름이 비슷하다고 같은 언어가 아니다. 사람들이 흔히 헷갈리는 부분 중 하나라 Java의 소유자인 오라클에서도 아니라고 강조한다.[2] 실질적인 구동 방식도 Java Virtual Machine을 이용해서 돌리는 Java와, 브라우저 내에 스크립트 엔진(인터프리터)이 존재하는 JavaScript는 완전히 다르다. 햄이랑 햄스터가 다르고 파와 파슬리가 다르며, 인도가 인도네시아와 다르듯 심지어는 웹 서버용 파생 규격도 다르다.


2. 역사[편집]


첫 탄생은 1995년 넷스케이프에서 근무하던 브랜든 아이크가 10일만에 설계한 것으로부터 시작한다. 처음에는 Mocha라는 이름이었지만 4달 만에 LiveScript라는 이름으로 개명하고 다시 3달 후에는 JavaScript라는 이름이 되어 오늘날까지 이어지고 있다. 'Java와 구문이 유사해서 이름을 JavaScript로 명명했다'는 표면상의 이유를 대지만 그 속은 Java의 유명세를 타서 묻어가려고 의도적으로 그렇게 작명한 것이다. 물론 무단으로 도용한 것은 아니고, 썬 마이크로시스템즈(지금은 오라클에 인수됨)에게 상표권 사용 허락을 받았다. # 오라클이 인수하면서 상표권도 오라클로 넘어갔는데, 소송으로 악명높은 오라클이 JavaScript는 딱히 손대지 않고 있다. 애초에 허락을 맡은 것이기도 하고 JavaScript가 워낙 널리 쓰이다보니 이제는 서로 각자의 유명세에 보탬이 되는 상부상조 관계이기 때문.

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

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

제1차 브라우저 전쟁에서 Microsoft는 당시만 해도 혁명적이었던 ActiveX를 탑재하면서 운영 체제 점유율을 늘려감에 따라 사용자들을 Internet Explorer를 사용하도록 지속적으로 유도하였고, 이에 버티지 못한 넷스케이프는 기어코 망하고 만다.

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

이렇듯 JavaScript는 각 웹 브라우저마다 서로 호환이 되지 않는 것이 문제였다. 1997년 ECMA TC39라는 문서를 통해 단일화 움직임이 시작되었지만, 각 웹 브라우저 벤더(특히 Microsoft)의 비협조적인 태도로 인해 실패했다. 그러다가 두 번째 브라우저 전쟁이 발발한 후 구글한테 처참하게 발린 Microsoft가 깽깽 거리고 나서야 ECMAScript 5가 제정되고 표준 문제가 다소 해결되었다.[7]

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

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

하지만 그렇다고 해서 JavaScript가 마냥 쉬운 언어라고 생각하면 오산이다. 웹으로 할 수 있는게 제한적이었던 과거에는 웹 애플리케이션으로 복잡한 기능을 수행하는게 불가능했기 때문에 당시 JavaScript로 작성된 코드들은 간단했고, 그로 인해 JavaScript는 쉬운 언어라는 인식이 널리 퍼졌다. 그러나 현재는 웹 애플리케이션이 사실상 데스크톱 설치형 애플리케이션을 상당수 대체하고 있어 JavaScript 기반으로 쓰여진 초대형 프로젝트들이 많은 상황이고, 무엇보다 Node.js의 등장으로 인해 프론트엔드 뿐만 아니라 백엔드 및 네이티브 프로그래밍에서도 JavaScript가 쓰이는 만큼 지금의 JavaScript는 여타 언어 못지 않은 높은 수준의 숙련도를 요구하고 있다고 봐야 한다.

원래 JavaScript 엔진들은 모두 실시간 인터프리팅을 하고 있었는데, 모질라에서 SpiderMonkey 엔진에 JIT 컴파일 방식을 도입했다. 이는 JavaScript 엔진으로는 최초로 도입한 것이고, 이 때 알려진 것으로는 순수 JavaScript 성능만 기존 버전의 20~40배에 달했다.[8] 그리고 구글 역시 V8이라는 JavaScript 엔진을 개발하면서 JIT 컴파일 방식을 도입하였고, JavaScript 성능이 비약적으로 향상하여 지금은 JavaScript 3D 게임 엔진도 개발되고 있다.[9]

3. 개발 도구[편집]


날코딩 항목에서 서술되어 있듯, 웹 개발자들은 다양한 마크업 언어프로그래밍 언어를 사용하기 때문에 통합 개발 환경보다는 텍스트 에디터를 사용하는 경우가 많다. 크롬이나 파이어폭스에서는 개발자 도구를 지원하여 브라우저에서 개발을 돕기도 한다.# 텍스트 에디터로는 그냥 메모장을 사용하는 사람들도 있지만 EditPlus, UltraEdit, Notepad++가 주로 사용되었다. 통합 개발 환경이 필요하다면 JetBrainsWebStorm이 권장되는데 이는 유료이다.[10] 이클립스의 JavaScript Development Tools는 무료. 허나 이클립스의 무거움은 그대로 가지고 있다.

최근에는 GitHubAtom, MicrosoftVisual Studio Code, AdobeBrackets[11] 등의 오픈소스 에디터도 출시되고 있다.[12] 해외의 경우 99프로 가까이 비주얼 스튜디오 코드를 쓰는 만큼 웹 개발에 비주얼 스튜디오 코드는 사실상 업계 표준이다. 자세한 내용은 텍스트 에디터 참고.


4. 특징[편집]


JavaScript는 클래스라는 개념이 없습니다. 그래서 기존의 객체를 복사하여(cloning) 새로운 객체를 생성하는 프로토타입 기반의 언어입니다. 프로토타입 기반 언어는 객체 원형인 프로토타입을 이용하여 새로운 객체를 만들어냅니다. 이렇게 생성된 객체 역시 또 다른 객체의 원형이 될 수 있습니다. 프로토타입은 객체를 확장하고 객체 지향적인 프로그래밍을 할 수 있게 해줍니다.[13]


부모 자식의 구분도 없으며, 메인 메소드 같은 것도 없고, 클래스-인스턴스 관계도 없으며, 모든 함수가 클래스도 될 수 있으며 인스턴스도 될 수 있다. 그렇기 때문에 모든 함수가 따로 놀기에 따라서 객체 지향처럼 "서로 맞물리는" 것을 기대할 수도 없다.(그런 이유로 클로저 개념이 있다.) 이 특성을 잘 이해해야 한다. 오히려 순서대로 읽는 절차 지향/객체 지향 언어보다는 모든 요소가 각자 따로 움직이는 스타크래프트 맵 에디터 스크립트에 더 가까운 개념으로 이해해야 한다. 로드는 순서대로지만 실행은 동시 실행이다. 그러니까 main()같은건 없고 필요할때 실행되고 사라지는 스크립트들의 집합이라고 보면 된다. 오히려 웹 페이지 자체가 main()이라고 봐야 할 지경.

JavaScript는 C에서 영향을 받은 C-Family 언어로 기본적인 문법이 유사 중괄호로 구분하는 블럭, 세미콜론으로 줄이 끝남을 알리는 것[14], 변수 쓰는 법, 연산자 사용법 등 기초적인 문법이 C 문법과 크게 다르지 않다. 호이스팅 같은 것도 C언어의 잔재이다. 무엇보다 다른언어 쓰다온 사람들을 힘들게 하는건 클래스와 메소드가 외관으로 구분이 안된다라는 점이다.

JavaScript에서도 함수형[15] 언어의 불편함과 호이스팅 등 여러 문제를 무마하기 위해서 클래스 개념의 도입과 변수 선언을 let[16], const[17]로 하는 등 다른 언어 쓰는 사람들의 적응을 돕도록 흉내는 내 주는 척하는게 다행. 물론 일반적인 객체 지향 프로그래밍 개발자에게는 이것마저 이해를 못 하고 Syntatic Sugar에 불과한 JavaScript의 클래스를 불만족스러워한다.

JavaScript는 멀티-패러다임 언어로 명령형, 함수형, 객체 지향형 언어다. 기본적으로는 함수가 일급 시민으로 취급되는 언어로써 함수형 프로그래밍 패러다임을 따른다. 자연스럽게 이는 클로저로 시작해 끝을 보는 것이 가능하다.[18] 멀티 패러다임 언어인만큼 원한다면 명령형 프로그래밍(imperative programming)으로 코드를 쓸 수도 있지만 보통은 함수형/선언형 프로그래밍으로 작성해야 JavaScript가 제공하는 장점을 백분 활용하는 것이 가능하다. 객체 지향으로 코드를 작성하는 것도 가능하고 심지어 class도 ECMAScript 6이후로 제공하지만, JavaScript에서의 class는 그냥 function을 class형식으로 쓸 수 있게 제공하는 syntatic sugar에 지나지 않으므로 타 객체 지향 프로그래밍 언어처럼 사용하다가는 장벽에 부딪히기 쉽다. 즉 JavaScript에서 class는 존재하지만 C++의 class와는 완전히 다른 개념이며, JavaScript의 객체 지향 프로그래밍은 함수 프로토타입에 기반한 객체 지향 프로그래밍이다. # 결국 근본적으로 JavaScript는 함수와 함수형 프로그래밍을 제대로 이해하지 않으면 제대로 다룰 수 없는 언어인 셈이다.

이런 특징 때문에 for이나 while 등의 loop은 특수한 경우를 제외하고는 쓰이지 않으며, 어떤 동작을 수행시키는 데 있어서 JavaScript에서 제공되는 prototype function에 콜백함수를 제공하여 선언적으로(declarative programming) 코드를 작성하게 된다. 일반적으로 대학교에서 C++ 등으로 프로그래밍을 시작한 사람이라면 이런 코딩 스타일에 익숙해지는 데 시간이 걸리지만, 한번 익히고 나면 매우 간단명료하게 코드를 쓸 수 있다는 점, 언제나 Immutability가 보장된다는 점, 순수 함수(Pure Function)을 기반으로 코드가 작성되기 때문에 예상치 못한 버그가 최소화된다는 점 등이 매력적인 요소가 정말 많은 프로그래밍 패러다임이다. 2010년 후반 들어서는 RxJS라는 라이브러리를 기반으로 한 반응형 프로그래밍이 등장했다. 함수형 프로그래밍과 매우 흡사하지만 여기에 이벤트와 데이터 스트림(Observable)을 기준으로 사고하는 것을 더한 프레임워크로, side effect 수행 및 asynchronous operation에 있어서 매우 장점이 많아 대세로 떠오르고 있다.

JavaScript는 동적 타이핑, 약타입 언어고[19], 간단한 문법에 코딩 방법이 비교적 유연하기 때문에 초기 진입장벽이 거의 없어서 쉽다고 이야기 되지만, 깊이 들어가 보면 매우 변태적인 특이한 언어이자 매우 우수한 설계를 자랑하는 강력한 언어이다. 편하면서도 강력한 텍스트 표기법(JSON(JavaScript Object Notation))[20]을 가졌으며, 구조적으로 비동기 프로그래밍에 유리하다. 이러한 비동기 프로그래밍에 특화된 특징은 이후 Node.js를 탄생시키며 JavaScript라는 언어의 사용 반경을 폭발적으로 늘리는 데 기여하게 된다.

진입 장벽은 낮지만 실제 사용하려면 모든 언어가 그렇듯 어렵다. 특히 다른 언어와 비교했을 때 상상도 못할 독특한 특징들이 많은 언어이다. 가장 대표적인 것이 객체(Object)의 상수(const) 개념이다. 객체의 경우 상수로 선언해도 메모리값만 상수일 뿐 객체 안의 내용은 변경이 가능하다. 즉 객체가 저장된 공간을 가리키는 정보만 상수일뿐 그 객체의 정보 자체는 변경이 가능하다. 이런 이유로 JavaScript에서 객체는 변수로 선언할 이유가 없으며 거의 모든 케이스에서 상수로 선언하는게 일반적이다. 또 이렇게 상수로 선언된 객체의 Immutability를 보장하기 위해 여러 테크닉이 쓰이게 되는데 주로 ECMAScript 6에서 도입된 Spread Operator를 사용하는 것이 일반적이다. 이렇게 객체를 복사하여 사용할 때도 Deep clone하지 않으면 의도치 않게 원본 객체가 변경되어버리기 때문에 많은 주의가 필요하다.

또한 비동기로 작동되는 코드가 많아 코드 위에서부터 차근차근 실행되는 게 아니라는 점 또한 JavaScript를 마스터하는 데에 넘어야할 장벽 중 하나이다. 이 때문에 특히 Side effect 수행이 요구되는 상황에서 절차적으로 원하는 바를 수행하도록 만들기 위해서 간단하게는 promise나 callback을 사용하는 방법에서부터 복잡하게는 반응형 프로그래밍 라이브러리도 사용할 수 있는 등 여러 테크닉이 요구된다. 이런 독특한 특징들 때문에 타 주류 언어와는 또 다른 사고방식을 요구한다. 복잡한 side effect 수행에 있어서 예상치 못한 버그를 유발하는 등 개발자에게 많은 피로감을 안겨주는 특징이지만 이러한 비동기 오퍼레이션은 JavaScript의 높은 퍼포먼스를 지탱하는 주요한 특징 중 하나이다.

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

다만 위에서 언급된 코루틴은 ECMAScript 6, 즉 2015년도 표준에 이미 포함되어 있는지 오래다. 보통 코루틴이 아닌 Promise라고 부르다 보니 둘이 같은 것이라는걸 모르는 사람도 있는 편. 또한 병렬적 실행도 Promise.all로 동시 실행이 가능하게 되었다.[24]

2010년대 중반 이후 JavaScript는 구글V8 JavaScript Engine 버프를 받아 하루가 다르게 발전하고 있으며 이러한 모양새는 다음 글에서도 잘 나타난다. 2016년에 JavaScript를 배우는 기분 개발자들 사이에서 이런 발전상이 화제가 되기도 했다. 과거에는 브라우저 환경에서만 사용이 가능한 웹 전용 프론트엔드 프로그래밍 언어에 불과했지만, 현재는 Node.js라는 강력한 Runtime Environment의 등장으로 백엔드 언어로써도 매우 강력한 성능을 가진 언어로 재탄생했으며 실제로도 백엔드 분야에서 빠르게 점유율을 높여가고 있다. Node.js 서버는 확장성이 높고 개발자 입장에서도 JavaScript만 알면 접근이 가능해 유지보수 측면에서도 유리한면이 있고 무엇보다 I/O가 자주 이루어지는 애플리케이션의 경우 성능이 매우 좋다. 여기에 ORM까지 등장하면서 심지어 데이터베이스 시스템이 제공하는 Stored Procedure까지도 대체가 가능한 수준까지 이르렀다. 이와 동시에 백엔드 및 프론트엔드 양방향에서 정말 수많은 라이브러리가 등장하면서 발전이 가속화되는 중이다. '여기에 HTML5, 반응형 웹 등 다양한 웹 기술의 발달로 인해 사실상 데스크탑 애플리케이션이 쇠퇴하고 웹이 모던 애플리케이션의 표준이 되면서 중요성이 더욱 두드러지는 언어가 되었다. 실제로 많은 소프트웨어 회사들이 기존 C++Java 등으로 쓰여진 PC용 애플리케이션을 웹앱으로 전환하고 있어[25] 수요도 많고 전망 또한 밝은 언어라 할 수 있다.

이 때문에 현재 JavaScript는 확장성이 매우 높은 언어이다. JavaScript만 알면 일반적인 사이트 개발부터 React.js 또는 Vue.js를 사용해 SPA#Single Page Application) 웹사이트 개발, iOS안드로이드 앱을 만들수 있는 React Native, 웹서버나 다른 서버 사이드 애플리케이션에 Node.js, 데스크탑 앱은 리눅스, macOS, 윈도우, tvOS 등 플랫폼에서 사용 가능한 Electron을 이용하거나 React Native for Windows를 사용해 Windows 10 SDK까지 접근할수 있다.

과거 프론트엔드 언어로만 JavaScript가 쓰였을 때 가장 유명했던 라이브러리로는 jQuery가 있었다. 잘 익혀두면 직접 짜는 것보다 꽤 간단하게 기능을 불러 쓸 수 있어 대학에서도 가르쳤던 필수 라이브러리였다. 하지만 ReactVue.js, 혹은 Angular가 등장한 이후로 모듈형 개발이 순식간에 대세가 되었고, 이는 jQuery 대비 비교도 안될 정도로 월등하게 생산성이 높기 때문에 현재로서는 jQuery 자체가 모던 웹 애플리케이션 개발에는 더이상 사용되지 않는 기술이라 생각하면 된다. 원한다면 다른 프레임워크에 jQuery 라이브러리도 병행해서 사용할 수도 있으나, 그럴 바에야 그냥 직접 querySelector를 사용해서 DOM을 업데이트하는 게 낫기 때문에 정말 간단한 애플리케이션이 아니면 사용할 이유가 없어져버렸다. 사실 jQuery 같은 라이브러리는 2000년대에 각 브라우저마다 JavaScript 문법이 달랐던 대혼돈의 시대에 문법을 통일시켜보자는 취지로 나온 거라 표준 문법이 정착되고 IE가 완전히 도태된 2022년 시점에서는 더 이상 쓸 필요는 없다.

대세가 된 ReactVue.js의 경우 단독으로 사용되는 경우는 드물며 Redux나 Mobx같은 상태관리 라이브러리를 같이 사용하여 개발한다. 상태관리 라이브러리를 사용하지 않아도 개발은 충분히 가능하나 매우 비효율적이라 규모가 큰 애플리케이션의 경우 사실상 개발 자체가 불가능하다고 보면 된다. 상태 관리를 위한 방법론은 다음과 같은 것이 존재한다.
  • Redux: 페이스북에서 리액트를 위해 만든 아키텍처인 Flux에 영향을 받아 댄 아브라모프가 만들어낸 아키텍처 및 이를 구현한 상태 컨테이너. React의 아키텍처에 영향을 받았지만, 그 자체로 상태 관리를 사용할 수 있기 때문에 다양한 프레임워크와 함께 사용할 수 있다. 상태 관리를 위한 방법이 다양하지 않았을 때 나타나 높은 점유율을 차지하였지만, 2022년 현재 다양한 상태 관리 라이브러리가 나오면서 점유율이 조금씩 줄고 있다. 각각의 상태를 위해서 Reducer와 Action을 복잡하게 정의한 뒤에야 사용할 수 있다는 것이 단점으로 꼽힌다.
  • context + useReducer: React 내부적으로 이후에 전체적인 상태 관리가 필요함을 인지하고 추가하였다. useReducer는 Redux 아키텍처의 Reducer와 유사하게 작동한다고 생각하면 대충 맞다. 소규모 웹앱에서 상태 관리를 위한 라이브러리를 사용하지 않기를 원한다면 고려할 수 있는 옵션이다. 다만, 이를 이용할 경우 리듀서가 제대로 작동하기 위해서는 다양한 최적화 작업을 해야하므로 대규모 환경에서 추천하기 어렵다.
  • Recoil: 페이스북에서 결국 체계적인 상태 관리를 위해서 만들었다. 2022년 기준 아직 기능이 완전하지는 않지만 리액트 제작자가 만들었다는 이유로 많은 기대를 받는다.

관련 책으로는 Douglas Crockford의 JavaScript 오브젝트 생성 패턴, JavaScript: The Good Parts(JavaScript 핵심 가이드) 매우 얇은 게 함정 , 카일 심슨의 You don't know JS(원문)이 있다.

이래도 저래도 이해가 안된다? htm 파일이 main함수고 존재하는 모든 위젯(라디오버튼,체크박스 등)이 클래스, 거기에 메소드가 딸린거라 생각하자.

5. DOM[편집]


Document Object Model / 문서 객체 모델

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

JavaScript에서 HTML의 문서에 접근하는 API를 뜻하는 용어로 DOM이 등장하였다. 초창기 ECMA 5의 등장과 본격화 이전 브라우저 전쟁에서 알 수 있다시피 마이크로소프트는 자사만의 구현을 고집하였고, 이는 DOM의 구현이 각 벤더 사마다 다르다는 것을 의미했다. 위에서 말한 Internet Explorer 8 이하의 브라우저들이 addEventListener가 아닌 attachEvent 등 Microsoft 자사의 문법을 개발했다고 했는데, 이 메서드들은 모두 document object 아래에 있다. 다행히 이 문제점은 제2차 브라우저 전쟁 이후 구글이 마이크로소프트를 꺾음으로서 JavaScript 표준화로 점차 사라졌다.

그중에서도 DOM의 경우 ECMAScript 쪽에 의한 제정보다는 애플, 구글 등이 WHATWG(Web Hypertext Application Technology Working Group)를 구성하고 HTML5 표준을 정한 것에 의해 표준화 되었다.


6. CommonJS[편집]


JavaScript의 발전과 함께 이 언어를 서버 사이트 스크립팅 등 다양한 환경에서 사용하고자 하는 움직임이 일어났으며, 그 시초가 바로 CommonJS다.[26] CommonJS는 다양한 API 규격으로 이루어져 있는데, 대표적인 것이 모듈 스펙이다. 당시 ECMAScript 표준에 모듈 스펙이 없었기 때문에, CommonJS의 모듈 스펙은 상당한 파급력을 가졌다.

CommonJS 진영이 모듈 구현에서 네트워크 사용을 고려하지 않는다는 비판에 갈라져 나온 것이 AMD(Asynchronous Module Definition)이다.

CommonJS를 이용한 가장 주요한 플랫폼은 Node.js이다. Node.js로 이뤄진 서버는 꽤 인기를 끌고 있는데, 웹의 프론트엔드와 백엔드를 동일 언어로 프로그래밍 함으로서 얻는 이득이 상당하고, 순수한 서버로서의 성능이 꽤 좋은 편이기 때문이다. 하지만 CommonJS에서 정의한 기능이 차후 다른 형태로 ECMAScript 표준에 대부분 추가되었고, Node.js는 CommonJS의 사용을 중지하기로 하였다. 그럼에도 여전히 CommonJS의 API는 Node.js 환경에서 많이 쓰이고 있다.


7. 관련 개념[편집]



7.1. 표준안[편집]


  • ECMAScript: 넷스케이프가 인터넷 상의 다양한 스크립트 언어를 하나로 묶기 위해 제시한 표준안. 이 스펙을 구현한 JavaScript 구현체로는 구글의 V8 엔진, 모질라의 SpiderMonkey, Microsoft의 Chakra 등이 있다. 실제로 JavaScript에만 적용되는 표준안이 아니라, Internet Explorer의 JScript나 Adobe Flash ActionScript의 표준이기도 하다. 현재는 ECMAScript 2021의 표준 (12판)까지 나와있으며, 대부분의 JavaScript 런타임에서는 이 표준을 모두 구현한 상태는 아니다. 현재는 Internet Explorer등의 구형 브라우저를 제외하고는 ECMAScript 2016 표준까지는 적당히 구현이 되어있는 상태. 또한, 구현이 안된 브라우저를 지원하기 위해서 Babel 등의 Transpiler를 사용해서 ECMAScript 2015 이상의 기능을 어느 정도 사용할 수 있긴 하다.


7.2. 주요 라이브러리[편집]


  • jQuery: DOM Manipulating 라이브러리. 사실상 JavaScript 개발에 필수였던 라이브러리였으나 리액트, 앵귤러 등의 프레임워크의 생산성이 워낙 높다 보니 2010년대 후반부터는 사실상 레거시가 되었으며 아주 간단한 웹사이트에서만 쓰이고 안쓰는 추세다. 기본적으로
    document.querySelectorAll('oooo')
    $('oooo')
    로 쓸 수 있는 등의 기능이 있다.
  • AngularJS: 구글에서 제작한 프론트엔드용 클라이언트 사이드 JavaScript 프레임워크. Angular 1으로도 불린다. 백엔드, 프론트엔드를 동시에 작업 할 수 있다. MongoDB, Express, AngularJS, Node.js를 함께 사용하여 MEAN Stack으로 많이 사용한다. Angular 2 이후로는 이건 TypeScript를 이용한다. 기본적으로 많은 기능들이 내재되어 있다.
  • React: Facebook에서 만든 프론트엔드용 오픈소스 라이브러리다.[27] 단방향 데이터 흐름과, Virtual DOM 개념을 도입한 UI 컴포넌트 라이브러리. 생산성이 높고, DOM 업데이트에 있어서 성능이 매우 빨라 동적인 웹 애플리케이션 구성에 유리하다. 그리고 이러한 동적 웹이 모던 웹 애플리케이션의 필수 요소가 되어버린만큼 출시 이후 꾸준히 점유율을 늘려가며 업계 표준 라이브러리 중 하나로 자리잡았다. 최근에는 React Hooks이라 불리는 메소드가 지원되면서 생산성이 더 좋아졌다. html로 뷰를 작성해야하는 Angular와는 다르게 JSX라는 문법을 지원하면서 JavaScript만으로 애플리케이션을 작성하는게 가능하다.
  • Vue.js: 중국계 미국인 에반 유가 만든 사용자 인터페이스를 만들기 위한 프론트엔드용 프레임워크이다. 굉장히 자유롭고 유연하게 추가 기능들을 불러올 수 있다는 특징이 있으나 추가 기능들을 무분별하게 사용하는 경우 안정성을 떨어뜨릴 수 있다.
  • Node.js: 브라우저 안에서만 작동하던 JavaScript를 브라우저 외의 환경에서 작동할 수 있게 만들어 준 런타임 환경이다.
  • Express.js: Node.js 환경을 기반으로 만들어진 웹 애플리케이션 프레임워크. 주로 JavaScript로 백엔드를 개발할 때 사용된다.
  • Deno: Node.js의 개발자 Ryan Dahl이 Node.js의 아쉬운점을 개선한 JavaScript 런타임 환경이다.
  • Svelte: Rich Harris가 2016년도 출시한 오픈소스 프론트엔드 웹 프레임워크이다.


7.3. 기타 라이브러리[편집]


  • Electron: GitHub에서 만든 HTML+CSS+Javascript 데스크톱 앱 프레임워크.
  • 언더스코어: 리스트 해석, 고차 함수 집합 라이브러리. 홈페이지
    • Lo-Dash: 위의 언더스코어 라이브러리의 성능 개선 버전.
  • npm : Node Package Manager
  • HTML5shiv: Internet Explorer 6~8에서 HTML5가 동작하게 해 주는 JavaScript 파일이다.
  • Prefix Free: JavaScript 언어로 된 CSS 라이브러리이다. Vendor Prefix 작업을 자동으로 진행하여 준다.

7.4. 파생 언어[편집]


  • TypeScript: 마이크로소프트에서 발표한 JavaScript에 정적 타입 개념을 추가한 신형 언어. CoffeeScript와 마찬가지로 컴파일 결과는 JavaScript이다. 약타입 언어인 JavaScript 타입 시스템의 구멍을 메우기 위해 나왔다. 그렇게 강타입 언어가 된 TypeScript는 코드의 견고함을 강점으로 내세우고 있다. 현재는 Angular 2 이후에서 이 언어를 채택하면서 많이 사용되기 시작했다. ECMAScript 2015 표준도 구현되어 있으며 순수한 JavaScript와 문법적인 차이가 적다. 마이크로소프트에서 만들었다보니 마이크로소프트 편집기인 Visual Studio Code에서 변수 타입이나 오류에 관한 피드백을 즉각즉각 해 주어서 버그 방지에 유용하다.
  • CoffeeScript: JavaScript의 문법을 개선한 신형 언어. 컴파일 결과로 JavaScript 코드를 내보낸다. 기존 JavaScript의 설계 결함을 극복할 목적으로 만들어졌다. 그러나 Python처럼 들여쓰기로 코드 블록을 구분하는 문법을 채택해 호불호가 갈리는 편이다. 2017년 말에는 '불호' 쪽으로 많이 기울어 있는 상황이다.
  • JavaScript.NET: JavaScript를 컴파일러용 언어로 개조한 것이다.
  • ReasonML: 전직 페이스북 개발자가 만든 정적타입, 함수형 프로그래밍 기반 언어이다.

8. 웹과 JavaScript[편집]


2021년 현재까지 사실상 웹 브라우저에서 사용할 수 있는 유일한 언어이다. 일부 정적인 웹사이트는 JavaScript를 사용하지 않고 만들 수 있지만, 단순 애니메이션(애니메이션 gif, CSS 애니메이션) 이상의 무언가를 하기 위해서는 JavaScript가 반드시 필요하다. JavaScript 없이 기능을 구현하려면 Flash 같은 리치 인터넷 애플리케이션을 사용하는 수밖에 없는데, Flash의 액션스크립트도 JavaScript의 표준인 ECMA를 따르는 언어이다. 또한 Flash는 2021년부터 브라우저에서 전면 퇴출되어 현재는 JavaScript가 브라우저상의 유일한 기능 구현 언어이다. 네이티브 환경에서는 수십 종의 다양한 프로그래밍 언어가 사용되지만 웹 환경에서는 JavaScript 사용이 강제되고 있다. 다른 언어로 기술된 소스 코드를 JavaScript로 변환해 주는 컴파일러(트랜스파일러)가 있긴 하지만, 어차피 최종적으로는 JavaScript로 번역돼서 실행되기 때문에 웹 개발자가 JavaScript를 피해갈 방법이 없다.

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

2021년까지 JavaScript의 성능을 끌어올리려는 시도(asm.js 등)는 있어도 JavaScript를 대체하려는 시도는 이루어지지 않고 있다. 과거에 마이크로소프트가 비주얼 베이직 기반의 VBScript를 민 적이 있지만 결국 JavaScript에 밀려 사라졌고, 오늘날에는 구글의 Dart 언어가 대체를 시도하고는 있지만 현재까지는 Dart 언어도 트랜스컴파일러에 의해 JavaScript로 번역되는 굴욕을 당하는 중이다. JavaScript를 거치지 않고 직접 Dart 코드를 실행할 수 있는 브라우저는 구글 크롬 브라우저가 유일하다.

2021년 현재 구글·Microsoft·모질라·애플에서 웹어셈블리(WebAssembly)에 대한 활발한 개발이 이루어지고 있다. 웹 엔진을 위한 일종의 어셈블리 언어(정확히는 바이트코드)를 개발하려는 프로젝트로서, 개발자가 C, C++, Rust 언어로 작성된 프로그램을 어떤 브라우저에서든 돌아가도록 컴파일할 수 있게 하는 것이 목표이다. 현재로서는 C, C++, Rust 언어로 작성된 프로그램을 컴파일 해서 돌리는 것이 목표지만, 나중에는 다른 언어들도 목표로 하고 있다. 다만 JavaScript를 완전히 대체하는 것은 아니고 상호 보완적인 관계로 연구되고 있다.

9. 엔진[편집]


  • SpiderMonkey
  • V8
  • 차크라: Microsoft에서 구버전 엣지를 위해 개발하던 JavaScript 엔진. 지금은 크로뮴 기반이라 V8을 쓰기 때문에 더이상 사용되지 않으나 차크라 엔진은 차크라 코어로 오픈소스로 공개되어서 쓰이고 있다.


10. 문법 예[편집]


자기호출함수와 재귀함수를 중개하는 개시함수로 구현된 팩토리얼 연산
(결과값) 5! = 120


11. 기타[편집]


  • Java와는 이름의 유사성과 같은 C-족 언어라는 걸 빼면 전혀 상관이 없는, 완전히 별개의 언어다. 프로그래밍에 대해 잘 모르는 사람들이 아직까지도 자주 헷갈려하는 부분.[28]
  • JavaScript 언어 자체는 ECMA-262 표준 스펙에 따른 공개된 언어이지만, JavaScript라는 용어는 오라클의 등록 상표이다. 물론 오라클은 JavaScript 에 대한 간섭을 하지 않으나, 엄연히 등록 상표인 만큼, 공개적으로는 ECMAScript 라 명명하고 있고, 개발자들 사이에서도 ECMAScript 부르기 운동을 전개하긴 했지만 큰 성과는 없었다. 커뮤니티 상에서는 JavaScript 라 불러도 문제는 없으니.
  • 해외에서는 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)으로 가고 있고 reactive 구현체인 rxjs는 현재 프론트엔드 3대장 프레임워크인 AngularJS/Angular의 필수 패키지 중 하나이다. 다른 reactive 구현체로는 Java에서 쓰이는 rxjava가 있다.
  • JavaScript는 멀티패러다임 언어로, 절차형, 함수형, 논리형을 포함한 그 어떤 방식으로도 코딩이 가능하다. 단, 이걸 JavaScript 킹왕짱 만능 끝판왕 종결자로 생각해서는 안 된다. 나쁘게 말하면 잡탕이기 때문. 정확히는 개발자가 패러다임을 흩뜨리지 않고 잘 쓸 수 있을 정도의 수준이 되어야 멀티 패러다임 언어를 이용한 소프트웨어가 잡탕이 안 된다. C++를 예시로 보면 너무 많은 패러다임을 지원해서 배우기도 쓰기도 어려운 언어 중 하나가 되어버렸고, 결국 좋은 개발자를 찾기가 힘든 상황이 됐다.[29]
  • 얼마 전까지만 해도 언어가 아닌 매크로로 취급됐는데 이제는 독립적인 언어로 인정되고 있는 이유는, 더 이상 브라우저의 확장이나 플러그인만을 위한 것이 아닌, 서버형인 Node.js(구글 V8 엔진)나 컴파일형인 JavaScript .Net 같은 것들의 개발에 기인한 것이다. 아마도 머지않아 더글라스 크락포드(Douglas Crockford)의 주장과 요구대로 독립적인 언어로 선언이 될 수도 있을 것이다.
  • 류샤오보 사망 이후 중국에서는 뜬금없이 금지어가 되었다. 추모 분위기 확산 방지를 위해 RIP를 금지어로 지정했더니 이 철자가 들어가는 JavaScript가 얼떨결에 피해를 본 것(...).
  • 2018년 11월 기준 해커랭크의 조사 결과 JavaScript에 능숙하다고 응답한 개발자의 비율이 73%로 가장 높게 나타났다. 2위는 Java로 71%. #
  • 어째서인지 await, async, of, let, yield는 예약어이지만 변수나 함수명으로 사용할 수 있다. 기존에는 이 단어들이 예약어가 아니었기에 이 단어들을 변수명으로 썼던 스크립트의 호환성을 보장하기 위해서일 수 있다.
    • 이를 활용해서 of를 이터레이터나 배열로 해놓고
      for(of of arr) { ... }
      for(i of of) { ... }
      라고 쓰는 것도 가능하다.
    • async function async() { ... }
      라는 코드도 정상 작동한다. 하지만
      async function await() { ... }; console.log(await await());
      라고 쓰면 오류가 난다. 허나 코드 가독성이 낮아지기 때문에 안 쓰는 것이 좋다.
    • JavaScript의 싱글스레드 이벤트 루프 기반의 작동 방식 때문인지
      setInterval()
      또는
      setTimeout()
      함수 사용 시 약간의 지연이 발생한다.[30]
  • 너무 오래된 컴퓨터에서 최신 웹 페이지의 JavaScript를 불러오면 브라우저에서 "JavaScript가 과도하게 로딩되어 종료해야합니다."같은 메시지가 뜨거나 브라우저가 뻗어버릴수 있다.
  • 구형 기기에서 동영상이 많은 나무위키의 문서를 볼 때도 뻗어버리므로 JavaScript를 잠시 끄면 된다.


12. 외부 링크[편집]



파일:크리에이티브 커먼즈 라이선스__CC.png 이 문서의 내용 중 전체 또는 일부는 2022-07-02 15:39:14에 나무위키 JavaScript 문서에서 가져왔습니다.

[1] 이 때문에 동적인 홈페이지가 필요없다면 JavaScript는 안 써도 된다. 그러나 현대의 웬만한 홈페이지에는 동적인 요소가 들어가므로 거의 필수적으로 쓰이는 것이 현실.[2] 다만 JavaScript라는 상표권은 오라클에게 있다.[3] 1990년대 중반에 발표된 언어가 요즘 새롭게 나오는 언어들보다도 더 한 추상화를 자랑한다.[4] 그때는 Java를 할 줄 알면 JavaScript를 몰라도 깔 수 있었다. 이름으로...[5] 과거에는 브라우저의 JavaScript 엔진이 파일 시스템 같은 자원에 접근할 수 있었다.[6] 링크를 보면 알겠지만 초창기 넷스케이프 사의 점유율은 80%로 압도적이었으나 점점 일방적으로 Internet Explorer에게 밀리는 것이 보인다. 참조.[7] Internet Explorer 8 이하의 버전에서는 JScript만의 문법이 남아있어 크로스 브라우징 문제가 빈번하게 일어났다. 대표적으로 addEventListener를 attachEvent 같은 식으로 구현하는 것이 그러하다. Internet Explorer 9부터는 ECMA 표준을 따르도록 수정되었으나, 레거시 지원을 위해 기존의 JScript도 남겨 두었다. 그래서 JScript 라이브러리 역시 jscript.dll과 jscript9.dll이 같이 존재하며, 기본의 JScript는 문서 모드를 8 이하로 설정한 경우에 사용된다.[8] Paul, Ryan (2008-08-22). "Firefox to get massive JavaScript performance boost". Ars Technica. Retrieved 2013-03-21.[9] 이런 3D 게임 같은 분야에서는 빠른 JavaScript와 WebGL 등으로도 부족해서 이젠 모질라에서 asm.js 같은 서브셋까지 만들어서, 산술 연산이 거의 네이티브 코드에 가깝게 실행될 수 있도록 극한의 최적화를 하고 있다.[10] 다만 대학생이라면 학교 이메일을 통해 무료로 사용할 수 있다. 굉장히 유용하므로 대학생이라면 놓치지 말자.[11] 2021년 9월부로 지원 종료[12] 재미있는 점은 이 세 에디터는 내부적으로 JavaScript를 쓴다는 것이다! 정확히는 Node.js의 라이브러리인 ElectronJS로 만든 것이다.[13] 프로토타입으로 인스턴스들의 공통 변수를 설정할 수 있는 건 다른 객체 지향 언어에도 있으니(클래스 변수,상수 개념) 그려러니 하지만 프로토 타입으로 아예 생판 관계없는 타입으로도 바꿀 수 있는 건(객체 지향은 상위/하위로 관계가 없지 않은 이상 형 변환이 불가능하다) 객체 지향에서 적응된 사람들을 헷갈리게 하는 원인 중 하나다. 오히려 프로토타입은 타 언어의 상위 클래스라는 용어로 설명하기 보다는 요식업에서 사용하는 원조라는 단어로 설명하는게 더 간편하다.[14] 다만 JavaScript는 한 줄로 붙여 쓰지 않는 이상 굳이 세미콜론을 쓰지 않아도 되는데, 강제개행이 세미콜론 역할을 하기 때문이다.[15] 정확히는 함수형이 주로 쓰이는 멀티 패러다임[16] 가변 변수 선언[17] 불변 변수 선언. 다만 객체는 객체 내부의 값을 변경할시 불변성이 유지되지 않는다. 객체 그 자체에만 불변성이 보장되는 셈.[18] 특히 arrow syntax의 등장으로 이 기능은 더더욱 강해졌다.[19] 약타입 언어라는 약점을 극복하기 위해서 JavaScript 슈퍼셋 언어인 TypeScript라는 것도 나왔으며 실제로 순정 JavaScript와 더불어 많이 쓰이고 있다.[20] JavaScript 객체 표기법으로 오늘날 AJAX의 XML 대신 쓰이고 있다. 그래서 AJAJ라고 불려야 된다는 사람들이 있을 정도.[21] 물론 절차적 프로그래밍에 익숙한 사람 기준에서다.[22] 항상 싱글 스레드로만 작동하는건 아니다.[23] 반대로 JavaScript 커뮤니티에서는 싱글스레드와 컨티뉴에이션의 단순하고 투명한 작동 모델이 오히려 프로그램을 더 좋게 만든다는 의견도 있다.[24] 완전한 동시 실행은 아니며, 그 중 하나라도 거부(rejected)되면 그 Promise의 오류가 떠 Promise 별로 오류를 확인하고 싶다면 Promise.allSettled를 써야한다. 파이썬의 asyncio.gather와 비슷하다.[25] 보통 Electron 프레임워크가 많이 쓰인다.[26] 본래 이름은 ServerJS였다.[27] 기존 문서에는 MVC의 V(View)를 담당하는 라이브러리라고 되어 있었으나 리액트는 MVC framework가 아니며 View뿐만 아니라 Controller 부분까지도 리액트 컴포넌트 내에서 작성이 가능하므로 정확한 설명이 아니다.[28] Java는 객체 지향, JavaScript는 객체 기반 언어이다.[29] 그래도 언매니지드 언어류에서는 대체가 없다. 웹에서 JS를 대체할 언어가 없는 것과 비슷하다.[30] 자세히 말하자면, 이벤트루프의 호출 우선순위에서 callback queue는 job queue나 microtask queue 보다 우선순위가 낮기 때문이다.

분류