# Javascript를 2개의 언어로 분할해야 할까?

> Clean Markdown view of GeekNews topic #17470. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=17470](https://news.hada.io/topic?id=17470)
- GeekNews Markdown: [https://news.hada.io/topic/17470.md](https://news.hada.io/topic/17470.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2024-10-28T14:12:07+09:00
- Updated: 2024-10-28T14:12:07+09:00
- Original source: [devclass.com](https://devclass.com/2024/10/22/should-javascript-be-split-into-two-languages-new-google-driven-proposal-divides-opinion/)
- Points: 9
- Comments: 4

## Summary

Google 엔지니어가 JavaScript를 두 개의 언어로 분할하는 제안을 발표하여, 보안과 성능을 개선하고 런타임 엔진의 복잡성을 줄이자는 주장을 했습니다. 대부분의 새로운 기능을 엔진이 아닌 도구에서 구현하는 방식으로 접근 방식을 변경하자는 것이며, 엔진에서 구현되는 언어를 "JS0"라고 하고, 도구에서 구현되는 언어를 "JSSugar"라고 지칭합니다. 이 제안이 채택될 경우, 미래의 구문 기능은 JSSugar로 가고, API 및 기능 기능만 JS0로 가게 됩니다. 이 제안은 JavaScript 개발자들이 새로운 문법 기능을 사용하기 위해 컴파일러에 더 의존하게 만들 수 있어 논란이 되고 있으며, 기존 코드와의 호환성 및 개발자 경험을 고려해야 합니다.

## Topic Body

- 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는 웹 개발의 기반이 되는 언어인 만큼, 앞으로도 활발한 논의와 발전이 이어질 것으로 예상됨

## Comments



### Comment 30513

- Author: kandk
- Created: 2024-10-29T13:24:10+09:00
- Points: 1

레이어를 하나더 추가하고 그 레이어에 DX에 도움되는 내용들을 추가하겠다고 하는것 같네요.

### Comment 30505

- Author: savvykang
- Created: 2024-10-29T11:43:12+09:00
- Points: 1

> 많은 JavaScript 개발자들은 이러한 도구에 덜 의존하고 싶어함  
> JavaScript를 중간 도구에 의존하게 만드는 개념은 인기가 없음  
  
당장 JSX만 해도 트랜스파일이 필요하도록 생태계가 구축되었는데 현실성 없는 의견이라 생각합니다. NodeJS가 전부라고 생각하는 것 같아요

### Comment 30502

- Author: aer0700
- Created: 2024-10-29T11:12:20+09:00
- Points: 1

정확히 이해한 건진 모르겠지만, C++에 BOOST라고 있는데, 그거 비슷한 느낌이네요. 구글의 제안이 어그리 되어서, JSSugar에 기존 라이브러리들을 통합한다면 뭐가 들어가게 될까요? 바벨?

### Comment 30475

- Author: neo
- Created: 2024-10-28T14:12:08+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=41955353) 
- Java의 Hotspot VM이 다른 언어들에 큰 성공을 가져왔음. JavaScript도 비슷한 방식으로 핵심 언어를 목표로 하고, 문법적 설탕을 사전 컴파일하는 것이 합리적임
  - JavaScript는 두 가지 언어로 나뉨: 인터넷의 어셈블리 언어로서의 JavaScript와 프론트엔드 웹 개발 언어로서의 JavaScript
  - 새로운 언어 기능은 기존 런타임에서 잘 지원되고 최적화된 부분으로 트랜스파일하는 것이 좋음. 트랜스파일링이 필요하지만, 이는 현대적인 빌드 도구를 사용하는 것과 같음

- WebAssembly에 집중하는 것이 더 나음. JavaScript는 스크립팅에 사용하고, 다른 언어는 더 큰 애플리케이션에 사용해야 함

- VanillaJS를 선호하는 사람으로서, 강제로 변경되는 언어 기능에 불만이 있음. API 개선에 집중하여 웹 앱이 네이티브 앱과 동등해지도록 해야 함

- BigInt에 대한 사용 사례가 없다는 주장에 반대함. Google의 프론트엔드 개발자들이 사용하지 않더라도, 다른 JS 개발자들은 사용하고 있음. 언어 발전에 집중해야 함

- JavaScript와 Wasm을 분리했어야 했음. 대신 Wasm을 웹 API 접근이 불가능한 2급 시민으로 만듦

- 제안된 해결책은 근본적인 문제를 해결하지 못하고, 도구에 의존하게 만듦. JavaScript는 성능과 복잡성을 줄이기 위해 새로운 언어로 전환해야 함

- TC39와 개발자 커뮤니티의 분리로 인해 문제가 발생함. TypeScript 도구는 표준화되지 않았고, Rust로 포팅할 계획도 없음

- Google의 V8 엔진 유지 관리 문제로 인해 JavaScript 변경을 제안함. 보안 문제와 복잡성 비용이 사용자에게 영향을 미침. C++ 대신 다른 언어를 시도해야 함