React

(번역) ‘Create React App 권장을 Vite로 대체’ PR 대한 Dan Abramov의 답변

Create React App 대신 Vite 의 사용(Vite 에도 CRA 처럼 리액트 앱 초기 셋팅을 해주는 기능이 있다)을 권장하는 게 어떻겠냐는 제안에, 유명한 개발자이자 React 컨트리뷰터인 Dan Abramov 가 답변한 내용을 번역한 글.

길긴 하지만 React 측에서 CRA 를 어떻게 생각하고 있는지, 건전한 React 생태계를 위해서 어떻게 고심하고 있는지 엿볼 수 있다.

대부분의 리액트 앱에서 프레임워크로 시작하는 것이 가장 좋은 방법이라면 어떤 프레임워크를 권장해야 할까요? 하나를 골라야 할까요? 어느 것을 선택할지 어떻게 결정하나요? 시간이 지나면서 정체된다면요? 더 민감한 인센티브에 대한 질문도 있습니다. 인기 있고 잘 관리되는 프레임워크에는 직간접적으로 이와 관련된 일종의 상업적 제품이 있는 경우가 많습니다. 이런 제안은 해당 프레임워크의 개발에 자금을 지원할 수 있습니다. 하지만, 예를 들어 특정 호스팅 플랫폼에서만 작동하는 제품으로 사람들을 밀어붙이는 것을 피하고 싶습니다.

Why React isn't dying

React 보다 더 좋은 경쟁자들이 많이 나오는데 왜 React 는 죽지 않는가? 에 대한 의견을 정리한 글.

글쓴이의 의견을 간단히 요약하자면

  1. 첫번째로는 많은 회사가 React 를 쓰기 때문애 그로 인해 많은 개발자들이 React 를 배우고 사용하고, 많은 개발자들이 React 를 배우고 사용하기 때문에 많은 회사가 React 를 쓴다는 상호 의존적인 상태 때문이며
  2. 두번째로는 이미 좋은 생태계와 커뮤니티가 잘 형성되어 있기 때문이다.

두 이유와 더불어 React 는 "충분히 좋은 상태"이기 때문에 상대적으로 기능적/기술적 우위를 갖는 라이브러리들이 React 를 밀어내지는 못하고 있다는 것이다.

나도 대체로 동의한다.

또한 React 가 당분간 이런 위명을 유지하겠지만 그렇다고 새로운 기술에 대한 도전을 포기할 필요는 없다고 말한다.

That doesn't mean finding new tech isn't worth trying. We need innovation. It might happen in React, or it might happen outside of it.

그 또한 동의한다.

리액트에서 이벤트 위임이 필요한가?

이벤트 위임은 작은 하위 엘리먼트들에 일일이 이벤트 리스너를 달지 않고, 상위의 하나의 엘리먼트에만 이벤트 리스너를 달아서 하위 엘리먼트의 이벤트까지 처리하게 하는 것을 말한다. 성능적인 면에서 득이 많아서 사용해야 했던 개념으로 React 를 사용하기 전에는 많이 사용했다.

React 를 사용하게 되면서 컴포넌트 단위로 구현하다보니 자연스럽게 이벤트 위임도 잊고 있었는데, 본문의 글쓴이는 React 상에서 이벤트 위임을 쓰는 게 좋은 건지 아닌지 궁금했던 모양이다.

결론은

여기서 알게 된 사실은 리액트는 우리의 이벤트 핸들러를 DOM 노드에 부착하지 않고 document 레벨에서 이벤트를 위임하여 처리한다는 것.
하지만 17 버전부터는 document 대신 root 태그에서 이벤트들을 위임한다.
결과적으로 리액트는 우리의 이벤트 핸들러를 실제 DOM 노드에 부착하지 않고, root 태그에서 이벤트를 위임하여 처리한다.

React 는 이벤트 위임을 알아서 잘 처리하고 있기 때문에

내가 받아들여야 할 것은 이벤트 위임을 사용해야 하냐는 질문에 댄 아브라모프는 눈에 띄는 성능 상의 이점을 제공하지 않는다 라고 답변을 했다는 점!

이벤트 위임을 쓸 필요가 없다고 한다.

본문에 들어가면 Dan Abramov 가 어떻게 대답했는지, 이벤트 위임을 썼을 때와 쓰지 않았을 때 성능 차이가 어떤지 등등 좀 더 상세한 내용이 담겨있다.

Am I Overreacting? Or is React Over-Reacting?

글쓴이의 생각의 흐름은 다음과 같다.

  • 500 개의 엘리먼트를 렌더링하면서 퍼포먼스 측정해보았음
  • 부모 앨리먼트의 state/prop 이 수정될 때마다 500 개가 모두 리렌더링 됨, 리렌더링되는 퍼포먼스가 너무 안 좋음 (대략 ~10ms)
  • 공식 문서에서는 엘리먼트가 많을 때 가상 목록 등을 사용하라고 제안하지만 백여 개일 때 가상 목록을 쓰는 건 이해할 수 없음. 그리고 가상 목록은 상황에 따라 코드의 복잡도만 올릴 뿐 그다지 효과적이지 않음.
  • useCallback 등의 훅을 사용하는 등의 방법으로도 어느정도 해결됨. 이게 필수가 아니라고 공식 문서는 말하지만 (과최적화 이슈) 퍼포먼스를 염두에 둔다면 그냥 필수적으로 쓰는 게 좋다고 생각함
  • 이럴 거면 React 왜 쓰냐? 그냥 바닐라 자바스크립트 쓰지? (?????)

비약과 급발진의 대가라고 할 수 있겠다.

일단 자신의 주장을 위해 사용한 예제들은 전혀 실제적이지 않아 와닿지도 않고, 성능에 너무 초점을 맞춘 나머지 트레이드오프에 대해서는 고려할 생각조차 없어보인다. React 가 바닐라 자바스크립트보다 성능적으로 좋지 않은 것은 당연한데, 그것을 조금 포기함으로서 얻는 이득들 (생산성, 가독성, 유지보수성 등) 은 안중에도 없는 것 같다.

글을 읽어보면 React 실무 경험이 많은 것 같지 않고, 다른 프로그래밍 경험을 통해 "성능에 목 맨" 스타일이라는 느낌이 든다.

안 좋은 사고 전개란 이런 것이다, 라는 의미로 추천이다.

프론트엔드

🎥 우아한형제들의 전사 디자인 시스템, 배시시

우아콘2022세션.

영상에 의하면 배민은 컴포넌트는 물론이고 컴포넌트에 사용되는 테마값(색상/글꼴/여백 등)까지 npm 패키지로 생성해서 관리하고 있다고 한다. 디자이너를 위한 전용 어드민이 있기 때문에 디자이너들은 테마값을 쉽게 관리(추가/수정/삭제)할 수 있고, 심지어 각각의 테마값이 어느 컴포넌트/화면/프로덕트에 쓰였는지 개발자의 도움 없이도 쉽게 알 수 있다.

개발자 입장에서는 테마값 패키지를 프로젝트에 설치해서 사용하기만 하면 되므로, 테마값 유지보수에 신경 쓸 필요가 없다.

정말 영상에 나온대로 잘 굴러가고 있다면 놀랍고 부러운 시스템임에 분명하다.

Etc

Reference Counting과 Mark and Sweep

가비지 컬렉션의 동작 방식인 Reference Counting 과 Mark and Sweep 에 대해 정리한 글. 어렵지 않은 내용이므로 아는 내용이 아니라면 가볍게 읽어보자.

CTO가 커리어를 걸고 비트 레벨까지 내려가서 DB를 해킹했던 이야기

CockroachDB 에 장애가 발생하고 업체의 서포트 엔지니어는 복구가 불가능하니 마지막 백업본으로 롤백하라고 권장하는 상황에서, 직접 DB 의 로우 데이터와 소스코드를 까보면서 복구한 경험을 공유하는 글. 어렵긴 하지만 백엔드/인프라/데브옵스 관점에서 흥미로운 내용이다.