최근 수정 시각 : 2024-11-26 17:26:08

JavaScript

ECMAScript에서 넘어옴
프로그래밍 사이트 선정 프로그래밍 언어 순위 목록
{{{#!wiki style="margin: 0 -10px -5px; word-break: keep-all"
{{{#!wiki style="display: inline-table; min-width: 25%; min-height: 2em;"
{{{#!folding [ IEEE Spectrum 2024 ]
{{{#!wiki style="margin: -5px 0" 		<rowcolor=#fff> 스펙트럼 부문 상위 10개 프로그래밍 언어 직업 부문 상위 10개 프로그래밍 언어
1 Python 1 SQL
2 Java 2 Python
3 JavaScript 3 Java
4 C++ 4 TypeScript
5 TypeScript 5 SAS
6 SQL 6 JavaScript
7 C# 7 C#
8 Go 8 HTML
9 C 9 Shell
10 HTML 10 C++
}}}
}}}
}}}
[ Stack Overflow 2024 ]
[ TIOBE 2024 ]
||<tablewidth=100%><width=9999><-4><bgcolor=deepskyblue><tablebgcolor=#fff,#222> 2024년 8월 기준 검색어 점유율 상위 20개 프로그래밍 언어 ||
1 Python 11 MATLAB
2 C++ 12 Delphi / Object Pascal
3 C 13 PHP
4 Java 14 Rust
5 C# 15 Ruby
6 JavaScript 16 Swift
7 SQL 17 Assembly language
8 Visual Basic 18 Kotlin
9 Go 19 R
10 Fortran 20 Scratch
{{{#!wiki style="margin: 0 -10px -5px; min-height: calc(1.5em + 5px);"
{{{#!folding [ 21위 ~ 50위 펼치기 · 접기 ]
{{{#!wiki style="margin: -5px -1px -11px" 		21 COBOL 36 Scala
22 Classic Visual Basic 37 Transact-SQL
23 LISP 38 PL/SQL
24 Prolog 39 ABAP
25 Perl 40 Solidity
26 (Visual) FoxPro 41 GAMS
27 SAS 42 PowerShell
28 Haskell 43 TypeScript
29 Dart 44 Logo
30 Ada 45 Wolfram
31 D 46 Awk
32 Julia 47 RPG
33 Objective-C 48 ML
34 VBScript 49 Bash
35 Lua 50 Elixir
}}}}}}}}} ||
[ PYPL 2024 ]

}}} ||
프로그래밍 언어 목록 · 분류 · 문법

TIOBE 선정 올해의 프로그래밍 언어 / JavaScript
{{{#!folding [펼치기 / 접기] 2013년
Transact-SQL 		→ 2014년
JavaScript 		→ 2015년
Java
}}} ||

자바스크립트
JavaScript
파일:javascript_logo_no_margin.svg
<colcolor=#000,#fff> 개발 브랜든 아이크, Ecma International
개발일 1995년 12월 4일
최신 버전 ECMAScript 2024( 2024년 6월)
파일 확장자 .js
파일:홈페이지 아이콘.svg

1. 개요2. 역사3. 개발 도구4. 특징5. DOM6. CommonJS7. 관련 개념
7.1. 표준7.2. 주요 라이브러리7.3. 기타 라이브러리7.4. 파생 언어
8. 웹과 JavaScript
8.1. 차단
8.1.1. 구글 크롬8.1.2. 모질라 파이어폭스8.1.3. 마이크로소프트 엣지
9. 엔진10. 문법11. 학습
11.1. 도서11.2. 웹사이트
12. 기타13. 외부 링크

[clearfix]
#!syntax javascript
console.log("Hello, World");

1. 개요


Ecma International의 프로토타입 기반의 프로그래밍 언어로, 스크립트 언어에 해당된다. 특수한 목적이 아닌 이상 모든 웹 브라우저에 인터프리터가 내장되어 있다. 오늘날 HTML, CSS와 함께 웹을 구성하는 요소 중 하나다. HTML이 웹 페이지의 기본 구조를 담당하고, CSS가 디자인을 담당한다면 JavaScript는 클라이언트 단에서 웹 페이지가 동작하는 것을 담당한다.[1] 웹 페이지를 자동차에 비유하자면, HTML은 자동차의 뼈대, CSS는 자동차의 외관, JavaScript는 자동차의 동력원인 엔진이라고 볼 수 있다.

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

그래서 흔히 하는 농담으로 자바와 자스의 관계는 인도와 인도네시아의 관계와 같다는 말이 있는데, 실제로도 엇비슷한 느낌이 있다. 자바스크립트가 자바와 관계가 없더라도 그 이름만큼은 실제로 자바에서 가져온 게 맞는데, 인도네시아 역시 인도랑은 별 관계가 없지만 인도네시아라는 국호는 인도에서 따온 게 맞기 때문[4]

2. 역사

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

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

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

제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가 제정되고 표준 문제가 다소 해결되었다.[10]

한편 그렇게 표준화를 거친 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배에 달했다.[11] 그리고 구글 역시 V8이라는 JavaScript 엔진을 개발하면서 JIT 컴파일 방식을 도입하였고, JavaScript 성능이 비약적으로 향상하여 지금은 JavaScript 3D 게임 엔진도 개발되고 있다.[12]

3. 개발 도구

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

최근에는 GitHub의 Atom[15], Microsoft의 Visual Studio Code, Adobe의 Brackets[16] 등의 오픈 소스 에디터도 출시되고 있다.[17] 해외의 경우 99프로 가까이 비주얼 스튜디오 코드를 쓰는 만큼 웹 개발에 비주얼 스튜디오 코드는 사실상 업계 표준이다. 한국도 뒤따라 비주얼 스튜디오 코드를 쓰는 추세가 되고있다. 자세한 내용은 텍스트 에디터 참고.

4. 특징

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

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

JavaScript는 C에서 영향을 받은 C-family 언어로 기본적인 문법이 유사 중괄호로 구분하는 블럭, 세미콜론으로 줄이 끝남을 알리는 것[20], 변수 쓰는 법, 연산자 사용법 등 기초적인 문법이 C 문법과 크게 다르지 않다. 호이스팅 같은 것도 C 언어의 잔재이다. 무엇보다 다른 언어 쓰다 온 사람들을 힘들게 하는 건 클래스와 메소드가 외관으로 구분이 안 된다라는 점이다. 물론 태생부터 동적 언어인데다 언어가 발전하면서 점차 독자적인 방향으로 나아갔기에 현재는 C랑 비슷하다는 이야기를 듣기가 거의 힘들다.

JavaScript에서도 함수형[21] 언어의 불편함과 호이스팅 등 여러 문제를 무마하기 위해서 클래스 개념의 도입과 변수 선언을 let[22], const[23]로 하는 등 다른 언어 쓰는 사람들의 적응을 돕도록 흉내는 내 주는 척하는 게 다행. 물론 웹에서 가장 많이 쓰는 언어라서 그런지 객체지향 쪽의 개념은 일반적이지가 않은 편이다.

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

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

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

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

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

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

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

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

이 때문에 현재 JavaScript는 확장성이 매우 높은 언어이다. JavaScript만 알면 일반적인 사이트 개발부터 React.js 또는 Vue.js를 사용해 SPA 웹사이트 개발, iOS와 안드로이드 앱을 만들수 있는 React Native, 웹 서버나 다른 서버 사이드 애플리케이션에 Node.js, 데스크톱 앱은 리눅스, macOS, 윈도우, tvOS 등 플랫폼에서 사용 가능한 Electron을 이용하거나 React Native for Windows를 사용해 Windows 10 SDK까지 접근할 수 있다.[34] 이외에도 순수 JS만을 이용하는 Vanilla JS도 존재한다. 다만 이 경우 빠른 속도를 자랑하지만 역설적으로 프레임워크 미사용으로 인해 코드가 더 길어진다는 단점이 존재한다.

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

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

이렇게만 보면 자바스크립트는 모든 것을 할 수 있는 최강의 언어처럼 보일 수도 있다. 보편적이며, 웹 한정이지만 많은 일을 할 수 있고, 정말 많은 런타임과 프레임워크가 사용자 친화적인 환경 설계를 도와준다. 하지만 자바스크립트의 맹점은 바로 처음부터 잘 설계된 언어가 아니라는 것인데, 호이스팅 이슈[35]는 기본, 백틱 사용, 클래스와는 다른 객체라는 특성, 함수와 객체의 여러 가지 선언법[36], 콜백 지옥[37] null과 undefined[38] 등의 문제로 지금도 끊임없이 새로운 문법이 생성되고 있고 앞으로도 그럴 것이다. 객체 지향이면서 안정적인 C# 그리고 자바, 생산성이 뛰어난 파이썬, 다트 등과 비교하자면 자바스크립트는 굉장히 허점이 많고 디버깅에서도 크게 불리하다. 어떻게 보면 이 불완전함이라는 약점을 강력한 웹 생태계를 통해 밀어붙였고, 사용자가 많으니 자연스레 여러 피드백과 지원 환경이 나와 결국 사용자들이 불편함을 편리하게 바꿨다고 볼 수 있다. 따라서 자바스크립트를 배우게 되면 다른 프로그래밍 언어와 완전히 따로 노는 별도의 체계를 이해해야 한다는 어려움이 생기게 된다. 그리고 그것을 시장 주도권으로 다 휘어잡아 버렸다. 불편함에 익숙해져라 이에 따라 타입스크립트가 나오자 정적 언어에 익숙한 유저들은 대부분 그곳으로 넘어가 버렸지만 타입스크립트 역시 약점이 많기에 자바스크립트를 완전히 대체하지는 못한다.

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

JavaScript는 기본적으로 인터프리터 언어이지만, V8, SpiderMonkey 등의 엔진에서 JIT(Just-In-Time) 컴파일을 도입했으며, Hopc, Static Hermes 같은 AOT 컴파일러도 아직 입지가 좁거나 개발 중이지만 존재한다.[39]

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 표준화로 점차 사라졌다.[40]

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

6. CommonJS

JavaScript의 발전과 함께 이 언어를 서버 사이트 스크립팅 등 다양한 환경에서 사용하고자 하는 움직임이 일어났으며, 그 시초가 바로 CommonJS다.[41] 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: 넷스케이프가 인터넷상의 다양한 스크립트 언어를 하나로 묶기 위해 Ecma 인터내셔널에 제시하고 채택된 표준. 이 사양을 구현한 JavaScript 구현체로는 구글의 V8 엔진, 모질라의 SpiderMonkey, Microsoft의 Chakra 등이 있다. 실제로 JavaScript에만 적용되는 표준안이 아니라, Internet Explorer의 JScript나 Adobe Flash의 ActionScript의 표준이기도 하다. 2024년 10월 기준 ECMAScript 2024의 표준 (15판)까지 나와 있다.

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에서 만든 프론트엔드용 오픈 소스 라이브러리다.[42] 단방향 데이터 흐름과, 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 데스크톱 앱 프레임워크.[43]
  • 언더스코어: 리스트 해석, 고차 함수 집합 라이브러리. 홈페이지
    • 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에서 변수 타입이나 오류에 관한 피드백을 즉각즉각 해 주어서 버그 방지에 유용하다.
  • AssemblyScript - TypeScript에서 WebAssembly로의 컴파일을 목적으로 또다시 파생되어 나온 언어.
  • CoffeeScript: JavaScript의 문법을 개선한 신형 언어. 컴파일 결과로 JavaScript 코드를 내보낸다. 기존 JavaScript의 설계 결함을 극복할 목적으로 만들어졌다. 그러나 Python처럼 들여쓰기로 코드 블록을 구분하는 문법을 채택해 호불호가 갈리는 편이다. 2017년 말에는 '불호' 쪽으로 많이 기울어 있는 상황이다.
  • JavaScript.NET: JavaScript를 컴파일러용 언어로 개조한 것이다.
  • ReasonML: 전직 페이스북 개발자가 만든 정적 타입, 함수형 프로그래밍 기반 언어이다.
  • ReScript

8. 웹과 JavaScript

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

반면, 같은 웹 환경에서 사용되는 나머지 두 핵심 언어(마크업 언어)인 HTML과 CSS는 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 코드를 실행할 수 있도록 하는 Dartium 프로젝트를 진행하였으나 개발이 중단되었다.

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

8.1. 차단

모든 사이트들이 그런 것은 아니지만, 광고나 특정 사이트에 무분별하게 끼어드는 리다이렉트를 없애기 위한 조치가 있다. 단, 일회성으로만 사용해야 하며, 이 방법을 계속 유지할 경우, 자바스크립트로 글이나 이미지 등 컨텐츠를 불러오는 대다수의 사이트[44]를 사용할 수가 없다. 인스타그램 같은 SPA 사이트는 거의 이용 불가능이다.[45] 광고로 수익을 내는 사이트에서는 아예 금기시되고 있어, 논란이 많은 편이다.

8.1.1. 구글 크롬

개인 정보 보안 탭으로 간 후, 사이트 설정으로 간 뒤, 컨텐츠 클릭 후, 자바 스크립트 허용 안 함 탭을 누르고. 새로 고침을 하면 된다.

8.1.2. 모질라 파이어폭스

주소 표시줄에 about:config 입력 후 엔터를 누른다. 그런 다음, 위험을 감수하고 클릭을 누른 다음, java 탭을 검색해서, javascript.enabled에 있는 true를 false로 바꾸고 새로 고침을 하면 된다.

8.1.3. 마이크로소프트 엣지

우측 상단의 점 3개를 누르거나, 설정 탭으로 간 다음, 쿠키 탭으로 간다. 모든 퍼미션 탭을 누른다음, 허용됨(권장)의 활성화를 끄고, 새로 고침을 하면 된다.

9. 엔진

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

10. 문법

파일:상세 내용 아이콘.svg   자세한 내용은 JavaScript/문법 문서
를
의 번 문단을
의 부분을
참고하십시오.

11. 학습

11.1. 도서

11.2. 웹사이트

12. 기타

  • Java와는 이름의 유사성과 같은 C-족 언어라는 걸 빼면 전혀 상관이 없는, 완전히 별개의 언어다. 프로그래밍에 대해 잘 모르는 사람들이 아직까지도 자주 헷갈려 하는 부분.[46]
  • 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, MESS를 LLVM/ Clang으로 컴파일하여 웹 브라우저에서 구동하게 한 것이다. Core i5 정도의 컴퓨터라면 플레이 하는 데 거의 지장이 없는 수준을 보여준다.
  • 웹 애플리케이션의 개발 트렌드를 따라가다 보면 흥미로운 사실을 발견할 수 있는데, 웹 클라이언트 사이드 언어인 JavaScript를 사용하는 방식이 절차형에서 객체 지향으로, 다시 함수형으로 이동하고 있다는 사실을 발견할 수 있다. 현재는 함수형에서 더 발전해 반응형(reactive)으로 가고 있고 reactive 구현체인 rxjs는 현재 프론트엔드 3대장 프레임워크인 AngularJS/ Angular의 필수 패키지 중 하나이다. 다른 reactive 구현체로는 Java에서 쓰이는 rxjava가 있다.
  • JavaScript는 멀티패러다임 언어로, 절차형, 함수형, 논리형을 포함한 그 어떤 방식으로도 코딩이 가능하다. 단, 이걸 JavaScript 킹왕짱 만능 끝판왕 종결자로 생각해서는 안 된다. 나쁘게 말하면 잡탕이기 때문. 정확히는 개발자가 패러다임을 흩뜨리지 않고 잘 쓸 수 있을 정도의 수준이 되어야 멀티패러다임 언어를 이용한 소프트웨어가 잡탕이 안 된다. C++를 예시로 보면 너무 많은 패러다임을 지원해서 배우기도 쓰기도 어려운 언어 중 하나가 되어버렸고, 결국 좋은 개발자를 찾기가 힘든 상황이 됐다.[47]
  • 얼마 전까지만 해도 언어가 아닌 매크로로 취급됐는데 이제는 독립적인 언어로 인정되고 있는 이유는, 더 이상 브라우저의 확장이나 플러그인만을 위한 것이 아닌, 서버형인 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() 함수 사용 시 약간의 지연이 발생한다.[48]
  • 너무 오래된 컴퓨터에서 최신 웹 페이지의 JavaScript를 불러오면 브라우저에서 "JavaScript가 과도하게 로드되어 종료해야 합니다"같은 메시지가 뜨거나 브라우저가 뻗어버릴 수 있다.
  • 구형 기기에서 동영상이 많은 나무위키의 문서를 볼 때도 뻗어버리므로 JavaScript를 잠시 끄면 된다.
  • 난해한 프로그래밍 스타일로 JSFuck이 있다.
  • 수많은 문제점으로 인해 현존 프로그래밍 언어들 중 가장 많이 까이는 언어다. 동적 언어들이 유달리 까이는 경우가 많지만 자바스크립트는 잊을 만하면 노근본이나 쓰레기로 까이며 이는 뚱이 밈처럼 해외에서도 별반 다르지 않다. 역으로 말하면 그만큼 자바스크립트를 사용하는 환경이 많다고 볼 수 있다. 이 외에도 많이 까이는 언어는 PHP와 Python이 있다. 그나마 파이썬은 호평하는 층이 많은 편이다. 자바스크립트는 10일, 파이썬은 7일 만에 설계되었다는 비슷한 점이 있긴 하다. 그런데 자바스크립트는 자바스크립트를 만든 브랜든 아이크 자신조차도 너무 급하게 만들었다는 걸 스스로 인정했다.
  • 현존하는 모든 역법을 통틀어 0월을 현재까지 사용하는 유일한 언어이다. 정확히는 날짜를 나타내는 자바스크립트 빌트인 객체인 Date는 월을 숫자가 아니라 문자열로(Jan, Feb, ...) 다루고, 월을 나타내는 getMonth가 월 값을 0-based index로 반환하는데 그래서 1월을 숫자로 표현하면 0이 되는 것이다. Date 객체의 저열함을 나타내는 대표적 요소 중 하나로 이외에도 빌트인 Date는 완성도가 떨어지고 쓰기 불편한 것으로 악평이 많고, 현업에서는 date-fns, dayjs등의 날짜 라이브러리를 사용하는 경우가 많다. 브랜든 아이크가 밝히기를 java.util.Date를 그대로 가져온 것이라서 사실 구버전 자바도 같은 문제를 공유하는데, 자바는 버전이 올라가면서 LocalDateTime 등 더 나은 객체를 지원하지만 자바스크립트 날짜 빌트인 객체는 여전히 저 구린 Date가 유일하다.
  • 마법사책으로 유명한 MIT출판사의 Structure and Interpretation of Computer Programs(SICP)는 원래 교육에 LISP의 방언인 Scheme을 사용했는데 2022년에 자바스크립트 버전이 출판되었다.
  • Javascript를 포함한 온갖 스크립트를 차단하면 패킷양을 줄일 수 있으나 Opera Mini의 극도 모드마냥 완전히 줄어드는 게 아니니 주의하자.
  • 게임 Cookie Clicker에서 쿠키를 생산하는 건물로 후반에 자바스크립트 콘솔이 등장한다.
  • 백준에서 알고리즘 문제를 풀 때 언어로 Node.js를 선택하면 자바스크립트로 문제를 풀 수 있는데, 입출력을 위한 보일러 플레이트가 꽤 길다. 자세한 내용은 이 글을 읽어볼 것.

13. 외부 링크


[1] 이 때문에 동적인 홈페이지가 필요 없다면 JavaScript는 안 써도 된다. 그러나 현대의 웬만한 홈페이지에는 동적인 요소가 들어가므로 거의 필수적으로 쓰이는 것이 현실. [2] 다만 JavaScript라는 상표권은 오라클에게 있다. [3] 재미있는 점은 Java는 인도네시아의 자바섬에서 따왔다고 한다. [4] 이런 이름을 갖게 된 이유는 인도네시아를 처음 통일하고 지배한 주체가 네덜란드 동인도회사이기 때문이다. 나중에야 여기가 인도랑은 상관 없는 땅이라는 걸 알았지만, 처음 이곳을 지배하기 시작했을 무렵에는 대충 향신료 같이 비싼 게 나오는 곳 중에서 중국이 아닌 곳을 죄다 인도의 일부로 퉁쳤기 때문이다(...) [5] 오라클이 오픈 소스나 다른 회사와 마찰이 많아 악명이 높지만 RHEL 포크판인 오라클 리눅스를 무료로 운영하는 등 의외의 면모도 있다. [6] 1990년대 중반에 발표된 언어가 요즘 새롭게 나오는 언어들보다도 더 한 추상화를 자랑한다. [7] 그때는 Java를 할 줄 알면 JavaScript를 몰라도 깔 수 있었다. 이름으로.... [8] 과거에는 브라우저의 JavaScript 엔진이 파일 시스템 같은 자원에 접근할 수 있었다. [9] 링크를 보면 알겠지만 초창기 넷스케이프사의 점유율은 80%로 압도적이었으나 점점 일방적으로 Internet Explorer에게 밀리는 것이 보인다. 참조. [10] Internet Explorer 8 이하의 버전에서는 JScript만의 문법이 남아있어 크로스 브라우징 문제가 빈번하게 일어났다. 대표적으로 addEventListener를 attachEvent 같은 식으로 구현하는 것이 그러하다. Internet Explorer 9부터는 ECMA 표준을 따르도록 수정되었지만, 레거시 지원을 위해 기존의 JScript도 남겨 두었다. 그래서 JScript 라이브러리 역시 jscript.dll과 jscript9.dll이 같이 존재하며, 기본의 JScript는 문서 모드를 8 이하로 설정한 경우에 사용된다. [11] Paul, Ryan (2008-08-22). "Firefox to get massive JavaScript performance boost". Ars Technica. Retrieved 2013-03-21. [12] 이런 3D 게임 같은 분야에서는 빠른 JavaScript와 WebGL 등으로도 부족해서 이젠 모질라에서 asm.js 같은 서브셋까지 만들어서, 산술 연산이 거의 네이티브 코드에 가깝게 실행될 수 있도록 극한의 최적화를 하고 있다. [13] 다만 플러터 웹은 마크업을 쓸 필요가 없어서 커뮤니티 버전도 지원이 매우 잘 되는 안드로이드 스튜디오를 쓰는 경우가 대다수다. 일부 자바스크립트 개발자는 편의를 위해 자바까지 같이 해결하려 IntelliJ를 쓰기도 한다. [14] 다만 대학생이라면 학교 이메일을 통해 무료로 사용할 수 있다. 굉장히 유용하므로 대학생이라면 놓치지 말자. [15] 2022년 12월부로 지원 종료 [16] 2021년 9월부로 지원 종료 [17] 재미있는 점은 이 세 에디터는 내부적으로 JavaScript를 쓴다는 것이다! 정확히는 Node.js의 라이브러리인 ElectronJS로 만든 것이다. [18] 프로토타입으로 인스턴스들의 공통 변수를 설정할 수 있는 건 다른 객체 지향 언어에도 있으니(클래스 변수, 상수 개념) 그러려니 하지만 프로토 타입으로 아예 생판 관계없는 타입으로도 바꿀 수 있는 건(객체 지향은 상위/하위로 관계가 없지 않은 이상 형 변환이 불가능하다) 객체 지향에서 적응된 사람들을 헷갈리게 하는 원인 중 하나다. 오히려 프로토타입은 타 언어의 상위 클래스라는 용어로 설명하기 보다는 요식업에서 사용하는 원조라는 단어로 설명하는 게 더 간편하다. [19] 이로 인해 디자인 패턴 또한 굉장히 다양하다. 스크립트 파일들만 별개로 묶어서 저장하기도 하고, 스벨트킷처럼 하나의 html에 하나의 js가 대응하기도 한다. [20] 다만 JavaScript는 한 줄로 붙여 쓰지 않는 이상 굳이 세미콜론을 쓰지 않아도 되는데, 강제 개행이 세미콜론 역할을 하기 때문이다. [21] 정확히는 함수형이 주로 쓰이는 멀티 패러다임 [22] 가변 변수 선언 [23] 불변 변수 선언. 다만 객체는 객체 내부의 값을 변경할 시 불변성이 유지되지 않는다. 객체의 참조 그 자체에만 불변성이 보장되는 셈. [24] 특히 arrow syntax의 등장으로 이 기능은 더더욱 강해졌다. [25] 어디까지나 예상치 못한 버그의 최소화일 뿐이지 언어 자체의 하자로 인한 함정 패턴을 피하는 건 끝없는 경험 외에는 해결책이 없다. [26] 약타입 언어라는 약점을 극복하기 위해서 JavaScript 슈퍼셋 언어인 TypeScript라는 것도 나왔으며 실제로 순정 JavaScript와 더불어 많이 쓰이고 있다. [27] JavaScript 객체 표기법으로 오늘날 AJAX의 XML 대신 쓰이고 있다. 그래서 AJAJ라고 불려야 된다는 사람들이 있을 정도. [28] 항상 싱글스레드로만 작동하는 건 아니다. [29] 반대로 JavaScript 커뮤니티에서는 싱글스레드와 컨티뉴에이션의 단순하고 투명한 작동 모델이 오히려 프로그램을 더 좋게 만든다는 의견도 있다. [30] 파이썬에서도 코루틴과 async/await의 개념 자체는 같지만 세부적으로는 조금 다른 편이다. [31] 완전한 동시 실행은 아니며, 그중 하나라도 거부(rejected)되면 그 Promise의 오류가 떠 Promise별로 오류를 확인하고 싶다면 Promise.allSettled를 써야 한다. 파이썬의 asyncio.gather와 비슷하다. [32] 런타임 환경이라는 단어에서 보듯 노드는 절대로 서버나 프레임워크가 아니다! 물론 서버로도 쓸 수 있지만 노드가 서버이냐 서버로 쓸 수 있느냐는 아예 다른 이야기다. [33] 보통 Electron 프레임워크가 많이 쓰인다. 다만 2020년대부터는 Blazor.net과 Flutter에 자리를 많이 내주고 있다. 블레이저의 경우 윈폼 사용자들을 그대로 흡수하기에 경쟁에서 이기기 어려운 상대이기도 하다. [34] 다만 JS로 웹 이외의 부분을 만드는 것은 어디까지나 권장되지 않는 부분이다. 모든 개발자가 JS 외에는 쓸 수 없는 상황이거나 하는 극단적인 상황이 아니라면 데스크탑과 임베디드에는 다른 언어를 쓰는 것이 좋다. [35] 문제는 자바스크립트 인강 강사들 중 일부는 자기가 이걸 지적해 놓고도 정작 리액트나 뷰 등의 라이브러리 강의에서는 계속 var를 사용하는 추태를 보이기도 한다. ES6 문법이 2015년에 나왔으니 한마디로 답이 없다. [36] 함수 선언법은 3가지, 객체 선언법은 4가지다. 물론 전부 실전에서 쓰이는 방법이며 ES6 권장 문법이라는 게 멀쩡히 있음에도 프레임워크 차원에서 쿨하게 무시해 버린다. 대표적으로 Vue와 Svelte가 함수 선언에서 ES6 권장 문법을 무시한다. [37] async와 await 문법이 지원된다지만 파이썬의 코루틴과 비교하면 이게 맞나 싶을 정도로 처참한 가독성을 자랑한다. 코드 양으로만 비교해도 두 배 가까이 차이가 난다. [38] 이 undefined가 사실상 만악의 근원이나 다름없다. 기존 개발자에겐 익숙할지 몰라도 신규 진입 개발자들은 undefined가 계속해서 발목을 잡으니 자바스크립트에 등을 돌릴려고 했는데 대안이 없어 억지로 참는 수밖에 없다. [39] 다만 AOT 컴파일러가 나올 때쯤이면 WASM 또한 안정화 궤도에 오를 가능성이 높아서 자바스크립트의 의존도가 낮아질 가능성도 존재한다. [40] 우습게도 이러한 JS 표준화는 구글이 차후 내놓은 언어인 Dart에게도 상당 부분 발목을 잡게 되었다. Dart 자체는 간결한 코드로 우아하게 작동되지만, 이미 JS로 모든 것이 동작되는데 아무리 좋다 한들 기존 것을 포기해 가면서까지 옮길 메리트가 없었던 것이다. Flutter의 웹 렌더링은 24년 5월 WASM이 지원되기 전까지는 JS로 컴파일되는 굴욕을 맛봐야만 했다. [41] 본래 이름은 ServerJS였다. [42] 기존 문서에는 MVC의 V(View)를 담당하는 라이브러리라고 되어 있었으나 리액트는 MVC framework가 아니며 View뿐만 아니라 Controller 부분까지도 리액트 컴포넌트 내에서 작성이 가능하므로 정확한 설명이 아니다. [43] 다만 어디까지나 JS로도 PC 어플리케이션을 만들 수 있다 정도지 실제로는 윈폼과 같이 좋은 SDK가 이미 많기에 권장되지 않는다. [44] 과거엔 대부분 HTML에 직접 컨텐츠를 넣어서 처리를 했지만 요즘은 자바스크립트를 통해 불러오는 경우도 많다. [45] 페이스북은 WAP 모드가 있어서 사용 자체는 된다. [46] Java는 객체 지향, JavaScript는 객체 기반 언어이다. [47] 그래도 언매니지드 언어류에서는 대체가 없다. 웹에서 JS를 대체할 언어가 없는 것과 비슷하다. Rust가 그 자리를 노리고는 있으나, 아직까지 큰 진전은 없다. [48] 자세히 말하자면, 이벤트 루프의 호출 우선순위에서 callback queue는 job queue나 microtask queue 보다 우선순위가 낮기 때문이다.

분류