GN⁺: React 때문에 잊어버렸거나 (혹은 모르고 있던) 것들
(joshcollinsworth.com)- 사용자 인터페이스 구축을 위한 널리 사용되는 JavaScript 라이브러리인 React에 대한 비판적인 검토 및 대안 제안.
- React는 시대에 뒤떨어진 것으로 비판되며, 성능과 적응성이 부족하다는 지적.
- 저자는 React의 생태계가 불필요하게 크다고 주장하며, React hooks는 이제 시대에 뒤떨어졌다고 주장.
- 프론트엔드에서 렌더링과 스케일링에 집중할 필요가 없다는 주장.
- 서버 사이드 렌더링이 더 이상 독특하지 않으며, 양방향 데이터 바인딩이 나쁜 생각이 아니라는 주장.
- 스타일링이 React보다 단순하며, 다른 프레임워크들이 배우기 어렵지 않다는 주장.
- React 대안들이 단지 "새롭고 반짝이는" 것이 아니라 성숙하고 더 나은 성능을 제공한다는 주장.
- Svelte, Vue, Solid, Fresh, Astro, Preact, Qwik 등 다른 프레임워크를 시도해 보는 것을 권장.
- 저자의 개인적인 Favorite는 Svelte로, React보다 배우기 쉽고 성능이 더 좋다고 주장.
- Svelte는 컴파일러로, 사용되지 않는 코드는 빌드 시간에 제거되어 더 작은 번들을 생성.
- Svelte의 메타 프레임워크인 SvelteKit는 다양하고 강력하며, 정적, 서버 렌더링, 엣지 배포가 가능.
- Vue는 React보다 더 나은 성능과 더 UI 중심적인 접근법을 제공하며, JSX보다 기본 HTML에 가까운 템플릿 언어를 사용.
- Solid는 React의 더 성능이 좋은 버전으로, 복잡성, 성능 문제, 보일러플레이트를 제거. 자체 메타 프레임워크인 SolidStart를 제공.
- Fresh는 Deno 위에 구축된 서버 렌더링 프론트엔드 프레임워크로, 섬 아키텍처를 가지고 있음. 최소한의 JavaScript와 빠른 동적 콘텐츠 로딩을 제공.
- Astro는 고성능 정적 사이트 생성기로, 동적 서버 사이드 기능을 가짐. 기본적으로 JavaScript를 전혀 사용하지 않으며, 다양한 프론트엔드 프레임워크와 호환.
- Preact는 React의 더 슬림하고 빠른 버전으로, React가 가지지 못한 몇 가지 우수한 기능을 획득.
- Qwik은 새로운 접근법으로 서버 렌더링 React와 유사한 코드를 제공하며, 많은 상호 작용이 있는 프로젝트에 좋은 선택.
- Lit, Stencil, Polymer과 같은 웹 컴포넌트 라이브러리는 동일한 컴포넌트를 여러 환경에서 재사용하거나 프레임워크 변경에 대비하려는 프로젝트에 권장.
- 저자는 기술 산업이 React에서 새로운 것으로 기술 채택에서 또 다른 도약을 할 수 있음을 제안.
기사에 대해 과열되는것 같습니다.
사이트 이용법 의 댓글달기 항목을 확인하여 주시기 바랍니다.
친절하고 점잖게 얘기해주세요.
글쓴이를 저격하지 말아주세요.
반론이 있다면 그 내용만을 적어주세요.
개인적으로는 그냥 JS 같은 언어가 서버 개발언어로 쓰이는게 별로라고 생각합니다.
요샌 TS 기반도 많긴 하지만 결국 결과물은 JS로 나오는거고... Python도 그렇고 JavaScript도 그렇고 언어 측면에선 정말 마음에 안드는데 편의성 때문인지 많이 쓰이네요.
언어의 민주화 같은 느낌이네요
학교 다닐 때 문법 오류도 안잡아주는 에디터로 지옥같은 서블렛 짜던 기억만 떠오르면 리액트던 스벨트던 모든것에 감사하게 되더군요.....
이것 저것 써보면 리엑트의 장담 점이 보이는데 리엑트가 좋다 JSX 가 강점이다 hooks 에 대한 부정 적인 의견에 부정 적인건 맹목적인 종교 같은 느낌 이네요
JSX가 아니라 '표현력'에 강점이다라고 썼구요.. hooks 는 실제로 원문을 읽어보니 hooks 패턴 자체를 비판한게 아니라 그저 더 이상 리액트만의 강점이 아니다 정도로만 쓴 것 확인했습니다. 이 정도에는 동의할 수 있죠.번역이 저렇게 되어 있으니 제가 오해했네요.
그래서 댓글쓴이 님이 파악하신 '장담 점'은 뭔지 구체적으로 써주실 수 있나요?
라이브러리나 프레임워크들이 설마 장점만 있고 단점은 없다고 생각 하시는 건 아니 겠지요? 혹시 쓰면서 리엑트 단점 같은건 못 느끼셨나요 ? 꼭 단점을 써달라 하시는 것 보니 한번도 못 느끼 셨나 보네요? 장단점 이란게 장점도 있다는 말인건 아시죠 ? 장점도 많지만 단점도 많죠 그중 어제 읽은 건데요 링크는 모르겠네요 서버컴포넌트에서는 서버컴포넌트 밖에 context 를 사용 할 수 없데요 그로인해 js-in-css 를 사용 할 수 없다네요 제가 직접해본건 아니라 진짜 단점이라고 말할 수 없네요 ㅎㅎ 훅요 ? 저는 정말 획기 적인 아이디어 제공자라고 생각 합니다 그런데 지금은요 ㅎㅎ 리엑트 보다 더 똑똑 하고 사용하기 편한 시그널이 있죠 본문에도 있고요
전혀 동의가 되지 않네요, JSX 같은 경우는 HTML 보다 표현력에 강점이 있으니 일부러 쓰는 거고
양방향 데이터 바인딩이 쭉 나쁜 생각이었던 일반적인 의견이 왜 갑자기 뒤집힌지도 의문..이고
불필요하게 큰 생태계는 또 무슨 말일까요 ? 그리고 hooks 가 시대에 뒤떨어졌다..
개인적으로 실제 프로그래머가 쓴 글인지조차 의문이네요
use 훅 함수와 서버 컴포넌트 공식화 하면 다시 일어설 수 있습니다. 하지만 다른 기술이 가만히 있지는 않죠.
lit 으로 범용 프레임워크 만드는 케이스가 늘어나고 있어서 관심을 가지기 시작했고(한국은 여전히 듣보),
next.js 대신 astro 와 react 조합도 상당한 매력을 갖고 있습니다(next.js 보다 astro+react 로 회사 홈페이지 뚝딱 만든 경험 있음)
한국에서는 받아들이기 어렵겠지만, 프론트엔드는 원래 이렇게 그냥 심심하면 변화하는 찻잔속 태풍같은 기술이라는 것을 다들 인지했으면 좋겠군요.
기술적으로 어떤 트레이드오프가 있는지 구체적으로 설명하는게 아니라 단순히 성능이 낮다는 주장에는 무리가 있어 보입니다. 예를 들어 React이외의 아일랜드 구현체들은 우선순위 기반 로딩같은것들이 불가능하니까요.
react 국내 인기와 전자정부와 무관합니다. 실제로 전자정부 사용처 중 리액트 사용률은 0 이거니와 react 는 gs 인증이 안되어 있기 때문에 공공 사용이 어렵습니다.
(그에 반해 vue는 삼성이 vue 사용한 프레임워크 gs인증 해버리는 바람에 의외로 공공 사용이 가능)
글쎄요. React의 대안으로 너무 많은 라이브러리들을 제시하고 있네요.
포괄적으로 모든것을 다 고려했을때, 리액트 보다 뛰어난 점들을 어필해야 하지 않을까 싶네요.
Hacker News 의견
- 일부 개발자들은 Vue의 템플릿 언어가 JSX보다 기본 HTML에 가깝고, 템플릿 파일에서 조건문과 반복문을 쉽게 작성할 수 있기 때문에 선호한다.
- React에서 filter, map, reduce 등의 언어 구조를 사용하는 것이 일부에게는 workaround보다 더 편리하다고 인식된다.
- 한 개발자는 React에서 벗어나 서버 사이드 렌더링 프론트엔드와 vanilla JS를 사용한 경험을 공유하며, 이를 유지 관리하기 더 쉽다고 발견했다.
- 일부 사람들은 이미 DOM이 React에 세 번째 파티 라이브러리를 통합하는 믿을 만한 방법을 제공하고 있기 때문에 Web Components를 과대평가된 것으로 본다.
- React의 인기는 프로그래밍 모델에 기인하며, JSX는 여전히 JS 애플리케이션의 UI 부분을 JS 부분에 직접 통합하는 더 나은 방법 중 하나로 간주된다.
- 비즈니스 관점에서, React와 같은 업계 표준을 고수하는 것은 쉬운 채용과 더 큰 생태계를 제공하며, 처음부터 구축할 필요를 줄여준다.
- React의 Hooks는 클래스 컴포넌트 생명주기 메소드보다 크게 향상된 것으로 간주되며, 더 깔끔하고 강력한 코드를 제공한다.
- 일부 개발자들은 React의 함수 컴포넌트와 Hooks를 실수로 보며, 이로 인해 코드베이스가 덜 유지 관리 가능하고 이해하기 어렵다고 판단한다.
- React는 다른 프레임워크보다 더 기본적인 것으로 간주되며, 명령형에서 더 함수적인 패러다임으로 전환한다.
- Google이 Web Components를 명세화하기 위해 Alex Russel에게 지불한 금액에 대한 기사 인용은 Web Components와 React 사이의 직접적인 경쟁 때문에 편향된 것으로 간주된다.
- 일부 개발자들은 웹 프로그래머들이 "스스로 해보기"와 실용적인 방식으로 복잡한 시스템을 구축하는 능력을 잃었다고 느끼며, React와 같은 프레임워크가 종종 과도하게 사용되고 있다고 느낀다.
- 기사의 저자는 예시를 제공하지 않고 현재 솔루션들 사이의 역사와 차이에 대한 전문성이나 이해가 부족하다는 비판을 받는다.
- 개발자들이 렌더링 성능에 대해 걱정할 필요가 없다는 기사의 주장에 일부 사람들이 동의하며, React가 개발자들에게 useMemo와 useCallback과 같은 기능을 사용하도록 요구하는 것이 의문스럽다고 느낀다.
- 개발자들이 오직 React 개발자가 되어 다른 방법을 찾을 수 없게 되는 기사의 주장에 일부 사람들이 동의하며, React가 컴포넌트, 상태, Hooks와 같은 정의를 도입함으로써 기본 프로그래밍 개념에 대한 이해가 손실되었다고 느낀다.