JavaScript

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

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

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

JavaScript는 C에서 영향을 받은 C-Family 언어로 기본적인 문법이 유사 중괄호로 구분하는 블럭, 세미콜론으로 줄이 끝남을 알리는 것[2], 변수 쓰는 법, 연산자 사용법 등 기초적인 문법이 C 문법과 크게 다르지 않다. 호이스팅(선언문에 값을 할당하는게 자동으로 선언문쪽으로 올라가는것)같은것도 C언어의 잔재이다.

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

최근 자바스크립트 인터뷰에서 아직도 왜 호이스팅을 물어 보냐는 Dan Abramov의 트윗 https://twitter.com/dan_abramov/status/1362530955420987396 이 화제가 되었는데, 물론 현대 JS에서 호이스팅을 만날 일은 흔치 않지만 호이스팅이 어떤 문제를 풀려고 했으며 그 문제를 현대 JS에서는 어떻게 다루는지는 이해할 필요가 있다 본다.

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

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

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

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

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

최근 들어 JavaScript는 웹 디자이너들에게도 교육이 되고 있는 만큼 진입 장벽이 타 언어에 비해 낮은 편으로 인식되고 있다. 해외는 front-end 전담 개발자가 있을 만큼 전문화되어있는 반면, 국내에서는 수준이 현격히 낮은 만큼 일반인도 쉽게 접근하고 배울 수 있다. 구글 등을 비롯한 여러 벤더 사에서는 이 언어를 활용한 다양한 플랫폼 환경을 지원하고 있으며, Chrome Extension이나 App들이 그 좋은 예이다. 순수 JS로 이루어져 있어 실력이 된다면 자신만의 것들을 구현해 배포할 수도 있기 때문. 하지만 그렇다고 해서 JavaScript가 마냥 쉬운 언어라고 생각하면 오산이다. 동적 타입 언어인 만큼 예상과 다른 동작을 하는 경우도 많고, 콜백과 비동기 처리는 초보자 입장에서 코드 리딩이 굉장히 어렵다. 즉 입문은 쉬우나 배우다보면 벽에 막히는 언어. 하지만 ES6로 넘어와서는 콜백이 비교적 편해졌다. 하지만 일부 구형 브라우저(대표적으로 IE)는 지원을 하지 않는다!

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

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

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

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

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

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

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

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

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

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

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

이 때문에 현재 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가 있었다. 잘 익혀두면 직접 짜는 것보다 꽤 간단하게 기능을 불러 쓸 수 있어 대학에서도 가르쳤던 필수 라이브러리였다. 하지만 React나 Vue.js, 혹은 Angular가 등장한 이후로 모듈형 개발이 순식간에 대세가 되었고, 이는 jQuery 대비 비교도 안될 정도로 월등하게 생산성이 높기 때문에 현재로서는 jQuery 자체가 모던 웹 어플리케이션 개발에는 더이상 사용되지 않는 기술이라 생각하면 된다. 원한다면 다른 프레임워크에 jQuery 라이브러리도 병행해서 사용할 수도 있으나, 그럴 바에야 그냥 직접 Query selector를 사용해서 DOM을 업데이트하는 게 낫기 때문에 정말 간단한 어플리케이션이 아니면 사용할 이유가 없어져버렸다.

대세가 된 React나 Vue.js의 경우 단독으로 사용되는 경우는 드물며 Redux나 Mobx같은 상태관리 라이브러리를 같이 사용하여 개발한다. 상태관리 라이브러리를 사용하지 않아도 개발은 충분히 가능하나 매우 비효율적이라 규모가 큰 어플리케이션의 경우 사실상 개발 자체가 불가능하다고 보면 된다. 이 때문에 현재로는 Redux가 사실상 업계 표준처럼 사용되고 있다. 최근에는 Facebook에서 context라고 불리는 상태관리 라이브러리를 React에 포함시키면서 작은 규모의 어플리케이션에는 context를 사용하는 것도 고려해볼만 하다.

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


변수.함수.함수.함수.콜백(에러,값) 이런식으로 사용 가능하다. 다른 언어가 상위클래스.하위클래스......하위클래스.그 클래스의 변수나 메소드 이런식과 다르게 ~의와 같은 똑같은 의미로 이런식으로 추가하는게 가능하다.

오늘날 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 표준을 정한 것에 의해 표준화 되었다.

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

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

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

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

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

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

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