프레임워크 비교
이 페이지를 읽고 계신다면, 다른 프레임워크를 사용하여 애플리케이션을 구축해 본 경험이 있으실 것이고, Mithril.js가 문제를 해결하는 데 더 효과적인 선택지인지 궁금하실 것입니다.
왜 [선호하는 프레임워크 이름]이 아닐까요?
대부분의 최신 프레임워크는 빠르고 복잡한 애플리케이션을 구축하는 데 적합하며, 효과적으로 사용하는 방법을 알고 있다면 유지 관리도 용이합니다. Udemy는 Angular를, AirBnB는 React를, Gitlab은 Vue를, Guild Wars 2는 Mithril.js를 (게임 내부에서!) 사용하는 등 널리 사용되는 프레임워크를 사용하여 매우 복잡한 애플리케이션을 구축한 사례가 많습니다. 이들은 모두 프로덕션 환경에 적합한 프레임워크임이 분명합니다.
일반적으로 팀이 이미 다른 프레임워크/라이브러리/스택에 많은 투자를 했다면, 기존 방식을 고수하는 것이 합리적입니다. 재작업에 드는 비용을 상쇄할 만큼 강력한 이유가 없다면 말입니다.
하지만 새로운 프로젝트를 시작하는 경우, Mithril.js를 고려해 보세요. Mithril.js 채택자들이 10KB (gzip 압축) 미만의 코드에서 얼마나 많은 이점을 얻고 있는지 확인해 보십시오. Mithril.js는 Vimeo, Nike, Fitbit과 같은 유명 기업에서 사용되며, Lichess, Flarum과 같은 대규모 오픈 소스 플랫폼도 지원합니다.
왜 Mithril.js를 사용해야 할까요?
Mithril.js는 실용적이기 때문입니다. 10분 가이드가 좋은 예시입니다. 컴포넌트, XHR, 라우팅을 배우는 데 필요한 시간은 그 정도면 충분하며, 이는 유용한 애플리케이션을 구축하는 데 필요한 적절한 양의 지식입니다.
Mithril.js는 의미 있는 작업을 효율적으로 수행하는 데 중점을 둡니다. 파일 업로드를 해야 하나요? 문서에서 방법을 확인하세요. 인증은요? 문서에 설명되어 있습니다. 종료 애니메이션은요? 준비되어 있습니다. 추가 라이브러리나 복잡한 설정은 필요하지 않습니다.
비교
React
React는 Facebook에서 관리하는 뷰 라이브러리입니다.
React와 Mithril.js는 많은 유사점을 공유합니다. React를 이미 알고 있다면 Mithril로 앱을 만드는 데 필요한 대부분의 지식을 이미 갖춘 셈입니다.
- 둘 다 가상 DOM, 라이프사이클 메서드, 키 기반 재조정을 사용합니다.
- 둘 다 컴포넌트를 통해 뷰를 구성합니다.
- 둘 다 JavaScript를 뷰 내에서 흐름 제어 메커니즘으로 사용합니다.
React와 Mithril.js의 가장 큰 차이점은 범위에 있습니다. React는 뷰 라이브러리이므로 일반적인 React 기반 애플리케이션은 라우팅, XHR, 상태 관리를 위해 타사 라이브러리에 의존합니다. 라이브러리 중심 접근 방식을 사용하면 개발자가 자신의 요구 사항에 정확히 맞게 스택을 사용자 정의할 수 있습니다. 하지만 React 기반 아키텍처는 프로젝트마다 크게 다를 수 있으며, 이로 인해 프로젝트 크기가 1MB를 넘을 가능성이 높아집니다.
Mithril.js는 라우팅 및 XHR과 같은 일반적인 필수 요소에 대한 기본 제공 모듈을 제공하며, 가이드에서는 표준적인 사용법을 보여줍니다. 이 접근 방식은 일관성과 쉬운 온보딩을 중시하는 팀에 적합합니다.
성능
React와 Mithril.js는 모두 렌더링 성능에 주의를 기울이지만, 접근 방식은 다릅니다. 과거에 React는 두 가지 DOM 렌더링 구현 (DOM API를 사용하는 방식과 innerHTML을 사용하는 방식)을 가지고 있었습니다. 곧 출시될 파이버 아키텍처는 작업 단위의 스케줄링 및 우선 순위 지정을 도입합니다. React는 또한 프로덕션 배포를 위해 다양한 검사 및 오류 메시지를 비활성화하고 다양한 브라우저별 최적화를 수행하는 정교한 빌드 시스템을 갖추고 있습니다. 또한 React의 shouldComponentUpdate 훅과 불변 데이터 구조 라이브러리의 빠른 객체 동등성 검사 속성을 활용하여 가상 DOM 재조정 시간을 줄이는 여러 가지 성능 지향적인 라이브러리도 있습니다. 일반적으로 React의 성능에 대한 접근 방식은 비교적 복잡한 솔루션을 엔지니어링하는 것입니다.
Mithril.js는 '적을수록 좋다'는 원칙을 따릅니다. 상당히 작고 적극적으로 최적화된 코드베이스를 가지고 있습니다. 작은 코드베이스는 감사 및 최적화가 용이하며 궁극적으로 실행되는 코드의 양도 적습니다.
다음은 각 프레임워크의 JavaScript 코드를 구문 분석하고 실행하는 데 걸리는 시간, 즉 라이브러리 로드 시간을 비교한 것입니다. 프레임워크 코드로만 구성된 스크립트의 첫 번째 줄에 console.time() 호출을 추가하고 마지막 줄에 console.timeEnd() 호출을 추가하여 측정했습니다. 참고로 2010년 PC 데스크톱에서 파일 시스템에서 실행되는 번들 스크립트에 수동으로 로깅 코드를 추가하여 얻은 20회 실행 중 최적 결과를 제시합니다.
| React | Mithril.js |
|---|---|
| 55.8 ms | 4.5 ms |
라이브러리 로드 시간은 애플리케이션이 장시간 열려 있지 않은 환경 (예: 모바일)에서 중요하며 캐싱 또는 기타 최적화 기술을 통해 개선할 수 없습니다.
이것은 마이크로 벤치마크이므로 하드웨어가 결과에 큰 영향을 미칠 수 있습니다. 따라서 직접 테스트를 수행하는 것이 좋습니다. Webpack과 같은 번들러 프레임워크는 정적 모듈 해결을 에뮬레이션하기 위해 타이머 호출 전에 종속성을 이동할 수 있으므로 컴파일된 CDN 파일에서 코드를 복사하거나 번들러 라이브러리에서 출력 파일을 열고 번들 스크립트에 고해상도 타이머 호출 console.time 및 console.timeEnd를 수동으로 추가해야 합니다. new Date 및 performance.now는 통계적으로 정확하지 않으므로 사용하지 마십시오.
편의를 위해 웹에서 CDN을 사용하도록 조정된 벤치마크 버전이 있습니다. React 벤치마크는 여기에 있고, Mithril.js 벤치마크는 여기에 있습니다. React와 범위가 동일한 렌더링 모듈만 벤치마킹하는 것이 아니라 Mithril.js 전체를 벤치마킹하고 있다는 점에 유의하십시오. 또한 이 CDN 기반 설정은 디스크 캐시에서 리소스를 가져오는 데 따른 오버헤드 (~리소스당 2ms)가 발생한다는 점에 유의하십시오. 이러한 이유로 여기의 숫자는 완전히 정확하지는 않지만 Mithril.js의 초기화 속도가 React보다 훨씬 빠르다는 것을 확인할 수 있습니다.
다음은 약간 더 의미 있는 벤치마크입니다. 10,000개의 div (및 10,000개의 텍스트 노드)를 만드는 데 걸리는 시간을 측정합니다. 다시 말하지만, React 및 Mithril.js에 대한 벤치마크 코드는 다음과 같습니다. 가장 좋은 결과는 아래에 나와 있습니다.
| React | Mithril.js |
|---|---|
| 99.7 ms | 42.8 ms |
이러한 숫자는 Mithril.js가 초기화 속도가 훨씬 빠를 뿐만 아니라 React가 사용할 준비가 되기 전에 20,000개 이상의 가상 DOM 노드를 처리할 수 있음을 보여줍니다.
업데이트 성능
업데이트 성능은 단일 페이지 애플리케이션이 실행되는 동안 업데이트가 여러 번 발생할 수 있으므로 초기 렌더링 성능보다 훨씬 더 중요할 수 있습니다.
업데이트 성능을 벤치마킹하는 데 유용한 도구는 Ember 팀에서 개발한 DbMonster입니다. 테이블을 최대한 빨리 업데이트하고 초당 프레임 수 (FPS)와 JavaScript 시간 (최소, 최대 및 평균)을 측정합니다. FPS 수는 브라우저 다시 그리기 시간과 setTimeout 클램핑 지연도 포함하므로 평가하기 어려울 수 있으므로 가장 의미 있는 숫자는 평균 렌더링 시간입니다. React 구현과 Mithril.js 구현을 비교할 수 있습니다. 샘플 결과는 아래에 나와 있습니다.
| React | Mithril.js |
|---|---|
| 12.1 ms | 6.4 ms |
개발 성능
React는 개발 모드에서 추가 검사 및 유용한 오류 메시지를 추가하므로 위의 벤치마크에 사용된 프로덕션 버전보다 개발 속도가 느립니다. 이를 설명하기 위해 위에 나온 10,000 노드 벤치마크를 React 개발 버전으로 사용한 버전은 여기에 있습니다.
드롭인 대체
React와 API 호환성을 주장하는 여러 프로젝트가 있지만 (일부는 호환성 레이어 라이브러리를 통해), 완전히 호환되지는 않습니다 (예: PropType 지원은 일반적으로 스텁 처리되고, 합성 이벤트는 때때로 지원되지 않으며, 일부 API는 의미 체계가 다릅니다). 이러한 라이브러리에는 일반적으로 공식 React API의 일부가 아닌 자체 기능도 포함되어 있으며, 나중에 React Fiber로 다시 전환하기로 결정한 경우 문제가 될 수 있습니다.
(React에 비해) 작은 다운로드 크기에 대한 주장은 정확하지만, 이러한 라이브러리의 대부분은 Mithril.js의 렌더러 모듈보다 약간 더 큽니다. Preact가 유일한 예외입니다.
일부 프로젝트에서 사용하는 벤치마크가 구식이고 결함이 있는 것으로 알려져 있으므로 (악용될 수 있고 실제로 악용된다는 의미에서) 공격적인 성능 주장을 경계하십시오. (일부 벤치마크의 작성자인) Boris Kaul은 벤치마크가 어떻게 조작되는지에 대해 자세히 썼습니다. 또 다른 염두에 두어야 할 점은 일부 벤치마크는 고급 최적화 기능을 적극적으로 사용하므로 잠재적인 성능, 즉 일부 주의 사항이 주어지면 가능한 성능을 보여주지만, 최적화 후보를 식별하고 최적화 주의 사항으로 인한 회귀 위험을 평가하는 데 적극적으로 시간을 할애하지 않는 한 현실적으로는 가능성이 낮습니다.
일반적인 성능 특성을 보여주는 관점에서, 이 비교 페이지에 제시된 벤치마크는 있는 그대로, 순진하고 표준적인 방식으로 구현됩니다 (즉, 일반적으로 코드의 99%를 작성하는 방식). 어느 한 프레임워크가 인위적으로 더 잘 보이도록 속임수나 고급 최적화를 사용하지 않습니다. 여기에 있는 DbMonster 구현이 더 표준적인 방식으로 작성될 수 있다고 생각되면 PR을 통해 기여해 주세요.
복잡성
React와 Mithril.js는 모두 다른 프레임워크에 비해 API 표면이 비교적 작아 학습 곡선을 완화하는 데 도움이 됩니다. 하지만 표준적인 Mithril.js는 일반 ES5를 사용하고 다른 종속성 없이 가독성을 잃지 않고 작성할 수 있지만, 표준적인 React는 복잡한 도구 (예: Babel, JSX 플러그인 등)에 크게 의존하며, 이러한 수준의 복잡성은 구문 확장 (예: Redux의 비표준 객체 스프레드 구문), 아키텍처 (예: 불변 데이터 라이브러리를 사용하는 아키텍처) 또는 부가 기능 (예: 핫 모듈 재로드)의 형태로 해당 생태계의 인기 있는 부분으로 확장되는 경우가 많습니다.
복잡한 도구 체인은 Mithril.js 및 기타 프레임워크에서도 가능하지만, Mithril을 사용할 때는 KISS 및 YAGNI 원칙을 따르는 것이 좋습니다.
학습 곡선
React와 Mithril.js는 모두 학습 곡선이 비교적 작습니다. React의 학습 곡선은 주로 컴포넌트와 해당 라이프사이클을 이해하는 데 관련됩니다. Mithril.js 컴포넌트의 학습 곡선은 거의 동일합니다. Mithril.js에는 라우팅 및 XHR도 포함되어 있으므로 배워야 할 API가 더 많지만, 학습 곡선은 React, React Router 및 superagent 또는 axios와 같은 XHR 라이브러리를 배우는 것과 비슷합니다.
표준적인 React는 JSX 및 관련 주의 사항에 대한 실무 지식이 필요하므로 Babel과 관련된 학습 곡선도 있습니다.
문서
React 문서는 명확하고 잘 작성되어 있으며, 좋은 API 참조, 시작하기 위한 튜토리얼, 다양한 고급 개념을 다루는 페이지가 포함되어 있습니다. 하지만 React는 뷰 라이브러리로만 제한되므로 해당 문서는 실제 애플리케이션 컨텍스트에서 React를 표준적으로 사용하는 방법을 다루지 않습니다. 결과적으로 많은 인기 있는 상태 관리 라이브러리가 있으며 React를 사용하는 아키텍처는 회사마다 (또는 프로젝트 간에도) 크게 다를 수 있습니다.
Mithril.js 문서에는 소개 튜토리얼, 고급 개념에 대한 페이지, 입력/출력 유형 정보, 다양한 일반적인 사용 사례에 대한 예제, 오용 및 안티 패턴에 대한 조언이 포함된 광범위한 API 참조 섹션이 포함되어 있습니다. 또한 빠른 참조를 위한 치트 시트도 포함되어 있습니다.
Mithril.js 문서는 또한 웹 표준이 이제 더 큰 기존 라이브러리와 동등할 수 있음을 개발자에게 알리는 것이 적절한 실제 애플리케이션에서 일반적인 사용 사례에 대한 간단하고 실용적인 솔루션을 보여줍니다.
Angular
Angular는 Google에서 관리하는 웹 애플리케이션 프레임워크입니다.
Angular와 Mithril.js는 상당히 다르지만 몇 가지 유사점을 공유합니다.
- 둘 다 컴포넌트화를 지원합니다.
- 둘 다 웹 애플리케이션의 다양한 측면 (예: 라우팅, XHR)을 위한 도구 모음을 제공합니다.
Angular와 Mithril.js의 가장 큰 차이점은 복잡성에 있습니다. 이는 뷰가 구현되는 방식에서 가장 쉽게 확인할 수 있습니다. Mithril.js 뷰는 일반 JavaScript이며, 흐름 제어는 삼항 연산자 또는 Array.prototype.map과 같은 JavaScript 기본 제공 메커니즘으로 수행됩니다. 반면에 Angular는 HTML 뷰를 확장하여 HTML 속성 및 보간 내에서 JavaScript와 유사한 표현식을 평가할 수 있도록 지시문 시스템을 구현합니다. Angular는 실제로 이를 달성하기 위해 JavaScript로 작성된 파서와 컴파일러를 제공합니다. 이것만으로도 충분히 복잡해 보이지 않는다면 실제로 두 가지 컴파일 모드 (성능을 위해 JavaScript 함수를 동적으로 생성하는 기본 모드와 콘텐츠 보안 정책 제한을 처리하기 위한 더 느린 모드)가 있습니다.
성능
Angular는 수년에 걸쳐 성능 측면에서 많은 발전을 이루었습니다. Angular 1은 큰 $scope 구조를 지속적으로 비교해야 했기 때문에 느려지는 경향이 있는 더티 체킹이라는 메커니즘을 사용했습니다. Angular 2는 훨씬 더 성능이 좋은 템플릿 변경 감지 메커니즘을 사용합니다. 하지만 Angular의 개선에도 불구하고 Mithril.js의 작은 코드베이스 크기로 인해 감사가 용이하기 때문에 Mithril.js가 Angular보다 빠른 경우가 많습니다.
Angular와 Mithril.js 간의 로드 시간을 비교하기는 몇 가지 이유로 어렵습니다. 첫 번째는 Angular 1과 2가 완전히 다른 코드베이스이며 두 버전 모두 공식적으로 지원되고 유지 관리된다는 것입니다 (그리고 현재 대부분의 Angular 코드베이스는 여전히 버전 1을 사용합니다). 두 번째 이유는 Angular와 Mithril.js가 모두 모듈식이라는 것입니다. 두 경우 모두 주어진 애플리케이션에서 사용되지 않는 프레임워크의 상당 부분을 제거할 수 있습니다.
그렇긴 하지만 가장 작은 알려진 Angular 2 번들은 Brotli 알고리즘으로 압축된 29kb hello world입니다 (표준 gzip을 사용하면 35kb). 그리고 대부분의 Angular 유용한 기능이 제거되었습니다. 이에 비해 모든 기능을 포함하는 전체 Mithril.js 코어를 포함하는 Mithril.js hello world는 gzip으로 압축하면 약 10kb입니다.
또한 Angular 및 Mithril.js와 같은 프레임워크는 중요하지 않은 애플리케이션을 위해 설계되었으므로 Angular의 API 표면을 모두 사용하는 애플리케이션은 29kb만이 아닌 수백 kb의 프레임워크 코드를 다운로드해야 합니다.
업데이트 성능
업데이트 성능을 벤치마킹하는 데 유용한 도구는 Ember 팀에서 개발한 DbMonster입니다. 테이블을 최대한 빨리 업데이트하고 초당 프레임 수 (FPS)와 JavaScript 시간 (최소, 최대 및 평균)을 측정합니다. FPS 수는 브라우저 다시 그리기 시간과 setTimeout 클램핑 지연도 포함하므로 평가하기 어려울 수 있으므로 가장 의미 있는 숫자는 평균 렌더링 시간입니다. Angular 구현과 Mithril.js 구현을 비교할 수 있습니다. 두 구현 모두 순진합니다 (즉, 최적화 없음). 샘플 결과는 아래에 나와 있습니다.
| Angular | Mithril.js |
|---|---|
| 11.5 ms | 6.4 ms |
복잡성
Angular는 다양한 지시문과 서비스를 제공하여 Mithril.js보다 더 많은 도구를 제공하지만 훨씬 더 복잡합니다. Angular의 API 표면을 Mithril.js의 API 표면과 비교해 보십시오. 어떤 API가 더 이해하기 쉽고 요구 사항과 더 관련이 있는지 직접 판단할 수 있습니다.
Angular 2에는 이해해야 할 개념이 훨씬 더 많습니다. 언어 수준에서는 Typescript가 권장되는 언어이고, 그 외에도 바인딩, 파이프, "안전한 탐색 연산자"와 같은 Angular 특정 템플릿 구문도 있습니다. 또한 모듈, 컴포넌트, 서비스, 지시문 등과 같은 아키텍처 개념과 무엇을 사용하는 것이 적절한지 알아야 합니다.
학습 곡선
비슷한 조건에서 비교하면, Angular 2와 Mithril.js는 학습 곡선이 비슷합니다. 둘 다 컴포넌트가 아키텍처의 중심 측면이고 둘 다 합리적인 라우팅 및 XHR 도구를 가지고 있습니다.
그렇긴 하지만 Angular는 Mithril보다 배워야 할 개념이 훨씬 더 많습니다. Angular는 쉽게 구현할 수 있는 기능에 대해서도 Angular 특정 API를 제공합니다 (예: 복수화는 기본적으로 스위치 문이고, "필수" 유효성 검사는 단순히 동등성 검사 등입니다). Angular 템플릿에는 또한 Mithril.js에서 JavaScript가 기본적으로 수행하는 것을 에뮬레이션하기 위한 여러 계층의 추상화가 있습니다. Angular의 ng-if/ngIf는 사용자 정의 파서 및 _컴파일러_를 사용하여 표현식 문자열을 평가하고 어휘 범위를 에뮬레이션하는 _지시문_입니다. Mithril.js는 훨씬 더 투명하고 따라서 추론하기 쉽습니다.
문서
Angular 2 문서는 광범위한 소개 튜토리얼과 애플리케이션을 구현하는 또 다른 튜토리얼을 제공합니다. 또한 고급 개념, 치트 시트 및 스타일 가이드에 대한 다양한 가이드가 있습니다. 하지만 현재 API 참조는 개선될 여지가 많습니다. 여러 API가 문서화되지 않았거나 API를 사용할 수 있는 컨텍스트를 제공하지 않습니다.
Mithril.js 문서에는 소개 튜토리얼, 고급 개념에 대한 페이지, 입력/출력 유형 정보, 다양한 일반적인 사용 사례에 대한 예제, 오용 및 안티 패턴에 대한 조언이 포함된 광범위한 API 참조 섹션이 포함되어 있습니다. 또한 빠른 참조를 위한 치트 시트도 포함되어 있습니다.
Mithril.js 문서는 또한 웹 표준이 이제 더 큰 기존 라이브러리와 동등할 수 있음을 개발자에게 알리는 것이 적절한 실제 애플리케이션에서 일반적인 사용 사례에 대한 간단하고 실용적인 솔루션을 보여줍니다.
Vue
Vue는 Angular와 유사한 뷰 라이브러리입니다.
Vue와 Mithril.js는 많은 차이점이 있지만 몇 가지 유사점도 공유합니다.
- 둘 다 가상 DOM과 라이프사이클 메서드를 사용합니다.
- 둘 다 컴포넌트를 통해 뷰를 구성합니다.
Vue 2는 Snabbdom의 포크를 가상 DOM 시스템으로 사용합니다. 또한 Vue는 라우팅 및 상태 관리를 위한 도구를 별도의 모듈로 제공합니다. Vue는 Angular와 매우 유사하게 보이며 유사한 지시문 시스템, HTML 기반 템플릿 및 논리 흐름 지시문을 제공합니다. Angular와 다른 점은 컴포넌트의 데이터 트리에서 기본 메서드를 덮어쓰는 몽키 패칭 반응형 시스템을 구현한다는 것입니다 (반면 Angular 1은 더티 체킹 및 다이제스트/적용 주기를 사용하여 유사한 결과를 얻습니다). Angular 2와 유사하게 Vue는 HTML 템플릿을 함수로 컴파일하지만 컴파일된 함수는 Angular의 컴파일된 렌더링 함수보다 Mithril.js 또는 React 뷰와 더 유사합니다.
비슷한 조건에서 비교하면, Vue는 Angular보다 훨씬 작지만 Mithril.js만큼 작지는 않습니다 (Vue 코어는 gzip으로 압축하면 약 23kb이고 Mithril.js의 해당 렌더링 모듈은 gzip으로 압축하면 약 4kb입니다). 둘 다 유사한 성능 특성을 가지고 있지만 벤치마크는 일반적으로 Mithril.js가 약간 더 빠르다고 나타냅니다.
성능
다음은 각 프레임워크의 JavaScript 코드를 구문 분석하고 실행하는 데 걸리는 시간, 즉 라이브러리 로드 시간을 비교한 것입니다. 프레임워크 코드로만 구성된 스크립트의 첫 번째 줄에 console.time() 호출을 추가하고 마지막 줄에 console.timeEnd() 호출을 추가하여 측정했습니다. 참고로 2010년 PC 데스크톱에서 파일 시스템에서 실행되는 번들 스크립트에 수동으로 로깅 코드를 추가하여 얻은 20회 실행 중 최적 결과를 제시합니다.
| Vue | Mithril.js |
|---|---|
| 21.8 ms | 4.5 ms |
라이브러리 로드 시간은 애플리케이션이 장시간 열려 있지 않은 환경 (예: 모바일)에서 중요하며 캐싱 또는 기타 최적화 기술을 통해 개선할 수 없습니다.
업데이트 성능
업데이트 성능을 벤치마킹하는 데 유용한 도구는 Ember 팀에서 개발한 DbMonster입니다. 테이블을 최대한 빨리 업데이트하고 초당 프레임 수 (FPS)와 JavaScript 시간 (최소, 최대 및 평균)을 측정합니다. FPS 수는 브라우저 다시 그리기 시간과 setTimeout 클램핑 지연도 포함하므로 평가하기 어려울 수 있으므로 가장 의미 있는 숫자는 평균 렌더링 시간입니다. Vue 구현과 Mithril.js 구현을 비교할 수 있습니다. 두 구현 모두 순진합니다 (즉, 최적화 없음). 샘플 결과는 아래에 나와 있습니다.
| Vue | Mithril.js |
|---|---|
| 9.8 ms | 6.4 ms |
복잡성
Vue는 Angular에서 많은 영감을 받아 지시문, 필터, 양방향 바인딩, v-cloak 등 Angular의 여러 기능을 포함하고 있지만, 컴포넌트와 같이 React에서 영감을 받은 기능도 가지고 있습니다. Vue 2.0부터는 하이퍼스크립트/JSX 구문 (단일 파일 컴포넌트 및 다양한 webpack 기반 언어 트랜스파일레이션 플러그인 외에도)을 사용하여 템플릿을 작성할 수도 있습니다. Vue는 양방향 데이터 바인딩과 선택적 Redux와 유사한 상태 관리 라이브러리를 모두 제공하지만 Angular와 달리 스타일 가이드를 제공하지 않습니다. 한 가지 작업을 수행하는 여러 방법 접근 방식은 수명이 긴 프로젝트에서 아키텍처 파편화를 유발할 수 있습니다.
Mithril.js는 개념이 훨씬 적고 일반적으로 컴포넌트와 데이터 계층 측면에서 애플리케이션을 구성합니다. Mithril.js의 모든 컴포넌트 생성 스타일은 기본 JavaScript 기능만 사용하여 동일한 vnode 구조를 출력합니다. 언어에 의존하는 직접적인 결과는 도구가 적고 프로젝트 설정이 더 간단하다는 것입니다.
문서
Vue와 Mithril.js는 모두 좋은 문서를 가지고 있습니다. 둘 다 예제가 포함된 좋은 API 참조, 시작하기 위한 튜토리얼, 다양한 고급 개념을 다루는 페이지를 포함합니다.
하지만 Vue의 하나의 작업을 수행하는 여러 가지 방법 접근 방식으로 인해 일부 사항이 적절하게 문서화되지 않을 수 있습니다. 예를 들어 하이퍼스크립트는 매우 간략하게 설명되어 있습니다.
Mithril.js 문서는 일반적으로 주제가 Mithril의 범위를 벗어난 사항과 관련된 경우 지나치게 철저한 경향이 있습니다. 예를 들어 주제가 타사 라이브러리와 관련된 경우 Mithril.js 문서는 타사 라이브러리의 설치 프로세스를 안내합니다. Mithril.js 문서는 또한 웹 표준이 이제 더 큰 기존 라이브러리와 동등할 수 있음을 개발자에게 알리는 것이 적절한 실제 애플리케이션에서 일반적인 사용 사례에 대한 간단하고 실용적인 솔루션을 자주 보여줍니다.
Mithril.js의 튜토리얼은 또한 Vue보다 훨씬 더 많은 내용을 다룹니다. Vue 튜토리얼은 큰 핵심 API를 다루기 위해 여러 페이지를 거친 후 간단한 로컬 할 일 목록으로 끝납니다. Mithril.js의 10분 가이드는 API의 대부분을 다루고 서버에서 데이터를 가져오고 라우팅하는 것과 같은 실제 애플리케이션의 주요 측면까지 다룹니다. 그것으로 충분하지 않다면 더 길고 철저한 튜토리얼도 있습니다.