(번역) 유쾌하게 이상한 자바스크립트 생태계

원문 : https://fly.io/blog/js-ecosystem-delightfully-wierd/

자바스크립트가 이상하다는 말을 하려는 것은 아니지만, 분명 이상하긴 합니다. 그러나 이 글의 요점은 그게 아닙니다.

저는 자바스크립트 생태계가 어떻게 이상한지 설명하는 대신에, 자바스크립트 생태계가 왜 이상한지 설명하면서 글을 시작하려고 합니다.

역사적인 배경

10년 전만 해도 자바스크립트는 형편없었습니다. import 구문, 클래스, async, 화살표 함수, 템플릿 리터럴, 구조 분해 할당, 파라미터 기본값, 나머지/스프레드 연산자가 모두 없었습니다. 그리고 자바스크립트가 주로 구동되는 환경인 브라우저의 DOM도 형편없긴 마찬가지였습니다. JQuery가 등장하면서 그나마 나아졌습니다. 여전히 별로이긴 했지만, 그 당시에는 비교적 쓸만했습니다.

브라우저에서 실행되도록 자바스크립트를 번들링하는 것이 이상함의 첫 징조였습니다. 이 과정에서 소스 코드를 최소화하고 트리 셰이크를 수행하며, 코드 분할도 할 수 있게 되었습니다. 일반적으로 번들링 과정에서 많은 자바스크립트 코드를 입력값으로 읽어 들이며, 결괏값으로 한 개 또는 여러 개의 자바스크립트 소스를 생산합니다. 이는 실행 중인 코드가 자신이 작성한 코드가 아니라는 뜻입니다. 소스맵이 이에 도움을 줬습니다.

그러던 중 커피스크립트가 등장했습니다. 자바스크립트 코드를 작성하는 대신, 자바스크립트로 컴파일되는 언어를 사용할 수 있게 되었습니다. 이는 다른 언어와 동일하게 바이트 코드로 컴파일되는 Elixir 및 Kotlin과는 약간 다릅니다. 커피스크립트는 실제 자바스크립트로 컴파일됩니다. C++이 이런 방식으로 시작되었습니다.

그리고 2015년에 ECMAScript 6가 출시되었습니다. 이후 몇 년간 자바스크립트는 빠르게 발전했습니다. 대부분의 커피스크립트는 대체되었지만, 또 다른 문제가 생겼습니다. 자바스크립트 구동 환경이 한동안 구현체를 따라가지 못했기 때문에, 새로운 자바스크립트 문법을 해당 환경에서 지원하는 오래된 버전의 자바스크립트로 변환해주는 트랜스파일러 바벨이 등장했습니다. 현재는 자바스크립트 번들러/트랜스파일러로서 esbuild가 빠르게 유명세를 타고 있습니다.

이 과정에서 실제 머신 코드를 자바스크립트의 하위 집합으로 컴파일하는 emscripten이 등장했지만, 요즘 일반적으로 Wasm이 이 역할을 하고 있습니다.

최근엔 자바스크립트 혁신의 속도가 느려지고, 자바스크립트 구현은 이를 예전보다 잘 따라가고 있습니다. 따라서 번들러가 필요 없는 서버 사이드에서라면 특히 트랜스파일러의 필요성이 줄어들었다고 생각할 수 있습니다. 하지만 그런 일은 발생하지 않습니다. 그 이유는 흥미롭습니다.

더 이상 누구도 자바스크립트 코드를 작성하지 않습니다

네, 위의 제목은 확실히 과장됐습니다. 그러나 이제부터 사람들이 자바스크립트 코드를 작성하지 않는 여러 방법에 대해 설명해보겠습니다.

만약 레일즈 애플리케이션을 만든다고 하면, 루비 코드를 작성하게 됩니다. 장고 애플리케이션을 만들게 되면, 파이썬 코드를 작성합니다. Phoenix는 Elixir코드를 작성하고, Lavavel은 PHP코드를 작성합니다. 레일즈는 메타 프로그래밍을 사용하여 마법을 부린다는 이유로 많은 비난을 받았고, Elixir에는 매크로가 있지만 앞서 언급한 모든 것은 언어가 할 수 있는 범위 내에 머물러 있습니다.

그러나 자바스크립트는 다릅니다. 명목상 ECMA TC39에 의해 표준화되지만, Next.JS, Remix, 또는 Svelte와 같은 유명한 프레임워크를 사용한다면 ECMA TC39에 의해 표준화된 ECMAScript를 이용하여 코드를 작성하는 것이 아닙니다. 이와 관련된 4가지 예시가 있습니다.

• 거의 20년전에 ECMA 위원회는 XML을 데이터 형식으로 취급할 수 있도록 E4X를 표준화하였습니다. 이 기능은 인기를 잃고 더 이상 사용되지 않아서 아카이브 되었습니다. 몇 년 후, 페이스북(현 메타)에서도 비슷한 필요성을 느꼈고 JSX를 개발했습니다. JSX는 자바스크립트로 컴파일된다는 점에서 E4X와 다릅니다.
• ECMA TC39가 표준화하지 않은 한 가지는 타입 어노테이션입니다. 그럼에도 불구하고 마이크로소프트는 타입스크립트로 이를 구현했습니다. 이 역시 자바스크립트로 컴파일됩니다.
• 스벨트는 코드를 반응형으로 표시할 수 있게 의도적으로 자바스크립트 라벨 구문을 오용하는 자체 컴파일러가 있습니다.
• 여기에서 끝나지 않습니다. 번들러/트랜스파일러가 import 구문을 마주하면 이들은 해당 파일이 자바스크립트 또는 앞서 언급된 다른 변형이라고 가정하지 않습니다. 설정이 올바르게 되어있고 CSS 또는 PNG 파일을 가져오려는 경우 기꺼이 그렇게 할 것입니다.

저는 앞서 레일즈가 메타 프로그래밍 때문에 많은 비난을 받았다고 언급했습니다. 하지만 앞서 언급한 자바스크립트 언어의 "남용"에 대해서는 누구도 걱정하지 않습니다. 자바스크립트 생태계는 포괄 정당입니다.

[역주] 포괄 정당 (Big Tent party) : 많은 지지자를 끌어들일 수 있도록 다양한 그룹과 사상을 포함하는 정치 정당.

"use server";

최근 번들러를 남용한 사례는 리액트 서버 컴포넌트(RSC)입니다. express로 처음 시연되었으며, 현재는 Next.js에 채택되었습니다.

"use server"와 "use client"의 역할은 아무것도 하지 않는 유효한 자바스크립트 문이라는 점 외에 그 뒤에 오는 코드의 의미를 변경하는 것입니다. 이에 대한 평가는 엇갈리지만, 저는 그 뒤에 오는 코드의 의미를 변경하는 "use strict"의 정신에 매우 부합한다고 생각합니다.

JSX는 자바스크립트로 컴파일하는 경우가 많지만, Server React DOM API를 사용하면 HTML로 컴파일할 수 있습니다. RSC는 이와 다른 방식으로 태그된 JSON 스트림 형식으로 컴파일합니다. 모든 것이 매우 투명하지만, 이를 통해 서로 다른 스타일의 프로그래밍을 할 수 있습니다. 많은 사람들은 PHP, 심지어 레일즈와 비교하곤 합니다.

이러한 비교가 긍정적인 의미인지는 확실치 않지만, 제 관점에서는 매우 좋은 일입니다.

fly.io의 관점에서 Update(Refetch) Sequence를 활성화하는 RSC는 매우 흥미롭습니다. 우리는 지리적 분포를 통해 이점을 얻을 수 있는 프레임워크에 특히 강점이 있습니다. Elixir의 LiveView, 라라벨의 Livewire, 그리고 루비온레일즈의 Hotwire가 이에 해당합니다. 우리는 이러한 종류의 프레임워크가 성공하길 바라며, 그들이 잘 될수록 우리가 더 가치 있게 됩니다. 이제 리액트의 RSC도 이 목록에 해당됩니다.

다시 주제로 돌아가면, 이러한 기능(ex. 자바스크립트 언어 자체에 대한 변경)이 오직 번들러를 통해서 가능하다는 사실은 심오하지만, 감히 말하자면, 유쾌합니다.

또 다른 차원

Dan Abramov는 RemixConf에서 다른 차원에서의 리액트라는 주제로 발표했습니다.

영상 링크 : https://youtu.be/wobP9yhrmhQ

Dan의 발표에서 그는 90년대 후반에 서버에서 리액트가 처음 구현된 후 오늘날까지 발전해 온 대체 세계를 상상해보았습니다. 해당 강연에서 그는 윈도우즈 95 에뮬레이터와 인터넷 익스플로러(IE6)를 리액트와 함께 구동했습니다. 심지어 해당 운영 체제와 브라우저 조합으로 대부분의 기능을 관리했습니다.

이 발표에서 마음을 사로잡은 부분은 클라이언트측 폼 액션을 구현하기 위해 처음으로 use server를 사용하고, 이후 use client를 사용하여 서버에서 클라이언트 측 알림을 실행하는 부분입니다.

그는 이를 위해서는 차세대 라우터와 차세대 번들러를 필요로 한다고 말하며 발표를 마쳤습니다.

그리고 당신이 작성한 자바스크립트가 당신이 실행하는 자바스크립트가 아닐 뿐만 아니라, 좀 더 깊게는 자바스크립트조차도 아니라는 사실이 이 모든 것을 가능하게 합니다.