- 최근 Node.js 툴을 Rust, Zig, Go 등의 더 빠른 언어로 다시 작성하려는 경향이 걱정스러우며, 객관적인 우려사항들을 정리함
[성능]
- JavaScript 툴의 속도를 높이기 위한 가능성이 아직 다 발굴되지 않았다고 봄
- ESLint, Tailwind 등에서 쉽게 개선할 수 있는 부분이 많이 존재함
- 브라우저에서 JavaScript는 대부분의 워크로드에 대해 "충분히 빠름"
- CLI 툴에서는 왜 JavaScript를 버리려 하는 것일까?
대대적인 재작성
- 오랫동안 JavaScript 툴 생태계는 "동작하는 것"에 초점을 맞추어 왔음
- 이제 API가 대부분 안정화되어 모두가 "같은 것을, 더 빠르게" 원하는 상황
- 성능을 고려해 새로 작성되고, API가 이미 정해져 있어 개발 시간을 아낄 수 있기 때문에 새 툴이 더 빨라질 수 있음
- A에서 B로 재작성하면 속도 향상이 있는데, 이는 B가 A보다 빠르다고 주장하기 쉬움
- 하지만 재작성 자체가 더 빠른 이유일 수 있음 (두 번째에는 더 많이 알고, 성능에 더 신경 쓰기 때문)
바이트코드와 JIT
- 브라우저에서는 당연하게 여기지만 바이트코드 캐시와 JIT(Just-In-Time 컴파일러)의 혜택을 받음
- JavaScript가 올바르게 캐시되면, 브라우저는 소스 코드를 바이트코드로 파싱하고 컴파일할 필요가 없음
- 자주 실행되는 함수는 기계어로 더 최적화됨 (JIT)
- Node.js 스크립트에서는 바이트코드 캐시의 혜택을 전혀 받지 못함
- 하지만 이제 Node에서도 컴파일 캐시를 사용할 수 있게 됨 (
NODE_COMPILE_CACHE환경변수 설정) - JIT는 함수를 여러 번 실행해야 "뜨거워지기" 때문에 일회성 스크립트에서는 혜택을 보기 어려움
- Pinafore에서 JavaScript 기반 blurhash 라이브러리를 Rust(Wasm) 버전으로 교체하려 했으나, 5번째 반복에 이르면 성능 차이가 사라짐
- Porffor와 같은 도구로 Node 스크립트를 AOT 컴파일하는 것을 고려해 볼 수 있음
- Wasm을 사용하면 순수 네이티브 툴에 비해 성능 저하가 있음
[기여도 및 디버깅 용이성]
- "모든 것을 네이티브로 다시 작성하기" 운동에 대한 주된 회의론임
- JavaScript는 관대한 타입, 쉬운 습득, 브라우저 지원 등으로 인해 대중적인 언어임
- 오랫동안 JavaScript 생태계에서는 라이브러리 작성자와 사용자 모두 JavaScript를 사용해 왔음
- 이는 기여의 장벽을 낮추는 데 도움이 됨
- 하지만 JavaScript 라이브러리 작성자가 다른 언어를 사용하면 이 점이 깨짐
- 또한 JavaScript 의존성을 로컬에서 수정하는 것이 간단함 (node_modules에서 직접 수정)
- 반면 네이티브 언어로 작성된 경우에는 소스 코드를 직접 체크아웃하고 컴파일해야 함
- JavaScript 라이브러리를 디버깅할 때는 익숙한 브라우저 개발자 도구나 Node.js 디버거를 사용할 수 있음
- Wasm에서도 디버깅이 불가능한 것은 아니지만, 다른 기술 세트가 필요함
[결론]
- JavaScript 생태계를 위한 새로운 세대의 툴이 나오고 있는 것은 좋은 일임
- 기존의 툴들이 매우 느리고 경쟁으로부터 혜택을 볼 것으로 보임
- 하지만 JavaScript 자체가 본질적으로 느리다거나, 개선의 여지가 없다고 생각하지는 않음
- Chromium 개발자 도구의 최근 개선사항을 보면 아직 갈 길이 멀다는 생각이 듦
- Rust와 Zig 개발자들만의 전유물이 되는 세상이 어떨지 우려됨
- 평균적인 JavaScript 개발자가 빌드 툴의 버그에 직면했을 때 무력감을 느낄 수 있음
- 젊은 웹 개발자들에게 배운 무기력함을 가르치는 셈이 될 수 있음
- 이는 알려지지 않은 길을 가는 것이며, 의도치 않은 결과를 초래할 수 있음
- 반면 덜 위험하면서도 거의 같은 결과를 얻을 수 있는 다른 길이 있음
- 하지만 현재의 흐름은 둔화될 기미가 보이지 않음
GN⁺의 의견
- Rust나 Zig 등으로 재작성하는 것이 항상 최선은 아닐 수 있음. Compile cache 등 JavaScript에서 개선할 여지가 더 있어 보임
- 초보개발자들에게 세그폴트 같은 복잡한 문제를 마주하게 하는 것이 과연 좋은 지 의문. 오히려 무기력함 만 가르칠 수도
- 오랫동안 JavaScript로 구축해온 생태계의 장점(라이브러리 간 자유로운 수정, 익숙한 디버깅 환경 등)을 희생하면서까지 속도를 높이는 것이 과연 좋은 방향일지 고민해 봐야 함
- 기존 JavaScript 라이브러리들의 개선 노력도 지속되어야 할 것으로 보임. 아직 JavaScript의 가능성이 다 발굴되지 않은 상태
- 비록 대세는 거스를 수 없어 보이지만, 이런 방향성에 대해서는 커뮤니티 차원의 진지한 토론과 고민이 더 필요해 보임