[번역글] React vs Angular : 둘 중 어떤 것이 당신의 프로젝트에 알맞을까요?

소개

안녕하세요. Popit에서 글을 쓰고 있는 김대희라고 합니다.  백엔드 개발자로서 , 프런트 개발자 분들이 쓰는 프레임워크 비교 기사를 보게되었는데 이 글이 흥미롭고 재미있게 읽을 수 있어서 해당 글을 번역하게 되었습니다. 기사와 개발자분들이 접하는 부분이 많이 다를 수 있고, 다소간 매끄럽지 않더라도 많은 좋은 피드백 부탁드립니다.

원본글은 다음글에 참고하세요.

React vs Angular  : 둘 중 어떤 것이 당신의 프로젝트에 알맞을까요?

세계에서 많이 쓰이는 두 종류의 Front-End 개발 도구중 어느것을 결정하려고 시도하고 있습니까? 훌륭한 비교 분석이 될 수 있는 이 글을 읽어보시면 됩니다.

프로그래밍 세계에서 Angular와 React는 Front-End 개발자에게 가장 널리 사용되는 JavaScript 프레임 워크 중 하나입니다.  더욱이,  Angular와 React는 Stack Overflow Developer Survey 2018에서 조사한 모든 프로그래밍 언어에서 Node.js와 함께 소프트웨어 엔지니어가 가장 많이 사용하는 프레임워크 입니다. 이러한 Front-End 프레임 워크는 모두 인기가 비슷하고 유사한 아키텍처를 사용하며 JavaScript를 기반으로 합니다. 그러면 이 두개의 프레임워크는 무엇이 다를까요? 지금부터 React와 Angular를 비교해 봅시다. 다음 단락에서 프레임 워크의 일반적인 특성을 살펴 보도록 하겠습니다.  추가로 React와 Angular의 비교가 더 필요하면 크로스 플랫폼 모바일 프레임워크 (React Native 포함) 기사나 Angular와 다른 Front-End 프레임워크를 비교한 기사를 읽어보세요.

Angular와 React.JS에 대한 간단한 설명

Angular는 Google에서 만들고 관리하는 Front-End 프레임 워크이며 대부분의 코드 편집기에서 작성할 수 있습니다.Anglular는 MEAN 스택의 구성원이며(A), MEAN 스택은 동적인 웹 사이트와 웹 애플리케이션을 구축할때 사용되는 Javascript를 중심으로 작동하는 무료 오픈 소스 Tool Set입니다.  MEAN 스택은 MongoDB (NoSQL 데이터베이스), Express.js (Back단 프레임워크), Angular 또는 AngularJS (Front-End 프레임 워크) 및 Node.js (서버 플랫폼)로 구성됩니다. Angular 프레임워크는 개발자들이 동적 단일 페이지 웹 애플리케이션(SPA)을 만들 수 있게 해줍니다. Angular가 처음 출시되었을 때 가장 주요한 장점은 HTML 기반 문서를 동적 인 콘텐츠로 변환 할 수 있다는 점이었습니다. 이 기사에서는 AngularJS(Angular 1)과 Angular(2버전 이후)의 차이점을 해결하기 위해 일반적으로 Angular 7이라고하는 최신 버전의 Angular에 중점을 둘 것입니다. Angular는 Forbes, WhatsApp, Instagram, healthcare.gov, HBO, Nike 등에서 사용을 하고 있습니다.

React.js는 동적 사용자 인터페이스를 만들기 위해 Facebook에서 2011 년에 만든 오픈 소스 JavaScript 라이브러리입니다. React는 Front-End 개발을 위한  HTML 요소의 생성을 허용하는 JavaScript 및 JSX를 기반으로 합니다.  React에는 모바일 앱 개발을 위한 별도의 Cross-Platform 프레임 워크 인 React Native가 있습니다. 링크된 글에서 React.js와 React Native 둘 다에 대한 심도 있는 정보를 제공하고 있습니다. React는 Netflix, PayPal, Uber, Twitter, Udemy, Reddit, Airbnb, Walmart 등에서 사용됩니다.

Toolset : Framework vs. Library

프레임워크 생태계는 실제 엔지니어링을 진행할 때(개발할 때) 밀접하게 영향을 끼칩니다. 여기에서는 Angular 및 React와 함께 일반적으로 사용되는 주요 도구들을 살펴 보겠습니다. 우선,  React는 실제로 프레임워크가 아니라 라이브러리입니다. 이는 추가 개발도구 및 라이브러리를 여러 번 통합해야 한다는 것을 의미합니다. Angular는 프레임워크이기 때문에 이미 앱을 만들기 시작할 모든 개발 도구들을 가지고 있습니다.

React vs Angular

Angular

Angular는  많은 특징들을 가지고 있습니다.

  • RxJS는 데이터 교환에 대한 다중 채널들을 설정하여 리소스 연산을 줄이는 비동기 프로그래밍용 라이브러리입니다. RxJS의 가장 큰 장점은 이벤트를 독립적으로 동시에 처리 할 수 있다는 것입니다. 그러나 RxJS가 많은 프레임 워크로 작동 할 수 있지만 문제는 Angular를 완전히 활용하려면 Rxjs를 배워야한다는 것입니다. 또한 리액티브 프로그래밍을 할 수 있게 해줍니다.
  • Angular CLI는 응용 프로그램 생성, 파일 추가, 테스트, 디버깅 및 배포를 지원하는 강력한 Command-Line Interface입니다.
  • 의존성 주입 ( Dependency injection ): 프레임 워크는 병렬적으로 컴포넌트를 실행하도록 분리시켜 재설정 하지 않아도 의존관계의 컴포넌트를 대체할 수 있습니다.
  • Ivy renderer: Ivy는 차세대 Angular 렌더링 엔진으로 성능을 크게 향상시킵니다.
  • Angular Universal는 서버 사이드 렌더링 기술입니다. 이것을 사용해 App의 첫페이지를 빠르게 렌더링할 수 있고 , 모바일 디바이스처럼 브라우저 렌더링 리소스가 부족한 디바이스에서 화면을 나타낼 수 있습니다.
  • AptanaWebStormSublime TextVisual Studio Code 는 일반적으로 Angular와 함께 사용되는 코드 편집기 및 IDE입니다.
  • JasmineKarmaProtractor 는 브라우저에서 End-To-End Test 및 디버깅을 위한 도구입니다.

React 

React를 실행하려면 여러 통합 및 지원 도구가 필요합니다.

  • Redux는 상태를 관리하는 컨테이너로 React로 대규모 응용프로그램을 짤 때 사용하면 효과적입니다. 많은 동적 요소가 있는 응용 프로그램의 구성 요소를 관리하며 렌더링에도 사용됩니다. 또한 React는 Redux 용 선택기 라이브러리 및 Redux DevTools Profiler Monitor를 포함하는 더 넓은 Redux ToolSet와 함께 작동합니다.
  • Babel은  JSX를 어플리케이션이 JavaScript로 변환을 시킴으로써 브라우저에서 이해할 수 있도록 해주는 트랜스 컴파일러입니다.
  • Webpack은 모든 구성 요소가 서로 다른 파일로 작성되므로 더 나은 관리를 위해 구성 요소를 Bundle로 묶어줍니다. Webpack은 표준 코드 Bundle로 간주됩니다.
  • React Router는 React와 함께 일반적으로 사용되는 표준 URL 라우팅 라이브러리입니다.
  • Angular와 마찬가지로 코드 선택면에서도 제한되지 않습니다. 가장 일반적인 편집기 및 IDE로는 Visual Studio Code, Atom 및 Sublime Text 입니다.
  • Angular와 달리 React에서는 단일 Tool로 전체 앱을 테스트 할 수 없습니다. 각기 다른 테스트 유형마다 별도의 Tool을 사용해야합니다. React는 다음 Tool들과 호환됩니다.

이러한 Toolset은 디버깅 및 시각화용 Reselect DevToolsChrome ,  FirefoxReact Sight용 React Developer Tools에 의해 제공되며 상태 및 Proprep Tree를 시각화 해줍니다.

일반적으로 Angular와 React 모두 강력한 생태계와 함께 제공되며 사용자는 어느 것이 더 나은지 결정할 수 있습니다. React는 일반적으로 파악하기가 더 쉽지만, Redux와 같은 여러가지 도구의 통합이 React의 능력을 완전히 활용하기 위해 필요할 것입니다.

Component 기반 구조 : 재사용 가능 및 유지관리 가능한 Component들을 가지고 있는 React와 Angular

Angular와 React 모두 Component 기반 Architecture를 사용합니다. 즉, 이것은 App은 유저 인터페이스를 구축하기 위해서 결합된 모듈화되고, 응집력 있고, 재사용 가능한  Component로 구성된다는 것을 의미합니다. Component Architecture는 웹 개발에 사용 된 다른 Architecture보다 유지 관리가 용이하고 편리합니다. 그러한 Architecture는 개발 시간을 단축시켜 개발자가 응용 프로그램을 조정하고 확장 할 수 있도록 개별적인 Component 요소를 만들어 개발 속도를 높입니다.

Code: TypeScript vs. JavaScript and JSX

 Angular는 TypeScript 언어를 사용합니다 (그러나 필요한 경우 JavaScript를 사용할 수도 있습니다). TypeScript는 대규모 프로젝트에 적합한 JavaScript 상위 언어입니다.  TypeScript는 더 엄격하고 Type을 정하는 부분에서 실수를 발견할 수 있게 해줍니다. TypeScript의 다른 장점으로는 더 나은 탐색, 자동 완성 및 더 빠른 코드 리팩토링이 있습니다. TypeScript는 더 정교하고, 확장 가능하며, 깨끗하여 대규모 엔터프라이즈 프로젝트에 적합합니다.

React는 JavaScript ES6+ 및 JSX 스크립트를 사용합니다. JSX는 UI 코딩을 단순화하는 데 사용되는 JavaScript의 구문 확장으로,  JavaScript 코드를 HTML과 유사하게 만듭니다. JSX를 사용하면 코드를 시각적으로 단순화하여 오류를 감지하고 주입으로부터 코드를 보호할 수 있습니다. 또한 JSX는 웹 브라우저가 읽을 수 있는 형식으로 코드를 변환하는 컴파일러인 Babel을 통해 브라우저 컴파일을 하는 데도 사용됩니다. JSX 구문은 TypeScript와 거의 동일한 기능을 수행하지만 일부 개발자는 배우기가 너무 복잡하다고 생각합니다.

DOM: Real vs. Virtual

DOM(Document Object Model)은 HTML, XHTML 또는 XML 문서에 대한 프로그래밍 인터페이스로, 스크립트가 웹 문서의 내용 및 구조와 동적으로 상호 작용하고 이를 업데이트할 수 있는 트리 형태로 구성됩니다. DOM에는 두 가지 유형, 즉 가상 및 실제가 있습니다. 전통적인 DOM 또는 실제 DOM은 한 요소에서 변경이 발생하더라도,  전체 트리 구조를 업데이트하는 반면 가상 DOM은 변경 사항을 추적하고 전체 트리의 다른 부분에 영향을주지 않고 특정 요소 만 업데이트하는 실제 DOM에 매핑된 표현입니다.

DOM

The HTML DOM tree of objects  (원본 : W3Schools ) 

React는 가상 DOM을 사용하고 Angular는 실제 DOM에서 작동하고 변경 감지를 사용하여 업데이트가 필요한 구성 요소를 찾습니다. 가상 DOM이 실제 DOM 조작보다 더 빠른 것으로 간주되지만, Angular의 현재 변경 감지 구현은 두 접근 방식을 모두 성능 측면에서 비교할 수 있게 합니다.

Data Binding: 양방향 vs. 하향식 (단방향) / Two-Way vs. Downward (One-Way)

데이터 바인딩은 모델 (비즈니스 로직)과 뷰 (UI)간에 데이터를 동기화하는 프로세스입니다. 데이터 바인딩에는 기본적으로 단방향과 양방향이라는 두 가지 기본 구현이 있습니다. 단방향 데이터 바인딩과 양방향 데이터 바인딩의 차이는 Model - View Update Process에 있습니다.

단방향과 양방향의 비교

Angular의 양방향 데이터 바인딩은 모델 - 뷰 - 컨트롤러 (Model-View-Controller / MVC) Architecture와 유사하며 모델과 뷰가 동기화되므로 데이터를 변경하면 뷰에 영향이 오게 되며,  뷰를 변경하면 데이터 또한 변경이 됩니다.

React는 단방향 또는 하향식  데이터 바인딩을 사용합니다. 단방향 데이터 흐름은 하위 Component가 업데이트될 때 상위 Component에 영향을 미치도록 허용하지 않으며, 승인된 Component만 변경되도록 하고 있습니다. 이러한 단방향 유형의 데이터 바인딩은 코드를 보다  안정성이 있게 만들지만 모델과 뷰를 동기화하기 위해서는 추가 작업이 필요합니다. 또한 하위 Component의 변경으로 트리거되는 상위 Component에서 업데이트를 구성하는 데 더 많은 시간이 소요됩니다.

React의 단방향 데이터 바인딩은 일반적으로 예측 가능성이 높기 때문에 코드가 안정적이며 디버깅이 쉽습니다.  하지만, Angular의 전통적인 양방향 데이터 바인딩 또한 작업하기가 더 단순합니다.

App의 사이즈와 성능 : Angular가 조금 더 장점이 있습니다.

AngularJS(Angular 1)는 복잡하고 동적인 애플리케이션을 처리할 때 성능이 낮은 것으로 유명합니다. 가상 DOM으로 인해 React 애플리케이션은 동일한 크기의 AngularJS 앱보다 더 빠르게 작동합니다. 하지만 freeCodeCamp.org.의 Jacek Shae의 연구에 따르면, 새로운 버전의 Angular(Angular 2버전 이상, 7버전)은 React와 Redux에 비해 약간 더 빠르다고 결과를 발표 하였습니다. 또한 Angular는 동일한 연구 결과에서 React + Redux와 비교할 때 앱 크기가 작습니다. Angular의 App 크기는 129KB이며, React + Redux는 193KB입니다.

스피드 테스트 결과

Angular가 최신 업데이트를 함으로써 Angular는 더 이상 속도나 App 크기면에서 React에게 부족하지 않음으로서 Angular와 React간의 경쟁이 더욱 심해졌습니다.

사전 제작 된 UI 디자인 요소 : Angular Material vs. Community-Backed Components

Angular의 Material Design 언어는 웹 애플리케이션에서 점점 더 인기를 얻고 있습니다. 따라서 몇몇 엔지니어들은 Material  Tool Set를 별도의 설치나 구성이 필요 없이 바로 사용할 수 있습니다. Angular는 사전 제작된 Material design Component들을 포함합니다. Angular Material은 일반적인 상호 작용 패턴을 구현하는 것들(ex) 폼 컨트롤, 내비게이션, 레이아웃, 버튼 및 indicators, 팝업 및 모듈, 데이터 테이블 등)을 가지고 있습니다.  Angular Material은 미리 빌드 된 요소가 있으므로 UI를 훨씬 빠르게 구성 할 수 있습니다.

React는 반면에 React를 위한 UI Tools의 대부분은 해당 커뮤니티(ex) React Portal 등)에서 가져옵니다. 현재 React Portal의 UI Components 섹션에는 다양한 무료 Components와 유료 Components가 제공됩니다. React의 요구사항에 따른 material design을 사용하려면 약간의 노력이 필요합니다.  이는 빌드하기 위해서는Material-UI Library와 의존성을 설치해야 하는 것을 말합니다.  또한 UI  Component 및 Toolsets를 사용하여 React 및 기타 패키지로 빌드 된 부트 스트랩  Component들을 확인할 수 있습니다.

모바일 이식성 : NativeScript vs React Native

Angular와 React에는 엔지니어가 기존 웹 응용 프로그램을 모바일 응용 프로그램으로 이식 할 수 있는 추가 도구들이 있습니다. NativeScript (Angular)와 React Native를 모두 심층적으로 분석하고 비교하였습니다. 먼저 간단히 요점을 되짚어 보겠습니다.

NativeScript는  TypeScript를 핵심 언어로 사용하는 크로스 플랫폼 모바일 프레임워크입니다. 사용자 인터페이스는 XML 및 CSS로 작성됩니다. NativeScript를 사용하면 iOS와 Android에서 약 90 %의 코드를 공유하고 비즈니스 로직을 웹 응용 프로그램에서 포팅할 수 있고, UI 작업을 할 때 동일한 기술을 사용할 수 있습니다. NativeScript의 철학은 모바일 용 단일 UI를 작성하고 필요한 경우 각 플랫폼에 맞게  UI를 약간 조정하는 것입니다. WebView 렌더링을 사용하는 하이브리드 크로스 플랫폼 솔루션과 달리 이 프레임워크는 JavaScript 가상 머신에서 애플리케이션을 실행하고 네이티브 모바일 API에 직접 연결하여 네이티브 앱에 필적할 수 있는 고성능을 보장합니다.

React Native는 JavaScript 프레임워크로서 웹에서 이식이 가능한 모바일 앱을 위한 크로스 플랫폼 구현입니다. React Native는 NativeScript와는 약간 다른 접근 방식을 취합니다. React Native의 커뮤니티는 다양한 플랫폼을위한 개별 UI를 작성하고 "한 번 배우고 모든 것을 쓸 수 있습니다"라는 접근 방식을 고수하도록 권장됩니다. 따라서 코드 공유 추정치는 약 70 %입니다. React Native는 NativeScript와 같은 기본 API 렌더링을 자랑하지만,  JavaScript 런타임과 네이티브 컨트롤러를 연결하기 위해 추가 브리지 API 레이어를 만들도록 요구됩니다.

일반적으로 두 프레임워크 모두 동일한 비즈니스 로직으로 웹 및 모바일 애플리케이션을 모두 실행해야 하는 경우에 적합한 프레임워크들입니다. NativeScript는 코드 공유와 시장 출시 기간을 단축시키는데에 더 중점을 두고 있고, React Native의 아이디어들은 개발 기간이 더 길지만 궁극적으로는 Native App의 외관과 느낌에 더 가깝습니다.

문서 및 공급 업체 지원 : 대규모 커뮤니티에서 제공해주는 문서나 설명이 부족합니다.

Angular는 Google에서 개발했으며, Google은 현재도 Angular EcoSystem을 발전시키고 개발하고 있습니다. 2018 년 1 월부터 Google은 버그 수정 및 적극적인 개선에 중점을 둔 LTS (장기 지원 버전) 프레임워크를 제공하고 있습니다. 하지만,  Angular 프레임워크의 빠른 개발에도 불구하고 문서 업데이트가 그렇게 빠르지는 않습니다. 문서와는 별개로, Angular 개발자의 개발 작업을 편리하게 하기 위해 대화형 서비스가 제공되고 있으며, 현재 프레임워크 버전과 업데이트 대상을 정의하여 어떤 업데이트를 할것인지 체크하는 체크리스트들을 얻을 수 있습니다.

Angular Update

원본 : Angular Update Guide

Angular 2부터 7까지는 이를 통해 전환할 수 있지만,

AngularJS ( Angular 1 ) 에서 다른 버전의 전환은 해당 Guide에서 확인할 수 없습니다.

AngularJS 문서 및 튜토리얼들은 Angular 2+보다 광범위한 범위를 제공하므로 개발자들로부터 아직도 칭찬  및 찬사를 받고 있습니다. 하지만, AngularJS가 오래되었다는 것을 고려할 때 사실상 거의 이것은 이점이 아닙니다. 또한 일부 개발자는 SLI 문서 업데이트 속도에 대해 우려를 표명하기도 합니다.

React 커뮤니티에서도 유사한 문서 부족 문제가 발생하고 있습니다. React를 가지고 일을 할때에는 변화와 지속적인 학습을 준비해야합니다. React 환경과 운영 방식은 상당히 자주 업데이트 됩니다.React에는 최신 버전의 설명서가 있지만 모든 변경 사항과 통합을 유지하는 것은 간단한 작업이 아닙니다. 그러나, 이러한 문제들은 커뮤니티 지원에 의해 어느 정도 해결이 되었습니다. React는 주제와 관련된 토론들을 통해서 지식을 공유할 수 있는 대규모 개발자 풀을 보유하고 있습니다.

러닝 커브(Learning Curve)  : Angular가 상대적으로 러닝커브가 가파릅니다.

Angular의 러닝커브는 React보다 상대적으로 많이 가파르다고 여겨지고 있습니다. Angular는 하나의 문제를 푸는 여러 가지 방법을 가진 복잡하고 장황한 프레임워크입니다. 그것은 많은 반복적인 행동이 필요하고, 복잡한 Component 관리를 하고 있습니다.

위에서 언급한 바와 같이, 프레임워크는 지속적으로 개발되고 있기 때문에 기술자들은 이러한 변화에 적응해야 합니다. Angular 2 이상 버전의 또 다른 문제는 TypeScript와 RxJS의 사용입니다. TypeScript는 JavaScript에 가깝지만 배우는 데는 어느 정도 시간이 걸립니다. RxJS 또한 여러분들이 편하게 사용하기 위해서는 많은 노력을 필요로 할 것입니다.

React 또한 업데이트가 빈번하기 때문에 지속적인 학습이 필요하지만, 일반적으로 새 사용자에게는 더 친숙하며, JavaScript를 사용하는데 이미 익숙하시다면 학습을 하는 데 많은 시간을 필요로 하지 않습니다. 현재 React의 주요 러닝커브 문제는 Redux 라이브러리입니다. React로 만들어진 애플리케이션의 약 60%가 그것을 사용하고, 결국 Redux를 배우는 것은 React 엔지니어의 필수적인 요소입니다. 또한, React는 초보자를 위한 유용하고 실용적인 튜토리얼을 제공합니다.

커뮤니티와 수용성: 두 가지 모두 광범위하게 사용되고 수용된다.

GitHub를 보았을 때, Angular보다 React가 더 많이 사용됩니다. React는 113,719 개의 스타와  6,467개의 뷰를 가지고 있고, Angular는 41,978 개의 스타와 3,267개의 뷰를 가지고 있습니다. 그러나 2018 년 StackOverFlow에서 실시한 개발자 설문 조사에 따르면 Angular로 작업하는 개발자의 수가 조금 더 많다고 발표하였습니다. 설문 조사 결과,  Angular로 작업하는 개발자는 37.6%이고, React로 작업하는 개발자는 28.3%였습니다. 이 설문 조사의 Angular 항목의 경우,  AngularJS(Angular 1)과 Angular 2 이상의 버전으로 작업하는 엔지니어 모두를 합친 결과입니다.

most used frameworks and tools of 2018

가장 많이 사용하는 프레임워크 ( 2018년 설문조사 ) / 원본: Stack Overflow

Angular는 Google에서 적극 지원을 하고 있습니다. Google은 Angular Ecosystem을 계속 개발하고 발전시키고 있으며, 2018 년 1 월부터 LTS (장기 지원 버전) 프레임 워크를 제공하고 있습니다. 그러나, Angular는 부정적인 피드백 또한 많습니다. 같은 설문 조사에 따르면 개발자 중 45.6 %가 가장 작업하기 두려운 프레임워크라고 생각하고 있습니다. Angular에 대한이 부정적인 피드백은  Angular 2버전 이후가 아닌 AngularJS를 사용하는 개발자가 많기 때문에  이러한 영향을 받은 것으로 보입니다.  그러나 여전히 Angular의 커뮤니티는 폭이 넓습니다.

React는 Angular보다 부정적인 피드백이 더 적습니다. 이 설문 조사 결과, 30.6%의 개발자들이 React를 가지고 일하기를 원하지 않는다고 발표하였습니다.

결론 : 어떤 프레임 워크를 선택해야 하는가?

Angular의 기본 개념은 전체적인 프론트엔드 개발 경험을 위한 강력한 지원과 Toolset를 제공하는 것입니다. Google의 지속적인 업데이트와 적극적인 지원으로 인해 프레임워크는 계속 유지되고 있으며, 이 프레임워크로 작업하는 엔지니어들은 기존 커뮤니티를 보존하고 회사에서 일하는 개발자들이 AngularJS에서 앱을 고성능 및 소형화시킬 수 있는 최신 Angular 2버전 이후로 전환 할 수 있도록 노력할 것입니다. TypeScript는 코드의 유지 보수성을 높여 주며, 기업 규모의 응용 프로그램의 규모에 도달할수록 점점 더 중요해지고 있습니다. 그러나 Angular는 React보다 가파른 러닝커브와 React쪽으로 작업을 하고 있는 많은 엔지니어 풀을 염두에 두어야 합니다.

React는 개발자가 많은 학습 없이 신속하게 업무를 수행할 수 있도록 훨씬 가벼운 접근 방식을 제공합니다. 다만, 라이브러리가 Toolset와 접근 방법을 지시하지는 않지만 Redux와 같은 여러 가지 개발 도구들을 학습하여야 합니다. 현재 React는 Angular와 성능면에서 비교가 가능합니다. 이러한 측면들은 더 많은 개발자들에게 어필이 되고 있습니다.

기사와 다른 점

  • Angular와 React의 Architecture는 많이 다릅니다. 해당 Architecture 파악 후 사용하시길 바랍니다.
  • TypeScript와 같은 기능을 JSX가 작업하지 않습니다.
  • React 또한 End-to-End 테스트가 가능합니다.
  • React는 라이브러리라고 부르는 의견 또한  있으며, 프레임워크라고 하는 의견이 있습니다.
  • 최신 React는 Redux가 필요 없을 정도로 발전된 상태입니다.

이 글을 마치며...

해당 기사를 읽었을때 백엔드밖에 하지 않은 개발자가 대강 이런 기능이 있구나. 하면서 이해할 수 있었던 기사 및 블로그 글이었던 것 같습니다.  아쉬운 점은 해당 기사에서 Vue와 함께 Front-End의 생태계 사이즈를 언급하고, 세개를 각기 비교하는 기사였으면 더욱 좋았을 것 같다는 생각이 들었습니다. 또한 실제 업무를 하시는 분들과 기사와의 차이점 또한 알 수 있었습니다. 해당 번역글에 대해 검수해 주신 분들과 이 기사를 볼 수 있고 점검해주신 Popit에게 감사드립니다.

검수에 도움을 주신 분들


Popit은 페이스북 댓글만 사용하고 있습니다. 페이스북 로그인 후 글을 보시면 댓글이 나타납니다.