React가 기본값으로 승리하고 있으며 프론트엔드 혁신을 늦추고 있음
(lorenstew.art)- 오늘날 React 채택은 기술적 우위가 아닌 기본값으로 이루어지고 있으며, 이는 프론트엔드 생태계의 혁신을 둔화시키고 있음
- 많은 팀이 제약 조건을 따지지 않고 “모두가 아는 React”를 선택하면서, 네트워크 효과가 기술 적합성보다 아키텍처 결정을 좌우하는 상황이 됨
- Svelte, Solid, Qwik 같은 혁신적 프레임워크는 더 나은 성능 모델을 제공하지만 채택률 부족으로 주류 경쟁에서 밀리고 있음
- React는 훌륭한 점이 많지만, 문제는 React-기본 사고방식이 기회 비용을 키우고 더 나은 대안을 고려할 여지를 막는 것임
- 건강한 생태계를 위해서는 다양성과 경쟁이 필요하며, 프레임워크를 기본값이 아닌 제약과 적합성에 따라 선택해야 한다는 메시지를 전함
React의 기본값 승리와 그 한계
- React는 더 이상 기술적 우위로 선택되는 것이 아니라 기본값으로 채택되는 경우가 많음
- 이는 팀들이 프로젝트 제약을 평가하지 않고 자동적으로 React를 사용하는 습관을 강화함
- 대안 프레임워크(Svelte, Solid, Qwik)는 React보다 특정 시나리오에서 성능 우위가 있음에도 제대로 평가되지 않음
- React 자체의 문제라기보다 React-기본 사고방식이 혁신을 저해하는 구조를 만들고 있음
혁신의 천장
- React의 Virtual DOM은 2013년에는 적합했지만 오늘날에는 불필요한 오버헤드로 작용함
- Hooks는 클래스 컴포넌트의 문제를 해결했지만, 의존성 배열과 stale closure 같은 새로운 복잡성을 도입함
- Server Components와 React Compiler는 성능 개선을 시도하지만, 이는 React 모델의 제약을 우회하기 위한 방편임
- 반면 Svelte의 Runes, Solid의 세밀한 반응성, Qwik의 Resumability는 전혀 다른 모델로 더 높은 잠재력을 보여줌
기술적 부채
- React를 기본값으로 선택하면 불필요한 런타임 비용과 리렌더링 관리 부담이 발생함
- 개발자는 비즈니스 가치 대신 effect 의존성이나 hydration 관리에 시간을 쓰게 됨
- 벤치마크에서 Solid는 React보다 2~3배 빠른 업데이트 성능을 보임
- React 패턴 중심의 사고는 웹 기본기를 약화시키고 아키텍처 관성을 심화시킴
대안 프레임워크들
-
Svelte: 컴파일러 혁명
- Svelte는 대부분의 작업을 컴파일 타임에 처리하고 virtual DOM을 없앰
- 컴포넌트는 웹의 기본 구조에 가까워지고, 실행 시 오버헤드가 크게 감소함
- 하지만 "업무 기회가 적음"이라는 인식 때문에 도입률이 낮음
- The Guardian, Wired, Shawn Wang 등 다양한 사례에서 Svelte 도입 후 번들 크기와 로딩 시간이 크게 감소하고, 개발 생산성이 향상됨을 입증함
- 예를 들어, Shawn Wang은 React에서 187KB였던 사이트 크기를 Svelte로 9KB까지 줄였음
-
Solid: 미세 반응성의 원시적 접근
- Solid는 정밀한 반응성(미세반응) 을 JSX 문법과 결합해 제공함
- signal을 통해 변경된 DOM만 직접 접근, reconciliation 병목을 완전히 회피함
- 뛰어난 성능과 간결한 상태관리의 강점을 가짐
- 아직 채택사례는 제한적이지만, 초기 도입 팀 경험을 보면 효율성·코드 단순함 모두에서 큰 혁신을 경험하고 있음
-
Qwik: Resumability 혁신
- Qwik은 traditional hydration 대신, resumability로 즉각적인 startup이 강점임
- 현재 필요 기능만 점진적 로드하고, 상태·코드 모두 직렬화 가능함
- 대형 사이트, 장기 세션, 느린 네트워크에서 탁월한 성과를 보임
- 아직 많은 팀들이 시도하지 않았으나, 도입한 팀에서 초기 로딩 시간과 자원 효율성 모두 큰 개선을 보고함
-
React API의 복잡성과 대안 프레임워크의 단순성
- React API는 hook, context, reducer, memoization 등 복잡한 개념을 포함하고 있어 개발자의 인지 부담이 높음
- 오용 시 의존성 문제로 인한 버그 발생이나 과도한 설계 부담이 큼
- 예를 들어, Cloudflare 2025년 9월 12일 장애의 원인도 useEffect의 의존성 배열 설정 오류로 발생함
- 반면, Svelte·Solid·Qwik 등의 대안은 훨씬 작고 집중된 API로 심플함과 웹의 근본 원리를 강조함
- 이 세 프레임워크 모두 기술적 우위는 충분하나, React라는 기본값 문화로 인해 대부분 실험조차 되지 못하는 현실
네트워크 효과의 감옥
- React 지배는 자기 강화적 장벽을 만들고 있음
- 구인 시장에 “React 개발자”만 찾고, 조직마다 컴포넌트 라이브러리, 개발 습관 등이 React에 맞춰 굳어짐
- 위험을 회피하려는 리더들은 당연히 안전한 React를 고르고, 교육기관도 이에 맞춤
- 이런 구조는 건전한 경쟁이 사라진 생태계의 특징
네트워크 효과 깨기
- 이를 탈피하려면 의식적인 선택이 필요함
- 기술 리더는 관성을 버리고 요구사항에 따라 구조를 결정해야 하고, 기업은 파일럿 예산을 배정해서 대안을 시도해 볼 수 있음
- 개발자 역시 단일 패러다임만 고집하지 않고, 다양한 프레임워크 정신을 습득해야 함
- 교육기관은 프레임워크 불가지론적 개념 수업을 늘려야 하며, 오픈소스 기여자들은 작은 생태계 지원에 힘쓸 수 있음
변화는 저절로 오지 않고, 의도적으로 만들어야 함.
프레임워크 평가 체크리스트
새 프로젝트 시, 다음을 평가 기준으로 삼을 수 있음
- 성능 요구: 초기 로딩, 업데이트 효율, 번들 크기 등과 컴파일 타임 최적화 여부
- 팀 역량 및 학습 곡선: 기존 경험 고려, Solid처럼 React와 호환되는 대안도 존재함
- 확장성 및 소유 비용: 유지보수, 의존성 관리, 기술부채 포함한 장기 비용 평가
- 생태계 적합성: 성숙도와 혁신성의 균형, 비핵심 업무에서 파일럿 시도 및 ROI 테스트
흔한 반론과 대응
- 생태계 성숙도: 나이 든 생태계가 필연적으로 오늘의 문제에 더 적합한 것은 아님. 써드파티 패키지 의존도가 높아지면 유지부담, 보안취약점, 번들 비대화 등 부작용이 큼. 오히려 작은 생태계는 웹 근본에 더 집중할 수 있고, AI 도구 발전으로 쉽고 빠른 커스텀 솔루션 개발이 가능함.
- 채용 문제: 수요가 곧 채용 기준이 됨. 핵심이 아닌 분야에서 대안 테스트 후 현장학습으로 부족한 역량 보완 가능함.
- 컴포넌트 라이브러리: 프레임워크 독립적 디자인 시스템, Web Component 활용 등으로 락인 줄이고 생산성 유지 가능함.
- 안정성: React 역시 hooks, Server Components 등 끊임없이 변화 중임. 대안 프레임워크가 오히려 더 일관된 API 제공하는 경우 많음.
- 대규모 사례 검증 필요성: 한때 jQuery도 세계적 사례였음. 과거의 성공이 미래에 유효하다는 보장은 없음.
생태계·산업 전반에 미치는 해악
- React 단일문화는 웹 발전 자체를 느리게 만듦
- 재능과 자본이 React 이슈 해결에만 몰리고, 플랫폼 고유 혁신은 지연됨
- 교육기관도 즉각 취업가능성 위주 커리큘럼으로 인해 이식성 없는 기술 학습만 늘어남
- 플랫폼(웹) 자체 발전이 “React만 있으면 된다”라는 답변에 막히고, 생태계 다양성 부족이 장기적으로 모두에게 손실로 돌아옴
우리가 만들어갈 수 있는 바람직한 생태계
- 다양성은 건강한 생태계의 필수조건임
- 여러 패러다임이 경쟁·교류할 때 혁신이 탄생함
- 개발자는 여러 사고방식을 익히며 성장하고, 웹 플랫폼 자체도 다양한 도전의식 덕분에 발전함
- 한 프레임워크에 올인하는 것은 단일 실패 지점이 됨. 한계에 도달하면 성장이 멈추고, 더 나은 기회도 사라짐
- 프로젝트마다 기술적 제약과 적합성을 중심으로 선택해야 하며, React 기본값에만 의존하지 않는 태도가 필요함
- 다양성만이 진정한 혁신을 보장함
- 이제는, 모두가 똑같은 ‘씨앗(React)’만 심지 말고, 더 다양한 프레임워크 실험을 통해 웹 생태계를 더 강인하고 혁신적으로 만드는 데 동참해야 할 때임
- 선택은 우리의 몫임
너무 편향적인 글인데요?
"Svelte, Solid, Qwik 같은 혁신적 프레임워크는 더 나은 성능 모델을 제공하지만 채택률 부족으로 주류 경쟁에서 밀리고 있음"
혁신이란 단어의 뜻을 이애하는 일관된 기준이 없다면,
가정부터가 잘못된 것 같습니다.
생태계를 무시 못하는게...요즘 나오는 서드파티나 오픈소스 라이브러리들이 대부분 리액트는 공식 지원하지만 다른 프레임워크는 커뮤니티 지원뿐이라 이것저것 조합해서 쓰려면 결국 리액트가 가장 안전한 선택지가 될 수 밖에 없...
근 10년간 FE 생태계에서 수많은 도구들이 쏟아져나오고, 흥망성쇄 끝에 이제서야 어느정도 안정화 되었는데, 다시 한번 그런 대혼돈을 시도하라니..
이런 글들을 보면 제품을 만드는데 신경쓰는게 아니라 소프트웨어 엔지니어링에만 넘 몰두하는 것 같다는 생각이 드네요. 어차피 고만 고만한거 제품을 잘 만들어야하는데, 맨날 새로운 프레임웍 새로운 아키텍쳐 찾아디니면서 오버엔지니어링하고 이게나으니 또 바꾸자고하고. 새거가 좋은게 아니라 뭐든 잘 써서 제품을 내놓는게 중요하다고 생각합니다.
어쩔 수 없는게, 국내 빅테크에서 리액트(next.js) 기준으로 채용을 하니까요.
메이저한 vue.js만 해도 빅테크에서 구인하는 자리가 많지 않죠.
어느정도 공감합니다.
백엔드에서 spring boot 프레임워크가 전자정부 프레임워크까지 만들어지기까지 포맷이 되면 생산성이 증대되는 부분도 분명 있기 때문이라 React도 그런 형태로 변화되어 가는 것이 아닐까 생각합니다.
네 꽤 많은 다수가 이해하는 컴포넌트 기반 설계와 렌더링 동작을 정립한 게 리액트의 의의라 생각하고요. 다만 리액트는 그 자체로 웹앱을 만들기에는 저수준의 프레임워크라 라우터랑 폼이라도 기본 제공해줬으면 하고, state랑 effect의 경우 깊은 비교를 기본 지원하고 구조체와 함수로만 로직을 작성할 수 있었다면 어땠을까 생각해 봅니다. 자바스크립트 얕은 비교 제약 때문에 커스텀 훅 문법으로 클래스를 작성하게 되더라구요
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가 여전히 잘 작동하지만, 실제로는 적합성보다는 관성으로 많이 사용된다고 생각함- 실리콘밸리는 언제든 빠르게 트렌드에 올라탄다는 농담도 할 수 있겠음