Backbone, Angular 1, Ember, React까지 모두 써봤음
React가 인기를 얻은 이유를 간과하면 안 됨. 컴포넌트 합성, 이벤트 처리, 상태 관리, 효율적인 DOM 업데이트 등에서 React는 기존 프레임워크의 고질적인 문제를 해결했음
Backbone은 DOM 생명주기 관리가 복잡하고, 이벤트 핸들러를 문자열로 지정해야 해서 유지보수가 어려웠음. React는 단방향 상태 흐름과 가상 DOM으로 이런 문제를 단순화했음
지금이라면 순수 JS를 쓰고 싶을 때는 Backbone보다 lit-html 같은 템플릿 솔루션이 훨씬 낫다고 생각함
예시가 현실적이지 않다고 느낌. 비교하려면 TodoMVC가 대표적임. Backbone 버전은 이 코드를 보면 유지보수 악몽 수준임. React 버전(링크)은 훨씬 명확함
프론트엔드는 예전에도 복잡했고 지금도 복잡하지만, 지금은 훨씬 덜 고통스러움
동의함. React도 완벽하진 않지만 결국 타협의 문제임. 어떤 도구를 쓰든 개발자가 그 복잡성을 감당해야 함. 중요한 건 우리가 올바른 타협점을 선택하고 있는가 하는 점임
요즘은 React 말고도 이런 기능을 제공하는 프레임워크가 많음. React만의 특권은 아님
앱의 복잡도는 컴포넌트 수가 아니라 상태 관리에서 비롯됨
Backbone Store의 양방향 데이터 흐름 때문에 UI가 멈추는 문제를 자주 겪었음. React의 혁신은 단방향 데이터 흐름을 중심으로 한 Flux 아키텍처였음
좋은 프레임워크는 “성공의 함정(Pit of Success)”으로 자연스럽게 이끌어주는 도구라고 생각함. React는 그 역할을 잘 해왔음
React/Flux/Redux 이전의 프론트엔드 개발은 정말 혼돈이었음. 1000줄도 안 되는 코드에서도 상태 관리 문제가 터졌음
글쓴이임. 단방향 데이터 흐름이 문제를 해결한 건 맞지만, React도 새로운 복잡성을 가져왔음
예를 들어 stale closure, 무한 useEffect 루프, 키 변경으로 인한 입력 초기화 같은 문제는 Backbone에는 없었음
Backbone의 문제는 눈에 보였고 디버깅이 쉬웠지만, React의 문제는 추상화 뒤에 숨어 있음
대부분의 앱은 Facebook 규모가 아니므로, 명시적이고 단순한 접근이 오히려 더 나을 수도 있음
Angular를 오래 하다가 React로 돌아왔는데, 완벽하진 않아도 React는 개발자가 올바른 방향으로 코딩하게 유도함
컴포넌트 자체가 또 다른 복잡성임. 마크업, 이벤트, 비즈니스 로직, 접근성까지 한데 묶여 거대한 구조가 됨. 결국 편안함을 위한 복잡성일 뿐 단순함은 공짜가 아님
“단방향 데이터 흐름”은 사실 DOM의 기본 동작과 비슷하지 않나? React 팀이 만든 건 Flux, Flow가 아님
인기 있는 기술을 “나쁘다”고 단정하는 건 일종의 순진한 오만함 같음
물론 인기가 품질을 보장하진 않지만, 전 세계의 뛰어난 엔지니어들이 모두 속았다고 보는 건 과함
인기 기술이 항상 옳은 건 아님. MongoDB, Kafka, Microservice 유행을 떠올려보면 됨
대기업과 마케팅이 밀면 CTO들이 채택하고, 커리어가 걸리면 아무도 “이건 별로”라고 말하지 않음. 인기 ≠ 적합성임
글쓴이임. “팔레오 인플루언서” 비유는 흥미롭지만, 새롭다고 무조건 좋은 것도 아님
React는 기술적 우수성만으로 승리한 게 아니라 Facebook의 마케팅과 생태계 자기강화 덕분이었음
15년이 지난 지금도 코드 길이나 복잡도는 크게 줄지 않았음. 단지 다른 방식으로 복잡해졌을 뿐임
과거를 돌아보는 건 향수 때문이 아니라, 우리가 비례하지 않는 복잡성을 추가했는지 점검하기 위함임
React나 Tailwind는 채용 친화성이 강점임. 기술적 완벽함보다는 온보딩 용이성이 이유임
웹은 여전히 디자인 패턴의 서부 개척지 같음. 그걸 받아들이고 나니 마음이 편해졌음
React를 “어리석다”고 단정하는 건 오만과 무지의 혼합처럼 보임. 수백만 개발자가 쓰는 이유가 있음. 완전한 부정은 Chesterton’s Fence를 무시하는 태도임
오만이라기보다 다른 관점의 경험일 수도 있음. React의 생태계를 좋아하는 사람도 있고, JS 양이 많아 싫어하는 사람도 있음
결국 프로젝트마다 트레이드오프를 재평가해야 함
“간단한 일엔 React가 필요 없다”는 주장은 흔한 React 오류(React fallacy) 임
단순한 예제로 React를 평가하는 건 “Hello World 길이로 언어를 평가”하는 것과 같음
간단한 일에도 React를 쓰는 이유는, 복잡한 일에도 React를 쓰기 때문임. 일관된 도구 세트가 유지보수에 유리함
“복잡한 일에도 쓰니까 단순한 일에도 쓴다”는 건 마치 트럭으로 장보러 가는 것 같음. 결국 적절한 도구 선택이 핵심임
Backbone은 “프레임워크처럼 보이지만 실제론 접착 코드 덩어리”였음
React의 진짜 승리는 DOM 직접 조작이 필요 없고, 반응형 상태 관리가 가능해진 점임. 이 두 가지가 개발 생산성을 크게 높였음
예전 Backbone 튜토리얼을 많이 썼던 사람으로서 약간 향수가 있음 예전 튜토리얼 링크, 아카이브 버전
요즘은 LLM이 코드를 어떻게 이해하느냐에 더 관심이 있음. JSX 같은 선언적 문법은 LLM 친화적임
하지만 useEffect 이후의 React는 표현력과 명시성 면에서 오히려 흐려진 느낌임
Marionette가 Backbone의 보일러플레이트를 많이 줄여줬음
React에 내장된 상태 관리가 있냐는 질문이 나옴
React가 인기 많아진 이유가 잘 드러남
React 코드는 대부분 순수 JS와 HTML이고, 핵심은 useState 하나뿐임. 직관적이라 문서 없이도 이해 가능함
Backbone은 .space-y-2 같은 문자열 셀렉터에 의존해 유지보수가 지옥이었음. 클래스명 하나 바꾸면 앱 절반이 깨짐
React는 이런 문제를 구조적으로 해결했음
6년 전 팀을 Backbone에서 Angular로 옮겼음
Backbone은 직관적이고 마법이 없는 구조라 주니어에게 좋았지만, 결국 TypeScript와 Angular가 더 체계적이었음
지금은 NG20을 쓰고 있고 만족함. 언젠가 브라우저가 더 많은 기능을 기본 제공하면, 다시 단순한 방식으로 돌아갈 수도 있을 것 같음
우리는 항상 추상화 위에서 프로그래밍하고 있음
중요한 건 그 추상화가 복잡성 대비 생산성 이득을 주는지, 그리고 신뢰할 수 있는지임
최악의 경우라도 디버깅 가능해야 함
React의 입력 필드가 Backbone보다 Undo 동작을 더 자연스럽게 처리함
Backbone은 한 글자씩 되돌리지만 React는 단어 단위로 되돌림
왜 브라우저 기본 동작을 덮어쓰는 게 더 낫다는 건지 이해가 안 됨. 오히려 자연스러운 스크롤을 망치는 JS 라이브러리 같음
흥미롭게도 Chrome에서는 다르지만 Firefox에서는 두 프레임워크 모두 동일하게 동작함
Hacker News 의견
Backbone, Angular 1, Ember, React까지 모두 써봤음
React가 인기를 얻은 이유를 간과하면 안 됨. 컴포넌트 합성, 이벤트 처리, 상태 관리, 효율적인 DOM 업데이트 등에서 React는 기존 프레임워크의 고질적인 문제를 해결했음
Backbone은 DOM 생명주기 관리가 복잡하고, 이벤트 핸들러를 문자열로 지정해야 해서 유지보수가 어려웠음. React는 단방향 상태 흐름과 가상 DOM으로 이런 문제를 단순화했음
지금이라면 순수 JS를 쓰고 싶을 때는 Backbone보다 lit-html 같은 템플릿 솔루션이 훨씬 낫다고 생각함
프론트엔드는 예전에도 복잡했고 지금도 복잡하지만, 지금은 훨씬 덜 고통스러움
앱의 복잡도는 컴포넌트 수가 아니라 상태 관리에서 비롯됨
Backbone Store의 양방향 데이터 흐름 때문에 UI가 멈추는 문제를 자주 겪었음. React의 혁신은 단방향 데이터 흐름을 중심으로 한 Flux 아키텍처였음
좋은 프레임워크는 “성공의 함정(Pit of Success)”으로 자연스럽게 이끌어주는 도구라고 생각함. React는 그 역할을 잘 해왔음
예를 들어 stale closure, 무한 useEffect 루프, 키 변경으로 인한 입력 초기화 같은 문제는 Backbone에는 없었음
Backbone의 문제는 눈에 보였고 디버깅이 쉬웠지만, React의 문제는 추상화 뒤에 숨어 있음
대부분의 앱은 Facebook 규모가 아니므로, 명시적이고 단순한 접근이 오히려 더 나을 수도 있음
인기 있는 기술을 “나쁘다”고 단정하는 건 일종의 순진한 오만함 같음
물론 인기가 품질을 보장하진 않지만, 전 세계의 뛰어난 엔지니어들이 모두 속았다고 보는 건 과함
대기업과 마케팅이 밀면 CTO들이 채택하고, 커리어가 걸리면 아무도 “이건 별로”라고 말하지 않음. 인기 ≠ 적합성임
React는 기술적 우수성만으로 승리한 게 아니라 Facebook의 마케팅과 생태계 자기강화 덕분이었음
15년이 지난 지금도 코드 길이나 복잡도는 크게 줄지 않았음. 단지 다른 방식으로 복잡해졌을 뿐임
과거를 돌아보는 건 향수 때문이 아니라, 우리가 비례하지 않는 복잡성을 추가했는지 점검하기 위함임
웹은 여전히 디자인 패턴의 서부 개척지 같음. 그걸 받아들이고 나니 마음이 편해졌음
결국 프로젝트마다 트레이드오프를 재평가해야 함
“간단한 일엔 React가 필요 없다”는 주장은 흔한 React 오류(React fallacy) 임
단순한 예제로 React를 평가하는 건 “Hello World 길이로 언어를 평가”하는 것과 같음
간단한 일에도 React를 쓰는 이유는, 복잡한 일에도 React를 쓰기 때문임. 일관된 도구 세트가 유지보수에 유리함
Backbone은 “프레임워크처럼 보이지만 실제론 접착 코드 덩어리”였음
React의 진짜 승리는 DOM 직접 조작이 필요 없고, 반응형 상태 관리가 가능해진 점임. 이 두 가지가 개발 생산성을 크게 높였음
예전 튜토리얼 링크, 아카이브 버전
요즘은 LLM이 코드를 어떻게 이해하느냐에 더 관심이 있음. JSX 같은 선언적 문법은 LLM 친화적임
하지만 useEffect 이후의 React는 표현력과 명시성 면에서 오히려 흐려진 느낌임
React가 인기 많아진 이유가 잘 드러남
React 코드는 대부분 순수 JS와 HTML이고, 핵심은
useState하나뿐임. 직관적이라 문서 없이도 이해 가능함Backbone은
.space-y-2같은 문자열 셀렉터에 의존해 유지보수가 지옥이었음. 클래스명 하나 바꾸면 앱 절반이 깨짐React는 이런 문제를 구조적으로 해결했음
Backbone 코드는 “무슨 일이 언제 일어나는지” 명확하지만, React는 내부 동작을 이해해야 함
나도 React의 동작 시점을 이해하려고 Dan Abramov의 useEffect 가이드와 Mark Erikson의 블로그를 여러 번 읽었음
Backbone 코드는 10년 만에 봐도 바로 이해됐음
6년 전 팀을 Backbone에서 Angular로 옮겼음
Backbone은 직관적이고 마법이 없는 구조라 주니어에게 좋았지만, 결국 TypeScript와 Angular가 더 체계적이었음
지금은 NG20을 쓰고 있고 만족함. 언젠가 브라우저가 더 많은 기능을 기본 제공하면, 다시 단순한 방식으로 돌아갈 수도 있을 것 같음
우리는 항상 추상화 위에서 프로그래밍하고 있음
중요한 건 그 추상화가 복잡성 대비 생산성 이득을 주는지, 그리고 신뢰할 수 있는지임
최악의 경우라도 디버깅 가능해야 함
React의 입력 필드가 Backbone보다 Undo 동작을 더 자연스럽게 처리함
Backbone은 한 글자씩 되돌리지만 React는 단어 단위로 되돌림