[러닝 타입스크립트] Ch 1. 자바스크립트에서 타입스크립트로

1.1 자바스크립트의 역사

• 1995년 웹 사이트에 쉽게 접근하고 사용할 수 있는 자바스크립트가 10일 만에 설계됨
  → 자바스크립트의 특성과 결점으로 인해 엄청난 조롱을 받음
• 그러나 1995년 이후로 엄청나게 발전함
  • 자바스크립트의 기반이 되는 언어 사양인 ECMA스크립트의 새로운 버전을 2015년부터 매년 출시했는데, 이 때 다른 최신 프로그래밍 언어에서 제공하는 기능에 맞춘 새로운 기능도 함께 제공
  • 놀랍게도 자바스크립트는 브라우저, 임베디드 애플리케이션 그리고 서버 런타임을 포함한 다양한 환경에서 새로운 버전과 이전 버전과의 호환성을 수십 년동안 유지함

 

 

1.2 바닐라 자바스크립트의 함정

바닐라(vanilla): 중요한 언어 확장이나 프레임워크 없이 자바스크립트를 사용하는 것

→ 한 마디로, 순수한 자바스크립트를 의미

 

1.2.1 값 비싼 자유

자바스크립트를 사용하는 개발자들의 가장 큰 불만은 핵심 기능에 있다.

자바스크립트는 사실상 코드를 구성하는 방법에 제한이 없기 때문에, 파일이 점점 늘어날수록 이 자유가 얼마나 훼손될 수 있는지 명확해진다.

다른 언어는 컴파일러가 충돌할 수 있다고 판단하면 코드 실행을 거부할 수 있다.

하지만 자바스크립트처럼 충돌 가능성을 먼저 확인하지 않고 코드를 실행하는 동적 타입 언어는 그렇지 않다.

결국 코드의 자유는 자바스크립트를 재밌게 만들기도 하지만, 내가 짠 코드를 안전하게 실행하려고 할 때는 상당한 고통이 따를 수 있다.

 

1.2.2 부족한 문서

자바스크립트 언어 사양에는 함수의 매개변수, 함수 반환, 변수 또는 다른 구성 요소의 의미를 설명하는 표준화된 내용이 없다.

따라서 많은 개발자가 블록 주석으로 함수와 변수를 설명하는 JSDoc 표준을 채택했다.

(JSDoc 표준: 표준으로 형식화된 함수와 변수 코드 바로 위에 문서 주석을 작성하는 방식)

/**
 * Performs a painter painting a particular painting.
 *
 * @param {Painting} painter
 * @param {string} painting
 * @returns {boolean} whether the painter painted the painting
 */
function paintPainting(painter, painting) {
  /* ... */
}

그런데 JSDoc에는 아래와 같은 주요 문제로 인해 규모가 있는 코드베이스에서 사용하기가 불편하다.

• JSDoc 설명이 코드가 잘못되는 것을 막을 수 없다.
• JSDoc 설명이 이전에는 정확했더라도 코드 리팩토링 중에 생긴 변경 사항과 관련된 현재 유효하지 않은 JSDoc 주석을 모두 찾기란 어렵다.
• 복잡한 객체를 설명할 때는 다루기 어렵고 장황해서 그 관계를 정의하려면 다수의 독립형 주석이 필요하다.

 

1.2.3 부족한 개발자 도구

• 자바스크립트는 타입을 식별하는 내장된 방법을 제공하지 X
• 코드가 JSDoc 주석에서 쉽게 분리됨

⇒ 코드베이스에 대한 대규모 변경을 자동화하거나 통찰력을 얻기가 매우 어렵다.

 

 

1.3 타입스크립트

• 타입스크립트는 2010년대 초 마이크로소프트 내부에서 만들어진 후 2012년에 출시 및 오픈 소스화 되었다.
• 타입스크립트는 종종 ‘자바스크립트의 상위 집합(superset)’ 혹은 ‘타입이 있는 자바스크립트’로 설명되곤 한다.
• 타입스크립트는 네 가지로 설명된다.
  • 프로그래밍 언어: 자바스크립트의 모든 구문과, 타입을 정의하고 사용하기 위한 새로운 타입스크립트 고유 구문이 포함된 언어
  • 타입 검사기: 자바스크립트 및 타입스크립트로 작성된 일련의 파일에서 생성된 모든 구성 요소 (변수, 함수 등)를 이해하고, 잘못 구성된 부분을 알려주는 프로그램
  • 컴파일러: 타입 검사기를 실행하고 문제를 보고한 후 이에 대응되는 자바스크립트 코드를 생성하는 프로그램
  • 언어 서비스: 타입 검사기를 사용해 VS Code 와 같은 편집기에 개발자에게 유용한 유틸리티 제공법을 알려주는 프로그램

 

 

1.4 타입스크립트 플레이그라운드에서 시작하기

타입스크립트 공식 웹사이트는 플레이그라운드 편집기(https://www.typescriptlang.org/ko/play)를 제공한다.

편집기에 코드를 입력하고, IDE(통합 개발 환경)에서 로컬로 타입스크립트 작업을 할 때 보게 되는 동일한 편집기 제안 사항도 확인할 수 있다.

+) ‘바벨’에 대한 내용 추가

 

 

1.5 로컬에서 시작하기

컴퓨터에 Node.js가 설치되어 있으면 타입스크립트를 실행할 수 있다. << TODO: Node의 역할?

npm i -g typescript : 타입스크립트 최신 버전을 전역으로 설치하는 명령어

tsc(타입스크립트 컴파일러) 명령어로 타입스크립트로 실행할 수 있다.

tsc —version : 버전을 확인해 타입스크립트가 올바르게 설정되었는지 확인 가능

 

1.5.1 로컬에서 실행하기

tsc --init 명령어로 신규 tsconfig.json 파일을 생성한다.

tsconfig.json 파일은 타입스크립트가 코드를 분석할 때 사용하는 설정을 선언한다.

여기서 알고가야할 중요한 특징은, tsc를 실행해 폴더의 모든 파일을 컴파일하도록 지시할 수 있고, 타입스크립트가 모든 구성 옵션에 대해서 tsconfig.json을 참조할 수 있다는 것이다.

 

1.5.2 편집기 기능

tsconfig.json의 또 다른 이점은, 편집기에서 특정 폴더를 열었을 때 편집기가 이제 해당 폴더를 타입스크립트 프로젝트로 인식한다는 것이다.

 

 

1.6 타입스크립트에 대한 오해

1.6.1 잘못된 코드 해결책

타입스크립트는 자바스크립트 코드를 구조화하는데 도움이 되지만, 타입 안정성 강화를 제외하고는 해당 구조가 어떻게 보여야 하는지에 대해서는 어떤 것도 강요하지 않는다.

타입스크립트는 특정 대상만을 위한 독단적인 프레임워크가 아닌 모든 개발자가 사용할 수 있는 프로그래밍 언어이다. 자바스크립트에서 사용했던 아키텍처 패턴 중 무엇이든 사용해서 코드를 작성할 수 있고, 타입스크립트가 이를 지원한다.

 

1.6.2 자바스크립트로의 확장

타입스크립트의 설계 목표는 다음과 같이 명시되어 있다.

• 현재와 미래의 ECMA스크립트 제안에 맞춘다.
• 모든 자바스크립트 코드의 런타임 동작을 유지한다.

타입스크립트는 자바스크립트의 작동 방식을 전혀 변경하지 않는다.

타입스크립트 개발자들은 자바스크립트에 추가되거나 자바스크립트와 충돌할 수 있는 새로운 코드 기능을 타입스크립트에 추가하지 않기위해 열심히 노력했다. 이런 작업은 ECMA 스크립트 자체에서 작업하는 기술 위원회인 TC39의 영역이다.

 

1.6.3 자바스크립트보다 느림

때로는 타입스크립트가 자바스크립트보다 느리다고 불평하는 평가들도 있다.

하지만 이 주장은 부정확하고 오해의 소지가 있다.

타입스크립트는 코드를 빌드하는 데 시간이 조금 더 걸린다.

타입스크립트 코드는 브라우저나 Node.js와 같은 환경에서 실행되기 전에 자바스크립트로 먼저 컴파일되어야 한다. 빌드 파이프라인은 대부분 성능 저하를 무시하도록 설정된다.

코드에서 발생할 수 있는 오류를 분석하는 느린 타입스크립트 기능은 실행 가능한 애플리케이션 코드 파일을 생성하는 것과는 분리된 채로 수행된다.