[번역] React 때문에 (몰랐거나!) 잊었던 것들

React 때문에 잊었거나 몰랐던 것들

다음 아티클은 2023년에 작성된 Things you forgot (or never knew) because of React 의 번역입니다. 저자 Josh Collinsworth는 JS 런타임 Deno의 개발자 중 한명입니다. 아티클 내용과 React 19 발표 내용을 같이 보시면 .. 더 재밌을듯요 React 19

Part 1: 음악, 기본값, 그리고 버블에 관한 서론

많은 사람들처럼 나도 한때는 내 지역 라디오 방송국에서 나오는 음악만 듣곤 했습니다. (30대 이상 대부분의 사람들이 그렇죠. 만약 이게 익숙하지 않다면 조금만 더 참아주세요.) 그때는 그것만으로도 만족했습니다. 그것이 내가 필요로 하는 전부처럼 보였습니다.

되돌아보면, 나는 좋은 것이 결국 인기를 얻게 되므로 가치 있는 것은 결국 스스로 찾아올 것이라고 순진하게 믿었습니다.

하지만 시간이 지나면서, 다른 음악들이 내 삶에 뿌리내리기 시작했습니다. 새로운 친구들과 인터넷을 통해, 내가 이전에 좋아했던 것들과는 더 멀리 떨어진 새로운 아티스트들을 알게 되었습니다.

이 음악은 달랐습니다. 일주일 만에 사랑에 빠졌다가 그 다음 주에는 싫증나는 것이 아니었습니다. 듣는 것이 끝없는 사이클의 일부가 아니었습니다.

오히려 반대였습니다. 실제로 좋아하고 들으면 들을수록 더 좋아했습니다. 깊이가 있었습니다. 물론, 내가 그때까지 즐겼던 시끄러운 기타, 재치 있는 가사, 설탕 같은 멜로디는 없었습니다. 하지만 놀랍게도, 그것이 더 나은 것이었습니다.

그때 나는 깨달았습니다. 어쩌면 내가 만족했다고 생각했던 것은 사실 무지에서 비롯된 것일지도 모른다는 것을요.

기본값 너머의 풍부함 찾기

이 이야기에 공감할 수 있을 것이라고 생각합니다, 음악과는 관련이 없더라도 말이죠.

아마도 이제는 한때 좋아하지 않았던 음식이나 음료가 가장 좋아하는 것 중 하나일 것입니다. 아니면, 영화, 책, 게임, 팟캐스트, 인플루언서, 취미가 예상치 못하게 당신과 공명한 경험이 있을 것입니다.

세부 사항은 중요하지 않습니다. 내가 말하고 싶은 것은:

아마도 당신은 인기 있는 기본값의 주변을 넘어서서 훌륭한 것을 발견한 경험이 있을 것입니다.

프론트엔드의 힙스터 같은 말을 하려는 것이 아닙니다. 그건 내 의도가 아닙니다. 올리브 가든에서 버드라이트를 즐기는 것이 좋은 시간이라고 생각한다면: 좋아요, 빵스틱을 주세요.

하지만 내가 말하고 싶은 것은: 어쩌면 당신이 훌륭한 것을 무의식적으로 막고 있을 수도 있다는 아이디어를 조심스럽게 공유하고 싶다는 것입니다.

어쩌면 이 개념—익숙한 경계를 넘어서 더 나은 것을 찾는 것—은 우리의 도구와 워크플로우에도 적용될 수 있습니다.

그리고 어쩌면—그냥 어쩌면—당신의 현재 만족은, 적어도 조금은, 당신이 놓치고 있는 것을 모르기 때문에 올 수도 있습니다.

비유 완성하기와 그 한계 인정하기

React가 새로운 기본 프론트엔드 프레임워크가 되었고, 대부분의 사람들이 얼마나 뒤쳐졌는지 깨닫지 못한다고 이전에 쓴 적이 있습니다.

이 점에서, 이 비유는 한계를 드러냅니다.

개인적인 취향에 대해서만 이야기한다면, 나는 결코 당신이 무엇을 좋아하는지에 대해 논쟁하는 블로그 게시물을 쓰지 않을 것입니다. (적어도 이 나이에 말이죠.) 누가 신경 쓰나요? 당신이 즐긴다면, 그걸로 충분합니다.

하지만 음악이나 다른 주관적인 것들과 달리, 프론트엔드 도구의 선택은 다른 사람들에게 경험적인, 측정 가능한 영향을 미칩니다.

그 결정은 실제로 책임이 따릅니다. 우리가 좋아하는 것만이 문제가 아닙니다. 개발과 관련된 것이라면—순전히 자신을 위해 무언가를 구축하는 것이 아니라면—우리의 즐거움은 부차적입니다. 사용자의 경험이 가장 중요합니다.

도구를 좋아하는 것은 멋진 일입니다. 그렇게 되길 바랍니다. 하지만 그건 부차적인 목표일 뿐입니다. 개발자 경험(DX)이 사용자 경험(UX)을 초월해서는 안 됩니다.

그래서 비유가 약간 부족한 점을 용서해 주세요. 평생 같은 음악을 듣고 싶다면, 그렇게 하세요. 나는 그걸 지지합니다. 하지만 도구를 사용할 때는 기존의 취향을 넘어서야 할 매우 타당하고 중요한 이유가 있습니다.

React 버블

React가 동료들에 비해 뒤처졌다는 생각이 당신에게는 새로울 수 있습니다. 많은 사람들처럼, React를 현대 프론트엔드의 표준으로 여길 수도 있습니다. 그래서 이 버블을 살짝 건드려보겠습니다, 이 목록에 들어가기 전에 마지막으로.

Mastodon을 통해 Alex Russell이 쓴 이 글이 이 게시물을 쓰게 만든 것입니다:

오늘 누군가 나에게 IE를 지원할 필요가 없는 새로운 앱에 React를 사용할 이유가 있는지 물었습니다.

나는 단 하나의 이유도 생각해낼 수 없었습니다…

React는 얼마나 구식인지 놀라울 정도입니다.

Alex는 그 스레드에서 React가 웹 컴포넌트를 지원하지 않는 것을 언급했습니다. 그 기능은 수년 동안 React에서 눈에 띄게 빠져 있었습니다. (예, “로드맵에 있습니다.”) 이 글을 쓰는 시점에서는 구현이나 예상 출시 날짜에 대한 확실한 약속이 없습니다.

반면, React의 동료들, 즉 React를 대신할 만한 프레임워크나 기술들은 이미 그 기능을 갖추고 있습니다.

웹 컴포넌트는 한 가지 예일 뿐입니다. 하지만 그것이 React보다 더 잘하는 유일한 항목은 아닙니다. (몇 가지 다른 예를 아래에서 다룰 것입니다.)

React는 초기 프레임워크 게임에서 큰 이익을 얻었습니다. 표준을 설정했죠. 하지만 그로 인해 민첩성과 적응력에 심각한 결함이 생겼습니다. 2013년경 시작된 React의 모든 결정은 또 하나의 기술 부채층입니다. 이는 새로운 동료들이 제약받지 않는 것입니다.

Alex의 말을 다시 인용하자면:

React는 ’08년 제약을 위해 설계된 ’13년 기술입니다. 2023년에는 혁신적인 것이 없습니다. 사실, 현대에 기능적 반응형 프론트엔드 프로그래밍을 얻는 가장 느린 방법입니다…

React가 얼마나 오래되고 얼마나 못된 것인지 대부분의 사람들이 깨닫지 못한다고 생각합니다. 그래서 위의 비유를 다른 말로 바꾸어 말하자면 (그리고 음악에 관한 서론과 연결시키자면):

React는 John Mayer와 Jennifer Aniston이 여전히 데이트 중이던 시절에 설계되었습니다.

(새로운 Taylor Swift 앨범을 포함해서 7개 앨범 전입니다. Taylor’s Version 릴리스를 포함하지 않았습니다.)

그래서 지난 몇 년 동안 React가 당신의 전부였다면, 당신이 잊었거나 전혀 몰랐을 수도 있는 것들을 알려주고 싶습니다. 이를 통해 현재 플레이리스트보다 더 나은 노래를 발견할 수 있기를 바랍니다.

Part 2: React 때문에 잊었거나 몰랐던 것들

1. 이제는 생태계가 커질 필요가 없습니다 (공유가 가능하므로)

다른 게시물에서도 언급했지만, “검증되지 않은” 프레임워크가 개발 프로젝트에 잠재적 도구로 등장할 때마다 사람들이 가장 먼저 묻는 질문은: “생태계가 얼마나 큰가?“입니다.

이 글의 전제를 읽자마자 이런 생각이 들었을 것입니다. React에서 다른 프레임워크로 이동하라고? 그 프레임워크들이 충분히 클까?

우리는 왜 생태계 크기에 집착하는 걸까요?

물론, 이 프레임워크가 사라지거나 몇 년 후에 유지 관리가 중단되지 않을 것이라는 확신을 원합니다. 그건 매우 타당합니다. 그리고 그렇습니다, 너무 새롭거나 검증되지 않은 것에 모든 것을 걸지는 않을 것입니다. 하지만 Vue, Svelte, Preact, Solid, Astro 등은 모두 그 지점을 훨씬 넘어서서 잘 지원되고 유지 관리되고 있습니다. 그러니 그것만이 문제가 아닙니다.

그래서 무엇이 문제일까요? 나는 한 가지 이론을 가지고 있습니다.

우리는 패키지가 우리 프레임워크를 위해 특별히 만들어져야 한다고 배워왔습니다.

이 사고방식은 jQuery에서 시작되었다고 주장할 수 있지만, 나는 React가 이를 가속화했다고 생각합니다.

React를 사용할 때, 특정한 일을 하는 모듈이나 위젯, 라이브러리가 필요할 때마다 그것이 React용이어야만 했습니다. 일반 웹용이나 바닐라 자바스크립트용은 안 됩니다. React의 모든 규칙과 상태 처리, 컴포넌트 생명 주기의 특이점 때문에 React용으로 명시적으로 작성되지 않은 패키지나 라이브러리는 작동하지 않을 가능성이 높았습니다.

React는 우리에게 특정 프레임워크를 위해 만들어져야 한다고 가르쳤습니다. 하지만 이제는 더 이상 그렇지 않습니다. 그리고 원래도 그래야 했는지 의문입니다.

우리는 그렇게 할 필요가 없습니다—특히 “그냥 자바스크립트”라고 주장하는 프레임워크라면. 만약 그것이 그냥 자바스크립트라면, 실제로 그냥 자바스크립트인 다른 모든 것과 작동해야 합니다.

물론, 다른 프론트엔드 프레임워크도 자체 규칙과 상태 및 아키텍처에 대한 규칙이 있습니다. 그들의 영역에서도 실수할 수 있습니다. 그리고 항상 Svelte나 Vue 또는 다른 것들을 위해 특별히 구축해야 하는 것들이 있을 것입니다.

하지만 중요한 것은:

아무 다른 현대 프론트엔드 프레임워크도 React만큼 플랫폼과 고집스럽게 호환되지 않습니다.

다른 현대 도구와 프레임워크를 사용하고 있다면, 바닐라 자바스크립트 패키지가 작동할 가능성이 훨씬 높으며, 수천 가지가 있습니다. 렌더링 주기나 다른 프레임워크 특유의 문제를 일으킬 가능성이 훨씬 적습니다. 게다가: 웹 컴포넌트도 사용할 수 있습니다.

종종, 특수하게 만들어진 패키지나 라이브러리가 필요하지 않습니다. 플랫폼과 이미 호환되므로 이미 나와 있는 모든 것들과 잘 작동할 가능성이 큽니다.

Preact Signals는 뛰어난 예입니다: Preact용으로 만들어졌지만, 어떤 프레임워크에서도 가져와 사용할 수 있습니다. 웹 컴포넌트도 거의 모든 현대 프레임워크와 호환됩니다.

프레임워크가 부족한 부분은, 플랫폼이 이미 필요한 것을 가지고 있을 가능성이 큽니다. (예를 들어, 양방향 데이터 바인딩을 사용하고 브라우저가 제공하는 규칙을 따르는 것이 항상 React에서 어려웠던 양식 제출.)

최악의 경우, 필요한 것을 만드는 것이 React에서보다 훨씬 쉬울 가능성이 큽니다. (useState와 다른 프레임워크의 버전을 비교하는 것만으로도 그 차이를 쉽게 알 수 있습니다.)

새로운 것은 보수적인 개발자들이 신중하게 테스트해보기를 꺼리는 경향이 있는 이유 중 하나입니다. 하지만 새로운 것이 또 다른 장점이 있다는 것을 기억하는 것이 중요합니다. 기술 부채와 오래된 브라우저 지원에 대해 걱정할 필요가 없으며, 새로운 것들은 기존의 좋은 아이디어와 더 현대적인 브라우저 기능을 바탕으로 더 발전할 수 있습니다.

2. React 훅은 사실 구식입니다

훅은 클래스 컴포넌트를 대체하는 React의 최신 진화입니다.

공로를 인정하자면, 훅은 프론트엔드 공간에서 엄청난 변화를 가져왔습니다. 그것들은 우리의 애플리케이션에서 로직과 상태를 구성하는 방식을 혁신적으로 바꿨습니다. 훅은 부인할 수 없이 훌륭하며, 거의 모든 프레임워크가 상태 관리에 훅과 비슷한 모델을 채택했습니다.

하지만 React 훅은 더 이상 새롭지 않습니다. (사실, 안정적인 React 훅은 내 아이와 거의 같은 나이입니다. 그는 지금 유치원에 가고 있습니다.)

훅은 더 이상 경쟁 우위가 아니며, 주목할 만한 기능도 아닙니다. 그것들은 기본입니다. 그저 우리가 일하는 방식입니다.

다른 모든 프레임워크는 자체 구현의 훅을 가지고 있을 뿐만 아니라, 대부분의 경우 더 빠르고, 더 스마트하고, 쓰기 쉽습니다.

Preact Signals는 여기서 언급할 만한 가치가 있습니다. Svelte의 매우 간단한 스토어도 마찬가지입니다. Solid에도 Signals가 있습니다. 심지어 Vue 3의 컴포지션 API도 React의 훅에서 영감을 받았지만, 몇 가지 주요 이점이 있습니다.

훅은 훌륭한 패턴이며, React는 이를 대중화한 공로를 인정받아야 합니다. 하지만 거의 모든 다른 프레임워크는 React의 구현보다 더 나은 훅을 가지고 있습니다. 규칙도 적고, 보일러플레이트도 적습니다.

Signals의 개념을 잘 모른다면: 이것은 훅의 다음 진화, 더 나은 반응형 상태의 업데이트입니다. Signals는 무엇이 리렌더링을 유발하는지에 대한 기본값이 더 좋으며, 전체 컴포넌트 대신 리렌더링이 필요한 노드만 리렌더링합니다.

3. 이제는 렌더링을 미세 관리할 필요가 없습니다

고백할 것이 있습니다: useMemo와 useCallback의 차이점이 무엇인지, 언제 사용해야 하고 언제 사용하지 말아야 하는지 아직도 정확히 모릅니다. (정말로 오늘 아침에 그 주제에 관한 여러 기사를 읽었지만 말이죠.)

또한, useEffect의 종속 배열에 무엇을 넣어야 하고 왜 넣어야 하는지 직관적으로 알지 못합니다. useEffect 호출을 쓸 때마다 코드를 리팩토링하는 데 15분 정도 걸립니다. 코드를 올바른 형태로 바꾸기 위해서요.

React를 사용한다면 이 고백에 공감할 수 있을 것입니다. 그리고 어쩌면 그 혼란과 모호함을 정상으로 받아들였을 수도 있습니다. 하지만 알아두세요:

다른 프레임워크에서는 몇 년 동안 이러한 렌더링 주기 미세 관리를 할 필요가 없었습니다.

이제 프레임워크들은 이런 일을 손쉽게 처리할 만큼 똑똑합니다. 당신이 손을 잡고 설명하지 않아도 됩니다.

그들은 더 이상 필요 없는 리렌더링을 낭비하지 않도록 이미 알고 있습니다. 기본적으로 더 퍼포먼스 있게 업데이트합니다.

물론 대부분의 경우입니다. 완벽하지는 않습니다. 하지만 React보다 훨씬 더 잘 알고, 기본적으로 효율적으로 작동합니다.

다른 프레임워크에서도 최적화가 필요할 수 있습니다. 완벽하지는 않습니다. 하지만 React에서 최적화가 필요할 때쯤에는 훨씬 더 지난 시점에 필요할 것입니다.

4. 다른 프레임워크에서는 useEffect와 같은 기능을 두려워하지 않습니다

컴포넌트가 DOM에 들어갈 때 무언가를 실행하거나, 다른 데이터나 변수에 따라 동적으로 무언가를 다시 계산하고 싶을 때, 대부분의 다른 프레임워크는 useEffect보다 더 나은 방법을 가지고 있습니다.

React 커뮤니티 내에서도 useEffect는 악명이 높고, 종종 완전히 피하는 경우가 많기 때문에 여기서 너무 많이 다룰 필요는 없을 것 같습니다. 하지만 신뢰해 주세요: 다른 비-React 프론트엔드 프레임워크에서는 사람들이 이처럼 유용한 기능을 두려워하지 않으며, 그것에 대한 규칙도 그렇게 까다롭지 않습니다.

컴포넌트가 마운트될 때 무언가를 실행하기 위해 서드파티 패키지를 찾는 사람은 없습니다.

5. 확장성은 더 이상 프론트엔드의 문제가 아닙니다

새로운 프레임워크가 등장할 때마다 사람들이 즉시 묻는 또 다른 질문은: “확장 가능합니까?“입니다. 하지만 그 질문은 약간 구식일 수 있습니다.

우리가 React를 사용하기 시작했을 때의 세상은 다른 문제를 가지고 있었습니다.

그 당시 대부분의 프론트엔드 UI는 바닐라 자바스크립트나 jQuery(또는 유사한 대안)로 작성되었습니다. 그리고 우리는 이제 그것이 특정 한계를 넘어서면 잘 확장되지 않는다는 것을 알게 되었습니다.

그 이유는 각 요소와 DOM 노드를 상호작용하려면 직접 선택자를 작성해야 했고, 상태를 추적하고 동기화하는 방법을 직접 만들어야 했기 때문입니다. 그 과정에서 DOM에 쓰고 읽는 작업이 많았는데, 이는 복잡하고 오류가 발생하기 쉽고, 가장 중요한 것은 느리다는 것이었습니다. (가상 DOM이 등장한 이유가 바로 이것이지만, 그것도 몇 년 전부터 상당히 구식이 되었습니다.)

그 당시에는 모듈식 코드를 작성하는 것이 어렵거나 불가능했습니다. JS 파일은 수백 줄, 심지어는 수천 줄까지 커졌습니다. 여러 저자가 같은 프로젝트를 작업하면 종종 코드를 재발명하거나 반복하거나 심지어는 서로의 코드를 덮어쓰곤 했습니다. (코드가 종종 공유 글로벌 네임스페이스에 들어가 충돌 가능성을 높였습니다.) 앱이 커지거나 복잡해질수록 문제가 더 심각해졌습니다.

프론트엔드에서 “확장 가능합니까?“라는 질문의 기준은 이것입니다. 앱이 기하급수적으로 커지더라도 적당히 유지 관리가 가능한가?

프론트엔드 프레임워크가 확장되지 않을 것이라는 우려는 jQuery만큼 오래되었으며, 현대 웹 개발과 관련해서는 구식으로 간주되어야 합니다.

React는 이러한 많은 문제를 해결했습니다. 하지만 그것이 최신 기술의 기적이어서가 아니라, 단순히 상태를 관리하고 공유하는 좋은 방법을 제시했기 때문입니다. 데이터 반응성을 만들고 복잡성을 추상화하며, 개발자들이 충돌이나 네임스페이스 충돌 없이 동일한 프로그래밍 패턴을 공유할 수 있게 했기 때문입니다.

React는 프론트엔드 확장성 문제에 대한 유일한 솔루션은 아니며, 최고도 아니었으며, 첫 번째도 아니었습니다. 그것은 단지 많은 가능한 패러다임 중 하나의 버전입니다.

(또한, React는 가장 오래된 것 중 하나입니다.)

어떻게 알 수 있습니까? 많은 벤치마크 테스트가 실행되었으며, React를 다른 모든 프론트엔드 프레임워크와 성능을 비교한 공개 결과가 있습니다. (여기서 링크를 걸지 않겠습니다. 온라인에서 쉽게 찾을 수 있습니다.) 모든 테스트는 현재의 프론트엔드 공간에서 React가 대부분의 경우 동등하거나 더 잘 수행된다는 것을 확인합니다.

여기서 나는 확장을 일반적인 의미로 언급합니다. 복잡성을 최소화하고, 앱이 커질수록 그 복잡성이 선형적으로 증가하지 않도록 합니다. 물론, 프레임워크마다 Markdown 파일에서 정적 HTML을 생성하는 것과 같은 보다 전문화된 작업에서는 훨씬 더 잘 확장될 수 있습니다.

6. 서버사이드 렌더링은 더 이상 특별하지 않습니다

몇 년 전만 해도, 서버 렌더링된 콘텐츠에 대해 React(주로 Next.js를 통해)가 거의 유일한 선택지였습니다. React가 클라이언트에서 단일 페이지 애플리케이션(SPA)으로 렌더링되는 대신, 서버에서 HTML로 렌더링될 수 있다는 아이디어에 많은 사람들이 흥분했습니다. 속도와 SEO 개선은 무시할 수 없는 장점이었으며, 초기에는 다른 프레임워크들이 이를 따라잡는 데 시간이 걸렸습니다.

하지만, 이러한 기술 트렌드에서 항상 그렇듯이, 첫 번째로 등장한 것이 반드시 최고인 것은 아닙니다.

SvelteKit은 기본적으로 서버 사이드 렌더링을 제공하며, 렌더링 패턴에 대해 세밀한 제어를 할 수 있도록 합니다. Vue의 메타 프레임워크인 Nuxt는 더 일찍 이 개념을 도입했습니다(Next에서 영감을 받았음이 분명합니다).

Deno의 프론트엔드 프레임워크인 Fresh는 ‘섬’으로 지정된 부분(클라이언트 렌더링)을 제외하고는 전부 서버 사이드 렌더링을 합니다. Fresh는 React보다 더 빠르고, useState와 반응성 모델의 더 성능이 좋고 사용하기 쉬운 버전인 Signals를 가진 Preact를 사용합니다.

Astro는 서버 사이드 렌더링을 지원하며, 원하는 컴포넌트 종류를 서버 사이드 렌더링할 수 있도록 합니다. 다른 프레임워크의 컴포넌트도 잘 렌더링할 수 있으며, 일부 경우에는 Next보다 성능이 더 좋다는 평가를 받기도 했습니다.

Solid의 메타 프레임워크인 SolidStart도 서버 사이드 렌더링을 지원합니다. Qwik은 아예 서버 사이드 렌더링을 중심으로 구축되었습니다. 오래된 프레임워크인 Ember와 Angular도 이와 관련된 기능을 갖추고 있습니다. 다른 프레임워크들도 많을 것입니다.

요점은 다음과 같습니다: 과거에는 React가 클라이언트 뷰 프레임워크 컴포넌트를 서버에서 렌더링할 수 있는 몇 안 되는 프레임워크 중 하나였습니다. 하지만 이제는 서버 사이드 렌더링이 기본 요건이 되었습니다. 많은 최신 프레임워크들이 서버 사이드 렌더링 옵션을 제공할 뿐만 아니라, 기본적으로 이를 수행하고 있습니다.

PHP가 다시 돌아왔습니다.

7. 양방향 데이터 바인딩은 어렵지 않고 나쁜 아이디어가 아닙니다

또는 이 섹션의 더 좋은 제목은: 폼은 그렇게 어렵지 않아야 합니다.

React는 Facebook에 의해 Facebook의 독특한 문제를 해결하기 위해 만들어졌다는 것을 기억하는 것이 중요합니다.

React의 강한 의견 중 하나인 데이터가 단방향으로만 흐른다는 것은 2010년대 초반 Facebook의 엔지니어링 과제가 React의 아키텍처에 깊이 반영된 것입니다.

일정 기간 동안 단방향 데이터 흐름이 최선의 관행으로 여겨졌습니다. 요즘에는 양방향 데이터 바인딩의 문제를 대부분 해결했으며, 많은 경우에 더 편리하다는 것을 알게 되었습니다.

React에서 폼을 작업하는 것은 악명 높게 복잡합니다. 사용자 입력의 모든 키 입력이 두 단계 과정이기 때문입니다. 입력 값 가져오기; 상태와 일치하도록 설정하기 (이로 인해 불필요하게 입력이 다시 렌더링됩니다). 물론, 보통 너무 빨라서 알아차리지 못할 수도 있지만, 이는 많은 추가 작업을 요구합니다.

이 때문에 React용 폼 라이브러리가 많이 있습니다. React에서 폼을 만드는 것은 악명 높게 가장 어려운 작업 중 하나입니다. 사실, 폼을 만드는 것이 이렇게 어렵다고 여겨지는 다른 도구는 알지 못합니다.

폼은 표준 웹 플랫폼 기능이며, 이후에 등장한 많은 프레임워크는 플랫폼을 신뢰하고 사용하기로 결정했습니다.

서버사이드를 잊고, 폼을 순전히 프론트엔드에서 다루더라도: Svelte, Vue 등 많은 다른 프레임워크는 같은 데이터 바인딩 및 동기화 문제를 가지고 있지 않습니다. 상태를 양방향으로 바인딩하여 양쪽 끝에서 자동으로 업데이트되도록 할 수 있습니다. 상태가 변경되면 DOM이 업데이트되고, DOM이 변경되면 상태가 업데이트됩니다.

이렇게 하면 여러 단계를 거칠 필요가 없습니다. 예를 들어 텍스트 상자의 값을 캡처하고 싶다면, 양방향 데이터 바인딩을 사용합니다. 그런 다음 사용자가 필드에 입력할 때 데이터가 자동으로 업데이트되고, 적절한 시점에 추가 단계 없이 가져올 수 있습니다. 그동안 값 설정이나 필드 지우기와 같은 작업이 필요하면 간단한 한 줄로 가능합니다.

양방향 데이터 바인딩을 통해 데이터와 DOM을 동기화하는 데 있어 서로가 따라잡아야 할 필요성을 줄일 수 있습니다.

이 방식을 사용하다가 문제가 생길 수 있나요? 물론입니다. 하지만 최선의 방법이라는 교조적인 이상이 도움이 되는 것 이상으로 방해가 되는 경우가 많다고 생각합니다. 한 방향 데이터 흐름은 그 대표적인 예입니다.

8. 스타일링은 사실 쉽습니다

대부분의 React 사용자는 프론트엔드 구성 요소의 스타일을 처리하는 두 세 가지 이상의 반복을 경험했을 것입니다.

JSX 구성 요소에 .css 파일을 직접 가져오거나, CSS Modules, Styled Components, Tailwind 등을 사용했을 것입니다(아마 classnames나 tailwind-merge 패키지 또는 둘 다, 그리고 몇 가지 추가 Tailwind 애드온과 함께 사용하셨을 것입니다). 그리고 그것들은 가장 인기 있는 옵션들입니다.

Tailwind는 그 자체로 토론할 주제입니다. 나는 그것이 플랫폼의 흐름을 거스르고, 단기적인 이득을 위해 장기적인 손실을 초래한다고 생각합니다. 그러나 React가 자체 스타일링 옵션이 없어서 이러한 스타일링 솔루션들이 존재하고 널리 채택되었다는 점은 부인할 수 없습니다.

다른 프레임워크에서는 스타일링이 해결된 문제라는 사실을 모를 수도 있습니다.

특히, Vue와 Svelte는 각자의 컴포넌트 스타일링 방식이 있습니다. 두 프레임워크 모두 컴포넌트 레벨의 범위 지정 스타일링을 지원합니다(Vue는 선택적, Svelte는 기본 제공). 이들은 기본 CSS와도 잘 작동합니다. 하지만 이 두 프레임워크—그리고 다른 모든 프론트엔드 프레임워크—는 CSS 모듈, Tailwind, Sass 등 원하는 모든 스타일링 방법과 호환됩니다.

가장 중요한 점은 CSS의 모든 문제점—이 문제점들이 실제로 문제가 된다고 생각하든 아니든—이 기본 스타일 처리로 완벽하게 해결된다는 것입니다. 패키지와 설정이 복잡할 필요가 거의 없으며, 범위 지정 CSS는 상상할 수 있는 거의 모든 문제를 해결해줍니다.

진지하게, CSS가 나쁘다고 주장하는 이유 목록을 읽어보세요 (CSS는 나쁘지 않지만, CSS를 잘 다루지 못하는 사람들이 그렇게 말하곤 합니다). CSS에 대한 비판은 거의 모두 범위 지정 스타일링으로 해결되며, 여러 비-React 프레임워크는 이미 이를 기본 제공하고 있습니다.

9. 프레임워크 배우는 것이 이제는 그렇게 어렵지 않습니다

React에 주로 익숙한 개발자들은 React를 배우는 것이 얼마나 어려웠는지를 생각하고, 다른 프레임워크의 학습 곡선을 비슷하게 평가할 것입니다. 그것이 우리가 새로운 것을 시도하지 않는 이유일 것입니다. 매우 어렵게 느껴지기 때문입니다.

상태 관리, props, 중첩, 컴포넌트 생명주기, hooks, 그리고 JSX 작성 방법 등 모든 것을 배우는 것은 많은 시간이 필요합니다. 열성적인 React 팬들조차도 초보자들이 빠르게 배우기 쉽지 않다는 점을 인정할 것입니다. (그렇지 않다고 말하는 사람들은 아마 초보자였던 때를 잊었을 것입니다.)

이 상황에 공감한다면 좋은 소식이 있습니다:

React만큼 배우기 어려운 도구는 없습니다. 한 프레임워크를 알면 다른 프레임워크를 배우는 데 큰 도움이 됩니다.

이것은 두 번째 악기를 배우는 것과 비슷합니다. 처음 악기를 배울 때는 음악에 대한 모든 것을 배우고, 특정 악기를 배우며 원하는 소리를 내기 위해 노력합니다. 두 번째 악기를 배울 때는 대부분의 개념이 익숙합니다. 음악을 이해하고, 익숙한 개념을 약간 다른 형태로 옮기면 됩니다.

프론트엔드도 비슷합니다. 모든 프론트엔드 프레임워크에는 컴포넌트가 있습니다. 모든 프레임워크는 TypeScript와 호환됩니다. props, children, 반응형 상태의 개념이 있습니다. 우리는 이러한 것들이 좋고 유용하다는 것을 알고 있습니다. 다만, 구현 방식은 다릅니다.

React는 이러한 개념을 확산시키는 데 큰 역할을 했지만, React가 이들의 이상적인 구현이라고 할 수는 없습니다.

훌륭한 것들은 반복을 통해 만들어지며, 대부분의 다른 선택지는 더 나은 것들을 구현하기 위해 React의 핵심 아이디어를 기반으로 발전했습니다.

React는 메인 브랜치에서 뒤처진 git 브랜치와 같습니다. React가 당신의 세계의 중심이라면 깨닫지 못할 수 있지만, 프론트엔드는 발전했습니다. 생태계는 이러한 아이디어를 채택하고 더 발전하여 더 나은 것들을 만들었습니다.

우리는 이제 더 성능이 좋고, 복잡성이 적으며, 배우기 쉬운 옵션이 많습니다. React를 알고 있다면 다른 프레임워크를 배우는 것도 어렵지 않을 것입니다.

추가 섹션: 2023년 8월 15일 추가된 내용

10. 다른 옵션들은 단지 “새롭고 반짝이는” 것이 아닙니다 (그리고 아무도 그것에 신경 쓰지 않습니다)

이와 같은 글을 논의할 때 종종 들리는 반응은:

“저 바보 같은 자바스크립트 개발자들, 항상 새롭고 반짝이는 것을 쫓고 있어! 그들은 장기적인 프로젝트 유지 관리에 신경 쓰지 않아. 뜨거운 새로운 프레임워크는 내일 잊혀질 것이며, 그들의 코드는 실행조차 되지 않을 거야!”

여기에는 일말의 진실이 있습니다. 자바스크립트 개발자들 (프론트엔드 개발자들 전반적으로) 새로움에 끌리는 경향이 다른 프로그래밍 전문가들보다 더 경계심이 적다는 것은 사실입니다.

하지만 그게 얼마나 사실일까요? 모든 자바스크립트 개발자가 새로운 것이 나올 때마다 전체 기술 스택을 다시 작성하려는 걸까요? 아니면 끝없는 온라인 하입 사이클 때문에 그렇게 느껴지는 걸까요?

실제로는 그렇지 않다고 생각합니다. 초기 기술을 채택하는 사람들이 가장 많은 관심을 받습니다. 그들은 모든 블로그 게시물을 쓰고 모든 비디오를 만들며, 그들이 하는 일은 훨씬 더 많은 이런 행동이 일어나는 것처럼 보이게 합니다. (결국, 만약 그게 반만이라도 사실이라면, React의 시장 점유율은 현재의 일부분일 것입니다.)

대부분의 프론트엔드 개발자는 다른 종류의 개발자들처럼 익숙한 것을 고수합니다. 우리는 새로운 것에 조금 더 쉽게 접근할 수 있어서 그렇습니다.

그건 그렇고, 이 견해는 현장에서 이용 가능한 다른 옵션들의 성숙도를 과소평가합니다.

Vue는 React만큼 오래되었고, 현재 버전(v3)은 거의 3년 전에 출시되었습니다. 현대적인 Svelte 버전은 React 훅이 출시된 지 두 달 후에 출시되었습니다. SvelteKit은 거의 1년 전에 1.0 버전을 출시했습니다. Preact는 버전 10입니다. Solid는 2년 넘게 1.0+ 상태입니다. Astro는 1년 전에 1.0 버전을 출시했습니다. Qwik과 Fresh는 올해 초에 1.0 버전을 출시했습니다.

따라서 이들 중 일부가 아직 너무 새롭다면 괜찮습니다. 이해합니다. 하지만 React 대안에 대한 모든 고려를 짧은 주의 집중력으로 줄이는 것은 성숙도와 깊이를 과소평가하는 것입니다.

11. React는 성능 면에서 <많이> 뒤쳐져 있습니다

이 주제에 대해 너무 길게 말하지 않겠습니다. 이와 관련하여 많은 글이 이미 작성되었고, 이 글에서도 많은 것을 다루었습니다. 하지만 간단히 말하자면: React가 느린 이유는 사소한 차이 같지만 그렇지 않습니다.

React는 성능 면에서 뒤쳐집니다 (번들 크기와 실행 속도 모두). JS 웹 프레임워크 벤치마크에서 React의 성능은 평균적으로 Solid보다 50% 느리고, Vue보다 25% 느리며, Svelte보다 40% 느리고, Preact보다 35% 느립니다.

이것은 React 훅만 사용한 비교입니다. useTransition 훅이나 추가 라이브러리는 포함하지 않았습니다.

다른 연구들도 있습니다. 숫자는 조금씩 다를 수 있고, 그들의 결과에는 항상 뉘앙스가 있을 것입니다. 하지만:

어떤 결과를 참조하든, React는 이후에 나온 거의 모든 것보다 크고 느릴 것입니다.

경험적으로: 안드로이드에서 입력 양식을 작성할 때 React를 사용하는지 알 수 있습니다. React를 사용할 때의 느림과 상태와 DOM을 일치시키는 반복적인 작업이 눈에 띕니다.

하지만 경험을 떠나 데이터로 보자면, 이러한 숫자들이 작게 들릴 수 있고, 성능이 기술 스택을 선택할 때 고려해야 할 많은 요소 중 하나일 수 있습니다. “모든 것은 상황에 따라 다르다.”

하지만 성능 향상이 25–50%라는 것은 엄청난 차이입니다. 프론트엔드 로딩 속도를 두 배로 빠르게 만드는 것은 단순히 좋아 보이는 것이 아니라, 대규모로 보면 엄청난 차이를 만들어냅니다.

웹사이트 로딩 시간이나 작업 완료를 기다리는 시간에 대한 많은 연구들이 얼마나 소중한지 보여줍니다. 큰 자바스크립트 번들을 다운로드할 대역폭이 없거나, 프레임워크가 페이지에서 변경할 때마다 두 배 더 기다려야 하는 컴퓨팅 파워가 없는 사용자를 고려하는 것이 얼마나 중요한지도 말씀드릴 필요는 없을 것입니다.

이러한 큰 로딩 또는 처리 시간을 줄인 엔지니어는 그것을 이력서의 주요 성과로 기록할 것입니다. 이는 큰 문제입니다.

React와 다른 프레임워크 간의 성능 차이는 사소하지 않습니다. 이는 최소화된 것입니다.

Part 3: 시도해볼 만한 다른 것들

몇 문단 전부터 궁금해졌을 것입니다. React가 그렇게 낡았다면 대안은 무엇일까요?

여러 가지를 다루면서 각 사용 사례도 언급하겠습니다. React의 문제 중 하나는 모든 사람에게 모든 것이 되려고 너무 오래 시도해왔다는 것입니다. React 형태의 도구가 유용할 수 있지만, 두세 가지 다른 도구가 하나의 스위스 군용 칼보다 나을 수 있다고 생각합니다.

잠깐, 두 가지 주의사항이 있습니다:

1. 여기서 언급한 모든 최신 프레임워크를 다루기 위해 여러 가지 옵션을 나열했습니다. 모든 것을 배우거나 사용하는 것을 기대하지 않습니다. 하나를 선택해야 한다면, Svelte나 Vue를 추천합니다. 하지만 모든 것을 다루기 위해 나열한 것임을 알아두세요.

2. 모든 옵션을 나열하지는 않았습니다. Ember와 Angular는 React보다 오래되었고, 벤치마크 테스트에서 React보다 뛰어나지 않기 때문에 생략했습니다.

   Alpine과 Petite Vue와 같은 경량 옵션도 생략했습니다. 이들은 React보다는 jQuery를 대체하는 데 더 적합하고, 프레임워크가 필요하지 않을 때 빛을 발합니다.

   마지막으로, Eleventy와 같은 탁월한 도구도 생략했습니다. Eleventy는 순수 정적 사이트 생성기이기 때문에 생략했습니다. (Gatsby를 사용 중이라면 여전히 고려할 가치가 있습니다.)

자, 이제 시작해봅시다.

Svelte (내 개인적인 선택)

여러분, 2023년의 여러분께 드리는 한 가지 조언: Svelte를 사용하세요.

농담을 제쳐두고: React 대신 추천할 한 가지가 있다면 Svelte입니다. 저는 오랫동안 “Svelte는 React의 번거로움 없는 버전”이라고 주장해왔습니다. 이는 시간이 지남에 따라 더욱 진실이 되어가고 있습니다.

Svelte는 사용하기 매우 간단하고, 배우기 쉬우며 (특히 React를 이미 알고 있다면), 거의 모든 경우에 훨씬 더 성능이 뛰어나며, React보다 더 많은 기능을 수행할 수 있습니다. 이 사이트와 제 모든 사이드 프로젝트는 SvelteKit으로 작성되었습니다.

Svelte는 빠릅니다. 가장 빠른 옵션과 비교할 만합니다. 개발자 경험(DX)은 훌륭합니다. 개발자 설문조사에서 가장 사랑받는 프레임워크 중 하나입니다.

Svelte는 가능한 한 웹 플랫폼에 가깝게 유지되므로, 매우 강력하지만 개념은 대부분 익숙할 것입니다. Svelte는 또한 전환, 이징, CSS 처리, 컴포넌트 스코프 스타일 등을 기본적으로 포함합니다.

이는 프레임워크 크기에 대해 궁금할 수 있습니다. 하지만 Svelte는 자바스크립트 런타임이 아닌 컴파일러입니다. 사용하지 않는 것은 빌드 시 제거되며, 코드는 작은 바닐라 자바스크립트 조각으로 변환됩니다. 이는 Svelte의 번들이 일반적으로 React보다 훨씬 작다는 것을 의미합니다.

Svelte는 프레임워크처럼 느껴지고 작동하지만, 본질적으로 간단한 문법을 가진 작은 우아한 HTML 상위 집합으로, 빠르고 최소한의 번들로 컴파일됩니다.

Svelte의 메타 프레임워크인 SvelteKit은 매우 다재다능하고 강력하며, 정적, 서버 렌더링, 엣지 배포 등을 지원합니다. 2022년 말에 1.0 버전을 출시했으며, 프로덕션 준비가 완료되었습니다. (Next.js를 만드는 Vercel에서도 지원합니다.)

Svelte 추천 이유:

위에서 언급한 이유로 프론트엔드의 기쁨을 다시 찾고 싶다면.

Svelte 대체 가능 항목:

React로 하고 있는 모든 것. Svelte는 React 자체를 대체할 수 있으며, SvelteKit은 Next, Gatsby, Remix 등을 대체할 수 있습니다.

Vue

Vue는 아마도 React에 가장 가까운 옵션이며, 다음으로 큰 생태계를 가지고 있을 가능성이 큽니다. 그러나 성능 면에서 React보다 훨씬 뛰어나며, 조금 더 UI에 집중되어 있습니다.

어떤 면에서는 Vue가 React에서 가장 작은 도약일 것입니다. 특히 Vue 3에서는 유사한 훅 기반 접근 방식을 가지고 있기 때문입니다. 그러나 Vue는 JSX보다 기본 HTML에 더 가까운 템플릿 언어를 사용하므로, 템플릿 파일에서 조건문과 루프를 작성하기가 훨씬 쉽습니다. map과 삼항 연산자를 사용하지 않아도 됩니다.

Vue는 Next와 유사한 메타 프레임워크인 Nuxt를 가지고 있으며, 이는 잘 유지 관리되고 강력한 새로운 기능을 추가하고 있습니다. Vue는 React보다 더 배터리가 포함된 프레임워크로, 컴포넌트 스코프 CSS 처리와 쉬운 전환/애니메이션 등을 기본적으로 포함합니다.

Vue 추천 이유:

커뮤니티 크기/전체 프레임워크 인기도가 중요한 요소라면; React와 비슷하지만 더 배터리가 포함된 또는 HTML 같은 것을 원한다면; 대기업이 소유하지 않은 독립 프레임워크를 선호한다면.

Vue 대체 가능 항목:

React 자체 또는 Nuxt는 Next를 사용하는 것을 대체할 수 있습니다.

Solid

Solid는 React보다 더 낫다고 볼 수 있습니다. 많은 경우 React와 거의 (또는 완전히) 동일하게 보이지만, Solid는 훨씬 더 성능이 뛰어납니다. 사실, 가장 빠른 옵션 중 하나입니다.

Solid는 기본적으로 React에서 시작하여 복잡성, 성능 문제 및 많은 보일러플레이트를 제거하기 위해 재구성되었습니다. Solid에는 Signals라는 개념이 도입되어 컴포넌트 렌더링과 생명 주기 주위의 많은 혼란과 발목을 잡는 문제를 제거합니다. Solid는 현대 시대에 React를 구축한 것처럼 React를 재구성한 것이라고 할 수 있습니다.

Solid는 현재 베타 버전인 자체 메타 프레임워크인 SolidStart도 제공합니다. Solid 자체는 사용할 만큼 충분히 성숙했으며, 인상적인 후원자 목록을 자랑합니다.

Solid 추천 이유:

React(JSX)를 일반적으로 좋아하지만, 더 현대적이고 빠르며 더 쉽기를 바란다면; 성능이 절대 최우선 순위라면.

Solid 대체 가능 항목:

React와 React DOM. SolidStart는 향후 Next를 대체할 수 있을 것입니다. 하지만 이 글을 쓰는 시점에서는 여전히 베타 버전입니다.

Fresh

Fresh는 Deno에서 빌드된 섬 아키텍처를 가진 서버 렌더링 프론트엔드 프레임워크입니다. 이 목록의 다른 항목보다 약간 젊지만, 엣지에서 실행될 수 있는 최소한의 JS, 섬 기반 프레임워크로 약속이 가득합니다. 서버 코드는 더 빠르고, 더 안전하며, 기본적으로 TypeScript이며, 전통적인 Node보다 Deno가 제공하는 모든 이점을 가지고 있습니다 (예: 더 쉬운, 일급 린팅, 테스트 및 코드 포맷팅 설정).

모든 Fresh 컴포넌트는 정적으로 렌더링되어 응답 시간에 HTML로 제공되며, JavaScript는 없습니다. 또는 클라이언트에서만 렌더링되는 “섬”입니다. 필요한 대로 혼합하고 일치시킬 수 있습니다. Deno에서 실행되기 때문에, 전 세계 어디서나 가능한 한 빨리 로드되는 매우 빠른 동적 콘텐츠를 제공할 수 있습니다.

Fresh는 Preact를 사용하므로 빠르며, React에서 오는 경우에도 배우기 어렵지 않습니다. 그리고 다시 한 번: Deno에서 빌드하는 것은 훌륭합니다.

Fresh 추천 이유:

클라우드에서 전 세계적으로 사용 가능한 서버 사이드 앱 아이디어가 마음에 들고, 최소한의 JavaScript를 제공하고 최신 기술로 빌드하고 싶다면.

Fresh 대체 가능 항목:

Remix는 React 세계에서 Fresh와 가장 가까운 것일 것입니다.

Astro

Astro는 성능이 뛰어난 차세대 정적 사이트 생성기입니다. 이 목록에서 가장 새로운 옵션 중 하나이지만, 이미 매우 안정적인 1.0 릴리스 상태이며, 널리 칭찬과 채택을 받았습니다.

주로 새로운 세대의 SSG로 구축되었으며 (React 팬들에게: JSX와 MDX를 지원합니다), Astro는 이제 동적, 서버 사이드 기능도 갖추고 있습니다. Gatsby를 사용 중이라면 Astro를 추천합니다.

진정한 킬러 기능은: Astro는 기본적으로 JavaScript를 전혀 제공하지 않습니다. 원하는 것을 선택하여 사용할 수 있습니다.

Astro는 원하는 프론트엔드 프레임워크와 호환됩니다. React, Vue, Svelte 등으로 템플릿을 작성할 수 있습니다.

Astro 추천 이유:

대부분 정적이거나 콘텐츠/Markdown 기반 사이트를 구축하고 있으며, 서버사이드 렌더링이나 로직이 필요할 수 있습니다. 최소한의 JavaScript를 제공하고 싶다면; 프론트엔드 프레임워크를 사용하고 싶다면.

Astro 대체 가능 항목:

Gatsby 또는 유사한 React 기반 콘텐츠 도구.

Preact

React 영역에 살고 있다면 이미 Preact에 대해 알고 있을 것입니다. 하지만 여기서 언급할 가치가 있습니다. React의 훨씬 슬림하고 빠른 버전입니다. 원래는 React의 대체품으로 시작했지만, 이제는 React가 가지지 않은 몇 가지 우수한 기능 (예: Signals)을 얻기 시작했습니다.

Preact 추천 이유:

기본적으로 React를 사용하고 싶지만 더 빠르게 만들고 싶다면.

Preact 대체 가능 항목:

React. (사실, 앞에 P를 추가한 것입니다. P는 성능(Performance)을 의미합니다. 그것은 내가 만든 것이며, Preact 팀을 비난하지 마세요.)

Qwik

Qwik은 React와 유사한 코드(JSX)를 서버에서 렌더링하고, 새로운 방식으로 성능을 개선합니다. 사실, 이것을 “하이드레이션”이라고 부를 수 없습니다. 대신, JavaScript를 DOM에 직렬화하고 필요할 때만 작은 조각으로 로드합니다. Qwik은 이 목록에서 더 깊은 선택이지만, 가능한 한 빠르게 실행해야 하는 많은 상호작용이 있는 경우 고려할 만한 가치가 있습니다.

Qwik 추천 이유:

브라우저로 많은 JavaScript를 제공하고, 이를 더 성능 높게 만드는 방법을 원한다면.

Qwik 대체 가능 항목:

React 자체를 대체하며, 엣지에서 매우 효율적으로 실행됩니다.

웹 컴포넌트 라이브러리

이 주제에 대해 깊이 다루지는 않겠습니다. 솔직히, 나는 그 분야의 전문가가 아닙니다. 독립적인 웹 컴포넌트나 웹 컴포넌트 프레임워크에 대한 경험이 많지 않아서입니다.

그렇지만 특정 프로젝트 클래스는 Lit, Stencil, Polymer 등의 웹 컴포넌트 프레임워크/라이브러리에서 이점을 얻을 수 있습니다. 특정 프론트엔드 프레임워크에서 “전용” 컴포넌트를 생성하는 대신, 이러한 라이브러리는 실제 웹 컴포넌트를 작성하는 데 도움이 되며, 이는 모든 웹 프로젝트에 이동할 수 있습니다.

내 생각에, 대부분의 프로젝트는 순수한 웹 컴포넌트 접근 방식보다는 프론트엔드 프레임워크를 사용하는 것이 더 이점이 있습니다. 아니면, 최소한 두 가지를 함께 사용하는 것이 더 나을 것입니다. 언젠가는 이 점이 바뀔 수 있지만, 현재로서는 대부분의 경우 순수한 웹 컴포넌트 접근 방식의 거래 비용이 더 크다고 생각합니다.

그럼에도 불구하고, 순수한 웹 컴포넌트 기반 접근 방식이 고려되어야 하는 특정 사용 사례가 있습니다. 그리고 이러한 프로젝트에는 React가 확실히 과잉입니다. 위에서 언급한 웹 컴포넌트 라이브러리가 훨씬 더 나은 선택이 될 것입니다.

웹 컴포넌트 라이브러리 추천 이유:

동일한 컴포넌트를 여러 환경에서 재사용해야 하거나, 프레임워크 변경에 대비해 미래 지향적이고 싶거나, 플랫폼을 사용하고 싶고 웹 컴포넌트 작성의 거래 비용을 감수할 준비가 되어 있다면.

웹 컴포넌트 대체 가능 항목:

React, 그러나 사용 사례에 따라 부분적으로 대체될 수 있습니다.

Epilogue

솔직히 말하면, 이 글은 작년의 글 “React의 자기 성취 예언”과 매우 비슷합니다. 일부 동일한 영역을 다루고 있으며, 동일한 주장을 펼치고 있습니다 (다만, 새롭거나 다른 관점에서 말하려고 노력했습니다).

자기 반복을 하려고 했던 것은 아니지만, 분명히 이 주제를 많이 생각하게 됩니다—아마도 그 글이 게시된 시점과 맞물려 React를 풀타임으로 작업하게 된 것이 계기가 되었을 것입니다.

React의 인기는 사람들이 그 너머를 보지 않기 때문이라는 생각이 점점 더 커졌습니다. React가 최고의 것은 아니지만, 대부분의 사람들은 최고의 것을 찾는 것이 아닙니다. 그저 충분히 좋은 것을 찾는 것입니다. (우리는 인간입니다. 모든 결정에는 많은 개인적, 감정적, 비합리적 이유가 있으며, 이는 괜찮습니다. 우리는 바쁩니다.)

프론트엔드 세계에서는 기술을 점진적으로 채택하기보다는 도약적으로 채택하는 것 같습니다. React 붐이 일어난 이유 중 하나는 그 당시 모든 사람들이 구식 기술에 갇혀 있었고, 더 나은 것을 찾고 있었기 때문입니다. 우리는 새로운 것에 점진적으로 나아가지 않았습니다. 큰 도약을 했습니다.

선형적으로 앞으로 나아가는 화살표가 그려진 ‘진보’라는 선 위에 ‘채택’이라는 라벨이 붙은 몇 개의 아치형 도약이 있습니다. 마지막 도약은 직선 ‘진보’ 선의 가장 먼 끝에 도달하지 못합니다.

문제는: 우리는 그 도약을 한 이후로 대부분 같은 자리에 머물러 있다는 것입니다.

제 생각에는: 또 다른 도약이 가까워지고 있습니다.

그것이 무엇일지, 왜 그런지 모르겠습니다. 하지만 우리는 React가 실제로 해결하지 못하는 모든 문제를 느끼기 시작하고 있는 것 같습니다. 마치 그 옛날 jQuery에서 느꼈던 것처럼요. 결국, 앞으로 나아갈 때가 될 것이라는 것이 명확해질 것입니다.

그 새로운 것이 무엇일까요? 모릅니다. 아마도 웹 플랫폼일 것입니다. 프레임워크가 필요 없을 수도 있습니다. 아마도 위에 언급한 프레임워크일 것입니다. 아니면 아직 보지 못한 무언가일 것입니다. 어쩌면 하나의 것이 아닐 것입니다. 더 다양한 도구가 존재하고 하나의 표준에 집착하지 않을 것입니다. (위의 모든 옵션 중에서 가장 가능성이 낮다고 생각하지만, 다시 말하지만: 우리는 바쁜 작은 원숭이들이며 기본값을 좋아합니다.)

하지만 React와 그 새로운 것 사이의 차이는 시간이 지남에 따라 점점 커질 것입니다.

따라서 매일이 당신이 놓친 것을 탐색하기에 이전보다 더 좋은 날입니다.

Happy listening.