[모던JS] 02. 자바스크립트란?

Rae-eun Yang·2022년 4월 29일

JavaScript 모던 js 딥다이브

모던 자바스크립트 Deep Dive

목록 보기

1/8

2.1 자바스크립트의 탄생

1995년, 넷스케이프 커뮤니케이션즈는 웹페이지의 보조적인 기능을 수행하기 위해 브라우저에서 동작하는 경량 프로그래밍 언어를 도입하기로 결정
-> 브렌던 아이크가 개발한 자바스크립트 탄생

2.2 자바스크립트의 표준화

크로스 브라우징 이슈의 심화
-> 모든 브라우저에서 정상적으로 동작하는 표준화된 자바스크립트의 필요성이 대두되기 시작함

크로스 브라우징 이슈 : 브라우저에 따라 웹페이지가 정상적으로 동작하지 않는 상황

이에 넷스케이프 커뮤니케이션즈는 컴퓨터 시스템의 표준을 관리하는 기구 ECMA 인터내셔널에 자바스크립트의 표준화를 요청
-> 1997년 7월, ECMA-262라 불리는 표준화된 자바스크립트 초판(EMCAScript 1) 사양이 완성

ECMAScript 버전별 특징

버전	출시 연도	특징
ES1	1997	초판
ES2	1998	ISO/IEC 16262 국제 표준과 동일한 규격을 적용
ES3	1999	정규 표현식, try ... catch
ES5	2009	HTML5와 함께 출현한 표준안 JSON, strict mode, 접근자 프로퍼티, 프로퍼티 어트리뷰트 제어, 향상된 배열 조작 기능(forEach, map, filter, reduce, some, every)
ES6	2015	let/const, 클래스, 화살표 함수, 템플릿 리터럴, 디스트럭처링 할당, 스프레드 문법, rest 파라미터, 심벌, 프로미스, Map/Set, 이터러블, for...of, 제너레이터, Proxy, 모듈 import/export
ES7	2016	지수(**) 연산자, Array.prototype.includes, String.prototype.includes
ES8	2017	async/await, Object 정적 메서드(Object.values, Object.entries, Object.getOwnPropertyDescriptors)
ES9	2018	Object rest/spread 프로퍼티, Promise.prototype.finally, async generator, for await...of
ES10	2019	Object.fromEntries, Array.prototype.flat, Array.prototype.flatMap, optional catch binding
ES11	2020	String.prototype.matchAll, BigInt, globalThis, Promise.allSettled, null 병합 연산자, 옵셔널 체이닝 연산자, for... in enumeration order

2.3 자바스크립트 성장의 역사

초창기 자바스크립트는 웹페이지의 보조적인 기능만을 수행, 한정적인 용도로 사용되었음. 대부분의 로직은 웹 서버에서 실행되었고, 브라우저는 서버로부터 전달받은 HTML, CSS를 단순히 렌더링하는 수준이었음.

렌더링(rendering) : HTML, CSS, 자바스크립트로 작성된 문서를 해석하여 브라우저에 시각적으로 출력하는 것

2.3.1 Ajax

1999년, Ajax의 등장!

자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능인 Ajax가 XMLHttpRequest라는 이름으로 등장.

이전의 웹페이지는 완전한 HTML 코드를 서버로부터 전송받아 웹페이지 전체를 렌더링하는 방식으로 동작했음.
-> 불필요한 데이터 통신 발생, 성능 면에서 불리, 화면 전환 깜빡임 현상

Ajax의 방식 : 서버로부터 필요한 데이터만 전송받아 변경해야 하는 부분만 한정적으로 렌더링하는 방식
-> Ajax가 등장함으로써 웹 브라우저에서도 빠른 성능과 부드러운 화면 전환 가능

구글 맵스 : 2005년, 구글이 발표, 자바스크립트와 Ajax를 기반으로 동작, 데스크톱 애플리케이션과 비교했을 때 손색없을 정도의 성능과 부드러운 화면 전환 효과

2.3.2 JQuery

2006년, jQuery의 등장!

jQuery의 역할 : 번거로웠던 DOM(Document Object Model)을 더욱 쉽게 제어, 크로스 브라우징 이슈 조금 해결

크로스 브라우징 이슈 : 브라우저에 따라 웹페이지가 정상적으로 동작하지 않는 상황

2.3.3 V8 자바스크립트 엔진

2008년, 구글의 V8 자바스크립트 엔진 등장!

구글 맵스 이후 자바스크립트로 웹 애플리케이션을 구축하려는 시도가 늠
-> 더욱 빠르게 동작하는 자바스크립트 엔진의 필요성 대두

V8 자바스크립트의 역할 : 자바스크립트가 UX를 제공할 수 있게 함, 과거 웹 서버에서 수행되던 로직들이 대거 클라이언트(브라우저)로 이동, 프론트엔드가 주목받는 계기

2.3.4 Node.js

2009년, Node.js 등장!

Node.js : 구글 V8 자바스크립트 엔진으로 빌드된 자바스크립트 런타임 환경, 브라우저의 자바스크립트 엔진에서만 동작하던 자바스크립트를 브라우저 이외의 환경에서도 동작할 수 있도록 자바스크립트 엔진을 브라우저에서 독립시킨 자바스크립트 실행 환경

서버 사이드 애플리케이션 개발에 주로 사용됨
이에 필요한 모듈, 파일 시스템, HTTP 등 빌트인(내장) API 제공

Node.js는 자바스크립트 엔진 기반임.
-> Node.js 환경에서 동작하는 애플리케이션은 자바스크립트를 사용해 개발, 따라서 프론트엔드와 백엔드 영역에서 자바스크립트를 사용할 수 있게 함!

Node.js는 비동기 I/O를 지원, 단일 스레드 이벤트 루프 기반으로 동작함으로써 요청(request) 처리 성능이 좋음.
-> Node.js는 데이터를 실시간으로 처리하기 위해 I/O가 빈번하게 발생하는 SPA(Single Page Application)에 적합, CPU 사용률이 높은 애플리케이션에는 권장 안함.

Node.js의 등장
-> 자바스크립트가 브라우저를 벗어나 서버 사이드 애플리케이션 개발에서도 사용할 수 있는 범용 프로그래밍 언어가 되도록 함

자바스크립트는 크로스 플랫폼을 위한 가장 중요한 언어로 주목받는 중
모바일 하이브리드 앱(PhoneGap, Ionic), 서버 사이드(Node.js), 데스크톱(Electron), 머신러닝(TensorFlow.js), 로보틱스(Johnny-Five) 환경을 위한 프로그래밍 언어

2.3.5 SPA 프레임워크

모던 웹 애플리케이션은 데스크톱 애플리케이션과 비교해도 손색없는 성능과 사용자 경험을 제공하는 것이 필수가 됨. 더불어 개발 규모, 복잡도 상승

필요에 따라 많은 패턴과 라이브러리 출현
-> 개발에 많은 도움이 되었음 But, 변경에 유연하면서 확장하기 쉬운 애플리케이션 아키텍처의 구축을 어렵게 함, 필연적으로 프레임워크 등장

CBD(Component based development) 방법론을 기반으로 하는 SPA(Single Page Applicatoin)가 대중화, Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임워크/라이브러리 또한 많은 사용층 확보 중

2.4 자바스크립트와 ECMAScript

ECMAScript는 자바스크립트의 표준 사양인 ECMA-262를 말하며, 프로그래밍 언어의 값, 타입, 객체와 프로퍼티, 함수, 표준 빌트인(내장) 객체 등 핵심 문법을 규정
각 브라우저 제조사는 ECMAScript 사양을 준수해서 브라우저에 내장되는 자바스크립트 엔진을 구현

자바스크립트는 일반적으로 프로그램이 언어로서 기본 뼈대(core)를 이루는 ECMAScript와 브라우저가 별도 지원하는 클라이언트 사이드 Web API, 즉 DOM, BOM, Canvas, XMLHttpRequest, fetch, requestAnimationFrame, SVG, Web Storage, Web Component, Web Worker 등을 아우르는 개념

클라이언트 사이드 Web API : ECMAScript와는 별도로 월드 와이드 웹 콘소시엄(W3C)에서 별도의 사양에서 관리 중

2.5 자바스크립트의 특징

자바스크립트 : HTML, CSS와 함께 웹을 구성하는 요소 중 하나, 웹 브라우저에서 동작하는 유일한 프로그래밍 언어

자바스크립트는 인터프리터 언어이다!
But, 대부분의 모던 자바스크립트 엔진(크롬의 V8, 파이어폭스의 SpiderMonkey, 사파리의 JavaScriptCore, 마이크로소프트 엣지의 Chakra 등)은 인터프리터와 컴파일러의 장점을 결합
-> 비교적 처리 속도가 느린 인터프리터의 단점을 해결, 인터프리터는 소스코드 즉시 실행, 컴파일러는 빠르게 동작하는 머신 코드 생성 후 최적화
-> 컴파일 단계에서 추가적인 시간이 필요함에도 더욱 빠르게 코드 실행 가능

인터프리터 언어 vs 컴파일러 언어

컴파일러 언어	인터프리터 언어
코드가 실행되기 전 단계인 컴파일 타임에 소스코드 전체를 한번에 머신 코드로 변환한 후 실행	코드가 실행되는 단계인 런타임에 문 단위로 한 줄씩 중간코드인 바이트코드로 변환 후 실행
실행 파일 생성	실행 파일 생성 X
컴파일 단계와 실행 단계 분리 명시적인 컴파일 단계를 거치고, 명시적으로 실행 파일 실행	인터프리트 단계와 실행 단계 분리 X 인터프리터는 한 줄씩 바이트코드로 변환하고 즉시 실행
실행에 앞서 컴파일 단 한번 수행	코드가 실행될 때마다 인터프리트 과정 반복 수행
컴파일과 실행 단계가 분리되어 있으므로 코드 실행 속도가 빠름	인터프리트 단계와 실행 단계가 분리 X 반복 수행되므로 코드 실행 속도가 비교적 느림