GN⁺: Javascript를 2개의 언어로 분할해야 할까?

• Google 엔지니어가 공식 표준화 위원회에 JavaScript를 두 개의 언어로 분할하는 제안을 발표함
  • 런타임 엔진에서 구현될 코어와 이를 컴파일하는 도구에 의존하는 더 많은 기능을 가진 변형으로 분할할 것을 제안
• 이번 달 초 Emca TC39 회의에서 발표가 이루어짐
  • TC39는 JavaScript(공식적으로 ECMAScript) 사양을 발전시키는 Ecma International의 위원회임
• Google의 Shu-yu Guo가 발표를 진행했으며, Mozilla, Apple, Moddable, Sony의 공동 저자와 함께 슬라이드를 작성함
  • Shu-yu는 JIT, VM, 컴파일러 및 표준화 전문
• 저자들의 주장
  • 언어의 새로운 기능은 거의 항상 보안을 악화시키고, 성능에는 중립적이거나 부정적인 영향을 미침
  • 안정성은 때때로 악화되며, 개발자가 새로운 기능을 사용하는 경우에만 앱 기능이 향상됨
  • JavaScript VM(가상 머신)은 속도에 대한 압박으로 인해 이미 매우 복잡해졌으며, 이는 보안을 타협함. 또한 새로운 기능이 채택되지 않을 때 특히 안 좋아 보임
  • 보안 결함과 런타임의 '복잡성 비용'은 수십억 개의 사용에 영향을 미치는 반면, 그 혜택은 실제로 이러한 복잡성을 활용하는 개발자와 애플리케이션에만 제한되기 때문에 자바스크립트의 기반 기술은 단순해야 한다는 것
• 여러 조직이 참여하고 있지만 이 이니셔티브는 어느 정도 구글이 주도하는 것으로 보임
  • 슬라이드 중 하나에는 "이 가능한 솔루션은 구글이 선호하는 솔루션이며 반드시 다른 구현자의 솔루션은 아니다"라는 면책 조항이 포함
• 제안된 해결책
  • 기존 기능을 되돌리는 것이 아니라, 앞으로는 대부분의 새로운 기능을 엔진이 아닌 도구에서 구현하는 방식으로 접근 방식을 변경하는 것
  • 엔진에서 구현되는 언어를 "JS0"라고 하고, 도구에서 구현되는 언어를 "JSSugar"라고 함
  • 많은 개발자가 실제로 TypeScript로 코딩하고 Babel, Webpack, TypeScript 컴파일러와 같은 컴파일러에 의존하기 때문에 JavaScript에 특히 적합한 아이디어임
  • 채택될 경우, 미래의 구문 기능은 JSSugar로 가고, API 및 기능 기능만 JS0로 감
  • 호환 엔진은 JS0만 지원하면 됨
  • 그 부담은 JSSugar를 지원하기 위해 도구 구현자에게 전가될 것
    • 부작용으로 도구 구현자가 표준 프로세스에 더 많이 관여해야 하며 새로운 기술 그룹을 형성해야 할 수도 있음
• 제안은 이미 논란의 여지가 있음
  • JavaScript 도구에 공식 지위를 부여하지 말 것을 요청하는 개발자들이 있고, 많은 JavaScript 개발자들은 이러한 도구에 덜 의존하고 싶어함
  • 보안, 성능, 안정성에 우선순위를 두는 것에 대해서는 광범위한 합의가 있지만, JavaScript를 중간 도구에 의존하게 만드는 개념은 인기가 없음
  • 개발자 한명은 "RIP Vanilla JS"라고도 말함

GN⁺의 의견

• 이 제안은 JavaScript 개발 생태계에 큰 변화를 가져올 수 있음. 개발자들이 새로운 문법 기능을 사용하기 위해 컴파일러에 더 의존해야 한다는 점에서 우려가 있음
• 그러나 런타임 엔진의 복잡성을 줄이고 보안과 성능을 개선하려는 목표 자체는 긍정적임. 장기적으로는 JavaScript의 발전에 도움이 될 수 있음
• 유사한 접근 방식을 취하는 다른 언어로는 Dart가 있음. Dart는 개발자 친화적인 문법을 제공하면서도 JavaScript로 컴파일되어 브라우저에서 실행됨
• 이 제안을 채택할 때는 기존 코드와의 호환성, 개발자 경험, 도구 지원 등 다양한 요인을 신중히 고려해야 함. 또한 커뮤니티의 의견을 충분히 수렴하는 과정이 필요할 것임
• JavaScript는 웹 개발의 기반이 되는 언어인 만큼, 앞으로도 활발한 논의와 발전이 이어질 것으로 예상됨