Hacker News 의견

• React가 기본값이 되어버린 게 아니고, 워낙 효과적이고 잘 설계돼서 사실상 표준이 되었음과 동시에 이제는 악역이 되어버렸음이라고 생각함
  React가 혁신을 늦추고 있다는 주장은 굉장히 어이없음이라고 느낌
  React는 수많은 "나도 끼워줘" 식 프레임워크와 혼란스러운 설계들 속에서 사실상 유일하게 안정적이고 합리적인 선택지임

  • 겸손하게 동의하지 않음
    나는 복잡한 인터랙티브 앱은 React로 제작해본 적 없고, 이전에 팀원들이 이미 React를 선택해둔 간단한 사이트만 몇 번 만들어봤음
    그 결과 React는 오히려 단순한 사이트에서는 확실히 축소가 잘 안 됨
    간단한 로그인 페이지라면 DOM에 직접 상태를 저장하고 <form>만 써서 값 보내면 되고, 비밀번호 표시/숨기기는 JS만 조금 쓰면 됨
    하지만 React로 구현하려면 JSX, hooks, 컴포넌트 생명주기, 개발 빌드, 프로덕션 패키징 등 배워야 할 게 너무 많음
    Vue나 Alpine 등 다른 프레임워크는 "점진적"으로 써볼 수 있고 CDN만으로 바로 시작할 수도 있음
    React도 점진적이라고 주장하지만, JSX 특성상 빌드-컴파일 과정이 필수라서 CDN으로 바로 시작하는 방법이 공식 문서에 없음
    억지로 불가능하진 않지만 결국 컴파일러까지 클라이언트에 함께 보내야 하므로 현실적으로 최악임
    대부분의 사이트가 Facebook, Spotify, Netflix 급이 아닌데(심지어 Netflix도 React에서 멀어진다 발표), React가 그렇게 효과적이며 잘 설계된 것이라는 주장은 동의하기 어려움

  • React가 12년 전에 등장했을 땐 진짜 혁신적이었음
    하지만 곧 비슷한 프레임워크가 여럿 나왔고, 이후로는 "그럭저럭 쓸만한" 수준에 머물렀지 혁신의 중심은 아니었음
    이제는 구식 Virtual DOM 설계 문제를 해결하면서 점점 boilerplate가 늘어나고, 최신 대안들 대비 매력이 떨어짐

  • 글 제목의 의미가 반전되어 있음
    실상은 "혁신"이 React 공식(성공 공식)을 따라잡지 못하고 있다고 느끼는 중임

  • 혁신이 얼마나 필요하냐에 대한 질문도 가져봄
    사실 반복, 개선이 더 낫고 저렴한 경우가 많음

• 나는 이 글과 2015~16년 다원주의적 시각이 마음에 듦
  "Svelte로 별도의 소규모 유즈케이스를 만들자"라고 팀에 말하고 싶지만, 평가 체크리스트가 글의 주장과 정반대로 작용함
  성능: 99%의 앱에선 차이를 체감하지 못하니 결국 React 선택
  팀 숙련도 및 러닝커브: 다들 React만 알고, Qwik 등은 모름. 자연히 React 선택
  확장성, 운영비용: 큰 차이 없음
  에코시스템: React가 훨씬 크고 안정적임. React 선택
  게다가 요즘 AI 툴이 React에 대응이 잘 되고, 개발자들도 거의 저절로 React 중심으로 학습하고 있음
  결국 React가 합리적 선택지가 될 수밖에 없음

• Web components가 이 프레임워크 과점 상황에서 탈출구가 된다고 생각함
  React를 제외한 모든 프레임워크가 web components를 적극 지지해, 각각이 자체적인 React 생태계를 다시 구축할 필요 없이 호환 가능한 컴포넌트와 유틸리티 에코시스템을 활용하는 게 답임
  많은 사람들이 web components를 프레임워크 경쟁상대로 보지만, 사실은 컴포넌트 구현체와 브라우저 간 인터페이스를 정의해 상호운용성과 신뢰성 높은 조립을 가능케 함
  이런 저수준 API 위에 다양한 방식의 컴포넌트 제작법(빌드리스, JSX, 탬플릿, 커스텀 문법, 컴파일러 등)과 다양한 컴포넌트 조립 및 상태관리 혁신도 여전히 이뤄질 수 있음
  "우리 새 Flugle 프레임워크는 어떤 프레임워크와도 잘 돌아가고 자동화 도구도 풍부!"라고 자랑해야 React 독점체제를 극복할 수 있음

  • 나도 boilerplate를 피하기 위해 wrapper를 이용해 web components를 사용하고 있음
    이 방법으로 80%의 web component 기능을 아주 적은 노력으로 얻을 수 있었음
    관련 GitHub: ZjsComponent, 예전 HN 논의 링크도 참고 (HN 토론)
    완벽하진 않지만 나에겐 이보다 쉽고 빠르게 새로운 HTML 컴포넌트를 만드는 방법이 없음

  • React Native 만큼의 대안이 없다면 web components만으로는 부족함
    브라우저 기술은 네이티브 앱 수준에 도달할 만큼 빠르지 않음
    React의 가장 큰 가치는 플랫폼 전반에 걸쳐 GUI 개발을 통합할 수 있다는 점임

  • lit web components로 비즈니스 앱을 만든 경험이 있음
    모든 프로퍼티가 string 타입이어야 해서 상당히 불편했고, real-time 중심의 컴포넌트 라이브러리와 비교할 수 없었음

  • 우리 대기업에서는 사내 앱에 반드시 중앙 React 라이브러리를 써야 함
    "디폴트라서 React"가 아니라 "React만 사용 가능"인 상태임
    탈출구는 중앙 라이브러리를 web components로 재구현해 원하는 프레임워크를 쓸 수 있도록 하는 것이라 생각함

  • React UI 라이브러리에서 web components를 잘 써본 분이 있는지 궁금함
    특정 디자인 시스템에 맞춰 컴포넌트 라이브러리를 만들 땐 RAC 같은 headless 라이브러리에 의존하는 것이 만족스러움
    web components가 보완재가 될 수 있다는 점은 알겠지만 실제로 어디에 쓰는 게 가장 좋은지는 잘 모르겠음

• 사실 이 글은 React의 성능 때문이 아니라 "사회적 이득"이 대안 대비 훨씬 크기 때문에 다른 선택지가 힘들다는 이야기임
  즉, React가 기술적으로 두드러지지 않아도 기본값 선택이 됐고, 네트워크 효과가 기술 적합성보다 결정에 큰 영향을 준다는 점에 동의함
  그렇다고 해도 팀들에게는 React가 대안 대비 명확한 이점이 계속 존재함
  실제 대부분의 유능한 팀들은 본인들이 정말 예외적인 경우에만 다른 대안을 채택하는 걸 잘 알아냄

  • 여러 기업과 스타트업에서 기술 스택 결정에 참여했지만, React 선택 근거로 "프레임워크 자체의 장점"을 들어본 적 없음
    항상 익숙함, 채용의 용이함, 생태계에 기반해서 결정했음

  • 웹 개발자들이 이성적인 판단을 내린다고 가정하는데, 내 경험상 그렇지 않음
    사람은 “사회적 증명”, “권위” 등 인간의 편향에 쉽게 휘둘림

  • "React가 좋아서 쓴다"는 말은 들어본 적 없음
    항상 "채용이 쉽다"는 이유 뿐임

  • React는 복잡한 문제 해결에 강점이 있음
    그렇지만 모든 문제가 복잡한 것도 아니고, 복잡한 도구를 기본값으로 쓰면 프로젝트에 쓸데없이 복잡도와 유연성 저하를 가져옴
    과거 기능 또는 향후 기능 때문에 유지보수해야 하는 생태계의 불안정성 역시 React에만 국한된 문제는 아님
    앞으로는 지금 세대의 web app 패러다임을 뛰어넘는 새로운 흐름을 기대함

• 프론트엔드 단일 문화(React 독점)에 대해 우려할 만한 이유가 있지만, 궁금한 점은 실제로 10년 전에는 완전히 반대 상황이었다는 것임
  신규 프레임워크들이 매주 HN에 쏟아지고, Angular 1.x에서 2.0으로의 혼란, "JavaScript 피로"라는 용어까지 나올 정도로 프론트엔드 개발이 힘들었음
  이제는 React가 확실히 표준으로 굳어졌고, 덕분에 마음 편히 서비스 개발에 집중할 수 있음
  React를 칭송하는 건 아니지만(나도 hooks는 좋아하지 않지만), 2015년 같은 시절이 아니라서 감사하고 있음
  이제는 시간이 흘러 점점 분위기가 변하고 있는 점이 흥미로움

• 미친 듯이 다양한 boutique 자바스크립트 라이브러리가 넘치던 때가 기억남
  React의 대세화는 일종의 승리라고 봄
  "혁신"이라는 모호한 개념을 위해 익숙하고 안정적인 걸 억지로 버리는 건 경계해야 한다고 생각함

• 진짜 공감함
  2009~2015년까지 상당히 선구적으로, 네이티브 앱 급의 브라우저 UX를 많이 만들어 봤음
  웹 표준과 이를 최대한 직접 활용하는 게 강점이었는데, 이후 백엔드로 방향을 틀고 React의 부상을 멀리서 지켜봄
  React가 비효율적으로 보였고, JSX의 "모든 게 표현식"이어야 한다는 한계도 답답했음
  그래도 React가 state management에 중요한 패러다임 변화를 가져온 덕이 크다고 평함
  과거 상태 모델에서 단방향 immutable data 흐름으로 바뀐 건 힘든 과정이었지만, 결국 의미 있었음
  혼란스러웠던 시절임에도 React는 혁신과, 웹 앱 설계 사고 방식에 큰 변화를 준 점은 사실임
  하지만 지금 SolidJS와 비교하면 Solid가 같은 이점은 더 간결하고, 성능도 더 뛰어나며 관리하기도 훨씬 쉬움
  JSX, 서버 컴포넌트, reactive 상태 관리도 더 잘 제공하고, React 개발자도 쉽게 넘어갈 수 있음
  앱 구조 사고 방식도 거의 그대로여서 React에서 실질적으로 얻는 거의 모든 장점을 더 좋고 빠르며 번들 크기도 확 줄인 형태로 누릴 수 있음
  그래도 시장 전체가 React에 쏠려 있어서 억지로 계속 쓸 수밖에 없음

  • SolidJS도 여전히 아픈 부분이 있음
    가장 큰 문제는 prop이 signal인지 아닌지 직관적으로 알기 어려움
    타입 시스템도 큰 도움을 주지 못함
    React에선 참조 변경이면 무조건 prop을 받는 곳에서 다시 렌더링되는 게 명확한데 Solid는 변화가 관찰될지 애매함

  • 대부분의 사람들이 본인에게 익숙한 걸 쓰는 걸로 만족한다고 생각함
    React를 억지로 쓰고 싶지 않아하는 개발자가 많은데, 결국 자기가 잘 아는 걸 쓸 수밖에 없음
    시간은 한정되어 있고 가족이나 취미 등 다른 삶을 위해 효율적인 선택이 필요함

  • React에 얽매일 필요는 꼭 없음
    내 회사(거의 나 혼자서) 지난 10년간 개발한 프레임워크도 있는데, MIT 라이선스로 오픈소스 공개함
    Q.js 링크
    의견을 듣고 싶음

• Hooks는 class component의 단점을 해소했지만, 새 복잡성(의존성 배열, stale closure, 오남용 등)도 같이 생김
  하지만 이런 문제들은 hooks 때문만이 아니라 과거 class 기반 컴포넌트 때도 존재했음
  의존성 배열은 과거에도 props, state 변경을 놓쳐서 생기는 버그가 흔했음
  stale closure 은 setState의 두 번째 인자에서도 똑같이 발생했음
  라이프사이클 메서드(componentDidMount, componentWillMount 등) 오남용도 빈번했음
  "Effect를 꼭 필요할 때만 써라" 같은 문서가 과거에도 필요했을 거라고 생각함
  hooks는 실수할 기회를 줄이고, 그런 기회를 파악하기 쉽게 하며, 경고까지 해주기 때문에 분명 개선에 기여함

  • 의존성 배열 문제는 eslint에서 react-hook 관련 규칙을 쓰면 아주 쉽게 해결됨

  • prop 테스트에 fast-check를 활용하면 사소한 변화 발생 시 버그 예방에 엄청 도움이 됨

• 자바스크립트 커뮤니티는 몇 년간 혁신을 멈춰도 될 듯함
  혁신이 너무 많았는데 실속이 부족했음
  이제 브라우저 쪽에서 웹을 위한 합리적인 컴포넌트 개발을 맡아야 함
  백엔드 지원 combobox나 표준 date picker라도 브라우저 단위에서 지원하면 매번 그런 기본 UI 컨트롤 상태 관리 혁신에 매달릴 필요가 없어짐

  • 브라우저가 더이상 원래 역할을 충실히 수행하지 않는 것도 문제라고 생각함
    Google은 Chrome을 통해 거의 독점에 가까운 영향력을 갖고 있어서, 구글이 관심 갖고 개발 리소스 쓰는 일 외엔 웹 표준에서도 진행이 잘 안 됨
    Safari, Firefox가 일정 부분 균형을 맞추긴 하지만, 진짜 차별화된 플랫폼으로 진화하려면 누군가는 리더십을 쥐고 밀어 붙여야 함
    결국 JS 진영이 플랫폼 수준에서 지원이 안 되니 NAND 칩 땜질하듯 계속 해킹해야 하는 안타까운 상황임

  • 최근 브라우저와 CSS가 전통적으로 JS에 의존하던 유스케이스를 꾸준히 개선/해결해 줬다고 느낌
    이런 움직임은 계속 확대되어야 좋을 것임

  • 아예 쇼핑, 뱅킹, 소셜 등 5~6개 종류로 브라우저를 나누는 것도 고민해 볼 만함
    각 서비스가 백엔드에서만 혁신을 경쟁하도록 하고, 프론트엔드는 통일된 경험을 제공하면 사용자에게 더 이로움
    회사마다 똑같은 프론트엔드를 계속 따로 따로 개발하는 건 엄청난 낭비임
    샌드위치 가게가 더 좋은 샌드위치를 만드는데 경쟁해야지 앱 설치 사용자 8% 뺏으려고 비슷한 프론트엔드 만들어내는 건 본질이 아님

  • 사실 이렇게 복잡한 플랫폼(HTML/CSS/JS) 위에서 프레임워크들이 해낸 걸 보면 놀랍기만 함
    '웹'이 문서/텍스트와 단순한 폼에 집중할 때나 적합한 구조였지, 이제는 복잡한 인터랙티브 앱에는 매우 부적합한 토대
    언젠가는 완전히 새롭게 재구성되어야 함

• React가 "최고라서" 이긴 게 아니라 "안전한 디폴트"가 됐기 때문에 이겼음
  모두가 React를 알고 있고, 채용도 쉽고, 에코시스템도 크니까 그게 안정됨
  덕분에 혁신은 적어지고, 좀 더 가벼운 Svelte나 Solid 같은 대안은 시도조차 해보지 않게 됨
  React가 여전히 잘 작동하지만, 실제로는 적합성보다는 관성으로 많이 사용된다고 생각함

  • 실리콘밸리는 언제든 빠르게 트렌드에 올라탄다는 농담도 할 수 있겠음