자바스크립트의 역사
1995년 넷스케이프의 브렌던 아이크는 웹사이트에 쉽게 접근하고 사용할 수 있는 자바스크립트를 10일 만에 설계했다. 그 당시 자바스크립트는 별난 특성과 드러난 결점때문에 개발자들에게 조롱 당했다.
그러나 자바스크립트의 기반이 되는 언어 사양인 ECMAScript의 새로운버전을 2015년부터 매년 출시하며, 브라우저, 임베디드, 애플리케이션, 서버 런타임을 포함한 다양한 환경에서 새로운 버전과 이전버전과의 호환성을 유지하며 발전해왔다.
별난 특성이 있지만 놀랍도록 유연한 자바스크립트는 웹 애플리케이션과 인터넷의 놀라운 성장을 가능하게 만들었다.
바닐라 자바스크립트의 함정
값 비싼 자유
코드를 구성함에 있어서 제한이 없는만큼 자바스크립트는 파일이 많아질수록 이러한 자유는 훼손되게 된다.
function paintPainting(painter, painting) {
return painter.prepare().paint(painting, painter.ownMaterials).finish();
}
만약 맥락 없이 다음 코드를 읽었을 때 paintPainting
을 어떻게 호출할지 고민에 빠지게된다. painting
이 문자열인지, painter
가 어떤 함수를 반환하는지 알 수 없다.
이러한 작업이 당장의 문제를 해결할 수 있더라도 나중에 코드를 변경하거나 문자열이었던 painting
이 다른 데이터 타입으로 변경되는 등 여러 상황이 발생하면 결국 앞선 상황이 반복될 것이다.
다른 언어는 컴파일러가 충돌할 수 있다고 판단하면 코드 실행을 거부할 수 있지만 자바스크립트처럼 충돌 가능성을 먼저 확인하지 않고 코드를 실행하는 동적 타입 언어는 안정성을 보장해주지 않는다.
부족한 문서
자바스크립트 언어 사양에는 함수의 매개변수, 함수 반환, 변수 또는 다른 구성 요소의 의미를 설명하는 표준화된 내용이 없다. 따라서 블록 주석으로 함수와 변수를 설명하는 JSDoc
표준을 채택했다.
/**
* Performs a painter painting a particular painting.
*
* @param {Painting} painter
* @param {string} painting
* @return {boolean} Whether the painter painted the painting.
*/
function paintPainting(painter, painting) {
/* ... */
}
하지만 JSDoc에는 몇 가지 주요 문제가 있다.
- JSDoc 설명이 코드가 잘못되는 것을 막을 수 없다.
- 그때는 맞고 지금은 틀리다. 설명이 이전에는 정확해도 리팩터링 중 생긴 변경 상황과 관련된 유효하지 않은 주석들을 모두 찾기 어렵다.
- 복잡한 객체를 설명할 때 다루기 어렵고 장황하다. 타입과 그 관계를 정의하기 위한 다수의 독립형 주석이 필요해진다.
이처럼 규모가 있는 코드베이스에서 수많은 파일을 꾸준히 업데이트하는 것은 불가능에 가깝게 된다.
부족한 개발자 도구
자바스크립트는 타입을 식별하는 내장된 방법을 제공하지 않고 코드가 JSDoc
주석에서 쉽게 분리되기 때문에 대규모 변경을 자동화하거나 통찰력을 얻기가 매우 쉽다.
타입스크립트
타입스크립트는 네 가지로 설명된다.
- 프로그래밍 언어
- 자바스크립트의 모든 구문과, 타입을 정의하고 사용하기 위한 새로운 타입스크립트 고유 구문이 포함된 언어
- 타입 검사기
- 자바스크립트 및 타입스크립트로 작성된 일련의 파일에서 생성된 모든 구성요소(변수, 함수 등)를 이해하고, 잘못 구성된 부분을 알려주는 프로그램
- 컴파일러
- 타입 검사기를 실행하고 문제를 보고한 후 이에 대응되는 자바스크립트 코드를 새성하는 프로그램
- 언어 서비스
- 타입 검사기를 사용해 비주얼 스튜디오 코드와 같은 편집기에 개발자에게 유용한 유틸리티 제공법을 알려주는 프로그램
타입스크립트 플레이그라운드에서 시작하기
타입스크립트 공식 웹사이트는 플레이그라운드 편집기를 제공한다. 편집기에 코드를 입력할 수 있고, IDE에서 작업할때 보게 되는 동일한 편집기 제안 사항도 확인할 수 있다.
타입스크립트 실전
언어 서비스가 실행되어 타입스크립트 코드에 오류를 표시해준다.
제한을 통한 자유
타입스크립트를 사용하면 매개변수와 변수에 제공되는 값의 타입을 지정할 수 있다. 코드 작성에 있어서 제한을 주는 것이다. 제한을 통해 코드의 한 영역을 변경하더라도 이 코드를 사용하는 다른 코드 영역이 멈추지 않는다는 확신을 주는 것이다.
예를 들어 함수의 매개변수 개수를 변경했을 경우, 변경된 함수를 호출하는 코드를 업데이트 하지 않았다면 타입스크립트는 오류를 발생시킨다. 반면 자바스크립트는 오류 없이 실행되며 예상한 것과 다르게 나온다.
// 이전 코드 sayMyName(firstName, lastNameName) { ...
function sayMyName(fullName) {
console.log(`You acting kind of shady, ain't callin' me ${fullName}`);
}
sayMyName("Beyonce", "knowles");
// You acting kind of shady, ain't callin' me Beyonce
정확한 문서화
앞서 다루었던 paintPainting
함수를 타입스크립트 버전으로 만들어보자.
interface Painter {
finish(): boolean;
ownMaterials: Material[];
paint(painting: string, materials: Material[]): boolean;
}
function paintPainting(painter: Painter, painting: string): boolean {
/* ... */
}
타입스크립트 개발자라면 Painter에 적어도 세 가지 속성이 있고, 그중 두 가지는 메서드라는 것을 이해할 수 있다. 타입스크립트는 구문을 적용해 객체의 '형태'와 객체가 어떻게 보이는지 설명한다.
더 강력한 개발자 도구
VSCode 같은 편집기에서 타입스크립트로 코드를 작성하면 편집기는 더 편리하고 유용하게 사용할 수 있다. 문자열 같은 객체의 내장 코드를 작성할 때 자동완성과 같은 기능을 제안한다.
구문 컴파일하기
타입스크립트 컴파일러에 타입스크립트 구문을 입력하면 타입을 검사한 후 작성된 코드에 해당하는 자바스크립트를 내보낸다.
타입스크립트 플레이 그라운드는 타입스크립트 코드가 자바스크립트로 어떻게 출력되는지 볼 수 있다.
로컬에서 시작하기
npm i -g typescript
tsc --version
tsc
는 타입스크립트 컴파일러 명령어로 타입스크립트를 실행할 수 있다.
로컬에서 실행하기
tsc --init
- 사용할 로컬 폴더에서
tsconfig.json
타입스크립트 구성파일을 생성한다. 이 파일은 타입스크립트가 코드를 분석할 때 사용하는 설정을 선언한다.
- 사용할 로컬 폴더에서
tsc 파일이름.ts
- 타입스크립트 컴파일러를 실행시킬 파일을 알려 사용할 수 있다.
편집기 기능
tsconfig.json
파일은 편집기에서 특정 폴더를 열었을 때, 편집기가 해당 폴더를 타입스크립트 프로젝트로 인식한다.
타입스크립트에 대한 오해
잘못된 코드 해결책
타입스크립트는 자바스크립트 코드를 구조화하는 데 도움이 되지만, 타입 안정성 강화를 제외하고는 해당 구조가 어떻게 보여야 하는지에 대해서는 어떤 것도 강요하지 않는다.
자바스크립트로의 확장
타입스크립트의 설계 목표는 다음과 같다.
- 현재와 미래의 ECMA스크립트 제안에 맞춘다.
- 모든 자바스크립트 코드의 런타임 동작을 유지한다.
타입스크립트는 자바스크립트 작동 방식을 전혀 변경하지 않는다.
자바스크립트보다 느림
자바스크립트보다 타입스크립트가 느리다고 말하는 사람들도 있다. 하지만 이 주장은 부정확하고 오해의 소지가 있다. 타입스크립트가 코드에 적용하는 유일한 변경 사항은 인터넷 익스플로러 11과 같이 오래된 런타임 환경을 지원하기 위해 이전 버전의 자바스크립트로 코드를 컴파일하도록 요청하는 경우이다. 운영 프레임워크 대다수는 타입스크립트의 컴파일러를 전혀 사용하지 않는다. 대신 트랜스파일을 위한 별도의 도구를 사용하고 타입스크립트는 타입 검사용으로만 사용한다.