프론트엔드를 자주 다루지는 않지만, React가 주류가 되던 시점부터 복잡성이 커질 조짐이 보였음
다른 추상화 계층은 단순화되는 경향이 있지만, React는 그 기반 기술보다 훨씬 복잡한 추상화를 만들어냄
React만 아는 개발자들이 점점 더 높은 레이어로 쌓아 올리면서 과도하게 설계된 결과를 낳는다고 느낌
이제는 모두가 React가 기본값이라고 당연히 여기는 분위기가 더 문제라고 생각함
예를 들어 Shadcn이나 Radix는 React 전용 UI 라이브러리인데, 마케팅 문구만 보면 일반적인 UI 라이브러리처럼 보임
나는 15년 넘게 순수 JavaScript와 DOM API로 UI를 만들어왔음
규모가 커지면 결국 나만의 프레임워크를 만들거나 기존 프레임워크에 불만을 품게 됐는데, React는 그 문제를 어느 정도 해결해줌
React 자체보다 생태계의 과잉 복잡성이 문제라고 봄. React만 잘 다루면 여전히 즐겁게 쓸 수 있음
이건 React만의 문제가 아니라, 사람들이 현대 CSS를 배우려 하지 않는 게 더 큰 문제라고 생각함
Tailwind 같은 도구로 CSS를 우회하려고만 함. 나는 React로 상태를 관리하지만, 스타일링은 CSS로 직접 하는 걸 선호함
팀원들에게 CSS를 배우게 설득하는 게 가장 어려운 일임
추상화는 본래 복잡성을 감추는 철학적 도구여야 하는데, 요즘은 오히려 더 복잡하게 만드는 경우가 많음
나는 이런 “현대적” 프레임워크를 피하고, 가능한 한 기본 기술을 선호함
React의 핵심은 컴포넌트 추상화임
React는 단지 “박스”를 제공하고, 그 안에 무엇을 넣을지는 개발자가 결정함. 그게 React의 진짜 힘임
이 라디오 버튼 예시는 웃기면서도 인상적임
결과물은 기본 CSS 라디오 버튼과 구분이 안 되는데, 왜 이렇게 복잡하게 만드는지 의문임
큰 규모의 사이트 중 이런 불필요한 복잡성 없이 만들어진 사례가 있는지 궁금함
15년 전 비디오 협업 웹앱을 만들었는데, 프론트엔드는 거의 jQuery 기반의 바닐라 구조였음
지금보다 코드량은 많았지만, 인터페이스는 즉각 반응하는 속도감이 있었음 Takeoff 프로젝트 코드 참고 가능
“이 사이트는 어때?” — 바로 이 Hacker News 자체가 그런 예시일지도 모름
회사 규모가 커질수록 관리자는 표준화된 스택을 원함
“React를 선택해서 잘린 사람은 없다”는 말처럼, 안전한 선택이 되어버림
UI는 모두가 볼 수 있고 의견이 많기 때문에, 복잡성이 공공재의 비극처럼 커지는 구조임
개발자는 디자인 요구사항에 항상 반박할 수 있음을 기억해야 함
React Native에서 단순한 레이아웃 문제로 4시간을 낭비하던 개발자에게 “디자인을 조금 바꿔도 되냐”고 물어보라 했더니, 10분 만에 해결됨
나는 요즘 JS 없는 UI 프레임워크들(Pico.CSS, Skeleton, Bulma, Tailwind/daisyUI)을 선호함
CSS만 잘 써도 충분히 좋은 결과를 얻을 수 있음. 혹시 이런 접근 써본 사람들의 추천이 궁금함
2025년에 가장 큰 실수는 Shadcn을 선택한 것이었음
Radix를 계속 import하는 걸 보고 첫 번째 경고, radio 컴포넌트를 보고 두 번째 경고를 느낌
이미 프로젝트가 진행 중이라 포기하고 Copilot으로 수정했지만, 결과적으로 AI 의존도 마음에 들지 않았음
이전 POC는 훨씬 단순하고 효율적이었음. 언젠가 전부 바닐라 HTML로 다시 만들고 싶음
React+NextJS+Tailwind+Shadcn 조합은 복잡함의 끝판왕임
Remix나 React Router 7은 그래도 웹 표준에 가깝게 유지하려는 시도가 있었음
Tailwind에서 “이건 아니다” 싶었고, 친구들이 리팩터링 후에도 좋다고 하면 그때 다시 볼 생각임
사실 Tailwind와 React는 잘 맞지 않음
React에는 props 기반의 스타일링이 있는데 굳이 CSS 클래스 덩어리를 쓸 이유가 없음
접근성 중심이라면 Radix UI만 써도 충분함
브라우저의 <input> 요소, 특히 radio와 select는 커스터마이징이 어렵다는 게 문제임
기본 라디오 버튼은 모바일에서 사용성이 떨어짐
사실 네이티브 컨트롤도 CSS로 충분히 스타일링 가능함
모바일에서 어떤 문제가 있었는지 더 구체적으로 알고 싶음
글에서도 CSS로 라디오 버튼을 꾸미는 방법을 설명함. 그게 문제인가?
<label>로 감싸고 패딩을 주면 모바일에서도 충분히 쓸 만함
“select”만큼은 여전히 스타일링이 까다롭지만, 나머지는 꽤 유연하게 커스터마이징 가능함
대부분의 프로젝트는 좋은 의도로 시작하지만, 어느새 200줄짜리 라디오 버튼 코드와 7개의 import로 가득 차게 됨
이렇게 코드 부패(code rot) 가 시작됨
최근 daisyUI를 써봤는데 꽤 마음에 듦
순수 CSS 기반이라 브라우저의 새로운 기능(dialog 등) 을 잘 활용할 수 있음
하지만 접근성 측면에서는 부족함이 많음
예를 들어 Drawer는 포커스를 가두지 못하고, Accordion은 라디오 버튼을 JS 대체용으로 남용함
이런 이유로 Radix 같은 라이브러리가 복잡해질 수밖에 없음
글의 요지에는 공감하지만, 디자이너가 Figma에서 만든 정확한 스타일을 모든 브라우저에서 동일하게 구현하려면 바닐라 CSS로 가능한지 궁금함 Radix의 데모 같은 걸 완전히 재현할 수 있을까?
글쓴이 본인이 직접 등장해, “기본 예시를 단순히 Shadcn 스타일에 맞춘 것일 뿐, 원하면 얼마든지 커스터마이징 가능하다”고 밝힘
하지만 어디까지 완벽함을 추구할지 고민됨
약간의 시각적 불일치를 피하려고 수십 KB의 코드와 유지보수 부담을 추가하는 게 과연 가치 있는가?
남춘백(백남준)의 말처럼 “너무 완벽하면 신이 화낸다”는 생각이 듦
진짜 비용은 코드가 아니라 온보딩 시간임
새로 합류한 개발자가 Radix 기반의 47줄짜리 라디오 버튼을 이해하려면 몇 주가 걸림
반면 바닐라 방식은 하루면 만들고 20분이면 설명 가능함
물론 Figma나 Linear처럼 접근성과 키보드 내비게이션이 중요한 제품이라면 복잡성이 정당화됨
좋은 라이브러리는 내부 구조를 몰라도 쓸 수 있게 해야 하지 않을까 하는 의문이 있음
많은 댓글이 Shadcn을 비판하지만, 나는 오히려 컴포넌트 구조와 재사용성을 잘 장려한다고 생각함
Shadcn의 핵심은 “컴포넌트를 직접 소유하고 수정하라”는 철학임
이는 기존 UI 라이브러리와는 근본적으로 다른 접근임
Hacker News 의견들
프론트엔드를 자주 다루지는 않지만, React가 주류가 되던 시점부터 복잡성이 커질 조짐이 보였음
다른 추상화 계층은 단순화되는 경향이 있지만, React는 그 기반 기술보다 훨씬 복잡한 추상화를 만들어냄
React만 아는 개발자들이 점점 더 높은 레이어로 쌓아 올리면서 과도하게 설계된 결과를 낳는다고 느낌
예를 들어 Shadcn이나 Radix는 React 전용 UI 라이브러리인데, 마케팅 문구만 보면 일반적인 UI 라이브러리처럼 보임
규모가 커지면 결국 나만의 프레임워크를 만들거나 기존 프레임워크에 불만을 품게 됐는데, React는 그 문제를 어느 정도 해결해줌
React 자체보다 생태계의 과잉 복잡성이 문제라고 봄. React만 잘 다루면 여전히 즐겁게 쓸 수 있음
Tailwind 같은 도구로 CSS를 우회하려고만 함. 나는 React로 상태를 관리하지만, 스타일링은 CSS로 직접 하는 걸 선호함
팀원들에게 CSS를 배우게 설득하는 게 가장 어려운 일임
나는 이런 “현대적” 프레임워크를 피하고, 가능한 한 기본 기술을 선호함
React는 단지 “박스”를 제공하고, 그 안에 무엇을 넣을지는 개발자가 결정함. 그게 React의 진짜 힘임
이 라디오 버튼 예시는 웃기면서도 인상적임
결과물은 기본 CSS 라디오 버튼과 구분이 안 되는데, 왜 이렇게 복잡하게 만드는지 의문임
큰 규모의 사이트 중 이런 불필요한 복잡성 없이 만들어진 사례가 있는지 궁금함
지금보다 코드량은 많았지만, 인터페이스는 즉각 반응하는 속도감이 있었음
Takeoff 프로젝트 코드 참고 가능
“React를 선택해서 잘린 사람은 없다”는 말처럼, 안전한 선택이 되어버림
개발자는 디자인 요구사항에 항상 반박할 수 있음을 기억해야 함
React Native에서 단순한 레이아웃 문제로 4시간을 낭비하던 개발자에게 “디자인을 조금 바꿔도 되냐”고 물어보라 했더니, 10분 만에 해결됨
CSS만 잘 써도 충분히 좋은 결과를 얻을 수 있음. 혹시 이런 접근 써본 사람들의 추천이 궁금함
2025년에 가장 큰 실수는 Shadcn을 선택한 것이었음
Radix를 계속 import하는 걸 보고 첫 번째 경고, radio 컴포넌트를 보고 두 번째 경고를 느낌
이미 프로젝트가 진행 중이라 포기하고 Copilot으로 수정했지만, 결과적으로 AI 의존도 마음에 들지 않았음
이전 POC는 훨씬 단순하고 효율적이었음. 언젠가 전부 바닐라 HTML로 다시 만들고 싶음
Remix나 React Router 7은 그래도 웹 표준에 가깝게 유지하려는 시도가 있었음
Tailwind에서 “이건 아니다” 싶었고, 친구들이 리팩터링 후에도 좋다고 하면 그때 다시 볼 생각임
React에는 props 기반의 스타일링이 있는데 굳이 CSS 클래스 덩어리를 쓸 이유가 없음
접근성 중심이라면 Radix UI만 써도 충분함
브라우저의
<input>요소, 특히 radio와 select는 커스터마이징이 어렵다는 게 문제임기본 라디오 버튼은 모바일에서 사용성이 떨어짐
모바일에서 어떤 문제가 있었는지 더 구체적으로 알고 싶음
<label>로 감싸고 패딩을 주면 모바일에서도 충분히 쓸 만함대부분의 프로젝트는 좋은 의도로 시작하지만, 어느새 200줄짜리 라디오 버튼 코드와 7개의 import로 가득 차게 됨
이렇게 코드 부패(code rot) 가 시작됨
최근 daisyUI를 써봤는데 꽤 마음에 듦
순수 CSS 기반이라 브라우저의 새로운 기능(dialog 등) 을 잘 활용할 수 있음
예를 들어 Drawer는 포커스를 가두지 못하고, Accordion은 라디오 버튼을 JS 대체용으로 남용함
이런 이유로 Radix 같은 라이브러리가 복잡해질 수밖에 없음
글의 요지에는 공감하지만, 디자이너가 Figma에서 만든 정확한 스타일을 모든 브라우저에서 동일하게 구현하려면 바닐라 CSS로 가능한지 궁금함
Radix의 데모 같은 걸 완전히 재현할 수 있을까?
CodePen 예시 참고 가능
CSS만 추출해서 간단한 React 컴포넌트에 붙이면 충분함
약간의 시각적 불일치를 피하려고 수십 KB의 코드와 유지보수 부담을 추가하는 게 과연 가치 있는가?
남춘백(백남준)의 말처럼 “너무 완벽하면 신이 화낸다”는 생각이 듦
진짜 비용은 코드가 아니라 온보딩 시간임
새로 합류한 개발자가 Radix 기반의 47줄짜리 라디오 버튼을 이해하려면 몇 주가 걸림
반면 바닐라 방식은 하루면 만들고 20분이면 설명 가능함
물론 Figma나 Linear처럼 접근성과 키보드 내비게이션이 중요한 제품이라면 복잡성이 정당화됨
많은 댓글이 Shadcn을 비판하지만, 나는 오히려 컴포넌트 구조와 재사용성을 잘 장려한다고 생각함
Shadcn의 핵심은 “컴포넌트를 직접 소유하고 수정하라”는 철학임
이는 기존 UI 라이브러리와는 근본적으로 다른 접근임