JavaScript의 탄생과 죽음 (2014)

 (destroyallsoftware.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 1995년부터 2035년까지의 JavaScript와 프로그래밍 역사를 SF·코미디·진지한 강연 형식으로 따라감
  • 범위는 JavaScript뿐 아니라 프로그래밍 전반의 역사까지 확장됨
  • JavaScript에 대해 찬성이나 반대 한쪽에 서지 않는 중립적 관점을 취함
  • 언어의 결함을 솔직하게 다루면서도 산업에 미친 최종 영향은 매우 긍정적으로 평가함
  • 핵심 메시지는 JavaScript가 결함에도 불구하고 프로그래밍 산업에 큰 긍정적 영향을 남겼다는 점임

강연 개요

  • JavaScript와 프로그래밍 전반의 역사를 1995년부터 2035년까지 따라가는 형식임
  • 강연의 성격은 SF, 코미디, 완전히 진지한 강연이 함께 섞인 형태임
  • JavaScript를 지지하거나 반대하는 강연이 아니며, 한쪽 입장으로 정리되지 않음
  • JavaScript의 결함은 솔직하게 다뤄지지만, 산업에 미친 최종 영향은 매우 긍정적으로 평가됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 2020~2025년에 전 지구적 재난이 올 거라고 정확히 예측하긴 했는데, 재난의 종류만 틀렸다는 게 좋음(?)
    아주 JavaScript답다

    • 거의 NaN% 정확도였다고 볼 수 있음

  • 이 사람이 우리에게 이 걸작을 남겼다는 얘기가 아직 없다니 놀랍다
    안 봤다면 하던 걸 멈추고 보길 권함. 오늘 하루 최고의 5분이 보장됨
    https://www.destroyallsoftware.com/talks/wat

    • 그의 발표는 전부 훌륭함
      Boundaries는 소프트웨어 아키텍처에 관해 본 영상 중 가장 통찰력 있었고, 지금도 복잡한 애플리케이션을 설계할 때 그 교훈을 떠올림
      상태가 여기저기 흩어진 명령형 논리에 익숙한 사람에게 함수형 프로그래머처럼 생각하는 법을 알려주는 좋은 입문 자료이기도 함
      https://www.destroyallsoftware.com/talks/boundaries
    • 이 발표에는 몇 가지 오류가 있고, 내가 본 것 중 두 가지만 적어봄
      Array(16)을 호출한 뒤 구분자가 16개 있다고 말하지만, 실제로는 15개뿐이라 Batman 농담이 조금 깨짐
      또 {}+[]를 쓰고 객체에 리스트를 더한다고 설명한 뒤 []+{}가 [object Object]를 주는 것과 결과가 다르다고 조롱하지만, 실제로 ({}+[])라고 쓰면 역시 [object Object]가 나옴
      왜 {}+[]가 다른지는 퍼즐로 남겨둠. 힌트: Gurer vf ab bowrpg gurer.

  • JavaScript는 실제로 컴파일 대상이 되었고, 당시 영상에서는 asm.js였지만 지금은 WebAssembly가 나왔음
    실제로 구현되고 네이티브에 가깝게 실행되는 걸 보면 예측이 꽤 맞았다고 보임
    나는 주로 TypeScript를 쓰고, Electron 덕분에 웹 기술이 데스크톱 앱으로 포장되면서 웹 문법이 일반 프로그램 안으로도 들어왔음
    Electron이 무겁고 별로라는 말은 있지만, Mac·Windows·Linux를 한 번에 지원하는 가장 빠른 방법이기도 함
    여기서 말하는 “죽음”은 JavaScript를 직접 쓰지 않게 되지만 어디에나 깔린 기반 계층이 되는 상태이고, 실제로 그렇게 됐다고 봄

    • Flutter도 있고, 데스크톱 운영체제뿐 아니라 iOS와 Android도 지원함
      개발 속도도 꽤 빠른 편이라고 봄
      다만 Electron이나 네이티브 앱과 성능이 어떻게 비교되는지는 잘 모르겠음
      작은 팀이라면 속도 최적화보다 실제로 출시하는 것에 맞추는 편이 훨씬 낫다
    • JavaScript는 말하자면 새로운 어셈블리 계층임
      컴파일러는 정의상 사람이 읽을 수 있는 코드를 기계어로 옮김
      JavaScript의 장점은 Google이 V8으로 한계까지 밀어붙였고 NodeJS가 백엔드에서 매력적인 환경을 만든 뒤, PDF처럼 어디에나 있고 한 번 쓰면 어디서든 쓸 수 있다는 데 있음
      WebAssembly보다 지금까지 우위를 가진 이유도 그 다재다능함이며, WebAssembly는 JavaScript만큼 널리 깔려 있지 않음
      요즘 JavaScript는 사실상 TypeScript와 동의어가 됐고, 이건 엄청난 도약이었음. 여기서 숨은 영웅은 Angular 2였다고 봄
      Angular는 처음부터 TypeScript를 택하면서 네이티브 JavaScript 버전도 제공했지만, 솔직히 그 버전은 거의 못 쓸 수준이었고 당시엔 강하게 비판받았음
      흥미롭게도 기본 선택지로 TypeScript를 내세우지 않는 마지막 피난처가 React인데, NextJS 같은 주요 프로젝트들이 기본적으로 TypeScript에 의존하는 상황이라 ReactJS도 결국 무너질 것임
      혁신이 다른 프로젝트에서 먼저 나오고 ReactJS가 따라가는 건 처음이 아니며, 여기서도 Angular가 앞서고 있다고 봄
      JavaScript와 Python을 고르면 크게 틀릴 일은 드물다
    • 그 “죽음”이 JavaScript가 직접 쓰이지 않는 기반 계층이 되는 뜻이라면, 내가 사는 시간선과는 다른 듯함
      사람들은 여전히 엄청난 양의 JS를 직접 쓰고 있고, WebAssembly도 아직 웹 애플리케이션의 일반적인 실행 환경을 장악하지 못했음
      WebAssembly 위에 무언가를 만드는 회사 사례는 찾을 수 있지만, Gary가 말한 종류의 대전환과 혼동하면 안 됨
    • 영상 속 이야기에서는 JIT가 충분히 좋아져서 가상 메모리와 메모리 보호를 없앴음
      그런 일은 전혀 일어나지 않았다
    • 웹사이트로 충분한데 왜 앱을 만들어야 하나?
      그걸 위해 웹 브라우저를 여러 개 실행할 필요는 없음

  • 몇 년마다 더 나은 JavaScript를 발명하고, 다시 그걸 JavaScript로 트랜스파일함

    • 대규모 채택은 언제나 좋은 설계를 이김
    • 결국 다 어셈블리 코드임
      JavaScript로 컴파일하는 것 자체에는 본질적으로 잘못된 게 없고, 고수준 언어는 순수 JavaScript가 직접 제공하지 않는 많은 보장을 구현할 수 있음
      지금까지 써온 거의 모든 언어 보장은 원시 어셈블리에서는 깨질 수 있다

  • 문제는 Wasm의 발전 속도가 여기서 예측한 만큼 빠르지 않다는 점임
    DOM 조작이 없어서 여전히 JS를 접착 코드로 써야 하고, 아니면 HTML과 CSS를 아예 버리고 Flutter나 일부 Rust GUI처럼 모든 걸 캔버스에 렌더링해야 함
    하지만 웹의 기능 집합을 잃는 건 아쉬운 일임

    • Flutter를 선택하는 사람들은 모든 브라우저에서 캔버스가 주는 일관성이, 제각각 구현된 웹 기능 집합을 얻는 것보다 더 가치 있다고 볼 것임
    • DOM과 JS는 떼려야 뗄 수 없음
      DOM API는 JS로 접근한다는 가정 아래 설계됐고, JS의 설계와 일부 “독특한” 특징도 DOM과 함께 쓰기 위해 만들어진 데서 부분적으로 비롯됨
    • JS는 WASM보다 훨씬 접근하기 쉬움
      즉석에서 디버깅할 수 있고, LLM에 넣어볼 수도 있으며, 래퍼도 없어서 만지고 실험하고 작업하기가 훨씬 쉽다

  • 2014년에 Canadian Undergraduate Software Engineering Conference(CUSEC)에서 Gary Bernhardt가 이 발표를 라이브로 하던 걸 봤음
    PNaCl은 바로 전년에 나왔고, Google은 Chrome과 ChromeOS 안에서 OpenSSH와 RDP 클라이언트를 교차 컴파일·실행·샌드박싱하는 데 쓰고 있었으며, Mozilla/Firefox 쪽은 그에 대한 대응으로 asm.js를 제안했음
    당시에는 그냥 웃겼는데, 지금 보니 그 아이디어 중 꽤 많은 부분이 살아남았다는 게 놀랍다

  • Gary Bernhardt의 Wat 라이트닝 토크는 내가 가장 좋아하는 발표였음
    이 글 제목의 발표보다 겨우 2년 앞선 것임
    [1]: https://www.destroyallsoftware.com/talks/wat

  • 거의 모든 것이 각본대로 일어났음
    이제 브라우저 기술에 완전히 기반한 또 다른 운영체제나 WASM OS를 기다리면 됨
    webOS와 Firefox OS는 적어도 시대를 20년 앞서갔다

    • 전혀 아님
      WASM은 그 명제를 확인해주는 게 아니라 반박함
      그 명제는 JavaScript 호환 소스가 미래의 기반이 된다는 것이고, 일반 JavaScript가 형편없는 기반임에도 호환 하위 집합을 효율적으로 해석하도록 고도로 최적화된 JavaScript 엔진이 미래의 범용 플랫폼이 될 수 있다는 주장임
      WASM은 저수준 대상이 되도록 설계된, JavaScript와 호환되지 않는 새로운 기반을 만들면서 이걸 근본적으로 거부함
      WASM이 그 명제를 확인한다고 하는 건, 모두가 브라우저 안에 Rust 인터프리터를 갖는 미래가 그 명제를 확인한다고 말하는 것만큼 이상함
      그렇게 주장한다면 결국 웹 브라우저가 어떤 언어로든 어떤 형태의 코드를 실행할 거라는 말일 뿐이고, 그건 이미 그러고 있음
      영상은 명백히 “놀라운” 가능성을 다루는데, 문자 그대로 평소와 다름없는 모든 가능한 미래와도 일치한다고 보는 건 말이 안 됨
    • ChromeOS를 언급하지 않은 기술적인 이유가 있나?
      순수한 호기심에서 묻는 것임
      그리고 내가 본 webOS 스크린샷들은 부활을 바라게 만들었음. 스마트 TV뿐 아니라 다른 곳에서도

  • Bernhardt의 2035년 시간표에서 이미 절반을 지났음
    JavaScript는 아직 죽지 않았지만, WebAssembly 안에서 자기 조사(弔辭)를 쓰고 있는 건 분명해 보임

    • 당신 가족의 여러 세대가 다 죽은 뒤에도 마지막 JS 명령은 아직 실행되고 있을 가능성이 큼
      전 지구적 핵전쟁이 일어나지 않는 한, JS가 대부분의 인간보다 오래 살아남는 쪽에 걸겠음
    • 매달 여러 고객사의 사이트를 검토하는데, 전부 어떤 형태로든 JavaScript를 쓰고 있음
      PHP처럼 절대 죽지 않을 것임

  • JavaScript는 역대 최고의 프로그래밍 언어임

답변달기