mir.pe (일반/밝은 화면)
최근 수정 시각 : 2024-04-14 21:35:51

JavaScript

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

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

자바스크립트
JavaScript
파일:JavaScript 로고.svg
<colbgcolor=#fff,#1f2023><colcolor=#000,#fff> 개발 브랜든 아이크, Ecma International
개발일 1995년 12월 4일
최신 버전 ECMAScript 2023( 2023년 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. 마이크로소프트 Edge
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는 완전히 다르다. 햄이랑 햄스터가 다르고 파와 파슬리가 다르며, 인도가 인도네시아와 다르듯[3] 심지어는 웹 서버용 파생 규격도 다르다.

2. 역사

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

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

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

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

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

3. 개발 도구

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

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

4. 특징

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

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

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

JavaScript에서도 함수형[18] 언어의 불편함과 호이스팅 등 여러 문제를 무마하기 위해서 클래스 개념의 도입과 변수 선언을 let[19], const[20]로 하는 등 다른 언어 쓰는 사람들의 적응을 돕도록 흉내는 내 주는 척하는게 다행.

JavaScript는 멀티-패러다임 언어로 명령형, 함수형, 객체 지향형 언어다. 기본적으로는 함수가 일급 시민으로 취급되는 언어로써 함수형 프로그래밍 패러다임을 따른다. 자연스럽게 이는 클로저로 시작해 끝을 보는 것이 가능하다.[21] 멀티 패러다임 언어인만큼 원한다면 명령형 프로그래밍(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는 동적 타이핑, 약타입 언어고[22], 간단한 문법에 코딩 방법이 비교적 유연하기 때문에 초기 진입장벽이 거의 없어서 쉽다고 이야기 되지만, 깊이 들어가 보면 매우 변태적인 특이한 언어이자 매우 우수한 설계를 자랑하는 강력한 언어이다. 편하면서도 강력한 텍스트 표기법( JSON(JavaScript Object Notation))[23]을 가졌으며, 구조적으로 비동기 프로그래밍에 유리하다. 이러한 비동기 프로그래밍에 특화된 특징은 이후 Node.js를 탄생시키며 JavaScript라는 언어의 사용 반경을 폭발적으로 늘리는 데 기여하게 된다.

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

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

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

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

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

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

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

관련 책으로는 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다.[34] 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. 표준

7.2. 주요 라이브러리

7.3. 기타 라이브러리

7.4. 파생 언어

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. 차단

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

8.1.1. 구글 크롬

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

8.1.2. 모질라 파이어폭스

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

8.1.3. 마이크로소프트 Edge

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

9. 엔진

10. 문법

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

11. 학습

11.1. 도서

11.2. 웹사이트

12. 기타

13. 외부 링크

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

분류