문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 TypeScript (문단 편집) === 결론 === 위와 같은 단점과 더불어 JavaScript 자체의 사양이 업그레이드되며 TypeScript만의 기능들이 도입되고, JsDoc의 발전으로 JavaScript만으로도 충분한 Type 지원이 가능해져 여러 프로젝트가 TypeScript 지원을 포기하고 JavaScript의 JsDoc으로 완전히 대체하는 걸 고려하거나, 대체하고 있다. TypeScript의 Type는 ''' ''any'' ''' type 남용과 '''런타임 타입 체크가 없다는 점'''[* 이게 가장 큰 한계이다. 불필요한 트랜스파일링 단계만 추가될 뿐, 얻을 수 있는 이득이 사실상 JsDoc과 다른 점이 없다. 강타입 언어로의 트랜스파일링 지원은 JsDoc만으로도 충분히 가능하다.], 형의 자유도가 JavaScript의 가장 큰 장점인데 이를 망친다는 관점 등 여러 방면에서 유명무실하다는 비판이 있으며, JavaScript + JsDoc은 컴파일이 필요하지 않다는 아주 큰 장점이 있어서 TypeScript의 필요성에 의심이 점점 강하게 제기되고 있다[* 다만 JsDoc의 타입 체커 또한 내부적으로는 TypeScript에 의존하고 있기 때문에 결국 TypeScript를 간접적으로나마 쓰는 것은 마찬가지다.]. 다만 위 단점들 전부 TypeScript가 주류언어로 떠오르고, JavaScript가 발전하고, 각종 편집기의 intelicode가 강화되면서 발견된 점들이고 어디까지나 TypeScript가 모든 JavaScript 프로젝트와 맞지는 않다는 뜻이다[* 즉, TypeScript가 맞지 않는 프로젝트에 TypeScript를 남용했다 보면 된다.]. 정말 문제투성이 언어였으면 이렇게 인기 있는 언어가 되지 못한다. 반대로 JsDoc등의 meta information 없이 언어가 자체적으로 타입을 지원한다는 건 분명 큰 장점이므로(대부분의 버그는 프로그래머의 실수이고, 타입 강제는 이런 실수를 줄일 수 있는 가장 강력한 방법이다) 아예 TypeScript 사용을 강제하는 프레임워크나, TypeScript를 컴파일 없이 바로 돌리는 가상 머신도 등장하고 있다[* 다만 대부분 내부적으로 JavaScript로 트랜스파일링 하는 형태로 구현한다]. TypeScript의 장점은 문법 단계에서 타입 체크를 지원한다는 점이 가장 크며, 이러한 장점이 TypeScript를 사용함으로서 발생하는 오버헤드를 능가하지 않는다면 JsDoc을 고려해보는 것이 좋다. 만약 프로젝트 곳곳에서 형변환이나 any type 남발로 불필요한 개발 시간, 인력이 소모된다면 해당 프로젝트가 정말 TypeScript를 요구하는지 다시 검토해볼 필요가 있다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기