React를 쓰기 위해 필요한 비용과 순수 JS로 개발하기 위해 필요한 비용은 거의 유사하다.

이 글에서는 우리가 React를 쓰는 이유에 대해서 설명하고, 이를 순수 JS를 통해 충분히 해결할 수 있다는 것을 설명한다.

React를 사용하는 이유와 반박

정립된 컴포넌트화를 제공

이건 사실이다. 순수 JS를 통해 컴포넌트화를 하는 여러 방법 중, 정석이라고 여겨지는 방법이 아직 없다.

사용자에게 노출 중인 값 변경 시, 값을 노출하는 요소에 대한 관리 불필요

React에서 State를 사용하는 방식은 2000년대 초기 웹 개발 경험과 유사하다. 화면에 표시되는 데이터가 변경될 때마다 전체 페이지를 다시 로드(새로고침) 한다. 다만, React는 전체 페이지를 다시 로드하는 대신 변경된 컴포넌트만 효율적으로 로드한다.

씨발 해당 값 쓰는 모든 요소 다 querySelector로 찾아서 변경 해줘 씨발 그거 요소 개수 얼마나 된다고.

JS의 SSR

이제 순수 JavaScript에서 SSR을 할 수 있다. (예시 코드 필요)

.map함수 따위를 활용한 엘리먼트 나열 최적화

기억 안 남.

HTML in JS

JavaScript에서 좋은 성능으로 HTML 코드를 사용자에게 뿌려줄 수 있다. (예시 코드 필요) (React랑 성능 비교 필요)

JS로 코드 다 짜려고 하면 장황해짐

씨발 안 장황하게 쓰려면 jQuery 쓰던가, document.querySelector vs $ 22배 차이 나는데도 jQuery 쓰는 인간들 존나 틀딱 취급해 놓고선 장황타령 하는 새끼들 보면 공중제비를 22바퀴 돌아버릴 것 같다.

결국 시장에서 jQuery가 스러져 가듯이, 코드를 장황하게 작성하는 것쯤은 사람들에게 금방 익숙해진다.

React 문제점

cleanup 함수가 return

아무리 편의성을 위해서라지만, return 함수가 cleanup 함수로 이용되는 것은 지나치게 비직관적이지 않은가.

라이브러리의 제한

React에서 라이브러리를 쓰기 위해서는 React에 종속적인 라이브러리만을 사용할 수 있다.

아무리 React 시장이 거대해서 웬만한 라이브러리를 제공한다 한들, 역사적인 라이브러리를 모두 활용할 수 없다는 것은 개발 자유도를 심각하게 침해한다고 볼 수 있다.

결론

씨발 내가 무슨 보모도 아니고, 애새끼 관리하는 것 마냥 생명 주기 관리하는 게 씨발 그냥 말이 안 된다.

React에서 컴포넌트 생명 주기를 관리하는 데 드는 개발 시간과 노력이, 순수 JavaScript로 직접 DOM 요소를 조작하는 알고리즘을 짜는 데 드는 비용과 별반 차이가 없다.

그럼 씨발 라이브러리도 더 자유롭게 쓸 수 있고, 러닝 커브도 훨씬 낮은 JavaScript 쓰는 게 이득이다.