▲

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

 (devclass.com)
9P by neo with xguru 1달전 | favorite | 댓글 4개
  • 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는 웹 개발의 기반이 되는 언어인 만큼, 앞으로도 활발한 논의와 발전이 이어질 것으로 예상됨
▲
kandk 1달전  [-]

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

답변달기
▲
savvykang 1달전  [-]

많은 JavaScript 개발자들은 이러한 도구에 덜 의존하고 싶어함
JavaScript를 중간 도구에 의존하게 만드는 개념은 인기가 없음

당장 JSX만 해도 트랜스파일이 필요하도록 생태계가 구축되었는데 현실성 없는 의견이라 생각합니다. NodeJS가 전부라고 생각하는 것 같아요

답변달기
▲
aer0700 1달전  [-]

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

답변달기
▲
neo 1달전  [-]
Hacker News 의견

  • 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++ 대신 다른 언어를 시도해야 함

답변달기