14P by tenshi 7달전 | favorite | 댓글 15개

그리고 오직 한명의 승자가 있다.

참가자들: 프레임워크 간 전쟁은 JS 커뮤니티의 뜨거운 주제. Backbone, Sencha 등은 사라짐. jQuery는 놀랍게도 여전히 큰 커뮤니티가 있음. Angular 같이 잘 안풀렸던 것도 있음.

jQuery: 가장 오래된 참가자. 브라우저 호환성을 고쳐주어 인기. 하지만 애플리케이션 확장 어려웠음. 오늘날엔 주류가 아니며 최선의 선택이 아님.

AngularJS: 이미 LTS 모드이며 퇴역함. 프레임워크 생태계에서 큰 도약이었고 그리워하는 사람들 많음. 더이상 유지되지 않아 더이상 참가자가 아님.

Angular:

  • React와 경쟁하기 위해 등장. AngularJS의 성능, 견고성 문제로 인해 많은 프로그래머들이 React를 부러워함. Angular는 AngularJS를 현대화하고 ES6 개선점을 활용해 React와 경쟁하기 위해 노력함.
  • 무거운 학습 곡선이 가장 큰 어려움. 많은 개념을 필요로 했음. AngularJS의 학습 곡선을 이어 받았지만 RxJS 혹은 계층적 종속성 주입(DI) 같은 새로운 어려움이 있었음.
  • 또 다른 우려는 많은 약속을 어긴 점. 예로, V2가 서버 사이드 렌더링(SSR) 페이지를 간단히 만들 수 있었지만 2022/2/24 현재 JS 없이 작동 불가능.
  • 가장 큰 문제는 파편화와 버전 업그레이드. 버전 업그레이드가 너무 어려워서 사용자들은 위험을 감수하지 않음. npm 사이트 통계에서 이것이 드러남.

VueJS:

  • AngularJS보다 성능이 뛰어나고 Angular보다 안정적이고 쓰기 쉬운 개발자들에게 해답이었음. 템플릿 시스템의 Vue는 AngularJS와 매우 가까워서 AngularJS의 단순성을 유지하는 동시에 React로부터 힘을 얻음.
  • 하지만 VueJS는 버전 1과 2에 심각한 문제가 있었음. array를 잘 다루지 못했고, 저자들은 업데이트 알고리즘를 잘못 선택했던 것에 대해 자바스크립트를 비난함. Vuex 또는 Redux 같은 라이브러리에 의존적.
  • 이 문제는 버전 3에서 해결됨. 그러나 자신의 실수에 대해 타인을 비난하는 것은 커뮤니티에 어울리지 않았음.

SvelteJS:

  • 성장하는 경쟁자. 큰 약속들을 하고 있음. 명령형 언어로 컴포넌트를 번역하는 것이 주요 장점이라고 주장함. 그들에 따르면 리액트의 선언문보다 낫다고 함.
  • 사용법은 간단. 다만 명령어 번역의 결과로 생기는 구성 요소는 보기만큼 예측이 쉽지 않음. 경우에 따라 변경 사항을 올바르게 감지할 수 없음. 이 경우 상태가 손상되어 view가 제대로 업데이트 되지 않을 수 있음. 이 문제가 많은 우려를 야기하여 과거 VueJS처럼 SvelteJS의 어떤 프로젝트도 정당화가 어려움.

StencilJS:

  • 엄밀히는 프레임워크는 아님. 컴포넌트를 작성하고 다른 프레임워크로 변환 가능. 현재 Angular, React, Vue 및 Web Components로 변환 가능.
  • 다른 프레임워크의 코드와 비슷한 코드인가? 라는 질문을 던짐 (원문 참조)

Mitosis:

  • 아마 들어보지 못했겠지만, 이 글을 쓰게 만든 이유. Angular를 만든 Misko Hevery가 만든 최신 프레임워크.
  • StencilJS와 같은 목적을 가짐. 컴포넌트를 수많은 프레임워크로 번역함.
  • 마찬가지로 다른 프레임워크의 코드와 비슷한 코드인가? 라는 질문을 던짐 (원문 참조)

React:

  • 10년 이상 npm 저장소에 보관된 가장 오래된 프레임워크 중 하나. 많이 변했지만 대부분 과거 버전과 호환. 모든 변화는 더 나아짐. 어떤 이들은 hook으로 React 하는 것이 훨씬 더 좋은 프레임워크를 만들었다고 함.
  • 가장 좋은 품질은 hook이나 눈에 보이는 기능에 있는 것이 아닌 그 반대. JS 최신 표준 및 JSX를 적용함. 이는 더이상 프레임워크가 아님. 결코 아니었을 것. React는 표준을 위해 너무 열심히 노력한 결과 사용자 코드에서 스스로를 제거함.

그래서 우승자는...

  • JSX. React이기도 하지만 React 뒤에 있는 철학. React 자체는 라이브러리. 다만 Preact나 React Native 등 많은 다른 라이브러리로 대체 가능. 자세히보면, StelcilJS 혹은 Mitosis는 React와 매우 유사하며 이는 우연의 일치가 아님
  • "최고의 프레임워크는 사용자 코드에서 자신을 제거하는 프레임워크"
  • React는 JS와 JSX를 많이 활용. 사용자 코드는 React와 무관. 큰 수정 없이 동일한 코드가 다른 프레임워크에서 작동 가능.
  • 그래서 의심할 여지 없이 React가 프레임워크 전쟁의 승자.
  • 왜냐하면 사용자 코드 내의 프레임워크가 아니기 때문.

중요한건 '프레임워크와 결혼하지 말라'는 밥아저씨의 말을 최대한 실천하여 코드를 작성하면 react든 vue든 angular든 재밌게 개발할 수 있지 않을까요

marko js의 전망은 어떤가요?
이베이에서 지원하는거라 최근에 관심이 생겼는데 원문에는 언급조차 없네요...

React의 "많이 변했지만 대부분 과거 버전과 호환" - 저는 이 호환 경험을 많이 하지 못했습니다.
Angular의 "파편화와 버전 업그레이드" - 하지만 이부분에서는 저는 부드러운 경험을 많이 했어요.

JSX 는 framework 가 아니라 specification 으로 분류해야된다고 생각합니다. 하고자 하는 말은 알겠는데, 안해도 될 서론이 너무 길고 무엇보다 제목이 clickbait 입니다. 글 자체의 퀄리티를 스스로 격하시키는 문체를 쓰시네요.

요약과 좋은 댓글 들에 감사드립니다~! 이런 얘기들이 다른 분들에게 많은 도움이 될것 같아요 ;)

StencilJS과 Mitosis에 설명이 달린 '다른 프레임워크의 코드와 비슷한 코드인가?' 부분이 헷갈려서 원문을 봤는데 아무래도 저 두 프레임워크에서 사용하는 코드가 다른 프레임워크에서 본 것 같지 않나? 물어보고 있네요.

아마 리액트와 코드 작성법이 비슷하다는 의미로 작성한 것 같습니다.

전체적으로 이상한 글이라는 생각이 듭니다.

먼저 스벨트 부분입니다.
원문을 보니, 배열을 업데이트할 때 array[0] += 1 이런 식으로 쓰면 업데이트가 안 되니까 문제라고 써놨는데요, 스벨트 공식 문서에서도 배열은 재할당해야 업데이트가 된다고 쓰여 있고, 애초에 리액트에서도 이런 식으로는 배열 업데이트가 안 되잖아요?

VueJS 부분도요.
Angular랑 비교하면서 Vue의 단점을 얘기하고 있는데, 작동하는 Angular 코드랑 작동 안 하는 Vue 코드를 갖다놓고는 Vue가 별로라고 말하는 게 무슨 의미가 있는 건지 모르겠습니다.

전 타당한 비판이라는 생각이 듭니다. 재할당과 mutation의 차이는 초심자에게는 헷갈리는 부분인데, svelte vue 모두 자바스크립트와 비슷한 별도의 문법을 사용하고 있는 이상 예상대로 동작하지 않는 부분은 비판받을 만 하죠.

특히 vue는 프록시를 통해 set이 될 때 상태를 업데이트하는 방식인데, 처음 보기에는 쉬워보이지만 함정에 빠질 여지가 많아서 그 부분을 비판하고 있는 것은 저도 깊이 공감합니다.

리액트는 이런 문제에서 훨씬 자유로운게, 재할당으로는 상태 업데이트가 되지 않고, 명시적으로 setUpdate 함수를 호출하는 식으로 자바스크립트 표준 안에서 단방향 업데이트를 제공하니까 배열 중 일부만 변경하는 거랑 재할당이랑 헷갈린다든지 하는 문제가 생길 일이 애초에 없죠.

좀 곁다리로 꼽사리 끼는 이야기입니다만, Vue 3에서는 저런 형태의 배열 업데이트를 reactive하게 지원하는데 본 글이 구버전의 Vue만 맹비난하고 대충 넘어간다는 생각이 드네요...^^;; 정작 리액트에서는 이런 업데이트가 되지 않는 건 결코 작은 단점이 아닐텐데, 그런 특징은 제대로 짚고 넘어가지 않는 느낌이 있네요.ㅎㅎ

원문에도 많은 댓글이 달렸고 여러가지 문제를 지적하는 댓글들이 많더라구요.

VueJS에 대해서는 너무 야박한 평가네요..

redux에 대한 의존성은 react도 절대 자유롭지는 않을텐데..

사용자 규모면에서라면 리액트가 압도적으로 1위인건 맞는데,

기술적인 측면에서 리액트보다 별로인 프로젝트라고 부르지는 못하죠.

여기서 VueJs에 대해 주로 이야기하는 논점은 외부 라이브러리에 대한 의존성보다는 "자신들이 발생시킨 문제에 대해 JS에 책임을 전가하는 태도" 아닌가요?

아무래도 vueJS에 대한 여론이 좋지 않은 건 사실이라고 봅니다.

본문가서 읽어보시면 Vuex, Redux에 대한 의존성을 언급한 부분도 VueJS 2에서 발생한 문제를 해결하기 위해서는 Vuex, Redux 같은 라이브러리가 '필수'였다 라는 부분이구요.

네 원문에도 여러 댓글이 이미 있는 내용이긴 한데

복잡성이 증가하면 Vue든 React는 redux와 같이 상태 저장/캐싱 라이브러리는 모두 "필수"가 됩니다.

그러네 원문 VueJS는 이게 단점이고 react는 언급을 "의도적"으로 안했네요.

커뮤니티의 행태는 저의 입장에서는 별로 중요하지가 않아서요..

React에서는 redux가 필수는 아닙니다. contextAPI나 useReducer 등을 사용해서 상태 관리를 할 수 있어서요. 이게 React가 Vue보다 낫다고 볼 수 있는 근거라고는 생각하지 않지만은요.

네 ㅎㅎ 전체적으로 좋은 글은 아닌 것 같습니다.

저자는 결론을 정해놓고 결론에 도달하기 위해 다른 프레임워크들을 까내리고 있네요.