References: Choosing between Babel and TypeScript
다음의 내용은 위의 글을 번역한 내용입니다.
바벨과 타입 스크립트 중 어떤 걸 사용해야 할까?
Babel 7은 약 6 개월 전에 TypeScript 구문 지원이 내장되어 출하되었습니다. 즉, Babel을 사용하는 프로젝트는 이제 TypeScript 컴파일러로 빌드를 복잡하게 할 필요 없이 TypeScript를 사용할 수 있습니다.
그러나 Babel과 TypeScript 컴파일러를 사용하는 경우의 차이점은 무엇이고 당신의 프로젝트에 Babel 또는 TypeScript중 어떤 걸 사용해야 할까요?
Babel과 TypeScript의 차이점
TypeScript를 사용하고 TypeScript를 Babel과 사용하는 데는 몇 가지 중요한 차이점이 있습니다.
이 글에서는 가장 중요한 네 가지 차이점을 살펴 보겠습니다.
1. 타입 검사 없음
Babel은 당신의 화려한 TypeScript의 타입에 대해서는 신경 쓰지 않습니다. 타입들이 옳다는 것을 확인하지 않고 그냥 쓰레기통에 버립니다. 아래 예제는 Babel을 사용하여 오류나 경고 없이 컴파일되지만 TypeScript에서는 컴파일되지 않습니다.
const myCoolString : string = 9;
9는 확실히 문자열이 아닙니다.
바벨을 사용하면 타입이 정확하지 않더라도 코드를 컴파일할 수 있는 빠른 프로토 타이핑에 탁월한 방법이 될 수 있습니다.
타입스크립트를 사용해 당신이 타입을 정하는 데에 노력을 기울이는 중이라면, 어느 시점에 당신은 아마 그것이 옳았다는 것을 확인하기를 원할 것입니다. 운 좋게 큰 문제가 아닙니다. 에디터가 처리하도록 하거나, "tsc --noEmit"를 실행하여 아무것도 컴파일하지 않고 프로젝트를 typecheck 할 수 있습니다.
2. Const enums
기본적으로 TypeScript는 한 번에 전체 프로젝트를 컴파일하지만 Babel은 한 번에 하나의 파일 만 컴파일합니다.
즉, Babel은 TypeScript의 기능중 여러 파일을 읽어야 하는 기능을 지원하지 않습니다. 좋은 소식은 그리 많은 기능이 포함되는 건 아니라는 것입니다. 가장 널리 퍼진 것은 아마도 enum입니다.
const enum에 대해서는 TypeScript가 아무것도 컴파일 하지 않습니다. 그것을 사용하는 방법과 트랜스 파일 된 코드가 무엇인지 살펴보겠습니다.
const enum FRUITS {
APPLE = 'APPLE',
PEAR = 'PEAR',
}
if (someString === FRUITS.APPLE){
console.log("This is an apple!");
}
다음의 짧은 문장이 트랜스 파일된 코드입니다.
if (someString === "APPLE" /* APPLE */) {
console.log("This is an apple!");
}
빵! 전체 enum 구조가 없어졌으며 TypeScript는 FRUITS.APPLE을 "APPLE"값으로 간단히 설명합니다.
하지만 이 const 열거 형을 내보내고 다른 파일에서 사용하려고 하면 어떻게 될까요? Babel은 한 번에 하나의 파일에만 액세스 할 수 있기 때문에 다른 파일에서 FRUITS.APPLE을 인라인 할 수 없습니다. 대신 단순히 오류가 발생합니다.
이것은 그리 심각하지 않습니다. Const enum은 대개 Babel이 잘 지원하는 일반 열거 형의 성능을 최적화하는 데에만 사용됩니다.
3. 데코레이터 및 메타 데이터
데코레이터들에 대해서 TypeScript는 조금 이릅니다. TypeScript가 데코레이터를 구현한 후에 데코레이터 제안이 여러 번 변경되었으며 아직 마무리되지 않았습니다.
이것이 의미하는 바는 현재 ECMAScript 스펙과 TypeScript가 데코레이터의 작동 방식을 직접 눈으로 보지 못한다는 것입니다. Babel의 플러그인은 ECMAScript 사양을 따르므로 Babel은 TypeScript와 동일한 방식으로 데코레이터를 컴파일하지 않습니다. 다행스럽게도 바벨은 legacy모드가 있어 예전의 동작으로 데코레이터를 컴파일할 수 있습니다.
바벨 플러그인 "@ babel / plugin-proposal-decorators"를 추가하고 레거시 옵션을 true로 설정하면 됩니다.
그러나 Babel은 제공하지 않지만 TypeScript에서 제공하는 데코레이터 기능 중 하나로 emitDecoratorMetadata가 있습니다.
TypeScript는 일반적으로 모든 타입 정보를 지우므로 런타임에 존재하지 않습니다. emitDecoratorMetadata는 데코레이터가 적용된 클래스 및 메서드에 대해 타입을 유지하는 기능입니다.
런타임에 타입을 사용하면 Dependency Injection과 TypeScript 타입을 SQL 데이터베이스의 타입에 매핑하는 등 모든 종류의 멋진 작업을 수행할 수 있습니다.
이 기능은 TypeORM, TypeGoose, inversifyJS 및이 기능에 따라 Angular의 종속성 주입 시스템과 같은 라이브러리와 함께 사용하면 상당히 유용합니다.
emitDecoratorMetadata의 부재는 Babel을 사용할 때 가장 큰 문제 일 것입니다. 이 기능에 의존하는 라이브러리 중 일부는 대단히 유용하지만 Babel과 함께 사용할 수는 없습니다.
4. 사용자 정의 변환
Babel은 TypeScript보다 훨씬 확장성이 뛰어납니다. 코드를 최적화하는 많은 플러그인이 있으며, 사용되지 않은 import, 인라인 상수 등을 제거 할 수 있습니다.
TypeScript에는 사용자 정의 변형을 허용하는 자체 Transformer API가 있지만 Babel의 환경에선 플러그인 선택의 폭이 넓으며 액세스가 훨씬 용이합니다.
사용자 정의 변환이 필요한 경우 Babel을 사용해야합니다. 다행스럽게도 대부분의 TypeScript 도구를 사용하면 TypeScript를 사용하고 나중에 바벨을 통해 코드를 실행하여 두 가지 장점을 모두 활용할 수 있습니다. 그러나 이것은 분명히 빌드 체인에 추가 복잡성을 가져옵니다.
기타 비 호환성 및 불일치
주로 문법 제약 및 레거시 TypeScript 기능과 관련된 몇 가지 다른 비 호환성이 있습니다. 누구에게나 방해물이 되어서는 안 되지만 여기에 발표되어 있습니다
성능
TypeScript와 Babel 7 모두로 React 앱을 컴파일하려했는데, 라이브 리로딩과 웜 캐시에서 중요한 차이점을 알 수 없었습니다. 벤치 마크는 ts-loader에 대한 것이었습니다. ts-loader는 TypeScript 용 두 개의 webpack 로더 중 가장 느린 것이었습니다 (다른 하나는 awesome-typescript-loader입니다).
물론, webpack을 구성하려고 시도하는 사람은 누구나 알고 있듯이 JavaScript 툴체인은 엄청나게 복잡합니다. 소스 맵 플러그인, 캐싱, 사용할 스레드 수 사이의 선택들이 계속됩니다. 단순한 벤치 마크는 전체 이야기를 고려할 수는 없지만, TypeScript 컴파일러에 비해 Babel을 사용하면 여러 배로 증가할 것으로 예상되는 경우 다른 곳에서 성능 향상을 찾아야 합니다.
당신은 무엇을 선택해야 합니까?
많은 자바 스크립트 개발자들처럼, 나는 반짝이고 새로운 것을 좋아합니다. 이 기사를 쓰기 시작했을 때 나는 Babel 로의 전환이 빌드 체인을 간소화하고 적은 단점이 있는 더 효과적인 빌드를 제공하기를 바랐습니다.
불행히도, 내 결론은 꽤 반대였습니다. 눈에 띄는 성능 향상은 없으며 단점도 원래 예상했던 것보다 훨씬 큽니다.
특히, 데코레이터 메타 데이터를 방출하지 않는 Babel은 내게 매우 적합하지 않습니다. 그 이유 하나만으로도 TypeScript 프로젝트가 있다면 Babel로 전환하는 것을 권장하지 않습니다.
Babel은 TypeScript를 처음 사용하거나 프로젝트를 점진적으로 마이그레이션 하려는 경우 교육용 바퀴로 유용할 수 있습니다. 어느 시점에서, 당신은 아마 훈련 바퀴를 벗어나고 싶을 것입니다.
Babel만 제공하는 사용자 정의 변형이 필요한 경우, 최상의 빌드 파이프 라인은 TypeScript 파일을 TypeScript 컴파일러로 전달한 다음 나중에 Babel로 전달하는 것입니다.
다소 복잡합니다. 하지만 누구도 자바 스크립트 빌드 툴체인이 쉽지 않다고 말한 적이 없습니다.
'Programming > JavaScript' 카테고리의 다른 글
[Redux] Redux란? (0) | 2019.10.04 |
---|---|
[jqGrid] 컬럼 순서 변경시 오류가 날 경우 (0) | 2019.08.23 |
Google의 JavaScript 스타일 가이드의 주목할만한 점 (0) | 2019.05.12 |
NodeJS - Webpack 소개 (0) | 2019.04.15 |
NodeJS - Meteor with React Tutorial (5) (0) | 2019.02.19 |