TypeScript와 JavaScript의 관계

타이프 라이터는 유형이 지정된 상위 자바 스크립트의 일반 자바 스크립트로 컴파일 – typescriptlang.org .

JavaScript는 EMCA의 Technical Committee 39 에서 개발 한 프로그래밍 언어 로, 다양한 이해 관계자로 구성된 그룹입니다. TC39는 ECMA가 주최하는위원회 로서 내부 표준 조직입니다. JavaScript는 여러 공급 업체 (예 : Google, Microsoft, Oracle 등)에 의해 다양한 구현 방식을 가지고 있습니다. JavaScript의 목표는 웹의 링구아 프랑카가되는 것입니다.

TypeScript는 단일 오픈 소스 컴파일러를 가진 JavaScript 언어의 상위 집합이며 주로 단일 공급 업체 인 Microsoft에서 개발합니다. TypeScript의 목표는 유형 시스템을 통해 실수를 조기에 발견하고 JavaScript 개발을보다 효율적으로 만드는 것입니다.

본질적으로 TypeScript는 세 가지 방법으로 목표를 달성합니다.

1. 최신 JavaScript 기능 지원 -JavaScript 언어 (런타임이 아님)는 ECMAScript 표준을 통해 표준화됩니다. 모든 브라우저 및 JavaScript 런타임이 모든 ECMAScript 표준의 모든 기능을 지원하는 것은 아닙니다 (이 개요 참조 ). TypeScript를 사용하면 최신 ECMAScript 기능을 많이 사용할 수 있으며 선택한 기존 ECMAScript 대상으로 변환 할 수 있습니다 ( 컴파일러 옵션 아래 의 컴파일 대상 목록 참조 --target). 즉, 모듈, 람다 함수, 클래스, 스프레드 연산자 및 구조 해제와 같은 새로운 기능을 안전하게 사용할 수 있으며 이전 브라우저 및 JavaScript 런타임과 호환됩니다.

2. 고급 형식 시스템 -형식 지원은 ECMAScript 표준의 일부가 아니며 JavaScript의 컴파일 된 특성 대신 해석 된 특성으로 인한 것이 아닙니다. TypeScript의 형식 시스템은 매우 풍부하며 인터페이스, 열거 형, 하이브리드 형식, 제네릭, 공용체 / 교차 형식, 액세스 수정 자 등을 포함합니다. TypeScript 의 공식 웹 사이트 는 이러한 기능에 대한 개요를 제공합니다. 타이프 스크립트의 타이프 시스템은 대부분의 다른 타이핑 된 언어와 동등하며 어떤 경우에는 아마도 더 강력합니다.

3. 개발자 툴링 지원 -TypeScript의 컴파일러는 백그라운드 프로세스로 실행하여 증분 컴파일 및 IDE 통합을 모두 지원하므로보다 쉽게 ​​탐색하고 문제를 식별하며 가능성을 검사하고 코드베이스를 리팩터링 할 수 있습니다.

다른 JavaScript 타겟팅 언어와 TypeScript의 관계

TypeScript는 JavaScript로 컴파일되는 다른 언어와 비교할 때 고유 한 철학을 가지고 있습니다. JavaScript 코드는 유효한 TypeScript 코드입니다. TypeScript는 JavaScript의 상위 집합입니다. .js파일 이름을 파일로 바꾸고 .tsTypeScript 를 사용할 수 있습니다 (아래 “JavaScript 상호 운용성”참조). TypeScript 파일은 읽을 수있는 JavaScript로 컴파일되므로 마이그레이션이 가능하고 컴파일 된 TypeScript를 이해하는 것이 전혀 어렵지 않습니다. TypeScript는 JavaScript의 성공을 기반으로하는 동시에 약점을 개선합니다.

한편으로, 현대 ECMAScript 표준을 채택하고 Babel이 가장 인기있는 이전 JavaScript 버전으로 컴파일하는 미래의 증거 도구가 있습니다. 반면, CoffeeScript, Clojure, Dart, Elm, Haxe, Scala.js 및 전체 호스트와 같이 JavaScript를 대상으로하는 JavaScript와는 완전히 다른 언어가 있습니다 (이 목록 참조).). 이 언어는 JavaScript의 미래보다 훨씬 나을 수 있지만 미래를 보장하기에 충분한 채택을 찾지 못할 위험이 더 큽니다. 이러한 언어 중 일부에 대한 숙련 된 개발자를 찾는 데 더 어려움이있을 수 있지만 종종 더 열성적인 언어를 찾을 수 있습니다. JavaScript와의 Interop은 JavaScript와 실제로 더 멀리 떨어져 있기 때문에 조금 더 복잡 할 수 있습니다.

TypeScript는이 두 극단 사이에 위치하므로 위험의 균형을 유지합니다. TypeScript는 표준에 따라 위험한 선택이 아닙니다. JavaScript가 완전히 다른 언어가 아니고 JavaScript 상호 운용성 지원이 우수하고 최근에 많이 채택되어 JavaScript에 익숙한 경우 익숙해지기 위해 거의 노력이 필요하지 않습니다.

선택적으로 정적 입력 및 유형 유추

JavaScript는 동적으로 입력됩니다. 즉, 실제로 런타임에 인스턴스화 될 때까지 JavaScript가 변수의 유형을 알지 못합니다. 또한 너무 늦을 수도 있습니다. TypeScript는 JavaScript에 유형 지원을 추가합니다. 특정 유형의 일부 변수에 대한 잘못된 가정으로 인해 발생하는 버그는 카드를 올바르게 재생하면 (코드를 엄격하게 입력하거나 코드를 전혀 입력하지 않으면) 완전히 제거 할 수 있습니다.

TypeScript를 사용하면 형식 유추를 사용하여 입력을 조금 쉽고 명확하게 할 수 있습니다. 예를 들어 : var x = "hello"TypeScript에서와 동일합니다 var x : string = "hello". 유형은 단순히 사용에서 유추됩니다. 명시 적으로 유형을 입력하지 않아도 런타임 오류가 발생하는 작업을 수행하지 않아도됩니다.

TypeScript는 기본적으로 선택적으로 입력됩니다. 예를 들어 문자열로 호출하면 런타임 오류가 발생 하더라도 모든 종류의 매개 변수 function divideByTwo(x) { return x / 2 }로 호출 할 수있는 TypeScript의 유효한 함수 가 있습니다. JavaScript에서 익숙한 것처럼. 이것은 splitByTwo 예제와 같이 형식이 명시 적으로 할당되지 않고 형식을 유추 할 수없는 경우 TypeScript가 암시 적으로 형식을 할당하기 때문에 작동합니다 . 이것은 divideByTwo 함수의 타입 시그니처가 자동으로된다는 것을 의미합니다 . 이 동작을 허용하지 않는 컴파일러 플래그가 있습니다 : . 이 플래그를 활성화하면 안전성이 높아지지만 더 많은 타이핑을해야합니다.anyfunction divideByTwo(x : any) : any--noImplicitAny

유형에는 관련 비용이 있습니다. 우선, 학습 곡선이 있으며, 무엇보다도 적절한 엄격한 타이핑을 사용하여 코드베이스를 설정하는 데 약간의 시간이 더 걸립니다. 내 경험상 이러한 비용은 다른 사람과 공유하는 심각한 코드베이스에서 그 가치가 있습니다. Github의 프로그래밍 언어 및 코드 품질에 대한 대규모 연구에 따르면 정적 유형 언어는 일반적으로 동적 유형보다 결함이 적으며 동일한 유형의 약한 유형보다 강한 유형이 더 좋습니다.

이 동일한 논문은 TypeScript가 JavaScript보다 오류가 덜 발생한다는 것을 발견했습니다.

양의 계수를 가진 사람들에게는 언어가 많은 수의 결함 수정과 관련이 있다고 기대할 수 있습니다. 이러한 언어에는 C, C ++, JavaScript , Objective-C, Php 및 Python이 포함됩니다. Clojure, Haskell, Ruby, Scala 및 TypeScript 언어는 모두 음수 계수를 가지 므로 이러한 언어는 평균보다 언어 수정 커밋이 발생할 가능성이 적습니다.

향상된 IDE 지원

TypeScript의 개발 경험은 JavaScript보다 크게 개선되었습니다. IDE는 풍부한 유형 정보를 TypeScript 컴파일러에 의해 실시간으로 알려줍니다. 이것은 몇 가지 주요 이점을 제공합니다. 예를 들어 TypeScript를 사용하면 전체 코드베이스에서 이름 바꾸기와 같은 리팩토링을 안전하게 수행 할 수 있습니다. 코드 완성을 통해 라이브러리가 제공 할 수있는 기능에 대한 인라인 도움말을 얻을 수 있습니다. 더 이상 그것들을 기억하거나 온라인 참조에서 찾을 필요가 없습니다. 코딩 오류가있는 동안 컴파일 오류가 IDE에서 직접 빨간색 구불 구불 한 줄로보고됩니다. 결국 JavaScript로 작업 할 때보 다 생산성이 크게 향상됩니다. 코딩에 더 많은 시간을 보내고 디버깅에 더 적은 시간을 할애 할 수 있습니다.

Visual Studio Code, WebStorm, Atom 및 Sublime과 같이 TypeScript를 완벽하게 지원하는 다양한 IDE가 있습니다.

엄격한 null 확인

폼의 런타임 오류 cannot read property 'x' of undefined또는 undefined is not a functionJavaScript 코드의 버그로 인해 매우 일반적으로 발생합니다. 기본적으로 TypeScript는 TypeScript 컴파일러에 알려지지 않은 변수를 사용할 수 없으므로 ( any유형 변수 의 속성 제외) 이러한 종류의 오류가 발생할 가능성을 이미 줄 입니다. 로 설정된 변수를 실수로 사용하는 것은 여전히 ​​가능합니다 undefined. 그러나 2.0 버전의 TypeScript를 사용하면 Null을 허용하지 않는 유형을 사용하여 이러한 종류의 오류를 모두 제거 할 수 있습니다. 이것은 다음과 같이 작동합니다.

엄격한 null 검사가 활성화 된 경우 ( --strictNullChecks컴파일러 플래그) TypeScript 컴파일러는 undefined변수를 nullable 유형으로 명시 적으로 선언하지 않는 한 변수에 할당 할 수 없습니다 . 예를 들어, let x : number = undefined컴파일 오류가 발생합니다. undefined숫자가 아니기 때문에 유형 이론에 완벽하게 맞습니다 . x합의 유형으로 정의 number하고 undefined이를 수정할 수 let x : number | undefined = undefined있습니다.

유형이 널 입력 가능으로 알려진 경우 ( null또는 값이 될 수있는 유형 undefined임) TypeScript 컴파일러는 제어 플로우 기반 유형 분석을 통해 코드에서 변수를 안전하게 사용할 수 있는지 여부를 판별 할 수 있습니다. 다시 말해 변수가 undefined예를 들어 if명령문을 통해 확인 하면 TypeScript 컴파일러는 코드 제어 흐름의 해당 분기에있는 유형이 더 이상 널 입력 가능하지 않으므로 안전하게 사용할 수 있다고 유추합니다. 다음은 간단한 예입니다.

let x: number | undefined;
if (x !== undefined) x += 1; // this line will compile, because x is checked.
x += 1; // this line will fail compilation, because x might be undefined.

빌드하는 동안 TypeScript Anders Hejlsberg의 2016 회의 공동 디자이너는 비디오 (44:30에서 56:30)에 대한 자세한 설명과 데모를 제공했습니다 .

편집

TypeScript를 사용하려면 JavaScript 코드로 컴파일하기위한 빌드 프로세스가 필요합니다. 빌드 프로세스는 일반적으로 프로젝트 크기에 따라 몇 초 밖에 걸리지 않습니다. TypeScript 컴파일러는 --watch모든 후속 변경 사항을 더 빠른 속도로 컴파일 할 수 있도록 증분 컴파일 ( 컴파일러 플래그)을 지원합니다 .

TypeScript 컴파일러는 생성 된 .js 파일에서 소스 맵 정보를 인라인하거나 별도의 .map 파일을 작성할 수 있습니다. 소스 맵 정보는 Chrome DevTools 및 기타 IDE와 같은 유틸리티를 디버깅하여 JavaScript의 행을 TypeScript에서 생성 된 행과 연관시키는 데 사용할 수 있습니다. 이를 통해 런타임 동안 TypeScript 코드에서 직접 중단 점을 설정하고 변수를 검사 할 수 있습니다. 소스 맵 정보는 꽤 잘 작동하지만 TypeScript 이전에는 사용되었지만 TypeScript 디버깅은 일반적으로 JavaScript를 직접 사용할 때만 큼 좋지 않습니다. 테이크 this예를 들어 키워드를. thisES2015 이후 클로저 와 관련하여 키워드의 의미가 변경 this되어 런타임 중에 실제로는 변수라는 변수로 존재할 수 있습니다 _this( 이 답변 참조)). 디버깅하는 동안 혼동 될 수 있지만 일반적으로 알고 있거나 JavaScript 코드를 검사하면 문제가되지 않습니다. 바벨은 똑같은 종류의 문제를 겪고 있습니다.

데코레이터를 기반으로 인터셉트 코드 생성, 다른 모듈 시스템에 대한 모듈로드 코드 생성 및 JSX 구문 분석과 같은 TypeScript 컴파일러가 수행 할 수있는 몇 가지 다른 트릭이 있습니다 . 그러나 Typescript 컴파일러 외에 빌드 도구가 필요할 수 있습니다. 예를 들어, 코드를 압축하려면 빌드 프로세스에 다른 도구를 추가해야합니다.

Webpack , Gulp , Grunt 및 기타 거의 모든 JavaScript 빌드 도구에 사용할 수있는 TypeScript 컴파일 플러그인이 있습니다 . TypeScript 문서에는 빌드 툴과의 통합에 관한 섹션이 있습니다. 린터이 경우에 당신은 더 많은 빌드 시간 확인을 부탁도 사용할 수 있습니다. Angular 2, React, Ember, SystemJS, Webpack, Gulp 등과 같은 다른 많은 기술과 함께 TypeScript를 시작할 수있는 많은 시드 프로젝트가 있습니다.

자바 스크립트 상호 운용성

TypeScript는 JavaScript와 밀접한 관련이 있기 때문에 뛰어난 상호 운용성 기능이 있지만 TypeScript에서 JavaScript 라이브러리를 사용하려면 약간의 추가 작업이 필요합니다. TypeScript 정의 는 TypeScript 컴파일러가 함수 호출 이 실제로 유효 하지 않은 명령문 과 같 _.groupBy거나 angular.copy그렇지 않다는 것을 이해하기 위해 필요 $.fadeOut합니다. 이러한 기능에 대한 정의는 .d.ts파일 에 있습니다.

정의가 취할 수있는 가장 간단한 형태는 식별자를 어떤 식 으로든 사용할 수있게하는 것입니다. 예를 들어 Lodash 를 사용할 때 단일 행 정의 파일 declare var _ : any을 사용하면 원하는 함수를 호출 할 수 _있지만 물론 실수를 _.foobar()할 수도 있습니다. 유효한 TypeScript 호출 일 것입니다. , 런타임시 불법적 인 전화. 적절한 유형 지원 및 코드 완성을 원하면 정의 파일이 더 정확해야합니다 ( 예를 들어 lodash 정의 참조 ).

자체 유형 정의가 사전 패키지로 제공되는 Npm 모듈 은 TypeScript 컴파일러에 의해 자동으로 이해됩니다 ( 문서 참조 ). 자체 정의를 포함하지 않는 다른 세미 인기 JavaScript 라이브러리의 경우 이미 다른 npm 모듈을 통해 유형 정의를 사용할 수 있습니다. 이 모듈은 접두사가 “@ types /”이고 DefinitelyTyped 라는 Github 리포지토리에서 제공됩니다 .

한 가지주의 사항이 있습니다. 형식 정의는 런타임에 사용중인 라이브러리 버전과 일치해야합니다. 그렇지 않은 경우 TypeScript는 함수를 호출하거나 존재하지 않는 변수를 참조하지 않거나 존재하지 않는 변수를 역 참조하거나 허용하지 않을 수 있습니다. 유형이 컴파일 타임에 런타임과 일치하지 않기 때문입니다. . 따라서 사용중인 라이브러리의 올바른 버전에 맞는 유형 정의 유형을로드해야합니다.

솔직히 말해서, 이것에 약간의 번거 로움이 있으며 이것이 TypeScript를 선택하지 않는 이유 중 하나 일 수 있습니다. 대신 타입 정의를 얻지 않아도되는 Babel과 같은 것을 찾으십시오. 반면, 수행중인 작업을 알고 있으면 정의 파일이 잘못되었거나 누락되어 발생하는 모든 종류의 문제를 쉽게 극복 할 수 있습니다.

JavaScript에서 TypeScript로 변환

모든 .js파일의 이름을 파일로 바꾸고 .tsTypeScript 컴파일러를 통해 실행하여 구문 적으로 동일한 JavaScript 코드를 출력과 동일하게 얻을 수 있습니다 (처음에 구문이 올바른 경우). TypeScript 컴파일러가 컴파일 오류를 가져 오더라도 여전히 .js파일을 생성 합니다. 플래그를 .js사용하여 파일을 입력으로 받아 들일 수도 있습니다 --allowJs. 이를 통해 TypeScript를 바로 시작할 수 있습니다. 불행히도 컴파일 오류는 처음에 발생할 수 있습니다. 다른 컴파일러에서 익숙한 것처럼 이러한 오류가 중단되지 않음을 기억해야합니다.

JavaScript 프로젝트를 TypeScript 프로젝트로 변환 할 때 처음에 발생하는 컴파일 오류는 TypeScript의 특성상 피할 수 없습니다. TypeScript는 모든 코드의 유효성을 검사 하므로 사용되는 모든 함수와 변수에 대해 알아야합니다. 따라서 모든 유형에 대해 유형 정의가 있어야합니다. 그렇지 않으면 컴파일 오류가 발생합니다. 위 장에서 언급했듯이 거의 모든 JavaScript 프레임 워크에는 DefinitelyTyped 패키지를.d.ts 설치하여 쉽게 얻을 수있는 파일이 있습니다.. 그러나 TypeScript 정의를 사용할 수 없거나 일부 JavaScript 프리미티브를 폴리 필 한 모호한 라이브러리를 사용했을 수 있습니다. 이 경우 컴파일 오류가 사라지도록 이러한 비트에 대한 유형 정의를 제공해야합니다. .d.ts파일을 작성 하고 tsconfig.json의 files배열 에 포함 시키면 항상 TypeScript 컴파일러에 의해 고려됩니다. TypeScript가 type으로 알지 못하는 비트를 선언합니다 any. 모든 오류를 제거한 후에는 필요에 따라 점차 해당 부분에 타이핑을 도입 할 수 있습니다.

TypeScript를 빌드 파이프 라인으로 가져 오려면 빌드 파이프 라인을 다시 구성해야합니다. 컴파일에 관한 장에서 언급했듯이 좋은 자료가 많이 있으며 작업하려는 도구 조합을 사용하는 시드 프로젝트를 찾는 것이 좋습니다.

가장 큰 장애물은 학습 곡선입니다. 처음에는 작은 프로젝트를 가지고 놀아 보는 것이 좋습니다. 작동 방식, 빌드 방법, 사용 파일, 구성 방법, IDE에서의 기능, 구성 방법, 사용 도구 등을 살펴보십시오. 대형 JavaScript 코드베이스를 TypeScript로 변환하는 것은 알고있을 때 가능합니다 당신이하고있는 일. 예를 들어 72 시간 안에 600k 라인을 타이프 스크립트로 변환하는 방법에 대한이 블로그를 읽으십시오 . 점프하기 전에 언어를 잘 이해하고 있는지 확인하십시오.

양자

TypeScript는 오픈 소스이며 (Apache 2 라이센스, GitHub 참조 ) Microsoft에서 지원합니다. C #의 수석 아키텍트 인 Anders Hejlsberg가이 프로젝트를 이끌고 있습니다. 매우 활발한 프로젝트입니다. TypeScript 팀은 지난 몇 년 동안 많은 새로운 기능을 발표했으며 앞으로도 많은 훌륭한 기능이 계획되어 있습니다 ( 로드맵 참조 ).

채택과 인기에 대한 몇 가지 사실 :

• 에서 2017 StackOverflow의 개발자 설문 조사 타이프 라이터는 (전체 9 위)는 가장 인기있는 자바 스크립트 transpiler이었다 가장 사랑 프로그래밍 언어 부문 3 위를 차지했다.
• 에서 JS의 2018 상태 조사 (ES6 다른 인 포함) 타이프 스크립트는 자바 스크립트 맛의 범주에서 두 개의 큰 수상자 중 하나로 선언했다.
• 에서 2019 StackOverlow의 deverloper 조사 타이프 라이터는 C와 C ++ 모두를 추월, 전문 개발자들 사이에서 가장 인기있는 언어의 9 위 상승했다. 그것은 가장 사랑받는 언어 중 3 위를 차지했습니다.

---

답변