GN⁺: JavaScript 도구를 "더 빠른 언어"로 재작성 하는 것에 대한 회의적인 시각

(nolanlawson.com)

14P by neo 2달전 | favorite | 댓글 15개

최근 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의 가능성이 다 발굴되지 않은 상태
비록 대세는 거스를 수 없어 보이지만, 이런 방향성에 대해서는 커뮤니티 차원의 진지한 토론과 고민이 더 필요해 보임

▲

savvykang 2달전 [-]

필자가 SPA와 자바스크립트 도구 개발에 둘다 자바스크립트가 쓰이므로 그외에 필요한 제반 역량도 같다고 착각하는 것처럼 보입니다. 자바스크립트 도구에는 시스템 프로그래밍과 컴파일러 분야 역량이 필요하다고 생각합니다

오랫동안 JavaScript 생태계에서는 라이브러리 작성자와 사용자 모두 JavaScript를 사용해 왔음
이는 기여의 장벽을 낮추는 데 도움이 됨
하지만 JavaScript 라이브러리 작성자가 다른 언어를 사용하면 이 점이 깨짐

언어가 같더라도 실행 환경이 브라우저와 NodeJS로 다르고 그 간극을 넘을 수 있는 사람만 자바스크립트 도구에 기여할 수 있을텐데요. 실행 환경이 다르니 다른 생태계라고 봐야하지 않을까 합니다

평균적인 JavaScript 개발자가 빌드 툴의 버그에 직면했을 때 무력감을 느낄 수 있음
젊은 웹 개발자들에게 배운 무기력함을 가르치는 셈이 될 수 있음

이것도 마찬가지로 SPA 개발과 자바스크립트 도구 개발의 경계를 넘을 수 있는 사람의 수를 과대평가한 지점이라고 생각합니다. 프론트엔드 개발자에게 시스템 프로그래밍에 준하는 지식을 요구하는 건 무리입니다. 도구 사용자는 표면적인 에러메시지나 현상만 이해할 수 있지 않나요? 언어만 알아서 해결되는 문제가 아니라고 생각합니다