Node.js, TypeScript 실험적 지원 추가

 (github.com/nodejs)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Node.js PR #53725가 병합되어 --experimental-strip-types 플래그로 TypeScript 파일 실행을 실험적으로 지원하게 됨
  • 이 기능은 TypeScript 소스에서 타입 구문을 제거해 JavaScript 소스로 변환하며, 변환 과정에서 타입 검사는 수행하지 않음
  • 초기 구현은 Enum, namespaces 같은 TypeScript 전용 기능 변환을 하지 않으므로, 타입 제거만으로 JavaScript가 되는 코드에 한정됨
  • 구현에는 @swc/wasm-typescript가 선택됐고, 이유는 Rust나 Go를 Node.js 툴체인에 추가하지 않아도 되는 단순성임
  • 논의에서는 ESM의 필수 파일 확장자 규칙, .js import가 실제 .ts 파일을 가리키는 TypeScript 관행, 소스맵과 에러 스택 위치 비용이 주요 제약으로 다뤄짐

--experimental-strip-types의 동작 방식

  • --experimental-strip-types를 설정하면 Node.js가 TypeScript 파일을 실행할 수 있음
  • Node.js는 TypeScript 소스 코드를 JavaScript 소스 코드로 트랜스파일함
  • 트랜스파일 과정에서 타입 검사는 수행하지 않고, 타입 정보는 버려짐
  • 예시는 다음과 같음
const foo: string = "foo";

const foo = "foo";

타입 제거만 선택한 이유와 초기 제한

  • 이 PR의 핵심은 TypeScript 문법 중 타입 구문 제거임
  • 다른 런타임은 enum처럼 JavaScript에 없는 TypeScript 전용 기능을 JavaScript로 변환하기도 함
  • 이 PR의 초기 구현은 그런 변환을 수행하지 않음
    • Enum 사용 불가
    • namespaces 사용 불가
    • 기타 TypeScript 전용 기능도 변환 대상이 아님
  • 구현 세부와 제한은 PR 변경 사항의 typescript.md를 참고하라는 안내가 포함됨

구현 도구로 @swc/wasm-typescript를 선택

  • @swc/wasm-typescript는 작은 패키지이며, wasm 파일과 이를 바인딩하는 JavaScript 파일로 구성됨
  • 다른 도구들은 Rust나 Go를 Node.js 툴체인에 추가해야 하는 요구가 있었음
  • SWC는 Deno에서도 같은 목적으로 사용되고 있으며, PR 작성자는 이를 검증된 선택지로 봄
  • 향후에는 이 기능이 네이티브 레이어에서 구현될 수 있다고 봄
  • 이 PR은 nodejs/loaders#217을 참조함

import 해석과 확장자 논의

  • import foo from "./foo" 같은 확장자 없는 import는 지원되지 않음
  • Node.js ESM에는 mandatory file extensions 규칙이 있어, 확장자 없는 import 미지원은 의도된 동작으로 다뤄짐
  • TypeScript 모듈 코드베이스에서는 실제 파일이 .ts여도 import 문에는 .js 확장자를 쓰는 경우가 흔하다는 의견이 제기됨
    • 예: import foo from './foo.js'
    • 실제 파일 시스템에는 ./foo.js가 없고 ./foo.ts만 있는 경우
  • PR 작성자는 이 문제를 향후 반복 작업에서 다룰 수 있으며, 확장자 추측은 추가 파일 시스템 확인과 휴리스틱이 필요하다고 봄
    • ./foo.js가 없으면 ./foo.ts를 확인
    • ./foo.ts가 없으면 ./foo.js를 확인
  • 이 논의는 nodejs/loaders#208에서 추적됨

소스 위치, 소스맵, 에러 스택

  • 리뷰에서는 에러 스택의 정확한 소스 위치가 단기적으로 필요하다는 의견이 나옴
  • 한 가지 가능한 방법은 타입 제거 과정에서 소스 위치를 바꾸지 않아 소스맵 생성과 매핑을 피하는 것임
  • 소스맵은 메모리 사용량과 성능 측면에서 비용이 있으며, 단순하지 않다는 제약이 언급됨
  • PR 작성자는 SWC가 이미 소스맵을 지원하므로 이를 활성화하는 플래그를 추가할 수 있다고 봄
  • 제거된 구문을 공백으로 대체해 원래 에러 스택을 바꾸지 않는 옵션을 SWC에 요청할 수도 있다고 봄

안정화 전 남은 설계 쟁점

  • TypeScript 지원은 두 축으로 나뉨
    • 타입 구문 제거
    • .ts 파일을 받아들이도록 해석 규칙을 조정
  • 해석 규칙 변경은 기존 TypeScript 로더와 충돌할 수 있다는 우려가 나옴
  • PR 작성자는 이 PR에는 해석 규칙 오버라이드가 없으며, 파일 확장자가 필요하다고 답함
  • allowImportingTsExtensions를 통해 import './file.ts' 형태를 지원할 수 있고, 이런 방식은 Deno와도 맞는다는 의견이 제시됨
  • 같은 소스 파일을 직접 실행하고 빌드 도구로 JavaScript 출력도 만들려면, file.ts를 file.js로 바꾸는 책임은 빌드 도구가 맡을 수 있다고 봄

병합과 후속 작업

  • PR은 2024년 7월 24일 nodejs:main에 병합됨
  • 변경 규모는 8개 커밋, 89개 파일, 2,190줄 추가와 25줄 삭제임
  • semver-minor, experimental, module, esm, notable-change 등의 라벨이 붙음
  • 웹사이트의 TypeScript 안내 페이지에 이 기능을 언급할지에 대한 논의가 있었고, 관련 업데이트 PR도 연결됨
  • 배포 메타데이터에 Node 바이너리가 타입 제거에 사용하는 TypeScript 버전을 포함하는 방안도 후속 이슈로 논의됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • TypeScript 타입 제거는 TypeScript 문법 없이 불가능함. 타입 제거는 토큰 단위 작업이 아니고, TypeScript 문법은 계속 바뀜
    예를 들어 foo < bar & baz > ( x )는 TypeScript 1.5에서는 bar&baz가 유효한 타입식이 아니어서 (foo (x))처럼 파싱됐지만, 교차 타입 연산자가 추가된 뒤에는 foo<(bar & baz)>(x)로 파싱되어 foo(x)로 탈당의화됐음
    최신 TypeScript 기능을 계속 쓰려면 JS로 컴파일하거나 Node 버전을 계속 최신으로 유지해야 하고, Node LTS에 머무르는 걸 선호하는 팀에는 받아들이기 어려운 타협일 수 있음

    • Node 팀도 이 문제를 이미 고려한 듯함. Node가 npm을 번들하지만 별도로 업그레이드할 수 있는 선례가 있으니, TypeScript 변환기도 비슷하게 할 수 있다는 논의가 있음
      코어에는 안정 버전을 두되 TypeScript가 새 기능이나 깨지는 변경을 내거나 사용자가 새 실험 기능을 쓰고 싶으면 NPM에서 별도 업그레이드하게 하는 방식임
      이렇게 하면 사용자가 고정되지 않으면서도 Node.js 릴리스의 3년 수명 동안 특정 TypeScript 버전을 지원할 수 있음: https://github.com/nodejs/loaders/issues/217
    • 타입 제거 관점에서의 문법은 불안정했던 기간보다 안정적이었던 TypeScript 버전이 훨씬 많음. 1.5까지 거슬러 올라간 것도 2.x 이후로는 꽤 안정적이었기 때문임
      마지막 큰 문법 변화는 아마 2.8의 조건부 타입으로, 타입 위치에 삼항 if 연산자 비슷한 문법이 들어간 때였을 것임. 타입 검사까지 하려면 타입 모델은 2.x 이후 많이 바뀌었지만, 문법은 대체로 안정적이었고 TypeScript의 혁신도 대부분 타입 모델과 타입 추론 쪽에 있었음
      아직 초기 단계인 Stage 1이지만, 타입 검사 말고 타입 제거 목적의 TypeScript 타입 문법 상당 부분을 표준화하려는 시도도 있음: https://github.com/tc39/proposal-type-annotations
    • 컴파일러도 같이 업데이트해야 함. 결국 “TypeScript 버전을 Node.js 버전과 독립적으로 올릴 수 없다”라고 표현할 수 있지만, 아마 큰 문제는 아닐 듯함
    • 부등호 기호를 꺾쇠괄호처럼 쓰는 건 정말 실수였던 것 같음
    • 최신 TypeScript를 항상 따라가고 새 언어 기능을 쓰는 팀은 최신 Node 버전도 따라갈 가능성이 높아 보임. 경험상 TypeScript 업그레이드가 Node 업그레이드보다 새 오류 때문에 마이그레이션이나 수정이 더 자주 필요했음
      최신 V8이나 Node 기능에 별 관심이 없고 LTS에 머무르는 팀은 최신 TypeScript 기능에도 덜 관심 있을 가능성이 큼

  • Node.js가 TypeScript 파일을 직접 실행할 수 있다면 TypeScript 컴파일러는 타입 제거와 JavaScript 변환 대신 타입 검사기로만 쓰일 수 있음. Python에서 타입 검사기는 타입을 검사하고 그대로 두며, 인터프리터는 타입 힌트를 무시하는 방식과 비슷함
    흥미롭게도 Python에서는 같은 타입 힌트 문법을 쓰면서도 의미론은 다른 인기 타입 검사기가 여러 개 생겼음. 반면 JavaScript에서는 TypeScript가 사실상 유일한 인기 타입 검사기가 된 듯함
    Python에서는 타입을 검사하지 않고 소스에 타입만 적어 더 편한 주석 문법처럼 쓰는 경우도 들었음. Node.js가 타입 무시를 지원하면 JavaScript에서도 그런 방식이 가능해짐

    • Facebook의 Flow가 몇 년 전에는 JavaScript 쪽에서 꽤 중요했지만, 지금은 TypeScript가 꽤 확실하게 이긴 것으로 보임
    • 타입 검사를 하지 않더라도 IDE가 타입 힌트를 이용해 자동완성 등을 개선할 수 있으니, 일부 위치에 타입을 추가하는 건 여전히 의미가 있음
    • 지금도 JSDoc으로 타입을 붙이고 TypeScript로 검증하면 컴파일 없이 가능함. 빌드는 빨라지고, 마법 같은 처리나 주석 외 제거 작업 없이 어디서나 동작하는 코드를 얻을 수 있음
      개인적으로 JSDoc 사용의 가장 큰 불편은 가져오기 문법이었는데, TypeScript 5.5 이후 바뀌어서 이제는 문제가 아니게 됨
    • Node.js만 JavaScript 런타임인 건 아님. 모든 브라우저가 TypeScript를 직접 실행할 수 있기 전까지는 브라우저용으로 TS를 JS로 컴파일해야 함
      다만 일부 번들러는 이미 SWC처럼 비공식 컴파일러를 써서 이 일을 하고 있고, Node도 이 기능에서 SWC를 시험 중임
      타입 힌트는 단순 주석만이 아니라 이름처럼 IDE가 더 나은 자동완성을 보여주기 위한 힌트이기도 함
    • 이 방향의 EcmaScript 제안이 있음: https://github.com/tc39/proposal-type-annotations
      이건 언어 명세의 일부가 되어야 한다고 봄

  • 이 기능이 플래그 뒤가 아니라 기본값이 되면 NPM 생태계가 어떻게 반응할지 궁금함. 기여자들이 NPM 모듈을 배포할 때 여전히 CJS와 ESM 버전을 빌드할지, 아니면 package.json에 engine: nodejs >= 25만 붙이고 빌드 단계를 생략할지 모르겠음
    개인적으로는 TS 원본을 가진 NPM 모듈들이 dist/.cjs 배포를 멈추면 디버거와 console.log를 어디에 넣어야 할지 명확해져서 더 좋겠음. NPM 기여자 입장에서도 빌드 단계를 없애는 유혹이 클 것임
    하지만 의존성 하나만 TS 파일을 배포해도 “모두가 TS 파일을 받는다”는 전제가 빠르게 퍼질 수 있음. Node.js가 이걸 옵트인 실험 플래그 밖으로 꺼내는 순간 커뮤니티 전체가 소비자에게 TS 파일 수용을 암묵적으로 기대하게 될 듯함
    그렇게 되면 몇 달 안에 Firefox와 Safari도 받아들이도록 압박받고, 모든 JS 컴파일러가 TS 타입 주석을 버릴 수밖에 없을 것임
    개인적으로는 이것도 괜찮음. TS를 쓰는 쪽에서도 어떤 가상의 JS 사용자 지원을 위해 TS 코드를 JS와 .d.ts로 바꾸는 변환 단계를 NPM 모듈에 넣고 있기 때문임. 그런데 Node가 .ts 파일을 받으면 그런 변환 단계를 눈치채지 못한 채 제거할 수 있으니, NPM 게시자가 js/d.ts 파일 배포를 중단하고도 깨진 걸 모르게 되는 걸 막는 장치가 궁금함

    • Ryan Dahl이 이 문제를 풀기 위해 JSR이라는 새 패키지 레지스트리를 만들고 있음
      빌드 단계 없이 TypeScript 코드를 올릴 수 있고, 다른 개발자가 설치하면 변환된 JavaScript가 아니라 원본 TypeScript 소스를 볼 수 있게 해주는 방식임
    • node_modules 안의 .ts 파일 실행은 지원하지 않음. 생태계를 깨지 않기 위한 주요 제약 중 하나임
    • 유지 중인 오래된 TypeScript 라이브러리들은 npm용으로 .cjs와 .mjs로 변환하고 있는데, 아마 세 가지 버전을 모두 배포하게 될 것 같음
      새로 처음부터 쓰는 프로젝트라면 TypeScript만 배포하고 변환은 안 할 수도 있음
      수정: PR 작성자이자 Node.js 기술 운영 위원회 멤버로 보이는 satanacchio의 형제 댓글에 따르면, TS 지원은 최상위 항목용이고 node_modules 안의 라이브러리에는 적용되지 않는다고 함
    • 내 소스 코드인 .ts를 npm에 배포하고 싶지만, TypeScript 팀은 tsconfig 문제와 성능 문제 때문에 이에 매우 반대했음. 그래도 기대는 하고 있음

  • 언젠가 Node가 JS에서 이 타입들을 런타임 반성할 수 있게 할지도 모름
    그러면 엄청난 이득임. Python에서는 타입을 반성할 수 있기 때문에 pydantic 같은 훌륭한 도구가 타입에서 검사를 생성할 수 있음
    단일 표준 표기만으로 타입 검사, 런타임 데이터 검사, API 생성, API 문서 생성을 얻을 수 있음
    지금 JS에서는 Zod 같은 도구가 const mySchema = z.string();처럼 TypeScript가 이미 하는 일을 사실상 다시 발명해야 함

    • Zod의 z.string()은 TypeScript 같은 타입 안전성만 제공하는 게 아님. TypeScript는 컴파일 시점 타입 검사를 제공하고, Zod는 런타임 검증과 파싱을 추가함
      z.string()은 mySchema를 파싱과 검증이 가능한 함수형 스키마로 만듦. mySchema.parse("some data")는 성공하고, mySchema.parse(321)은 예외를 던짐
      런타임 검증과 프로세스 내 확인이 필요한 곳에서 써봤는데 꽤 잘 동작했고, const A = z.string(); type A = z.infer; // string처럼 타입도 뽑아낼 수 있음
      즉 Zod에서 타입을 먼저 정의하고 거기서 타입을 추론하면 컴파일 시점과 런타임 타입 검사를 모두 얻음. 다만 빠르게 움직이는 작은 코드베이스에는 과할 수 있지만, 프로세스 내 검증이 필요한 상황에서는 꽤 유용하고 작업량도 크지 않음
    • 요즘 TypeScript 팀의 초점은 JavaScript 언어와의 정렬에 많이 가 있고, 런타임 타입 같은 새 기능은 거의 배제됐거나 적어도 TC39 JavaScript 타입 제안 뒤로 밀린 상태임. 클래스 구조 밖 변수에 데코레이터를 쓰는 문제도 비슷했음
      다만 TypeScript는 플러그인을 허용함. 잘 쓰이진 않지만 결과 JavaScript로 변환되는 다른 기능을 언어에 추가할 수 있음
      런타임 타입과 관련된 플러그인으로 Typia가 있고, assert(myValue) 같은 가드에서 TypeScript 타입 시그니처를 런타임에 사용할 수 있게 해줌. 이 함수 호출을 가로채 변환된 JavaScript에 전달 변수의 성격을 검사하는 exhaustive if 문을 생성함
      앞으로 4~6년 안에 언어 일부가 될 것 같지는 않지만, 오늘도 이런 일을 할 수 있게 해주는 라이브러리는 이미 있음
    • JS가 언젠가 타입 검사를 추가한다면 TypeScript를 선택하지 않았으면 함
      실제로 건전한 타입 시스템이 필요하지만 TS는 의도적으로 건전하지 않음. TS처럼 나쁜 코딩 관행을 허용하지 않고, 프로그램을 빠르게 만들 수 있는 설계를 강제하는 타입 시스템이 필요함. Hindley-Milner 타입 시스템이 필요함
      모듈을 타입 있는 코드로 만들고 싶다면 "use type"을 추가하는 식이면 됨. 이 모드는 타입 강제 변환 같은 나쁜 부분을 금지하고, 객체 모양이나 값 타입을 바꾸거나 아무 값이나 섞은 배열을 만드는 등 성능을 해치는 요소를 막아야 함
      타입 없는 모듈에서 들어오는 데이터는 변환되거나 변환할 수 없으면 오류를 던지고, 그러면 컴파일러는 더 강한 타입 보장과 중도 포기 위험이 없는 상태에서 타입 있는 코드를 깊게 최적화할 수 있음
    • 이게 Node가 예외가 ValueError의 하위 클래스인지, 객체가 SomeClass의 인스턴스인지 알 수 있다는 뜻인지 궁금함. TS 초보라서 배열, 객체, 숫자, 문자열 외의 타입은 JS에 없고 Zod나 타입 가드 함수는 “믿어줘” 수준의 일반 객체를 반환한다고 생각했음

  • Bun의 개발자 경험은 이 영역에서 꽤 전례 없는 수준이고, 이제 대부분의 사용 사례가 커버되거나 bun run으로 실행 스크립트를 쓸 때 Bun이 크래시하지 않음
    반면 Node는 import에서 확장자를 요구하지 않게 설정할 수도 없고, tsc가 컴파일 결과에 .js 확장자를 자동으로 붙이게 할 수도 없어서 번들러를 추가해야 함
    네이티브 TypeScript 지원이 이 사소한 불편을 꽤 고치겠지만, 안정화되더라도 사용자 경험이나 성능이 Bun과 맞먹을지는 상상하기 어려움

    • 확장자는 요구되어야 함. 로컬 디스크처럼 네트워크에서 경로 검색을 할 수는 없고, 브라우저 같은 네트워크 연결 런타임은 JavaScript에서 매우 중요함
    • Bun을 많이 좋아하지만, Deno가 여전히 더 성숙하고 안정적이며 기능도 많음. 안정적인 워커, HTTP/2 같은 것도 있고, 사용 사례에 따라 V8이 JSC보다 더 빠를 수 있음
      개발자 경험과 도구도 최고 수준임. Deno는 타입 검사도 할 수 있고, 기억하기로는 TSC를 번들함
      Bun은 화제성이 크지만, 진지한 작업에는 현재 Deno가 명확히 더 나은 선택지임. 그래도 Bun의 비전과 실행력은 인상적이고 개발자에게 좋은 일임
    • 몇 달 간격으로 Bun을 두 번 시도했지만 Windows에서 bun install 실행이 실패해서 한 번도 제대로 동작하지 않았음: https://github.com/search?q=repo%3Aoven-sh%2Fbun+bun+install...
    • “전례 없는” 건 Deno를 빼면 그렇겠지
    • Bun은 아직 너무 날것 아닌가 싶음. 1.0도 안 나온 Zig로 만들어졌음

  • TypeScript 런타임을 오래 바라왔고 TypeScript도 정말 좋아하지만, 오래전 Java를 떠나놓고 결국 Java에 훨씬 가까운 무언가를 찾게 된 게 웃김
    결국 우리가 원한 건 JIT, 더 풍부한 타입 시스템, 점진적 타입을 갖춘 Java였던 듯함. npm 생태계에도 단점은 많지만, 이 생태계에서 라이브러리를 쓰는 건 훨씬 덜 부담스럽고 더 재미있음
    놀랍게도 Rust는 언어 스펙트럼의 다른 끝에 있지만 비슷한 느낌을 주기도 함
    수정: JIT라는 표현은 적절하지 않았음. 게으르게 JIT라고 썼지만, JVM과 V8에서 뭔가를 실행할 때의 시작 시간과 런타임 차이를 말하려던 것임. Java는 무겁게 느껴지지만 JavaScript 생태계는 훨씬 민첩하게 느껴짐

    • Java가 말 그대로 JIT라는 용어를 유명하게 만든 존재라서, “JIT 있는 Java”가 무슨 뜻인지 모르겠음
      TypeScript가 Java에 더 가까운지도 전혀 모르겠음. 둘이 공유하는 건 “Javascript”라는 잘못된 이름과 명령형 프로그래밍 지원 정도뿐이고, 나머지는 매우 다르다고 봄
    • 경험상 TypeScript가 Java보다 훨씬 좋음. 훨씬 덜 장황하고 더 유연함
    • 개인적으로 Java보다 TypeScript를 쓰는 게 훨씬 좋음. 특히 클래스의 다소 불완전한 부분을 피하고 인터페이스와 함수에 집중하면 사용성이 훨씬 낫음
      다만 Java에 있고 TypeScript에서 그리운 건 런타임 타입 반성임. TypeScript 생태계에는 이를 우회하는 방법이 수없이 많지만, 모두 약간 보기 흉하다고 느낌
    • Java에는 JIT가 있음. 그리고 TypeScript 타입 시스템이 Java보다 어떻게 더 기능이 풍부한지 궁금함
    • 나도 비슷한 위치에 있음. 개인적으로 원하는 건 현재의 레거시 또는 사실상 폐기된 부분을 뺀 C# 표준 라이브러리와 생태계에, 구조적 대수 타입의 쉬움과 힘을 더한 것임
      AoT도 괜찮고 단일 바이너리 옵션이 있으면 좋음. 이상적으로는 런타임이 없고 영리한 제거가 가능하면 좋겠음. 브라우저에서 JIT로도 돌면 더 좋음
      exhaustive 패턴 매칭 같은 컴파일러와 타입 검사기 편의 기능도 원함

  • 내가 좋아하는 Deno 기능이 Node에 직접 들어오고 있음. 아주 좋음
    이제 타입 제거를 위해 항상 esbuild를 설치하지 않아도 될지도 모름. TypeScript로 스크립트를 작성해 쓰기가 훨씬 쉬워질 것 같아 기대됨
    최근에는 일회성 스크립트에 Python을 선호했지만, 타입 측면에서는 개인적으로 TypeScript가 Python보다 낫다고 봄. 특히 몇 달 뒤 다시 보는 큰 스크립트는 타입의 이점을 크게 받음

  • Node에 정말 사건이 많은 한 달이었음. 먼저 v22.5.0에서 node:sqlite가 추가됐고, 이제 TypeScript 지원도 들어오고 있음. Node가 가는 방향이 마음에 듦

    • Bun의 영향이나 경쟁 때문인 것 같음. 모두에게 좋은 일임
    • 최근 추가된 테스트 러너도 아주 멋짐

  • PR 작성자임. 뭐든 물어봐도 됨

    • 다음 단계가 무엇인지, 그리고 Node와 전체 JS 생태계에서 TypeScript가 어떤 미래를 가질 수 있다고 보는지 궁금함

  • 오래전에 백엔드 작업에 Node.js를 쓰기 시작했는데, PHP로 코드를 쓰는 것보다 많은 장점이 있으면서 Java의 문제를 많이 가져오지는 않는 듯했음
    하지만 Node는 다소 투박했고, 원하는 언어를 만들려면 이것저것 붙여야 하는 언어처럼 느껴졌음. 결국 Go를 쓰기 시작했는데 훨씬 쓰기 쉬웠고, 때로는 훨씬 장황하지만 타입 안전성 덕분에 코딩이 단순해졌음
    TypeScript는 좋은 선택지처럼 보였지만 결국 또 다른 덧댐이었음. TypeScript를 Go 대신 쓰면 어떤 가치를 얻는지 잘 모르겠음. 명확한 타입이 있는 건 좋지만, Go에서 해결된 언어의 다른 문제들을 해결해주지는 않음. Deno도 일부 해결함
    Node가 Go보다 갖는 큰 장점은 빠르게 프로토타입을 만들 수 있다는 점인데, TypeScript를 쓰면 그 장점이 상당히 줄어드는 것 같음. 그래서 이게 좋은 진전인지, 아니면 Node를 좋은 선택지로 만들던 특성을 잃게 하는 건지 판단하기 어려움

    • TypeScript는 더 안전한 JS임. TS를 써도 여전히 JS를 쓰는 것임
      “덧댐”이라는 표현을 보면 문제는 언어 자체보다 Django처럼 모든 걸 기본으로 관리해주는 의견 강한 프레임워크의 부재일 수도 있음. Django를 쓰는 건 좋아하지만, 정해진 길에서 벗어나기는 조금 더 어려움
    • 명백한 답은 언어 친숙도임. 프로젝트의 프런트엔드 코드가 JavaScript나 TypeScript라면 Node를 쓰는 건 쉬운 선택임. 공유 라이브러리, 공유 타입 등을 쓸 수 있음
    • 이미 JavaScript를 알고 있거나 사내 경험이 있다면 Go를 배우는 것보다 낫기 때문일 수 있음. 우리도 이전 프런트엔드 경험이 있어서 cdktf와 함께 쓰고 있고, Go보다 논리적인 선택처럼 보였음
답변달기