JQuery

자바스크립트 이제는 너무 과하지 않나...

지난 10년간 매해 아니 매달 새로운 것들이 만들어지고 변화하고 개선해나가며 추상화 레어이가 쌓여가던 프론트엔드 씬이 이제는 좀 잠잠해져가네요

아울러 그간 만들어진 레이어들을 너무나 당연하게 사용되는 자바스크립트의 추상화 레이어들이 너무 과도하다는 식의 의견들이 자주 보이네요.

관련해서 자비스크립트가 너무 과도하다는 걸 보여주는 재미난 자료글이 있어 소개합니다. 아무기능도 없는 페이지에 자바스크립트가 10mb나 되는 사이트들도 있군요 ㅋ

최근 React도 컴파일러를 준비하고 있고 Svetle도 경량화를 추구했고, jQuery가 다시 4.0을 만들고 있고 htmx가 다시 재조명을 받고 있는 재미난 형국입니다.

앞으로 프론트엔드 씬이 또 어떻게 흘러갈지 흥미롭네요 ㅎ

https://tonsky.me/blog/js-bloat/

- jQuery, AngularJS, Vue를 거쳐 React에 이르기까지의 경험을 공유합니다.

---

오늘은 어떤 주제로 글을 쓸까 고민을 하다가, 예전에 생각해두었던 주제인 저의 기술 스택의 변화에 대해 이야기해보려고 합니다.

제 블로그를 초창기부터 살펴보신 분이라면 아시겠지만, 저는 2021년까지는 주로 Vue를 사용하다가 그 이후부터는 React를 사용하고 있습니다. 하지만 그전에는 jQuery와 AngularJS를 사용한 적도 있죠. 이처럼 시간이 흐르면서 사용하는 기술 스택에는 변화가 생기기 마련입니다.

엄밀하게 따지자면 AngularJS와 Vue는 프레임워크, jQuery와 React는 라이브러리라는 차이가 있습니다. 이들을 함께 포괄할 수 있는 단어가 마땅치 않아서 프론트엔드 UI 도구라고 이름을 붙여 보았습니다.

그래서 오늘은 이렇게 제가 4가지의 프론트엔드 UI 도구를 사용하며 겪은 경험에 이야기해보려고 합니다.

https://wormwlrm.github.io/2024/03/18/UI-Tools-History.html

1. 리액트 19 신규 클라이언트 훅
   New client-side hooks coming to React 19 https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html React 19에서 도입되는 새로운 클라이언트 측 훅을 살펴볼 수있습니다. use(Context)가 루프와 조건문 내에서도 호출될 수 있다는 점이 흥미롭습니다.
   

2. 버셀은 어떻게 버셀을 빌드하는가
   How Vercel Builds Vercel https://www.youtube.com/watch?v=-huwRrj_HA4&ab_channel=Vercel Vercel이 제품을 배포하는 방법을 설명합니다. 자신들의 제품을 개발 및 배포 파이프라인 전체에서 최대한 활용하려고 노력하는 도그푸딩(dogfooding)의 실제를 볼 수 있습니다.

3. 수백만 코드를 타입스크립트로 마이그레이션하기
   Migrating millions of lines of code to TypeScript https://stripe.com/blog/migrating-to-typescript
   Stripe는 Flow에서 TypeScript로 거대한 코드베이스를 마이그레이션하는 경험을 공유했습니다. 아주 거대한 리팩터링도 가능하다는 것을 보여주는 좋은 예입니다.
   

4. 새로운 프론트엔드 마스터 강좌 출시
   New Frontend Masters courses https://frontendmasters.com/courses
   여러 흥미로운 주제에 대한 짧은 강좌를 살펴볼 수 있습니다.
   

5. Locality of Behaviour 원칙
   https://htmx.org/essays/locality-of-behaviour/
   물리학에서는 온 국소성의 원리(principle of locality 라는 개념이 있습니다. 공간적으로 멀리 떨어져있는 두 물체는 절대 서로 직접적으로 영향을 줄 수 없다는 물리학 원리입니다. 한 물체가 다른 물체에게 영향을 미치기 위해서는 반드시 둘 사이의 공간이 매개되어야 합니다.
   "이 코드 조각은 무슨 역할을 하는가"라는 질문에 답할 수 있는, Locality of Behaviour 코드 구성의 원칙을 소개합니다. htmx 예제와 jQuery 예제를 통해 왜 htmx이 왜 인라인 구현(inlining implementation)을 선택했는지 확인해 볼 수있습니다.

jQuery는 더 이상 새로운 버전이 안 나올 줄 알았는데 4.0 베타 버전이 출시되었네요. 곧 출시된 버전 4.0에서는 IE 10까지 지원이 종료되고, 추후 출시될 버전 5.0에서는 IE 11까지 지원의 종료하면서 jQuery 마저도 IE 지원을 완전히 종료한다고 선언하였습니다. jQuery를 썼던 큰 이유는 IE와 타 브라우저 호환성 문제였는데 jQuery의 이러한 변화는 시사하는 바가 큰 것 같습니다.

📝 관련 포스트: https://blog.jquery.com/2024/02/06/jquery-4-0-0-beta

2006년에 출시되었던 jQuery는 한 때는 자바스크립트 개발이 곧 jQuery 개발이라고 여겨질 정도로 정도로 상당히 오랫동안 자바스크립트 생태계를 주름잡던 라이브러리입니다. 하지만 최근에는 React, Angular, Vue.js, Svelte와 같은 모던 자바스크립트 라이브러리에 밀려 주로 레거시(legacy) 코드에서나 미처 못해 쓰는 라이브러리로 전략하고 말았는데요.

jQuery 새로운 버전을 출시하더라도 얼마나 많은 프로젝트에서 업그레이드를 할 지는 의문입니다. 이미 컴포넌트 기반의 웹 프로그래밍이 대세가 된 상황에서 jQuery가 이번 업그레이드를 통해 과연 과거의 영광을 얼마나 되찾을 수 있을지 궁금해지네요.

Brian Birtles 님의 블로그를 의역/요약한 글입니다.

---

"2022년도 쯤에 썼던 글이지만, 2024년에도 유효한 내용이어서 끌올했습니다."

Mozilla를 퇴사한 후 웹 개발 전선에 뛰어들어 보니 놀라운 것들이 많았습니다. 웹 개발은 어렵고, 웹 개발자들은 사실 "개발잘알" 이었으며, 브라우저 개발자들이 비웃던 많은 프레임워크와 요행들이 아주 쓸만한 기술들이었습니다.

전부는 아니지만 많은 웹 개발자들이 웹 개발에 대한 선입견(?)을 가지고 있습니다. 브라우저 개발자였고 표준을 정의하는 개발자였던 저로써는 이해하기 힘든 내용이지만 몇 가지 공유하려고 합니다.

“웹 브라우저 개발자는 웹 개발에 대해 잘 안다”

웹 브라우저 개발자라면 웹 개발에 대해 1도 모르는게 없는 사람들이라고 생각하기 쉽습니다. 왜냐면, 브라우저를 만드는 사람들이니까요.

문제는, 웹 브라우저 만드는 게 정말 빡셉니다.

대부분의 브라우저 개발자들은 특정 영역을 아주 잘하는 사람들입니다. 그리고 대부분 C++이나 Rust와 하루 종일 씨름하고 있지 JavaScript는 거의 접할 기회가 없습니다. 심지어 엄청 큰 모노 레포지토리에 코드만 푸시 할 뿐, 그 이후의 일은 다른 사람이 맡아서 합니다.

그래서 브라우저 개발자들은 webpack과 씨름하는 것도, TypeScript 에러를 보는 것도, iOS Safari를 크롬처럼 길들이는 것도 (그 외 웹 개발자가 접하는 이슈 기타등등) 다 경험해본 적이 없을 겁니다. 그러니 브라우저 개발자들은 대부분의 웹 개발자들보다 찐 웹 개발에 대한 경험이 적습니다. 물론, 개발자 도구나 브라우저의 프론트엔드를 만드는 개발자들은 JS를 좀 더 많이 사용하기는 합니다. 다만, 이들도 현역 웹 개발자들의 문제를 모두 다 이해하는 것은 아닙니다.

웹 브라우저 개발과 웹 개발은 그냥 다른 영역입니다.

“웹 브라우저 표준을 정하는 사람들은 웹 개발을 정말 잘 아는 고수들 일거야”

표준을 정하는 건 법을 정하는 것과 같습니다. 둘 다 보이지 않는 수고가 많이 들어갑니다. 다만, 이 표준을 정하는 사람들도 대부분 브라우저 개발자들입니다.

웹 개발자 입장에서 하나의 표준이 무수히 많은 회의와 고수들의 정제된 토론 끝에 정해진다고 생각할 수 있습니다. 다만, 이 환상은 이 회의에 한번이라도 참여할 수 있다면 산산이 부서질 것입니다. 물론, 최선의 결과를 추구하는 것은 맞지만 때론 미팅에 참여한 누군가의 주도 아래 속전속결로 표준이 정해질 때도 많습니다. 심지어 자기 승진을 위해 표준에 넣을 기능을 배포하기도 합니다.

우선 욕만 하는 것 같아서 좀 덧붙이자면, 이 회의에 참여하는 개발자들은 모두 좋은 의도를 가진 선한 사람들입니다. 대부분 본인들과 속한 팀의 한계를 잘 알고 있고 그 속에서도 웹 개발자들의 의견을 최대한 수집하고 반영하고 소통하려고 합니다. 다만, 이를 잘 해내는 그룹은 아직까지 없었습니다.

두 번째로, 전 WHATWG 표준 (HTML과 DOM 표준)은 경험이 전무합니다. WHATWG는 표준을 정하는 방식이 비동기로 이루어지고 회의는 필요할 때만 한다고 알고 있습니다. 제 느낌 상 표준을 정하는 과정이 더 합리적인 쪽은 WHATWG였습니다. 하지만, 이들도 웹 개발에 대해 잘 알고 있다고 말하기 어렵습니다. 표준을 정하는 것과 웹 개발은 아주 다른 것이니까요.

“웹 개발자들은 웹 개발에 대해 잘 알 것이다”

브라우저 개발자 입장에서 새로운 기능을 배포하고 그 기능이 여기저기 기사로 실리고 개발자들이 X/트위터 같은 곳에서 인지도를 쌓는 것을 보면 흥분되고 보람찹니다. 이제 온 세상이 이 새로운 기능에 대해 알고 있다고 착각하기 쉽습니다.

현실은 그렇지 않습니다.

일본 Mozilla에서 개발하고 있을 때, 현직자 인터뷰를 한 적이 있습니다. 인터뷰 대상자들은 웹 개발자들이었습니다. 놀랍게도 그들은 10년 전에 배포된 CSS 기능도 모르고 있었고, 알려줬을 때도 뜨뜻미지근한 반응이었습니다. 이미 같은 기능을 jQuery와 WordPress로 잘 구현해서 쓰고 있었습니다.

오히려 개발자 도구에서 모바일 뷰를 볼 때, 옆에 아이폰 테두리가 안 뜨는 것에 대한 요구 사항이 있었습니다. 브라우저 개발자였던 저는 실망했지만 한편으로는 그들이 마주하는 현실을 깨닫게 되었습니다. 작은 스타트업에서 웹 앱 하나에 회사의 존망이 결정된다면, 새로운 웹 기능을 하나 하나 뜯어보고 있을 시간이 없습니다. 그들은 속도전을 하고 있고 하나라도 빠르게 개발하고 배포해야 하기에 이미 검증된 기술을 쓰지 새로운 기술을 실험해 볼 여유 따윈 없었습니다.

“브라우저는 SPA를 위해 만들어지지 않았다”

이 주장은 아마 초기부터 브라우저는 네트워크를 통해 컨텐츠를 로딩하고 점진적으로 배치한 후 렌더링하는 형태로 작동했기에 이쪽으로 최적화가 잘 되었고 SPA 처럼 동적으로 페이지를 조작하는데는 비효율적이라고 생각할 수 있습니다. 20년 동안 브라우저 개발자로 일해본 경험을 빗대어 보자면, 이제는 더 이상 유효한 주장이 아닌 것 같습니다. Firefox의 개발자 도구는 React와 Redux로 작성된 SPA입니다. 브라우저가 복잡하고 동적인 SPA에 최적화되지 않았다는 주장은 어불성설입니다.

물론, 모바일 브라우저에서 SPA를 위한 최적화가 되지 않았다 - 라는 주장은 어느 정도 수용할 수 있습니다. Firefox도 모바일에서는 성능을 위해 기존 HTML로 렌더링 하던 브라우저를 네이티브 브라우저로 바꿨기 때문입니다. 물론, 제가 해당 작업을 진행하지는 않아서 왈가왈부 할 입장은 아니지만 당시 기술 블로그에 따르면 앱 시작 시간 단축과 네이티브 제스쳐를 지원하기 위해 변경한 걸로 알고 있습니다.

“SPA는 결국 MPA로 대체될 거야”

View transition 표준에 참여했던 저로서는, 개인적으로 MPA를 흥미롭게 보고 있습니다. View transition은 사실 SPA를 염두에 두고 만들었지만, MPA도 유용하게 쓸 수 있습니다.

아무튼, “SPA는 결국 MPA로 대체될 거야”라는 주장으로 돌아와보면 사실 우리가 말하는 MPA가 뭔지 모르겠습니다.

제가 이해하기로 SPA는 하나 또는 두 개의 DOM 트리를 아주 오랫동안 JS로 조작하면서 앱을 만드는 형태고, MPA는 페이지 이동을 통해 서버에서 새로운 HTML을 받아오면서 앱을 조작하는 형태로 알고 있습니다. 이 네비게이션은 항상 최상위 네비게이션일 필요는 없고 iframe 같은 요소를 사용하고 있을 수 있습니다.

이 개념이 맞다면, 포토샵, 슬랙, 구글 맵, 피그마 같은 웹 앱들이 MPA로 어떻게 전환 될 수 있는지 상상이 안 갑니다. 이런 앱들을 MPA로 전환할 수 있다고 한들 - 개발 복잡도만 올라가고 사용자에게 실질적인 이득은 거의 없거나 SPA와 똑같을거라고 생각합니다.

지금 제가 만들고 있는 웹 앱도 MPA를 고려하지 않은 건 아니지만, 도저히 MPA로는 답이 안나와 SPA로 만들고 있습니다. “모든 앱이 MPA가 될거야” 라는 주장은 놀랍기만 합니다.

“모든 웹 사이트는 JavaScript 없이 돌아갈 수 있어야 해”

JavaScript 없이 웹 사이트 기능을 다 지원할 수 있다면 표준을 정말 잘 따르는 것이고 사실 이렇게 하기 위해 노력해야 하는 것은 맞습니다. 현존하는 모든 브라우저를 지원할 것이고 초기 렌더링을 막는 JS도 로딩할 필요가 없다는 뜻이니까요.

다만, 앞서 말한 것처럼 피그마나 포토샵이 JS 없이 어떻게 돌아갈지 상상이 가지 않습니다. 그리고 많은 사람들이 JS 때문에 접근성이 잘 고려되지 않는다고 생각하지만, 때론 접근성 기능을 넣는데 JS가 필요할 수도 있습니다.

Mozilla에 있을 때 배운 것 인데, Tab으로 요소를 이동한 뒤 화살표로 해당 요소 내에 있는 항목을 순회하는 것은 JavaScript가 없으면 구현할 수 없습니다. 심지어 저는 어떤 웹 사이트들은 JS를 더 (잘) 썼으면 좋겠습니다.

“웹 개발에서 빌드 과정은 필요 없다”

최근에 본 글 중에 이 같은 주장을 한 것을 봤습니다. 한평생 컴파일 언어로만 개발해온 저로서는 이해하기 힘든 부분입니다. 컴파일러는 대단한 기술입니다. 구닥다리 같은 내 코드를 몇 단계의 과정을 거쳐 컴퓨터가 수행할 수 있는 아주 효율적인 코드로 만들어주니까요.

물론, JavaScript 언어의 불완전함을 알고 있습니다. 컴파일 하기 까다로운 것도 이해합니다. 하지만, JavaScript 컴파일 단계도 분명 더 개선할 점이 있습니다.

이미지 에셋이나 정적인 HTML은 미리 빌드하는데 동의하는 웹 개발자들이, 코드를 정적으로 컴파일 해놓는 것에 반대하는 것은 저로서는 이해하기 조금 어렵습니다. 미리 컴파일 해놓을 수 있는데 왜 굳이 연산과 I/O를 런타임에서 하려고 하는 걸까요?

아무튼, 2024년에는 Rust/WASM 프레임워크들이 좀 더 각광을 받아서 이쪽 분야에서 두각을 나타냈으면 좋습니다.

“제 블로그가 웹 개발의 전형적인 예시”

브라우저 개발자에서 웹 개발자로 돌아온 저에게 웹 개발은 미지의 세계였습니다. 웹 개발자들이 주장하는 대부분의 것들이 놀라웠던 이유는 대부분 제가 직접 경험해보지 못했기 때문입니다.

Mozilla를 퇴사하고 지난 4년 간 저는 웹 개발자로 어떤 웹 앱을 만드는데 많은 시간을 할애했습니다. 그리고 동시에 이 블로그를 개발했습니다. 신기하게도, 이 블로그와 제가 만들고 있는 웹 앱은 웹 개발이라는 세계에서 양극단에 있는 것 같습니다. 서로 겹치는 기술이 없어요.

제가 하고 싶은 말은, 당신이 경험하고 있는 게 웹 개발의 전부는 아닐 겁니다. 웹 개발은 너무나 큰 세계고 우리의 상상을 아득히 뛰어넘는 곳입니다.

---

저도 제가 경험한 개발 세계는 극히 일부라고 생각하는데 비슷한 생각을 풀어낸 글이라 공유합니다. 비단 개발 뿐만 아니라 대부분의 영역이 여러 사람들의 집단 지성으로 이루어 졌을텐데, 한 개인이 그 영역을 다 이해하기란 불가능하다고 생각합니다. 물론 사람이 아니라 ChatGPT 같은 LLM이라면 가능할 수도? 😎

원글: https://birtles.blog/2024/01/06/weird-things-engineers-believe-about-development/#my-blog-is-representative-of-web-development-at-large