자바스크립트 프레임워크 역사 (3)

Primal Skill Programming 블로그의 요약/번역 글입니다 --- TypeScript와 어딘가 이상한 Type 덧대기 CoffeeScript와 유사하게 TypeScript도 source-to-source 프로그래밍 언어입니다. JS 프레임워크는 아니지만 JS 프레임워크 발전에 크게 기여한 것은 맞습니다. 물론, 마이크로소프트와 기타 다른 수많은 개발자들의 주장이지만요. 오해 하지 마시길 바랍니다. 프로그래밍 언어에서 타입 세이프는 중요합니다. 하지만 전 애초에 다이나믹 타입이 버그가 아닌 기능으로 허용된 언어에 굳이 타입을 위에다가 덧대는 것이 맞는지 잘 모르겠습니다. 이 맥락에서 DHH (터보 개발자)가 Turbo에서 TypeScript를 사용하지 않기로 한 결정에 어느정도 동의합니다. TypeScript가 공개되기 전, JavaScript는 단순히 정적 타입의 부재 뿐만 아니라 큰 프로젝트에서 제대로 관리하기 어려웠습니다. 특히 디버깅과 유지 보수의 복잡도가 프로젝트 크기에 비례했습니다. TypeScript는 이런 대규모 프로젝트를 “잘” 관리할 수 있도록 JS에는 없는 interfaces, enum types, optional parameter 등의 기능을 제공했습니다. 또한, TypeScript는 개발 툴도 제공하여 정확한 자동 완성이나 리팩토링 등이 더 수월하게 해주었습니다. 하지만, TypeScript는 여전히 JS위에 추가된 레이어입니다. 즉, 불필요한 개발 복잡도와 오버헤드를 유발하며 이는 몇 몇 개발 팀이나 프로젝트에는 안 맞을 수도 있습니다. TypeScript가 다방면으로 유용한 것은 맞지만, 새로운 개발 언어의 syntax, 규칙, 표준 방식 등을 배워야 하는 비용이 발생합니다. 심지어 다른 JS 프레임워크 들이 Type을 어떻게 규정했는지도 원치 않아도 알아야합니다. 이는 작은 규모의 프로젝트나 팀에게 장애물이 될 수 있습니다. TypeScript는 개발자들로 하여금 변수, 함수 반환 값, 인수 등에 타입 명시를 요구합니다. 이는 큰 프로젝트에서 코드의 가독성을 높여주고 디버깅 하기 쉽게 해주지만, 개발 속도에 영향을 미칠 수 있습니다. 즉, 작은 규모의 프로젝트에서는 TypeScript를 버리고 JS로만 개발하는 것이 효율적일 때도 있습니다. 결론적으로 TypeScript 덕분에 JS에도 선택적으로 정적 타입을 사용할 수 있게끔 논의가 진행되고 있으니 감사할 따름입니다. 행복하고 좋은 Svelte 많은 개발자들이 JS 생태계에 지쳐가고 있을 때 Svelte가 등장했습니다. Svelte는 기존 JS 프레임워크를 사용하면서 생기는 불필요한 요소들을 제거하고자 했습니다. 또한, 단순한 사용법으로 러닝 커브를 낮추고자 했습니다. React나 Angular가 좋은 툴은 맞지만 이런 프레임워크의 복잡성은 초심자들이 이해하기 어려울 수 있습니다. 반면, Svelte는 직관적이고 단순한 방식을 채택했습니다. 개발자들은 기본적인 HTML, CSS, JavaScript 지식 만으로도 Svelte를 빠르게 익힐 수 있습니다. Svelte는 HTML, CSS, JS 같은 코드를 파싱하는 파서의 느낌보다는 이것들을 컴파일하는 새로운 개발 언어라고 볼 수도 있습니다. Svelte가 다른 새로운 개발 언어라고 생각하면 이는 HTML, CSS, JS와 유사하지만 다른 언어라고 생각할 수 있습니다. 하지만 그렇지 않습니다. 결국 Svelte로 작성된 모든 것은 HTML, CSS, JS로 표현됩니다. 이는 Svelte가 devDependencies로 들어가는 이유이자 React와는 다르게 프로덕션에서 Svelte 코드가 필요없는 이유기도 합니다. 기존 JS 프레임워크들은 클라이언트 브라우저에서 JS 번들 전체를 로딩하고, 파싱하고, 컴파일 하는 과정을 거쳐야 사용자가 상호작용 할 수 있습니다. 이 과정은 때로는 느리며 사용자 경험에 안 좋은 영향을 줍니다. 특히 네트워크가 제한된 환경이거나 모바일의 경우 그렇습니다. SvelteJS는 이 느린 프로세스 중 일부를 빌드 과정에서 처리합니다. Svelte는 React 보다 좀 더 색채가 짙습니다. Svelte를 작성하는 방식이 어느 정도 정해져 있지만 이는 꼭 나쁜 것 만은 아닙니다. SvelteKit에서 이 색채가 상당히 도드라집니다. 또한, Svelte는 클라이언트 사이드 개발에서 Multi-Page Application을 다시 대두 시키려고하는 프레임워크 중 하나입니다. 이전까지 MPA는 이제 아무도 쓰지 않는 옛날 기술로 취급되어 왔습니다. 아무렴 Svelte는 현재 말도 많고 탈도 많은 프론트엔드 생태계에 한 줄기 빛이 되고자 합니다. Htmx 두둥등장! HTMX를 들어본 적 없다면 그럴 수 있습니다. 최근에 나온 JS 프레임워크이니까요. CoffeeScript, TypeScript, Svelte 모두 JS를 JS와 유사한 무언가로 작성한 뒤 다시 JS로 변환하는 방식으로 문제를 해결하려고 했다면 HTMX는 JS를 안 쓰는 방식을 선택했습니다. HTMX는 개발자들이 AJAX, CSS Transitions, WebSockets, JS Events, Server Sent Events를 JS 없이 HTML에서 접근 가능하도록 해줍니다. (사실 JS 조금 있음). HTMX는 새로운 방식으로 정적인 HTML을 동적인 웹 앱으로 만들어 줍니다. (완전 새로운 건 아님). 다른 JS 프레임워크와는 다르게 HTMX는 기존 JS가 많이 가지고 있던 책임의 균형을 살짝 전환해 좀 더 단순한 웹 개발 방식을 추구합니다. 개발자들이 간단한 UI 상호작용은 HTML에서 구현할 수 있도록 적절한 특성들을 제공해 JS 의존도를 낮춥니다. 어떤 이들은 이를 “directives”라고 부르기도 하더군요. 이는 HTML과 CSS가 웹 앱의 근간이 되며, 필요 시에 상호작용 요소를 JS로 구현해서 JS를 최대한 가볍게 유지하는 “점진적 향상”의 개념을 다시 상기 시켰습니다. 심지어 HTMX는 엄청 단순합니다. 엄청 단순해서 길고 긴 프론트엔드 생태계 터널 끝에 한 줄기 빛이 HTMX 라는게 짜증 날 정도입니다. HTMX는 결국 터널에 들어갈 필요도 없이 아주 오래전부터 존재한 기술이니까요. 백엔드 개발 언어와 함께 개발자들은 웹 앱을 자유롭게 수정하며 원래 있어야 할 백엔드 단에서 상태 관리를 할 수 있으며, 다이나믹하고 반응적인 UI 역시 원래 있어야 할 프론트엔드 단에서 처리할 수 있게 되었습니다. 결과적으로 이는 좋은 방향입니다. 왜냐하면, 젊은 개발자들이 “모던 JS 프레임워크” 없이도 프론트엔드 개발의 기쁨을 알 수 있게 되니까요. 그렇다고 React, Vue, Angular, Svelte 가 하루 아침에 사라지지는 않을 겁니다. 거론되지 않은 것들 Alpine, Astro, Babel, Bun, Dojo, EmberJS, Esbuild, ES6, Express 등등 웹 개발에 기여했지만 거론되지 않은 무수히 많은 라이브러리, 프레임워크, 툴 들이 있는 것을 알고 있습니다. 그 이유는 1) 하나의 글에 담기에는 너무 많고, 2) 많은 기술들이 근간이 되는 사상을 공유하고 있고, 3) 개인적으로 이들을 논할 만큼 경험하지 않았기 때문입니다. --- (끝) 원글: https://primalskill.blog/a-brief-history-of-javascript-frameworks